Re: WMM not working for mcast packets on ath10k

[Ben Greear <greearb@candelatech.com>]

On 8/11/20 7:36 AM, Ahmed Zaki wrote:
> On Tue, 11 Aug 2020 at 16:01, Ben Greear <greearb@candelatech.com> wrote:
>>
>> On 8/11/20 5:22 AM, Ahmed Zaki wrote:
>>> On Tue, 11 Aug 2020 at 01:05, Ben Greear <greearb@candelatech.com> wrote:
>>>>
>>>> On 8/10/20 3:08 PM, Ahmed Zaki wrote:
>>>>> Hello,
>>>>>
>>>>> I have 2 ath10k devices set in Mesh Point mode. When I use iptables'
>>>>> DSCP target to set the WMM AC for some traffic ports to VO, the rules
>>>>> work fine but only for unicast packets. All broadcast on the target
>>>>> UDP ports goes out as BE, and not VO.
>>>>>
>>>>> With some ath10k debugging enabled, it seems that the htt is indeed
>>>>> sending the tx descriptor with the correct tid (6) set.
>>>>>
>>>>> Is this the intended behavior for some reason? If not, is there any
>>>>> more debugging on the TX path that I can do?
>>>>
>>>> I don't think that WMM makes sense for bcast frames since they go out on
>>>> a special TID that does not do aggregation or per peer QoS settings.
>>>
>>> I get that, but we want to give some WMM priority to bcast as they tend to have
>>> higher probability of loss under high network loads.
>>>
>>> That special TID that you mentioned, is it set in the ath10k fw?
>>> Because I traced the
>>> htt and it is sending the intended tid in the txbuf flags, but bcast
>>> still come 0 (BE) on air.
>>> Or am I missing something in the driver?
>>>
>>> Thanks again for help.
>>
>> Maybe you can convert bcast to unicast in the driver/mac80211?  There are no retries
>> or proper rate-ctrl for bcast either, so I don't think you can get great performance
>> for bcast.
>>
> 
> The bcast that we want to send with higher WMM are kind of KEEPALIVES,
> small and
> infrequent but important for network stability. So, we do not care
> about aggregation, rate-ctrl
> or higher MCS, just lower probability of being missed. They are, by
> design, sent to all
> neighbors and cannot be sent as unicast.
> 
> Sorry to ask again, but without access to the fw I cannot know the
> answer to this: are you aware
> of anything in the fw that can override the tid sent from the driver
> if the destination is bcast?

There is no way to put bcast frames on the high priority queues.
If you run a sniffer near the transmitter, do you actually see that
your bcast frames are dropped before being put on air?

The ath10k driver probably has some tx status that indicates whether it
was dropped before being put on air as well...have you checked that?

You can send your frames more often if you want better chance of some
of them getting through.

Thanks,
Ben

> 
> Thanks,
> 


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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k