WMM not working for mcast packets on ath10k

[Ahmed Zaki]

On Tue, 11 Aug 2020 at 16:40, Ben Greear <greearb at candelatech.com> wrote:
>
> On 8/11/20 7:36 AM, Ahmed Zaki wrote:
> > On Tue, 11 Aug 2020 at 16:01, Ben Greear <greearb at candelatech.com> wrote:
> >>
> >> On 8/11/20 5:22 AM, Ahmed Zaki wrote:
> >>> On Tue, 11 Aug 2020 at 01:05, Ben Greear <greearb at 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.