On Fri, 2023-02-17 at 19:02 +0000, Ryder Lee wrote: > On Fri, 2023-02-17 at 19:53 +0100, Johannes Berg wrote: > > On Fri, 2023-02-17 at 18:43 +0000, Ryder Lee wrote: > > > On Fri, 2023-02-17 at 19:01 +0100, Johannes Berg wrote: > > > > On Sat, 2023-02-18 at 01:50 +0800, Ryder Lee wrote: > > > > > This allows low level drivers to refresh the tx agg session > > > > > timer, > > > > > based on > > > > > querying stats from the firmware usually. Especially for some > > > > > mt76 > > > > > devices > > > > > support .net_fill_forward_path would bypass mac80211, which > > > > > leads > > > > > to tx BA > > > > > session timeout for certain clients. > > > > > > > > > > > > > Does it even matter? We could just request sessions without a > > > > timeout > > > > in > > > > the first place. > > > > > > > > > > I think we're already. Our main issue is performance periodically > > > drops > > > every few seconds when .net_fill_forward_path is enabled. > > > Wireless > > > client have normal 500+ Mb/s iperf3 download speed for several > > > seconds. > > > Then it drops less than 100 Mb/s for several seconds. Then > > > everything > > > repeats. Issue occurs only on certain clients. (i.e. Intel cards > > > AX200, > > > AX1675, Advanced-N 6235 in Win11) > > > > > > > Strange. But how does this patch do anything about it, that should > > be > > completely client agnostic? > > > > > > Since there's no any keep alive packet being received by host stack, > leads to mac80211 destrory BA sesion. > More specifically, the BA session relies on client side's Tx data to maintain ... but the point is mac80211 can't get any data after .net_fill_forward_path being enabled (HW path). So, we need a way to notify mac80211 to refresh last_tx... I think my patch is needed for that case. Ryder
