Re: iwlwifi aggregation info

[Johannes Berg <johannes@sipsolutions.net>]

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

Had to think about this for a bit...

> > Right. Which brings us back to the original point, why does the hw need
> > to make the scheduling decision between agg and non-agg?
> 
> There is no scheduling between aag and legacy queue in the sense of
> qdisc .

Right. So why are you saying we should have a separate qdisc for it?

> The aggregation need to be taken from single stream as
> explained before,

I think we simply agree on that. Which brings me back to my original
point: to provide fairness within that stream we shouldn't have separate
qdiscs for agg/non-agg parts of the stream.

> Iwlwifi has HW support for it that that's the whole story we just need
> queueing support from the software buffering stopping and starting
> queue and last but not least there is a classification just an
> extension of the regular AC scheduling.  The fairness between legacy
> and agg queue must be provided by actually 'not scheduling'

I don't understand what you mean by "not scheduling". AIUI from the
specs, there is no scheduling between aggregation/non-aggregation
queues, or "within an AC" as I would say it.

Therefore, I think we should remove the extra software queues and split
up the single-AC stream into the different hardware queues in the
driver, to be reunited in the FIFOs.

> If you don't want to experiment but provide QoS by spec the scheduling
> is best to leave to HW.

I don't contend that only the hw is able to make QoS scheduling
decisions, as they depend on air access etc. after all.

johannes

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