Re: [RFC] mac80211: Re-enable aggregation

[Sujith <Sujith.Manoharan@atheros.com>]

Johannes Berg wrote:
> On Wed, 2008-10-22 at 13:59 +0200, Tomas Winkler wrote:
> 
> > It answers BA i n RX path and interpret BA in TX Scheduling
> > retransmission of not acked frames is done in HW (not firmware) no
> > need to requeue them. In corner case when retries are exhausted  BA
> > request is issued from mac80211 to advance RX side window.
> 
> Ok, but if we do both of that in mac80211, it wouldn't really matter
> since we never see the relevant frames, right? Or we can add a flag to
> ignore them.
> 
> > > 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.
> > 
> > Works for me. What I stumble upon is retransmission from within TX
> > response  path
> > how this go together with context of regular TX path. Even in iwlwifi
> > we need to be able to kick/start the internal aggregation queue?
> 
> Yeah, this is something we definitely need to work out. We haven't even
> managed to decide yet how aggregated packets are given to the driver :)
> I think for atheros and bcom a model where mac80211 decides pretty much
> everything and hands the driver a list of skbs to aggregate would work
> best, but then I think that wouldn't work with your hw at all.
> 

Retransmission of unacked frames is done within the driver, in ath9k.
In case of retry exhaustion (failed transmission), we do what Intel does,
i.e, request for a BAR to be sent out.

Sujith