On Tue, Sep 23, 2008 at 1:11 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
