On Tue, Jan 15, 2013 at 5:36 PM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote: > On 2013-01-15 11:20 AM, Krishna Chaitanya wrote: >> Hi Johannes, >> >> Is there any work in progress/planned related to Tx AMSDU logic in mac80211? >> Even though only Rx is mandatory, but to test the Rx we need the Tx. >> >> I see that the support is there in mwifiex(marvell's) driver. So is >> there any patent/legal issue before we can implement one? > The issue with AMSDU Tx is a technical one, not a legal one: A-MSDU > aggregation needs a queue and some buffering to properly work, A-MPDU > needs the same. A-MPDU is typically implemented in the driver/firmware. > > Doing extra buffering/queueing in mac80211 is not a good idea, as it > would add significant extra latency in the Tx path, so A-MSDU > aggregation really needs to be done on the same queue. > > For implementing A-MSDU in ath9k, my plan is to share the per-sta-tid > A-MPDU driver queues between mac80211 and ath9k. That way I can keep the > logic inside mac80211 with no added buffering/latency. I might even be > able to have an A-MSDU aggregation fastpath that happens before 802.11 > header encapsulation. > > The problem with this approach is that it doesn't work with drivers > using hardware/firmware based A-MPDU aggregation. Such drivers will > probably either have to do A-MSDU in firmware as well, or > > - Felix Thanks Felix for the inputs. I suggest we can have a Tx AMSDU in mac80211 for only *Testing Purposes* of Rx AMSDU where we do not care about the performance implications. But for commercial use drivers/firmware can handle the same. -- 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
