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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
