On Mon, 2008-10-20 at 23:46 +0200, Tomas Winkler wrote: > > Immediate Block-Ack is mandatory for 11n, delayed BA is optional. > > ath9k currently maintains the BA window state internally too. > > Another candidate that can be moved to mac80211, IMO. > > > > TX or RX side? Both? What exactly does your firmware do, say of the list that Sujith posted? > >> 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. > > What you need is to compute how many frames can be transmitted within > TXOP i think we can provide the calculation > depending on the current state. Just with the retransmission down > scaling need to be taken into account. We really need TXOP handling in mac80211 anyway, no? Right now we won't handle frames that are too long for the TXOP, for example. > That > >> might leave Intel out a bit, but I'm starting to think that we want to > >> special-case them a bit anyway. > > Let's see first mvel and bcom implementation :) Like I said, from what I can tell bcom is really similar, and I'd like to not have to re-implement all this first. mac80211 used to have a more push-model, which we've deviated from with the HT stuff you did, but for most hardware the push-model is still appropriate, so imho we should try to go to one even with HT and then see. We've since reworked rate control to be able to cope with HT too, so mac80211 can have much more information about what's going on and should be able to make many of the necessary decisions. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
