Question on ath10k_mgmt_tx_flush

Ben Greear greearb at candelatech.com
Wed Apr 16 23:35:06 PDT 2014


On 04/16/2014 11:04 PM, Michal Kazior wrote:
> On 17 April 2014 03:03, Ben Greear <greearb at candelatech.com> wrote:
>> On 04/14/2014 11:41 PM, Michal Kazior wrote:
>>> On 14 April 2014 17:45, Ben Greear <greearb at candelatech.com> wrote:
>>>> On 04/13/2014 11:31 PM, Michal Kazior wrote:
>>>>> On 11 April 2014 15:25, Ben Greear <greearb at candelatech.com> wrote:
>>>>>> 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?
>>>>>
>>>>> You want to always skip the sleep between mgmt tx and flush commands?
>>>>> I'm afraid this won't work because tx flush command can end up with
>>>>> queued frame being dropped or transmitted regardless of destination
>>>>> station powersave state if submitted too soon.
>>>>
>>>> I just want to know if I can skip the sleep if we currently have 2 tx-credits.
>>>
>>> No, not really. At least not in any sane way I can think of.
>>
>> I managed to hack the firmware and ath10k today so I can get tx
>> rate reported (perhaps at least mostly correctly, even).  Since this
>> can only work with my firmware, patch was not sent to the list.
>>
>>
>> So, I'm back to working on this tx-flush issue again.
>>
>> I may not have been clear in my question above, as your answer makes no
>> sense to me :)
>>
>> My question is:  If the driver/firmware supports max of 2 tx-credits, and we currently
>> have 2 tx-credits available (ie, there are no pending things in firmware
>> because we have all credits available), then can we skip the sleep when
>> flushing?
>
> If you do mgmt_tx+flush without any wait you'll end up disregarding
> station powersave or drop frame before it is actually transmitted.
> With stock firmware there's no way to wait for wmi mgmt tx completion
> other than to sleep because tx credits are replenished in pairs. If
> you send a mgmt tx and don't flush you risk getting stuck with next
> mgmt tx at which point you can't even flush because you're out of
> credits.

Ok, I will try to fix that issue of credits being replenished in
pairs.  I have been following the twisty paths of the firmware, but
so far I cannot see why the problem should exist...

Thanks for the patience and details below..I think I'm getting
and understanding of the problem now...

Thanks,
Ben

>
>
>> Second question:  Assuming this is true, if I just make sure the firmware
>> returns all credits as soon as they are freed up, should that be good
>> enough to not waste any time sleeping during flush when we do not need
>> to flush?
>
> Yes, this is sufficient as a tx completion but is the most hacky way to do it.
>
>
>> And even with stock firmware, we should be able to skip the sleep at
>> least when we get lucky with current tx-credits-available count...
>
> I don't think you can do that.
>
> Even if you have 2 tx credits available and submit mgmt tx - what do
> you do from then on? You won't receive tx credit replenishment when
> the tx completes unless you submit flush or another mgmt tx. Flush can
> drop frames/disregard powersave and next mgmt tx can get stuck. You
> could try pushing dummy mgmt tx (spurious probe resp?) assuming it
> never gets stuck but that's way beyond an acceptable workaround..
>
> There really isn't any way other than to have a reliable tx completion
> indication so that wmi tx worker can flush mgmt frames if they take
> too long to complete.
>
> I'd be happy to proven wrong though.
>
>
> Michał
>


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




More information about the ath10k mailing list