Re: [RFC] mac80211: Re-enable aggregation

[Johannes Berg <johannes@sipsolutions.net>]

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

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.

> > 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.
> 
> What to remind that iwl-agn-rs update rates scale out of band meaning
> TX packet doesn't bear the rate scale information. The reasoning
> behind is that appropriate rate is picked up when packet is ready to
> go on the air and not when it's somewhere deep in the queue.
> Otherwise it's regular multiretry algorithm.

Well, yeah, but the best thing we can do if we don't do it in firmware
is actually determining it at the point we stick the packet into the
queue. I wouldn't mind moving all iwl-agn rate scaling into the driver
and telling mac80211 that it doesn't need rate scaling, but I'm not
quite sure how this affects aggregation?

johannes

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