On Tue, Feb 15, 2011 at 7:39 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2011-02-15 at 19:34 +0530, Vivek Natarajan wrote: >> On Tue, Feb 15, 2011 at 6:14 PM, Johannes Berg >> <johannes@xxxxxxxxxxxxxxxx> wrote: >> > >> > I've recently been thinking about this -- I'm thinking that maybe we >> > should change this behaviour. Right now the tx() routine basically >> > always returns OK (except in at76) and I suppose instead it could return >> > whether the frame was queued up successfully... >> > >> >> After some time interval, once again stop queues on receiving ack for >> >> nullfunc, configure the hw and then wake up queues. So, during the >> >> above time interval, there is a race of queuing a frame to the hw. I >> >> have tested this and the issue is quickly reproducible. >> > >> > Right. The code that sends the nullfunc -- I think it can probably >> > sleep? If so, instead of starting the queue for the TX it could just >> > flush TX again after sending the nullfunc -- after that either it had >> > status for the frame, or the frame was dropped, no? >> >> So, this requires changing all the drivers to return the status for >> tx() routine. > > Not necessarily. I think that if you do the flush() based approach, then > mac80211 can infer that the frame was dropped by not getting a TX status > during flush, right? Assuming there's reliable TX status to start with. > >> And this is how I understand this: >> stop queues, then send nullfunc, then do a flush to get the status and >> wake queues again irrespective of acked or not(but set the ACK_STATUS >> correspondingly). If tx() routine of nullfunc fails, then also wake >> the queues. > > Yes, but since the flush is there, the latter (tx fails, ...) won't be > needed. If queues are stopped before sending nullfunc, it is added in the pending frames queue and the flush after nullfunc is ineffective. So, is it okay to bypass this queue_stop check with REASON_PS if it is a nullfunc frame? Any more ideas will be helpful. Vivek. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
