[ath9k-devel] ath9k EDMA behaviour with TXOP?

[Adrian Chadd <adrian@freebsd.org>]

hi,

I've noticed something reasonably quirky with the AR9380 and later
EDMA engine and I'd like to see if anyone else has seen it with ath9k.

It /looks/ like the TXOP gating for burstTime (ie, WMM bursts) is
gated by a TX FIFO entry. Ie, if you queue 8 separate TX FIFO entries,
each with a single MPDU, then you end up only getting one frame per
burst window.

For TDMA it shows up as frames only going out every time I push new
frames into the FIFO. It's very .. odd.

Now, if I try /really hard/ to keep pushing groups of frames into the
FIFO (ie, a list of frames per TX FIFO slot) and I don't push a single
frame here and there in, I get reasonably consistent 30mbit
performance each way, which is what I'm expecting without A-MPDU or
A-MSDU aggregation.

But if I schedule say, 5 groups of 32 frames and then one frame, the
PCU/QCU doesn't seem to grant that queue any more airtime until I push
/another/ frame into the TX FIFO. Merely just hitting TXE for that
queue doesn't work - I have to push in more frames to keep it
immediately going rather than waiting for the next TXOP/gating time.

So, I have some local hacks that only push groups of X (where X is 16
atm) frames into TX FIFO slots to keep the engine happy and will only
push a shorter amount of frames into the TX FIFO if the FIFO itself is
empty. That gets the performance on part with TDMA on AR5416/AR9280,
which was the initial goal.

Ok, so with all of the above - has anyone seen this kind of behaviour
with ath9k? eg, doing lots of non-aggregate frames to some WMM burst
queue, like voice or video?

Thanks,

-adrian