management frames are lost during high load situations


From: Pedro Estrela (pedro.estrela_at_inesc.pt)
Date: 2002-10-16 13:32:25 UTC


Hello HostAP,

I'm having the following problem, which was NOT solved by using the latest 1.4.9 firmware.

Simply put, when the card is put in stress with a major downstream UDP flow
(greater than a flood ping), the AP is unable to process further
associations/reassociations. In this scenario, a station moving from one unloaded AP to a loaded AP will keep on sending associations until the load stops. (card details: NIC: id=0x8002 v1.0.1 , PRI: id=0x15 v0.3.0, STA: id=0x1f v0.8.0).

To try to solve this situation, i've tryed to insert an artificial busy loop on prism2_send_mgmt when the queue is full, to try to artificially wait until the interrupt appears that executes wake_queue() in IRQ context. However, my simple patch did not work as expected (see below both the patch and the resulting log).
Previouly, i was using a old (April) version of the driver with the maximum number of packets pending for transmition capped to a low value, by controlling TX and TX_EV events, and calling wake_queues/stop_queues. However, this solution incresases greatly the CPU usage, and also degrades maximum 802.11 throughtpt.

Any ideas on this particular problem?

MODIFICATION:
at the end of
static void prism2_send_mgmt(struct net_device *dev,

                             int type, int subtype, char *body,
                             int body_len, int txevent, u8 *addr)

...

#define MAX_BUSY_WAIT 1000

        {
                int count = 0;

                if (in_interrupt())
                        printk("ERROR: send_management IN INTERUPT \n" );

                if (netif_queue_stopped(dev)){
                        printk("netif_queue_stopped while sending management
packet. will probably be lost. \n" );
                        count = 0;
                        while( (count < MAX_BUSY_WAIT) &&

(netif_queue_stopped(dev))){
count++; udelay(100); if((count % 100) == 1) printk("waiting... count == %d \n", count ); } if (!netif_queue_stopped(dev)) printk("netif_queue was waked \n" ); if (count >= MAX_BUSY_WAIT) printk("TIMEOUT! %d \n", count ); } } /* FIX: is it OK to call dev_queue_xmit() here? This can be called
...

RESULT:
Oct 16 03:22:49 estrela kernel: netif_queue_stopped while sending

management packet. will probably be  lost.
Oct 16 03:22:49 estrela kernel: waiting... count == 1
Oct 16 03:22:49 estrela kernel: waiting... count == 101
Oct 16 03:22:49 estrela kernel: waiting... count == 201
Oct 16 03:22:49 estrela kernel: waiting... count == 301
Oct 16 03:22:49 estrela kernel: waiting... count == 401
Oct 16 03:22:49 estrela kernel: waiting... count == 501
Oct 16 03:22:49 estrela kernel: waiting... count == 601
Oct 16 03:22:49 estrela kernel: waiting... count == 701
Oct 16 03:22:49 estrela kernel: waiting... count == 801
Oct 16 03:22:49 estrela kernel: waiting... count == 901
Oct 16 03:22:49 estrela kernel: TIMEOUT! 1000 Oct 16 03:22:49 estrela kernel: wlan0: 00:02:2d:02:2c:dc auth (alg=0 trans#=1 stat=0 len=6fc=00b0) == > 0 (authenticated) ... repeat until load is stopped ...

This archive was generated by hypermail 2.1.4.