[PATCH 1/2] wifi: mac80211: introduce ieee80211_refresh_tx_agg_session_timer()

[Ryder Lee]

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