WMM not working for mcast packets on ath10k

WMM not working for mcast packets on ath10k

[Ahmed Zaki]

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?

Any help is appreciated. Thank you.

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

Re: WMM not working for mcast packets on ath10k

[Ben Greear]

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.

Thanks,
Ben

-- 
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

Re: WMM not working for mcast packets on ath10k

[Sebastian Gottschall]

Am 11.08.2020 um 01:05 schrieb Ben Greear:

> 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.
and in addition broadcast frames are transmitted with legacy rates (2 
mbit by default, but can be changed)
>
> Thanks,
> Ben
>

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

Re: WMM not working for mcast packets on ath10k

[Ahmed Zaki]

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.

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

Re: WMM not working for mcast packets on ath10k

[Ben Greear]

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.

Thanks,
Ben


-- 
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

Re: WMM not working for mcast packets on ath10k

[Ahmed Zaki]

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?

Thanks,

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

Re: WMM not working for mcast packets on ath10k

[Ben Greear]

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

Re: WMM not working for mcast packets on ath10k

[Ahmed Zaki]

On Tue, 11 Aug 2020 at 16:40, Ben Greear <greearb@candelatech.com> wrote:
>
> 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.
>

Yes, the sniffer shows the packets on air with BE and tid 0, although
for the same packets the ath10k debugging shows the intended tid.
Debugging logs do not show anything being dropped.

I was able to bump the WMM AC for broadcast with the ath9k, but it
seems that’s not doable with ath10k firmware.

Thanks for your help though.

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