Re: [RFC] mac80211: Re-enable aggregation

[Johannes Berg <johannes@sipsolutions.net>]

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

On Mon, 2008-10-20 at 16:05 +0530, Sujith wrote:

> > But couldn't non-HT frames be buffered similarly? Maybe I'm missing one
> > of the finer points of the 11n draft?
> 
> Probably because 11n aggregation have more rigorous timing requirements
> between frames.

What kind? I can only find the ampdu spacing/length exponent stuff.

> > I guess there's no clear answer here. How about "whichever you want"?
> > Though I think I prefer pushing them down as that makes the model easier
> > to understand. It probably also makes the Intel case easier to
> > implement.
> 
> A way to pull down buffered frames for each TID (like ieee80211_get_buffered_bc() )
> would be really useful for ath9k.

I'm not sure, that seems like a useful thing initially, but leaves a lot
of stuff for the driver. We should probably think about moving more
things *up* into mac80211 rather than giving the driver more access to
low-level details. This would also allow us possibly even send A-MPDU
mcast when acting as an HT AP, something the driver cannot easily do.

Can you explain the way it currently works in ath9k?

Also, I'm trying to understand the relation between a block-ack
agreement and A-MDPU, I understand that without a block-ack-agreement
aggregation isn't very useful, but could we not, for example, implement
(regular) delayed block-ack with much the same infrastructure?

What I could also imagine is that mac80211 simply does pretty much
everything and hands a number of skbs to the driver at once with some
additional information about how to aggregate them, what sort of spacing
to use, etc. It should be able to calculate all the required stuff since
it knows from the rate control algorithm what's happening there. That
might leave Intel out a bit, but I'm starting to think that we want to
special-case them a bit anyway.

johannes

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