On Mon, 2023-02-20 at 02:55 +0000, Ryder Lee wrote: > 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 Typo... I mean *our side*. Something like this ieee80211_8023_xmit() if (tid_tx->timeout) tid_tx->last_tx = jiffies; Ryder
