Re: [RFC] mac80211: Re-enable aggregation

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

On Mon, 2008-10-20 at 14:28 +0530, Sujith wrote:
> Johannes Berg wrote:
>  >  

Can you change your quote string from " > " to "> "? Just asking, if you
can't/don't want to that's fine, it just always confuses me for a
second. I really should try to figure out if I can convince my mailer to
highlight " > " indented text as quote too.

> Well, currently ath9k maintains a buffer list for each tid.
> When mac80211 sends down a frame, if the recipient has an aggr. session going,
> it is appended to the tid's buffer list. Non-HT frames are sent out immediately.

Incidentally, why the distinction between HT and non-HT frames?

> On TX completion, we run through all the ACs, STAs and TIDs and send out pending
> frames as aggregates.

So basically you can always have one frame or one aggregation
"pack" (for lack of a better word) queued to the hw?

> IMO, this is heavy stuff for a driver.

Yeah most of it probably is.

> mac80211 can probably help by maintaining the TX state for each TID, maintain the
> buffer list, etc.  and provide appropriate mechanisms for drivers to obtain pending
> frames as and when needed.

Sure could. Intel's hw would probably like a way to say "stop this TID"
and "wake this TID" which is what they tried to do using real queues.
mac80211 could queue up the frames in per-station state and provide a
functions like

ieee80211_stop_aggr_stream(struct ieee80211_sta *sta, u8 tid);
ieee80211_wake_aggr_stream(struct ieee80211_sta *sta, u8 tid);

or something like that. Then those frames would flow into the right
queue. We might need a multi-layer start/stop management but we already
do, we've just managed to get away without it without tx stalls. Or they
just haven't been reported yet.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]