* WMM not working for mcast packets on ath10k @ 2020-08-10 22:08 Ahmed Zaki 2020-08-10 23:05 ` Ben Greear 0 siblings, 1 reply; 8+ messages in thread From: Ahmed Zaki @ 2020-08-10 22:08 UTC (permalink / raw) To: ath10k; +Cc: ahmed nader 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: WMM not working for mcast packets on ath10k 2020-08-10 22:08 WMM not working for mcast packets on ath10k Ahmed Zaki @ 2020-08-10 23:05 ` Ben Greear 2020-08-11 12:14 ` Sebastian Gottschall 2020-08-11 12:22 ` Ahmed Zaki 0 siblings, 2 replies; 8+ messages in thread From: Ben Greear @ 2020-08-10 23:05 UTC (permalink / raw) To: Ahmed Zaki, ath10k 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: WMM not working for mcast packets on ath10k 2020-08-10 23:05 ` Ben Greear @ 2020-08-11 12:14 ` Sebastian Gottschall 2020-08-11 12:22 ` Ahmed Zaki 1 sibling, 0 replies; 8+ messages in thread From: Sebastian Gottschall @ 2020-08-11 12:14 UTC (permalink / raw) To: ath10k 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: WMM not working for mcast packets on ath10k 2020-08-10 23:05 ` Ben Greear 2020-08-11 12:14 ` Sebastian Gottschall @ 2020-08-11 12:22 ` Ahmed Zaki 2020-08-11 14:01 ` Ben Greear 1 sibling, 1 reply; 8+ messages in thread From: Ahmed Zaki @ 2020-08-11 12:22 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: WMM not working for mcast packets on ath10k 2020-08-11 12:22 ` Ahmed Zaki @ 2020-08-11 14:01 ` Ben Greear 2020-08-11 14:36 ` Ahmed Zaki 0 siblings, 1 reply; 8+ messages in thread From: Ben Greear @ 2020-08-11 14:01 UTC (permalink / raw) To: Ahmed Zaki; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: WMM not working for mcast packets on ath10k 2020-08-11 14:01 ` Ben Greear @ 2020-08-11 14:36 ` Ahmed Zaki 2020-08-11 14:39 ` Ben Greear 0 siblings, 1 reply; 8+ messages in thread From: Ahmed Zaki @ 2020-08-11 14:36 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: WMM not working for mcast packets on ath10k 2020-08-11 14:36 ` Ahmed Zaki @ 2020-08-11 14:39 ` Ben Greear 2020-08-12 13:09 ` Ahmed Zaki 0 siblings, 1 reply; 8+ messages in thread From: Ben Greear @ 2020-08-11 14:39 UTC (permalink / raw) To: Ahmed Zaki; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: WMM not working for mcast packets on ath10k 2020-08-11 14:39 ` Ben Greear @ 2020-08-12 13:09 ` Ahmed Zaki 0 siblings, 0 replies; 8+ messages in thread From: Ahmed Zaki @ 2020-08-12 13:09 UTC (permalink / raw) To: Ben Greear; +Cc: ath10k 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-08-12 13:09 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-10 22:08 WMM not working for mcast packets on ath10k Ahmed Zaki 2020-08-10 23:05 ` Ben Greear 2020-08-11 12:14 ` Sebastian Gottschall 2020-08-11 12:22 ` Ahmed Zaki 2020-08-11 14:01 ` Ben Greear 2020-08-11 14:36 ` Ahmed Zaki 2020-08-11 14:39 ` Ben Greear 2020-08-12 13:09 ` Ahmed Zaki
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.