Progress on aggregation
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
Quoted 4 lines · 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.
Quoted 8 lines
* iwl4965 has been tested to work
* ath9k *does* xmit aggregate frames but throughput is lowSince 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
Quoted 15 lines · Luis R. Rodriguez
Quoted 4 lines · 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.Quoted 8 lines
* iwl4965 has been tested to work
* ath9k *does* xmit aggregate frames but throughput is lowSince 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.
Quoted 7 lines
Also, we currently handle aggregation buffering internally in our driver so the whole
amdpu_queuestuff 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 theampdu_queuesrepresent 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
Quoted 24 lines · Johannes Berg
Quoted 15 lines · Luis R. Rodriguez
Quoted 4 lines · 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.Quoted 8 lines
* iwl4965 has been tested to work
* ath9k *does* xmit aggregate frames but throughput is lowSince 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.Quoted 7 lines
Also, we currently handle aggregation buffering internally in our driver so the whole
amdpu_queuestuff 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 theampdu_queuesrepresent 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?
Quoted 3 lines
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