Re: Regarding .wake_tx_queue() model

[Maxime Bizon <mbizon@freebox.fr>]

On Tuesday 05 May 2020 à 18:50:45 (+0200), Toke Høiland-Jørgensen wrote:

> This seems like a bad idea; we want the TXQ mechanism to decide which
> frame to send on wakeup.

.release_buffered_frames() is only needed/used if STA went into
powersave while packets were already sitting inside txqi, that's an
edge case.

In the other much more common case (STA went into sleep without any
traffic pending in txqi), then the "classic" ps delivery code is used:
frames gets pulled from ps_tx_buf queue (1 by 1 for ps poll, more for
uapsd), and those frames ends up being sent through drv_tx(), since
they have the flag IEEE80211_TX_CTRL_PS_RESPONSE so they bypass txqi.

so I was just looking at removing that edge case, sending those frames
back to ps_tx_buf() from the driver.


> really is no way around having a way to instruct the driver "please use
> these flags for the next N frames you send" - which is what
> release_buffered_frames() does. What you're suggesting is basically
> turning off this 'pull mode' for the frames buffered during PS and have
> mac80211 revert to push mode for those, right? But then you lose the
> benefits of pull mode (the TXQs) for those frames.

I just want to give those back to mac80211, those frames were already
in push mode anyway.

> I remember Johannes talking about a 'shim layer' between the mac80211
> TXQs and the 'drv_tx()' hook as a way to bring the benefits of the TXQs
> to the 'long tail' of simple drivers that don't do any internal
> buffering anyway, without having to change the drivers to use 'pull
> mode'. Am I wrong in thinking that mwl8k may be a good candidate for
> such a layer? From glancing through the existing driver it looks like
> it's mostly just taking each frame, wrapping it in a HW descriptor, and
> sticking it on a TX ring?

maybe with the current firmware interface, but with the new one
aggregation is done on host side, so tx path is no more that simple.

-- 
Maxime