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.
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
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
<[email protected]> 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
>
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 a lot Bing. Its very helpful, will do that.
On Fri, Jan 18, 2013 at 12:59 AM, Bing Zhao <[email protected]> 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
>> <[email protected]> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 15, 2013 at 4:53 PM, Johannes Berg
<[email protected]> 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.
.. 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
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
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
> <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 15, 2013 at 5:36 PM, Felix Fietkau <[email protected]> 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.