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

[Ryder Lee]

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