On 10.02.24 15:55, Toke Høiland-Jørgensen wrote:
Felix Fietkau <nbd@xxxxxxxx> writes:Excessive broadcast traffic with little competing unicast traffic can easily flood hardware queues, leading to throughput issues. Additionally, filling the hardware queues with too many packets breaks FQ for broadcast data. Fix this by enabling AQL for broadcast packets. Signed-off-by: Felix Fietkau <nbd@xxxxxxxx> --- include/net/cfg80211.h | 1 + net/mac80211/debugfs.c | 19 +++++++++++++++---- net/mac80211/ieee80211_i.h | 2 ++ net/mac80211/main.c | 1 + net/mac80211/sta_info.c | 21 ++++++++++----------- net/mac80211/tx.c | 14 +++++++------- 6 files changed, 36 insertions(+), 22 deletions(-) diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index a499bd7e1def..2f280c629aea 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -3385,6 +3385,7 @@ enum wiphy_params_flags { /* The per TXQ device queue limit in airtime */ #define IEEE80211_DEFAULT_AQL_TXQ_LIMIT_L 5000 #define IEEE80211_DEFAULT_AQL_TXQ_LIMIT_H 12000 +#define IEEE80211_DEFAULT_AQL_TXQ_LIMIT_BC 50000How did you arrive at the 50 ms figure for the limit on broadcast traffic? Seems like quite a lot? Did you experiment with different values?
Whenever a client is connected and in powersave mode, all multicast packets are buffered and sent after the beacon. Because of that I decided to use half of a default beacon interval.
- Felix
