Question on ath10k_mgmt_tx_flush

[Ben Greear]

On 04/10/2014 10:21 PM, Michal Kazior wrote:
> On 10 April 2014 15:41, Ben Greear <greearb at candelatech.com> wrote:
>> Can we optimize this method to return early if the tx-credits
>> are fully replenished (ie, == 2) instead of just sleeping the
>> 2 x beacon-interval?  That would indicate all messages
>> have been flushed, right?
>
> Yeah. You're _almost_ right. Every odd mgmt frame will trigger tx
> credit replenishment, even if you set NEEDS_CREDITS htc tx flag for
> all packets. It seems that tx credits aren't replenished until you
> submit an even number of mgmt tx:
>
>   [tx credits =2]
>   vdev create [-1, =1]
>   [replenish +1, =2]
>   mgmt tx [-1, =1]
>   [frame is seen on air, means it left tx queue, but no replenishment]
>   vdev set param [-1, =0]
>   [replenish +1, =1]
>   mgmt tx [-1, =0]
>   [frame seen on air]
>   [replenish +2, =2]
>
> However once you flush peer tids you get the tx credit immediately.
> This means you don't ever reach having 2 mgmt tx consuming 2 tx
> credits (unless things go terribly terribly wrong at which point it's
> probably already beyond help).
>
> A very ugly hack would be to try and send out mgmt tx in pairs - a
> requested frame and a dummy frame (such that firmware will not buffer
> it) so that you use tx credit replenishment as tx completion
> indication.

If you ignore how firmware replenishes the tx-credits for now,
is it safe to assume that if you have 2 tx-credits while in
the flush routine, then everything is indeed flushed and
we can skip the sleep?

I imagine both I and the QCA firmware guys can make the
firmware properly replenish tx-credits one at a time instead
of the only-on-even/odd behaviour you found.

But even without that, we might be able to speed up the
flush 1/2 of the time?

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com