[rt2x00-users] [PATCH 7/7] rt2x00: Fix WMM Queue naming

[Helmut Schaa]

Hi Johannes,

Am Donnerstag, 9. Dezember 2010 schrieb Johannes Stezenbach:
> On Thu, Dec 09, 2010 at 10:07:05AM +0100, Helmut Schaa wrote:
> > On Wed, Dec 8, 2010 at 5:46 PM, Johannes Stezenbach <js at sig21.net> wrote:
> > >
> > > And then there are the AC_ parameters, which is not clear how they
> > > are selected.  Since there are more endpoints (6) than ACs (4),
> > > it doesn't look like there is a 1:1 mapping, right?
> > 
> > Correct, it is no 1:1 mapping. 4 of the queues can be individually configured
> > (through WMM_*_CFG), thus these are the queues used for AC_*. There are
> > two additional (DMA) queues (MGMT and HCCA), not sure if these can be
> > configured as well, I haven't found an appropriate register yet ...
> 
> OK, you believe that WMM_*_CFG_*0 corresponds with DMA queue/endpoint 0.

Yep ;)

> But this does not make sense with the additional "HCCA" DMA queue / endpoint,
> since you would put packets with varying AC into this queue, right?

Good point, haven't investigated in that direction much yet.

> > > There is an EDCA_TID_AC_MAP register (without any comments), which suggests
> > > the AC is derived from the TID from the 802.11 QoS Control field.
> > 
> > I don't think that is true. The current mechanism to put the frames into the
> > according DMA queues seems to work as expected. At least in a RF environment
> > with a log of STAs transmitting "ping -Q 0 x" has (on an average) worse timing
> > then using "ping -Q 240 x" for example. So, frames put into AC_* get the
> > correct channel access parameters assigned and thus get a higher or lower
> > probability of obtaining access to the media.
> > 
> > => I guess the currently used approach seems to behave correctly.
> 
> In my testing environment I could net see any difference between
> "ping -Q 0 x" and "ping -Q 240 x".

Hmm, really? You have to be in a real crowded place to see the difference but
on an average the -Q 240 frames have a lower latency then the -Q 0 frames.
JFI I only tested with rt2800pci, you're on USB right?

> I wanted to hack rt2x00mac_tx()
> to force qid = 0 and see whether there's still a difference.
> If yes, it would indicate the hw looks at the packet's QoS field.

The QoS field should be setup correctly by mac80211 already, so just
give it a try.

[...]

> OK, my theory of how the hardware works:
> 
> The hw will fetch packets from the highest prio DMA queue
> first, and will only fetch packets from the lower prio queues
> if the higher ones are empty or blocked. Packets are then put into the
> queue selected by the QSEL TXINFO field.
> 
> a) even if 100 data frames are queued with AC_BE, a MGMT
>    frame (or AC_VO) can be fetched by DMA immediately

That was my initial question. If higher priority queues are really
treated differently within the hw or if the queues are scheduled
round-robin-like. And yes, if some queues get precedence over others
we would have remap mac80211 QID to rt2x00 QID.

> b) however, if all frames use QSEL=2, the MGMT frame
>    cannot be sent until the AC_BE frames in the hw queue 2
>    are sent (it's not clear to me how many frames can be
>    in that queue); thus I believe we should use QSEL=0
>    for MGMT frames

The spec talks about a maximum queue depth of 7 for queue 1 and 20 for queue 2
but nothing about queue 0.

I have no objection against using QSEL=0 for MGMT frames __but__ since we only
use 4 queues between mac80211 and rt2x00 we cannot simply decide to move all
MGMT frames to a different queue. IMO if we really want to handle management
frames differently we need to tune mac80211 to also use an additional MGMT
queue. The decision which queue to use should not be in rt2x00 but solely in
mac80211, moving frames to other queues based on the frame contents can (but
must not) cause frame reordering ...

> c) for data frames, if they are all sent via hw queue 2,
>    it seems a AC_BK frame at the head of the hw queue can block
>    the following higher prio packet if there currently is no
>    TXOP for AC_BK but one for other AC.

Yep, I guess that would happen ;)

> d) the "There are 6 bulk out EP. EP6 highest priority" comment from
>    the legacy driver suggests EP0 has lowest prio, thus we
>    are using them the wrong way round
>    (but the driver also has "#define MGMTPIPEIDX 0" thus it is not
>    clear which one is right)
> 
> It would be very nice if Ralink could confirm which theory is
> correct.

Very appreciated.

Thanks,
Helmut