Hi, > It doesn't, but softmac tries to send 2 separate frames in quick > succession when associating, the second of which is a probereq (haven't > looked at the first), and the first one hasn't had quite enough time to > complete at that point.
Ah ok. The second one should only come in after a receive though, or maybe it is resending the packet.. doubt that though. > Interesting idea. netif_stop_queue() is called at the start of the TX > function, and netif_wake_queue() is called when the entire transmission > has been completed. netif_queue_stopped() can be called at any point to > determine whether the queue is running. Right. I was just wondering if there was a completion in the network layer for netif_wake_queue() :) > Maybe we should lose the is_queue_running hook and simply just use the > netif queue as detailed above. Then we could provide softmac wrappers > around those functions. Probably. > That way, when softmac_netif_queue_wake() is called, we can first > transmit the internal softmac packets which were previously suspended, > and when they are done, softmac_netif_queue_wake() can call the real > netif_queue_wake(). > > Does that sound sensible? That way we won't need the completion in any case :) > Will any softmac developers be at the summit? Yes, I'll be there. johannes
signature.asc
Description: This is a digitally signed message part
