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:
signature.asc
Description: This is a digitally signed message part
