* Tx AMSDU Support @ 2013-01-15 10:20 Krishna Chaitanya 2013-01-15 11:23 ` Johannes Berg 2013-01-15 12:06 ` Felix Fietkau 0 siblings, 2 replies; 10+ messages in thread From: Krishna Chaitanya @ 2013-01-15 10:20 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless, nbd 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? Regards, Chaitanya T K. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Tx AMSDU Support 2013-01-15 10:20 Tx AMSDU Support Krishna Chaitanya @ 2013-01-15 11:23 ` Johannes Berg 2013-01-16 4:09 ` Krishna Chaitanya 2013-01-15 12:06 ` Felix Fietkau 1 sibling, 1 reply; 10+ messages in thread From: Johannes Berg @ 2013-01-15 11:23 UTC (permalink / raw) To: Krishna Chaitanya; +Cc: linux-wireless, nbd Hi, > Is there any work in progress/planned related to Tx AMSDU logic in mac80211? At some point Felix was planning to look at this, but I don't think he ever did. I guess he'll correct me if I'm wrong. > 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? I'm not aware of any issue. You could probably even take some of that code and make it some generic cfg80211 helper library for use by both mwifiex and mac80211. johannes ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Tx AMSDU Support 2013-01-15 11:23 ` Johannes Berg @ 2013-01-16 4:09 ` Krishna Chaitanya 2013-01-16 23:05 ` Adrian Chadd 0 siblings, 1 reply; 10+ messages in thread From: Krishna Chaitanya @ 2013-01-16 4:09 UTC (permalink / raw) To: Johannes Berg; +Cc: linux-wireless, nbd On Tue, Jan 15, 2013 at 4:53 PM, Johannes Berg <johannes@sipsolutions.net> wrote: > Hi, > >> Is there any work in progress/planned related to Tx AMSDU logic in mac80211? > > At some point Felix was planning to look at this, but I don't think he > ever did. I guess he'll correct me if I'm wrong. > >> 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? > > I'm not aware of any issue. You could probably even take some of that > code and make it some generic cfg80211 helper library for use by both > mwifiex and mac80211. > > johannes > That sounds right, we can at least develop a test helper for doing that if not a commercial one. Chaitanya T K. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Tx AMSDU Support 2013-01-16 4:09 ` Krishna Chaitanya @ 2013-01-16 23:05 ` Adrian Chadd 2013-01-16 23:23 ` Johannes Berg 0 siblings, 1 reply; 10+ messages in thread From: Adrian Chadd @ 2013-01-16 23:05 UTC (permalink / raw) To: Krishna Chaitanya; +Cc: Johannes Berg, linux-wireless, nbd .. for testing that out, I ended up just using a NIC that implements AMSDU in software. God knows what it was though (intel?).. Yes it would be nice to implement A-MSDU TX in software. But I agree with Felix - there's a lot of logic that can be shared with the A-MPDU aggregation code.. Adrian ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Tx AMSDU Support 2013-01-16 23:05 ` Adrian Chadd @ 2013-01-16 23:23 ` Johannes Berg 2013-01-17 8:44 ` Krishna Chaitanya 0 siblings, 1 reply; 10+ messages in thread From: Johannes Berg @ 2013-01-16 23:23 UTC (permalink / raw) To: Adrian Chadd; +Cc: Krishna Chaitanya, linux-wireless, nbd On Wed, 2013-01-16 at 15:05 -0800, Adrian Chadd wrote: > .. for testing that out, I ended up just using a NIC that implements > AMSDU in software. > > God knows what it was though (intel?).. Probably Broadcom and/or Marvell. johannes ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Tx AMSDU Support 2013-01-16 23:23 ` Johannes Berg @ 2013-01-17 8:44 ` Krishna Chaitanya 2013-01-17 19:29 ` Bing Zhao 0 siblings, 1 reply; 10+ messages in thread From: Krishna Chaitanya @ 2013-01-17 8:44 UTC (permalink / raw) To: Johannes Berg; +Cc: Adrian Chadd, linux-wireless, nbd Ok...will try with the below ones..Marvell definitely has support for AMSDU Tx. On Thu, Jan 17, 2013 at 4:53 AM, Johannes Berg <johannes@sipsolutions.net> wrote: > On Wed, 2013-01-16 at 15:05 -0800, Adrian Chadd wrote: >> .. for testing that out, I ended up just using a NIC that implements >> AMSDU in software. >> >> God knows what it was though (intel?).. > > Probably Broadcom and/or Marvell. > > johannes > ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Tx AMSDU Support 2013-01-17 8:44 ` Krishna Chaitanya @ 2013-01-17 19:29 ` Bing Zhao 2013-01-18 6:15 ` Krishna Chaitanya 0 siblings, 1 reply; 10+ messages in thread From: Bing Zhao @ 2013-01-17 19:29 UTC (permalink / raw) To: Krishna Chaitanya, Johannes Berg Cc: Adrian Chadd, linux-wireless, nbd@openwrt.org [-- Attachment #1: Type: text/plain, Size: 2717 bytes --] Hi Krishna, > Ok...will try with the below ones..Marvell definitely has support for AMSDU Tx. mwifiex driver uses AMPDU aggregation by default. Please apply the following change to disable AMPDU so that AMSDU can be chosen for aggregation. Also increase the Tx buffer size to 4K to allow AMSDU aggregation for two 1500-byte packets. Or, you can use 8K to aggregate more packets for your tests. --- diff --git a/drivers/net/wireless/mwifiex/init.c b/drivers/net/wireless/mwifiex/init.c index e00b806..97ef459 100644 --- a/drivers/net/wireless/mwifiex/init.c +++ b/drivers/net/wireless/mwifiex/init.c @@ -317,9 +317,9 @@ static void mwifiex_init_adapter(struct mwifiex_adapter *adapter) adapter->pm_wakeup_fw_try = false; - adapter->max_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K; - adapter->tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K; - adapter->curr_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K; + adapter->max_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K; + adapter->tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K; + adapter->curr_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K; adapter->is_hs_configured = false; adapter->hs_cfg.conditions = cpu_to_le32(HOST_SLEEP_CFG_COND_DEF); diff --git a/drivers/net/wireless/mwifiex/wmm.c b/drivers/net/wireless/mwifiex/wmm.c index 135d96d..ea722c2 100644 --- a/drivers/net/wireless/mwifiex/wmm.c +++ b/drivers/net/wireless/mwifiex/wmm.c @@ -425,8 +425,8 @@ mwifiex_wmm_init(struct mwifiex_adapter *adapter) for (i = 0; i < MAX_NUM_TID; ++i) { priv->aggr_prio_tbl[i].amsdu = tos_to_tid_inv[i]; - priv->aggr_prio_tbl[i].ampdu_ap = tos_to_tid_inv[i]; - priv->aggr_prio_tbl[i].ampdu_user = tos_to_tid_inv[i]; + priv->aggr_prio_tbl[i].ampdu_ap = BA_STREAM_NOT_ALLOWED; + priv->aggr_prio_tbl[i].ampdu_user = BA_STREAM_NOT_ALLOWED; priv->wmm.tid_tbl_ptr[i].ra_list_curr = NULL; } -- Patch attached for your convenience. Thanks, Bing > > On Thu, Jan 17, 2013 at 4:53 AM, Johannes Berg > <johannes@sipsolutions.net> wrote: > > On Wed, 2013-01-16 at 15:05 -0800, Adrian Chadd wrote: > >> .. for testing that out, I ended up just using a NIC that implements > >> AMSDU in software. > >> > >> God knows what it was though (intel?).. > > > > Probably Broadcom and/or Marvell. > > > > johannes > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html [-- Attachment #2: mwifiex_choose_amsdu_aggr.patch --] [-- Type: application/octet-stream, Size: 1437 bytes --] diff --git a/drivers/net/wireless/mwifiex/init.c b/drivers/net/wireless/mwifiex/init.c index e00b806..97ef459 100644 --- a/drivers/net/wireless/mwifiex/init.c +++ b/drivers/net/wireless/mwifiex/init.c @@ -317,9 +317,9 @@ static void mwifiex_init_adapter(struct mwifiex_adapter *adapter) adapter->pm_wakeup_fw_try = false; - adapter->max_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K; - adapter->tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K; - adapter->curr_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K; + adapter->max_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K; + adapter->tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K; + adapter->curr_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K; adapter->is_hs_configured = false; adapter->hs_cfg.conditions = cpu_to_le32(HOST_SLEEP_CFG_COND_DEF); diff --git a/drivers/net/wireless/mwifiex/wmm.c b/drivers/net/wireless/mwifiex/wmm.c index 135d96d..ea722c2 100644 --- a/drivers/net/wireless/mwifiex/wmm.c +++ b/drivers/net/wireless/mwifiex/wmm.c @@ -425,8 +425,8 @@ mwifiex_wmm_init(struct mwifiex_adapter *adapter) for (i = 0; i < MAX_NUM_TID; ++i) { priv->aggr_prio_tbl[i].amsdu = tos_to_tid_inv[i]; - priv->aggr_prio_tbl[i].ampdu_ap = tos_to_tid_inv[i]; - priv->aggr_prio_tbl[i].ampdu_user = tos_to_tid_inv[i]; + priv->aggr_prio_tbl[i].ampdu_ap = BA_STREAM_NOT_ALLOWED; + priv->aggr_prio_tbl[i].ampdu_user = BA_STREAM_NOT_ALLOWED; priv->wmm.tid_tbl_ptr[i].ra_list_curr = NULL; } ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: Tx AMSDU Support 2013-01-17 19:29 ` Bing Zhao @ 2013-01-18 6:15 ` Krishna Chaitanya 0 siblings, 0 replies; 10+ messages in thread From: Krishna Chaitanya @ 2013-01-18 6:15 UTC (permalink / raw) To: Bing Zhao; +Cc: Johannes Berg, Adrian Chadd, linux-wireless, nbd@openwrt.org Thanks a lot Bing. Its very helpful, will do that. On Fri, Jan 18, 2013 at 12:59 AM, Bing Zhao <bzhao@marvell.com> wrote: > Hi Krishna, > >> Ok...will try with the below ones..Marvell definitely has support for AMSDU Tx. > > mwifiex driver uses AMPDU aggregation by default. Please apply the following change to disable AMPDU so that AMSDU can be chosen for aggregation. Also increase the Tx buffer size to 4K to allow AMSDU aggregation for two 1500-byte packets. Or, you can use 8K to aggregate more packets for your tests. > > --- > diff --git a/drivers/net/wireless/mwifiex/init.c b/drivers/net/wireless/mwifiex/init.c > index e00b806..97ef459 100644 > --- a/drivers/net/wireless/mwifiex/init.c > +++ b/drivers/net/wireless/mwifiex/init.c > @@ -317,9 +317,9 @@ static void mwifiex_init_adapter(struct mwifiex_adapter *adapter) > > adapter->pm_wakeup_fw_try = false; > > - adapter->max_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K; > - adapter->tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K; > - adapter->curr_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_2K; > + adapter->max_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K; > + adapter->tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K; > + adapter->curr_tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K; > > adapter->is_hs_configured = false; > adapter->hs_cfg.conditions = cpu_to_le32(HOST_SLEEP_CFG_COND_DEF); > diff --git a/drivers/net/wireless/mwifiex/wmm.c b/drivers/net/wireless/mwifiex/wmm.c > index 135d96d..ea722c2 100644 > --- a/drivers/net/wireless/mwifiex/wmm.c > +++ b/drivers/net/wireless/mwifiex/wmm.c > @@ -425,8 +425,8 @@ mwifiex_wmm_init(struct mwifiex_adapter *adapter) > > for (i = 0; i < MAX_NUM_TID; ++i) { > priv->aggr_prio_tbl[i].amsdu = tos_to_tid_inv[i]; > - priv->aggr_prio_tbl[i].ampdu_ap = tos_to_tid_inv[i]; > - priv->aggr_prio_tbl[i].ampdu_user = tos_to_tid_inv[i]; > + priv->aggr_prio_tbl[i].ampdu_ap = BA_STREAM_NOT_ALLOWED; > + priv->aggr_prio_tbl[i].ampdu_user = BA_STREAM_NOT_ALLOWED; > priv->wmm.tid_tbl_ptr[i].ra_list_curr = NULL; > } > > -- > > Patch attached for your convenience. > > Thanks, > Bing > >> >> On Thu, Jan 17, 2013 at 4:53 AM, Johannes Berg >> <johannes@sipsolutions.net> wrote: >> > On Wed, 2013-01-16 at 15:05 -0800, Adrian Chadd wrote: >> >> .. for testing that out, I ended up just using a NIC that implements >> >> AMSDU in software. >> >> >> >> God knows what it was though (intel?).. >> > >> > Probably Broadcom and/or Marvell. >> > >> > johannes >> > >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Tx AMSDU Support 2013-01-15 10:20 Tx AMSDU Support Krishna Chaitanya 2013-01-15 11:23 ` Johannes Berg @ 2013-01-15 12:06 ` Felix Fietkau 2013-01-16 4:07 ` Krishna Chaitanya 1 sibling, 1 reply; 10+ messages in thread From: Felix Fietkau @ 2013-01-15 12:06 UTC (permalink / raw) To: Krishna Chaitanya; +Cc: Johannes Berg, linux-wireless 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Tx AMSDU Support 2013-01-15 12:06 ` Felix Fietkau @ 2013-01-16 4:07 ` Krishna Chaitanya 0 siblings, 0 replies; 10+ messages in thread From: Krishna Chaitanya @ 2013-01-16 4:07 UTC (permalink / raw) To: Felix Fietkau; +Cc: Johannes Berg, linux-wireless On Tue, Jan 15, 2013 at 5:36 PM, Felix Fietkau <nbd@openwrt.org> 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-01-18 6:15 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-01-15 10:20 Tx AMSDU Support Krishna Chaitanya 2013-01-15 11:23 ` Johannes Berg 2013-01-16 4:09 ` Krishna Chaitanya 2013-01-16 23:05 ` Adrian Chadd 2013-01-16 23:23 ` Johannes Berg 2013-01-17 8:44 ` Krishna Chaitanya 2013-01-17 19:29 ` Bing Zhao 2013-01-18 6:15 ` Krishna Chaitanya 2013-01-15 12:06 ` Felix Fietkau 2013-01-16 4:07 ` Krishna Chaitanya
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.