Re: [RFC] mac80211: Re-enable aggregation

[Johannes Berg <johannes@sipsolutions.net>]

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

On Wed, 2008-10-22 at 13:41 +0200, Tomas Winkler wrote:

> >> * mac80211 sends down a frame
> >>    * Initiate an aggregation session for the <RA,TID> if one isn't already in progress.
> >
> > It seems that should be a rate control decision? Possibly taking into
> > account more than just always doing aggregation sessions. Then again, I
> > suppose aggregation sessions are cheap. What about latency here?
> 
> Aggregation has it's overhead, both computing resources and on the
> air. Obvious that it has negative affect on latency so if the 'minimum
> HW queue depth'  is not satisfied the  packets
> are delayed till the queue is full enough.

That would be "do I have enough frames to aggregate them"?

> In iwl-agn-rs scale we keep track of  current tpt to take decision
> about starting aggregation. The throughput watch  can be viewed as
> different entity it was just convenient and conceptually fit  to
> incorporate into rate scale.

Sure, that kinda makes sense. The RC algorithm is conceptually
responsible for making sure things go as fast as possible :)

> > Obviously. But why isn't this done in parallel? I mean, why not send out
> > the frame and do addba and don't aggregate until addba was successful,
> > that would mean no latency for those frames... addba could even time out
> > which would add a lot of latency, no?
> 
> The negotiation is done on starting sequence number.

Ah, good point.

johannes

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