[ath9k-devel] ath9k EDMA behaviour with TXOP?

[ath9k-devel] ath9k EDMA behaviour with TXOP?

[Adrian Chadd]

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

[ath9k-devel] ath9k EDMA behaviour with TXOP?

[Adrian Chadd]

On 9 June 2016 at 19:56, Adrian Chadd <adrian@freebsd.org> wrote:
> 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.
>

So it looks like it's not specifically TXOP gating, but it's frame
scheduling gating and chantime gating. I need to go see what's going
on in more detail.

Ie, if I have a TXOP burst with lockout and it's frame scheduling is
beacon gated (eg, like CAB queue is setup) then only one TX FIFO entry
seems to get ungated, and then things stay locked out. If I'm pushing
frames into the queue then things seem to get serviced, but if the
queue is full then nothing extra gets serviced.



-adrian