From: "Tomas Winkler" <tomasw@gmail.com>
To: "Johannes Berg" <johannes@sipsolutions.net>
Cc: Friedrich.Beckmann@infineon.com, linux-wireless@vger.kernel.org, j@w1.fi
Subject: Re: iwlwifi aggregation info
Date: Fri, 1 Aug 2008 15:40:04 +0300 [thread overview]
Message-ID: <1ba2fa240808010540g660cdaa9p1158a27061e3fcd@mail.gmail.com> (raw)
In-Reply-To: <1217592554.8621.23.camel@johannes.berg>
On Fri, Aug 1, 2008 at 3:09 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> 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?
I need a sw queue 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.
You agree on the fact that it's a seperate stream but you still
doesn't want separate queue for it....
>> 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".
Not scheduling mean not string to prioritize streams in SW. I guess it means RR.
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.
Aggregation is a separate stream even on the air it has it's own
rhythm. For example
from AP perspective you an have 3 streams for the same TID for 3
stations. Each station
has it's own rate of processing aggregation stream. It may vary on
number of packets and size of the aggregation
this is determine in association time.
So shell I stop the whole AC queue just because on station is slower?
Tomas
next prev parent reply other threads:[~2008-08-01 12:40 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-29 11:32 iwlwifi aggregation info Johannes Berg
2008-07-29 11:36 ` Johannes Berg
2008-07-29 12:25 ` Tomas Winkler
2008-07-29 12:27 ` Johannes Berg
2008-07-29 12:35 ` Tomas Winkler
2008-07-29 12:53 ` Johannes Berg
2008-07-29 13:04 ` Tomas Winkler
2008-07-29 13:07 ` Johannes Berg
2008-07-29 13:18 ` Tomas Winkler
2008-07-29 13:23 ` Johannes Berg
2008-07-29 13:43 ` Tomas Winkler
2008-07-29 13:46 ` Johannes Berg
2008-07-29 14:06 ` Tomas Winkler
2008-07-29 14:21 ` Johannes Berg
2008-07-29 15:55 ` Tomas Winkler
2008-07-30 9:53 ` Johannes Berg
2008-07-30 11:03 ` Friedrich.Beckmann
2008-07-30 13:19 ` Johannes Berg
2008-07-30 13:45 ` Tomas Winkler
2008-07-30 13:50 ` Johannes Berg
2008-07-30 13:59 ` Tomas Winkler
2008-07-30 15:19 ` Johannes Berg
2008-07-30 16:08 ` Tomas Winkler
2008-07-31 13:05 ` Johannes Berg
2008-07-31 18:14 ` Tomas Winkler
2008-07-31 18:23 ` Johannes Berg
2008-07-31 19:16 ` Tomas Winkler
2008-08-01 12:09 ` Johannes Berg
2008-08-01 12:40 ` Tomas Winkler [this message]
2008-08-01 12:54 ` Johannes Berg
2008-08-06 21:45 ` Johannes Berg
2008-08-06 22:05 ` Tomas Winkler
2008-08-06 22:31 ` Tomas Winkler
2008-08-07 11:13 ` mac80211 aggregation (was: iwlwifi aggregation info) Johannes Berg
2008-08-07 12:21 ` Friedrich.Beckmann
2008-08-07 12:31 ` Johannes Berg
2008-08-07 13:00 ` Friedrich.Beckmann
2008-07-30 12:01 ` iwlwifi aggregation info Tomas Winkler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ba2fa240808010540g660cdaa9p1158a27061e3fcd@mail.gmail.com \
--to=tomasw@gmail.com \
--cc=Friedrich.Beckmann@infineon.com \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox