[Make-wifi-fast] [RFC 1/3] mac80211: Add TXQ scheduling API
johannes at sipsolutions.net
Tue Oct 10 12:05:55 EDT 2017
> In particular, I'm not sure what the right thing to do in regards to
> PS wakeup is...
Can you explain what you were _trying_ to do?
I don't like calling this "driver_buffered" because that's already a
term for frames that are buffered in the driver ... :-)
PS is complicated, we basically transmit, in the following order:
* filtered frames (tx_filtered)
* buffered frames (ps_tx_buf)
* regular frames
This is when we _leave_ powersave. When we deliver frames while the
station is sleeping (PS-Poll or U-APSD), they don't even go through the
TXQ. They still come from this place, but currently go directly to the
->tx() method, which to me is actually pretty weird but that's what it
As I think I said in my other thread, we should probably eventually
just get rid of ps_tx_buf entirely, instead just keeping the frames on
the TXQ. Then, filtered can just be pushed onto txqi->frags [*], and we
get rid of having that separately as well.
Then, we've completely solved the wakeup scenario, we just start
scheduling that TXQ normally again.
For the deliver-while-sleeping (PS-Poll/U-APSD) scenario, I think the
driver should still pull frames, after calling something like
drv_release_buffered_frames(). We want this to be scheduled pretty much
immediately, so we shouldn't just put the TXQ into the normal rotation,
but otherwise it should work similarly - except limited to a certain
number of frames [**].
In this case the driver probably needs to pull the frames using a
different function so that we can
a) tag the packets properly (more-data, EOSP)
b) generate nulldata as EOSP container where needed
Thus, it seems likely that we'll want a separate function, "pull for PS
delivery" rather than the normal ieee80211_tx_dequeue().
[*] ok not exactly, if there are frags there already things get messy.
but we can probably solve that somehow without needing more special
More information about the Make-wifi-fast