Date: Fri, 17 Jun 2011 19:27:39 +0800 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Subject: Direct-dispatching addba frames and to the correct hardware queue? Message-ID: <BANLkTi=k8iKMzF6JwGNEG_DsrvM5j79atg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi, I've found that all the HT action frames are assigned to the WME priority 3 (voice). This means they'll go out in a different hardware queue in ath(4) than any pre-aggregation frames queued to the hardware. So the ADDBA frame appears before some of the already-queued frames. Frames in the ath software TX queue can be held, but those in the hardware queue can't. I've added a hack to my branch that rewrites the priority on ADDBA frames, and also marks them as direct dispatch to the hardware rather than stuffed in the software queue. But I'd rather this be done in the net80211 stack. So the questions! * Should the stack be throwing the action frame(s) for a given TID onto the right hardware queue? * Should there be an ieee80211_param flag that says "don't software queue, please just send straight through thanks?" for things like action frames that should behave as above? * Should the ADDBA (and DELBA) TX be split out from the actual status change so the driver can actually say when the frames go out? Ie, the driver can wait for all pending packets to the given node in the relevant TID to have gone out before completing the ADDBA transaction. I'm not sure yet about DELBA as I haven't yet gotten to implementing it. :-) I don't mind leaving this dirtiness in the ath(4) code I'm working on for now until we've figured out a cleaner option, so there's no rush to figure it out. Thanks, Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=k8iKMzF6JwGNEG_DsrvM5j79atg>