Progress on aggregation

Progress on aggregation

[Luis R. Rodriguez]

Just a quick note on the progress of aggregation. It works but we still
need to hanld the rtnl_lock() in a sane way. Johannes we proposing we
use a workqueue for this.

* iwl4965 has been tested to work
* ath9k *does* xmit aggregate frames but throughput is low

Since ath9k still needs some work we are looking into it.
Tomas, have you had a chance to consider the workqueue usage
for the rtnl_lock()? I figure to leave that to you as we
are still looking into the throughput issues with aggreation with
ath9k.

  Luis

Re: Progress on aggregation

[Luis R. Rodriguez]

On Mon, Sep 22, 2008 at 10:41 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> Just a quick note on the progress of aggregation. It works but we still
> need to hanld the rtnl_lock() in a sane way. Johannes we proposing we
> use a workqueue for this.
>
> * iwl4965 has been tested to work
> * ath9k *does* xmit aggregate frames but throughput is low
>
> Since ath9k still needs some work we are looking into it.
> Tomas, have you had a chance to consider the workqueue usage
> for the rtnl_lock()? I figure to leave that to you as we
> are still looking into the throughput issues with aggreation with
> ath9k.

Also, we currently handle aggregation buffering internally in our
driver so the whole amdpu_queue stuff is not required for us as we
don't have internal aggregation schedulers in hardware. For now we'll
use it though as we just want to get it working and for 2.6.27 we have
not alternative. For us, what will the ampdu_queues represent then? We
don't exactly have a limit on this except for the standard limitations
of 16 TIDs per station so what do you recommend to set this to?

  Luis

Re: Progress on aggregation

[Johannes Berg]

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

On Mon, 2008-09-22 at 12:33 -0700, Luis R. Rodriguez wrote:
> On Mon, Sep 22, 2008 at 10:41 AM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
> > Just a quick note on the progress of aggregation. It works but we still
> > need to hanld the rtnl_lock() in a sane way. Johannes we proposing we
> > use a workqueue for this.
> >
> > * iwl4965 has been tested to work
> > * ath9k *does* xmit aggregate frames but throughput is low
> >
> > Since ath9k still needs some work we are looking into it.
> > Tomas, have you had a chance to consider the workqueue usage
> > for the rtnl_lock()? I figure to leave that to you as we
> > are still looking into the throughput issues with aggreation with
> > ath9k.
> 
> Also, we currently handle aggregation buffering internally in our
> driver so the whole amdpu_queue stuff is not required for us as we
> don't have internal aggregation schedulers in hardware. For now we'll
> use it though as we just want to get it working and for 2.6.27 we have
> not alternative. For us, what will the ampdu_queues represent then? We
> don't exactly have a limit on this except for the standard limitations
> of 16 TIDs per station so what do you recommend to set this to?

You've only enabled STA mode (and maybe IBSS but there it rarely
matters) so anything like 8-16 would probably be fine.

johannes

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

Re: Progress on aggregation

[Tomas Winkler]

On Tue, Sep 23, 2008 at 1:11 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2008-09-22 at 12:33 -0700, Luis R. Rodriguez wrote:
>> On Mon, Sep 22, 2008 at 10:41 AM, Luis R. Rodriguez
>> <lrodriguez@atheros.com> wrote:
>> > Just a quick note on the progress of aggregation. It works but we still
>> > need to hanld the rtnl_lock() in a sane way. Johannes we proposing we
>> > use a workqueue for this.
>> >
>> > * iwl4965 has been tested to work
>> > * ath9k *does* xmit aggregate frames but throughput is low
>> >
>> > Since ath9k still needs some work we are looking into it.
>> > Tomas, have you had a chance to consider the workqueue usage
>> > for the rtnl_lock()? I figure to leave that to you as we
>> > are still looking into the throughput issues with aggreation with
>> > ath9k.
>>
>> Also, we currently handle aggregation buffering internally in our
>> driver so the whole amdpu_queue stuff is not required for us as we
>> don't have internal aggregation schedulers in hardware. For now we'll
>> use it though as we just want to get it working and for 2.6.27 we have
>> not alternative. For us, what will the ampdu_queues represent then? We
>> don't exactly have a limit on this except for the standard limitations
>> of 16 TIDs per station so what do you recommend to set this to?
>
> You've only enabled STA mode (and maybe IBSS but there it rarely
> matters) so anything like 8-16 would probably be fine.
>
TIDs 8-16 are reserved for HCCA and nobody implements this. In
addition you probably won't aggregate voice TIDs as aggregation impose
great delay, so 5 is only reasonable numbers for aggregation.
Aggregation for IBSS is not in the spec, it's rather cumbersome to support.

Anyhow in theory you need #supported sta * 8/16 queues, where in STA
mode it's 1 * 16 = 16 in AP mode it can goes to hundreds queues. In
practice you cannot push so much traffic on one channel.  I don't have
any statistics in hand what is maximal effective number of concurrent
aggregations on the air but I guess is up to 10.

I've did some first implementation with work item (start ba session)
but it start to look more massive change....I will send the rfc

Tomas