[Make-wifi-fast] [RFC 1/3] mac80211: Add TXQ scheduling API

[Johannes Berg]

> 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
is now.

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().

johannes

[*] ok not exactly, if there are frags there already things get messy.
    but we can probably solve that somehow without needing more special
    cases