* Re: wil6210 firmware version
From: Robert Marko @ 2019-03-14 10:05 UTC (permalink / raw)
To: merez; +Cc: linux-wireless, wil6210, linux-wireless-owner
In-Reply-To: <0aabbc6e74fefa8bd5a094dc84b1f87c@codeaurora.org>
Biggest thing would be Channel 4 support as it is supported by driver
but requires FW support also.
But I would also like 20 station limit instead of 8.
Cheers
Robert Marko
On Thu, 14 Mar 2019 at 11:03, <merez@codeaurora.org> wrote:
>
> On 2019-03-14 11:07, Robert Marko wrote:
> > Hi,
> > I am working on OpenWrt support for device using wil6210 card.
> > I am using firmware and board file provided in linux-firmware for its
> > development but it appears tha most of newer features that driver
> > enables are firmware dependant and version 5.2 in linux-firmware is
> > too old to expose those.
> >
> > Is there any chance of QCA pushing updated version to linux-firmware?
> >
> > Thanks
> > Robert Marko
>
> Is there any specific feature you are interested in?
>
> --
> Maya Erez
> Qualcomm Israel, Inc. on behalf of Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
^ permalink raw reply
* Re: wil6210 firmware version
From: merez @ 2019-03-14 10:03 UTC (permalink / raw)
To: Robert Marko; +Cc: linux-wireless, wil6210, linux-wireless-owner
In-Reply-To: <CAOX2RU5igDk_nkj74i-1_hoC4JbSSK3w1_-DyH+3EzyeMHnMcw@mail.gmail.com>
On 2019-03-14 11:07, Robert Marko wrote:
> Hi,
> I am working on OpenWrt support for device using wil6210 card.
> I am using firmware and board file provided in linux-firmware for its
> development but it appears tha most of newer features that driver
> enables are firmware dependant and version 5.2 in linux-firmware is
> too old to expose those.
>
> Is there any chance of QCA pushing updated version to linux-firmware?
>
> Thanks
> Robert Marko
Is there any specific feature you are interested in?
--
Maya Erez
Qualcomm Israel, Inc. on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
^ permalink raw reply
* wil6210 firmware version
From: Robert Marko @ 2019-03-14 9:07 UTC (permalink / raw)
To: linux-wireless, merez, wil6210
Hi,
I am working on OpenWrt support for device using wil6210 card.
I am using firmware and board file provided in linux-firmware for its
development but it appears tha most of newer features that driver
enables are firmware dependant and version 5.2 in linux-firmware is
too old to expose those.
Is there any chance of QCA pushing updated version to linux-firmware?
Thanks
Robert Marko
^ permalink raw reply
* Re: [RFC] mac80211: rework locking for txq scheduling / airtime fairness
From: Toke Høiland-Jørgensen @ 2019-03-13 22:55 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless; +Cc: johannes
In-Reply-To: <20190313181531.62539-1-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> Holding the lock around the entire duration of tx scheduling can
> create some nasty lock contention, especially when processing airtime
> information from the tx status or the rx path.
Right, I can see how that could become an issue at higher loads than
what I tested with :)
> Improve locking by only holding the active_txq_lock for lookups /
> scheduling list modifications.
So the (potential) issue I see with this modification is that it
requires the driver to ensure that it will not interleave two different
scheduling rounds for the same acno. I.e., another call to
schedule_start() will reset the round counter and something needs to
guarantee that this doesn't happen until the driver has actually
finished the previous round.
I am not sure to what extent this would *actually* be a problem. For
ath9k, for instance, there's already the in-driver chan_lock (although
the call to ieee80211_txq_schedule_start() would then have to be moved
into the section covered by that lock). But it does introduce an
implicit dependency in the API, which should at least be documented.
If memory serves, avoiding this implicit dependency was the original
reason I had for adding the full lock around everything. I can't think
of any other reason right now, but if I do think of something I'll be
sure to let you know :)
-Toke
^ permalink raw reply
* [PATCH AUTOSEL 4.20 50/60] mac80211_hwsim: propagate genlmsg_reply return code
From: Sasha Levin @ 2019-03-13 19:10 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Li RongQing, Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190313191021.158171-1-sashal@kernel.org>
From: Li RongQing <lirongqing@baidu.com>
[ Upstream commit 17407715240456448e4989bee46ffc93991add83 ]
genlmsg_reply can fail, so propagate its return code
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mac80211_hwsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index d1464e3e1be2..47a4610e7a5b 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3449,7 +3449,7 @@ static int hwsim_get_radio_nl(struct sk_buff *msg, struct genl_info *info)
goto out_err;
}
- genlmsg_reply(skb, info);
+ res = genlmsg_reply(skb, info);
break;
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.19 38/48] mac80211_hwsim: propagate genlmsg_reply return code
From: Sasha Levin @ 2019-03-13 19:12 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Li RongQing, Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190313191250.158955-1-sashal@kernel.org>
From: Li RongQing <lirongqing@baidu.com>
[ Upstream commit 17407715240456448e4989bee46ffc93991add83 ]
genlmsg_reply can fail, so propagate its return code
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mac80211_hwsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 4ca6592f5b3a..7cd428c0af43 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3454,7 +3454,7 @@ static int hwsim_get_radio_nl(struct sk_buff *msg, struct genl_info *info)
goto out_err;
}
- genlmsg_reply(skb, info);
+ res = genlmsg_reply(skb, info);
break;
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 28/33] mac80211_hwsim: propagate genlmsg_reply return code
From: Sasha Levin @ 2019-03-13 19:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Li RongQing, Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190313191506.159677-1-sashal@kernel.org>
From: Li RongQing <lirongqing@baidu.com>
[ Upstream commit 17407715240456448e4989bee46ffc93991add83 ]
genlmsg_reply can fail, so propagate its return code
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mac80211_hwsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 8f57ca969c9f..27224dc26413 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3241,7 +3241,7 @@ static int hwsim_get_radio_nl(struct sk_buff *msg, struct genl_info *info)
goto out_err;
}
- genlmsg_reply(skb, info);
+ res = genlmsg_reply(skb, info);
break;
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 19/24] mac80211_hwsim: propagate genlmsg_reply return code
From: Sasha Levin @ 2019-03-13 19:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Li RongQing, Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190313191647.160171-1-sashal@kernel.org>
From: Li RongQing <lirongqing@baidu.com>
[ Upstream commit 17407715240456448e4989bee46ffc93991add83 ]
genlmsg_reply can fail, so propagate its return code
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mac80211_hwsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 780acf23fd19..e9ec1da9935d 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3167,7 +3167,7 @@ static int hwsim_get_radio_nl(struct sk_buff *msg, struct genl_info *info)
goto out_err;
}
- genlmsg_reply(skb, info);
+ res = genlmsg_reply(skb, info);
break;
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 13/15] mac80211_hwsim: propagate genlmsg_reply return code
From: Sasha Levin @ 2019-03-13 19:17 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Li RongQing, Johannes Berg, Sasha Levin, linux-wireless, netdev
In-Reply-To: <20190313191806.160547-1-sashal@kernel.org>
From: Li RongQing <lirongqing@baidu.com>
[ Upstream commit 17407715240456448e4989bee46ffc93991add83 ]
genlmsg_reply can fail, so propagate its return code
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/mac80211_hwsim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 0d1abcfec003..0f582117b0e3 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3002,7 +3002,7 @@ static int hwsim_get_radio_nl(struct sk_buff *msg, struct genl_info *info)
goto out_err;
}
- genlmsg_reply(skb, info);
+ res = genlmsg_reply(skb, info);
break;
}
--
2.19.1
^ permalink raw reply related
* [PATCH] mwifiex: Fix potential NULL pointer dereference
From: Aditya Pakki @ 2019-03-13 18:42 UTC (permalink / raw)
To: pakki001
Cc: kjlu, Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat,
Xinming Hu, Kalle Valo, David S. Miller, linux-wireless, netdev,
linux-kernel
dev_alloc_skb can fail and return a NULL pointer. The patch avoids
a potential NULL pointer dereference and returns -ENOMEM.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
---
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 60db2b969e20..4e2fa972a78a 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -341,6 +341,9 @@ static int mwifiex_dnld_sleep_confirm_cmd(struct mwifiex_adapter *adapter)
sleep_cfm_tmp =
dev_alloc_skb(sizeof(struct mwifiex_opt_sleep_confirm)
+ MWIFIEX_TYPE_LEN);
+ if (!sleep_cfm_tmp)
+ return -ENOMEM;
+
skb_put(sleep_cfm_tmp, sizeof(struct mwifiex_opt_sleep_confirm)
+ MWIFIEX_TYPE_LEN);
put_unaligned_le32(MWIFIEX_USB_TYPE_CMD, sleep_cfm_tmp->data);
--
2.17.1
^ permalink raw reply related
* [RFC] mac80211: rework locking for txq scheduling / airtime fairness
From: Felix Fietkau @ 2019-03-13 18:15 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Toke Høiland-Jørgensen
Holding the lock around the entire duration of tx scheduling can create
some nasty lock contention, especially when processing airtime information
from the tx status or the rx path.
Improve locking by only holding the active_txq_lock for lookups / scheduling
list modifications.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
include/net/mac80211.h | 48 ++++++++++++++++--------------------------
net/mac80211/tx.c | 44 ++++++++++++++------------------------
2 files changed, 34 insertions(+), 58 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 3771625b7a9d..40fbd15e6c8c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -6269,8 +6269,6 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
* @hw: pointer as obtained from ieee80211_alloc_hw()
* @ac: AC number to return packets from.
*
- * Should only be called between calls to ieee80211_txq_schedule_start()
- * and ieee80211_txq_schedule_end().
* Returns the next txq if successful, %NULL if no queue is eligible. If a txq
* is returned, it should be returned with ieee80211_return_txq() after the
* driver has finished scheduling it.
@@ -6278,51 +6276,41 @@ struct sk_buff *ieee80211_tx_dequeue(struct ieee80211_hw *hw,
struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw, u8 ac);
/**
- * ieee80211_return_txq - return a TXQ previously acquired by ieee80211_next_txq()
- *
- * @hw: pointer as obtained from ieee80211_alloc_hw()
- * @txq: pointer obtained from station or virtual interface
- *
- * Should only be called between calls to ieee80211_txq_schedule_start()
- * and ieee80211_txq_schedule_end().
- */
-void ieee80211_return_txq(struct ieee80211_hw *hw, struct ieee80211_txq *txq);
-
-/**
- * ieee80211_txq_schedule_start - acquire locks for safe scheduling of an AC
+ * ieee80211_txq_schedule_start - start new scheduling round for TXQs
*
* @hw: pointer as obtained from ieee80211_alloc_hw()
* @ac: AC number to acquire locks for
*
- * Acquire locks needed to schedule TXQs from the given AC. Should be called
- * before ieee80211_next_txq() or ieee80211_return_txq().
+ * Should be called before ieee80211_next_txq() or ieee80211_return_txq().
*/
-void ieee80211_txq_schedule_start(struct ieee80211_hw *hw, u8 ac)
- __acquires(txq_lock);
+void ieee80211_txq_schedule_start(struct ieee80211_hw *hw, u8 ac);
+
+/* (deprecated) */
+static inline void ieee80211_txq_schedule_end(struct ieee80211_hw *hw, u8 ac)
+{
+}
/**
- * ieee80211_txq_schedule_end - release locks for safe scheduling of an AC
+ * ieee80211_schedule_txq - schedule a TXQ for transmission
*
* @hw: pointer as obtained from ieee80211_alloc_hw()
- * @ac: AC number to acquire locks for
+ * @txq: pointer obtained from station or virtual interface
*
- * Release locks previously acquired by ieee80211_txq_schedule_end().
+ * Schedules a TXQ for transmission if it is not already scheduled.
*/
-void ieee80211_txq_schedule_end(struct ieee80211_hw *hw, u8 ac)
- __releases(txq_lock);
+void ieee80211_schedule_txq(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
/**
- * ieee80211_schedule_txq - schedule a TXQ for transmission
+ * ieee80211_return_txq - return a TXQ previously acquired by ieee80211_next_txq()
*
* @hw: pointer as obtained from ieee80211_alloc_hw()
* @txq: pointer obtained from station or virtual interface
- *
- * Schedules a TXQ for transmission if it is not already scheduled. Takes a
- * lock, which means it must *not* be called between
- * ieee80211_txq_schedule_start() and ieee80211_txq_schedule_end()
*/
-void ieee80211_schedule_txq(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
- __acquires(txq_lock) __releases(txq_lock);
+static inline void
+ieee80211_return_txq(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
+{
+ ieee80211_schedule_txq(hw, txq);
+}
/**
* ieee80211_txq_may_transmit - check whether TXQ is allowed to transmit
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index ca23abbf5c0b..51cc37802439 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3653,16 +3653,17 @@ EXPORT_SYMBOL(ieee80211_tx_dequeue);
struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw, u8 ac)
{
struct ieee80211_local *local = hw_to_local(hw);
+ struct ieee80211_txq *ret = NULL;
struct txq_info *txqi = NULL;
- lockdep_assert_held(&local->active_txq_lock[ac]);
+ spin_lock_bh(&local->active_txq_lock[ac]);
begin:
txqi = list_first_entry_or_null(&local->active_txqs[ac],
struct txq_info,
schedule_order);
if (!txqi)
- return NULL;
+ goto out;
if (txqi->txq.sta) {
struct sta_info *sta = container_of(txqi->txq.sta,
@@ -3679,21 +3680,25 @@ struct ieee80211_txq *ieee80211_next_txq(struct ieee80211_hw *hw, u8 ac)
if (txqi->schedule_round == local->schedule_round[ac])
- return NULL;
+ goto out;
list_del_init(&txqi->schedule_order);
txqi->schedule_round = local->schedule_round[ac];
- return &txqi->txq;
+ ret = &txqi->txq;
+
+out:
+ spin_unlock_bh(&local->active_txq_lock[ac]);
+ return ret;
}
EXPORT_SYMBOL(ieee80211_next_txq);
-void ieee80211_return_txq(struct ieee80211_hw *hw,
- struct ieee80211_txq *txq)
+void ieee80211_schedule_txq(struct ieee80211_hw *hw,
+ struct ieee80211_txq *txq)
{
struct ieee80211_local *local = hw_to_local(hw);
struct txq_info *txqi = to_txq_info(txq);
- lockdep_assert_held(&local->active_txq_lock[txq->ac]);
+ spin_lock_bh(&local->active_txq_lock[txq->ac]);
if (list_empty(&txqi->schedule_order) &&
(!skb_queue_empty(&txqi->frags) || txqi->tin.backlog_packets)) {
@@ -3713,17 +3718,7 @@ void ieee80211_return_txq(struct ieee80211_hw *hw,
list_add_tail(&txqi->schedule_order,
&local->active_txqs[txq->ac]);
}
-}
-EXPORT_SYMBOL(ieee80211_return_txq);
-void ieee80211_schedule_txq(struct ieee80211_hw *hw,
- struct ieee80211_txq *txq)
- __acquires(txq_lock) __releases(txq_lock)
-{
- struct ieee80211_local *local = hw_to_local(hw);
-
- spin_lock_bh(&local->active_txq_lock[txq->ac]);
- ieee80211_return_txq(hw, txq);
spin_unlock_bh(&local->active_txq_lock[txq->ac]);
}
EXPORT_SYMBOL(ieee80211_schedule_txq);
@@ -3736,7 +3731,7 @@ bool ieee80211_txq_may_transmit(struct ieee80211_hw *hw,
struct sta_info *sta;
u8 ac = txq->ac;
- lockdep_assert_held(&local->active_txq_lock[ac]);
+ spin_lock_bh(&local->active_txq_lock[ac]);
if (!txqi->txq.sta)
goto out;
@@ -3766,34 +3761,27 @@ bool ieee80211_txq_may_transmit(struct ieee80211_hw *hw,
sta->airtime[ac].deficit += sta->airtime_weight;
list_move_tail(&txqi->schedule_order, &local->active_txqs[ac]);
+ spin_unlock_bh(&local->active_txq_lock[ac]);
return false;
out:
if (!list_empty(&txqi->schedule_order))
list_del_init(&txqi->schedule_order);
+ spin_unlock_bh(&local->active_txq_lock[ac]);
return true;
}
EXPORT_SYMBOL(ieee80211_txq_may_transmit);
void ieee80211_txq_schedule_start(struct ieee80211_hw *hw, u8 ac)
- __acquires(txq_lock)
{
struct ieee80211_local *local = hw_to_local(hw);
spin_lock_bh(&local->active_txq_lock[ac]);
local->schedule_round[ac]++;
-}
-EXPORT_SYMBOL(ieee80211_txq_schedule_start);
-
-void ieee80211_txq_schedule_end(struct ieee80211_hw *hw, u8 ac)
- __releases(txq_lock)
-{
- struct ieee80211_local *local = hw_to_local(hw);
-
spin_unlock_bh(&local->active_txq_lock[ac]);
}
-EXPORT_SYMBOL(ieee80211_txq_schedule_end);
+EXPORT_SYMBOL(ieee80211_txq_schedule_start);
void __ieee80211_subif_start_xmit(struct sk_buff *skb,
struct net_device *dev,
--
2.17.0
^ permalink raw reply related
* [PATCH] mac80211: fix unaligned access in mesh table hash function
From: Felix Fietkau @ 2019-03-13 17:54 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
The pointer to the last four bytes of the address is not guaranteed to be
aligned, so we need to use __get_unaligned_cpu32 here
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
net/mac80211/mesh_pathtbl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 8822c4f3dc48..0a1148328f19 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -23,7 +23,7 @@ static void mesh_path_free_rcu(struct mesh_table *tbl, struct mesh_path *mpath);
static u32 mesh_table_hash(const void *addr, u32 len, u32 seed)
{
/* Use last four bytes of hw addr as hash index */
- return jhash_1word(*(u32 *)(addr+2), seed);
+ return jhash_1word(__get_unaligned_cpu32(addr+2), seed);
}
static const struct rhashtable_params mesh_rht_params = {
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v5 09/18] x86/split_lock: Handle #AC exception for split lock
From: Dave Hansen @ 2019-03-13 16:22 UTC (permalink / raw)
To: Fenghua Yu
Cc: Thomas Gleixner, Ingo Molnar, H Peter Anvin, Paolo Bonzini,
Ashok Raj, Peter Zijlstra, Xiaoyao Li, Michael Chan,
Ravi V Shankar, linux-kernel, x86, linux-wireless, netdev, kvm
In-Reply-To: <20190313004955.GA31710@romley-ivt3.sc.intel.com>
On 3/12/19 5:49 PM, Fenghua Yu wrote:
> On Tue, Mar 12, 2019 at 04:51:22PM -0700, Dave Hansen wrote:
>> On 3/12/19 4:00 PM, Fenghua Yu wrote:
>> I don't see any feature checking here. Don't we need to see if this MSR
>> is supported?
>>
>> Shouldn't the code here on systems that don't support split lock
>> disabling be the same as on CONFIG_CPU_SUP_INTEL=n systems?
>
> You are right. Is the following #AC handler code better?
Fenghua, I'd really appreciate if you could take a deep breath and slow
down. The most important thing is getting the right patch out and being
as respectful as possible with reviewer bandwidth.
> @@ -293,7 +294,37 @@ DO_ERROR(X86_TRAP_OLD_MF, SIGFPE, 0, NULL, "coprocessor segment overru
> DO_ERROR(X86_TRAP_TS, SIGSEGV, 0, NULL, "invalid TSS", invalid_TSS)
> DO_ERROR(X86_TRAP_NP, SIGBUS, 0, NULL, "segment not present", segment_not_present)
> DO_ERROR(X86_TRAP_SS, SIGBUS, 0, NULL, "stack segment", stack_segment)
> -DO_ERROR(X86_TRAP_AC, SIGBUS, BUS_ADRALN, NULL, "alignment check", alignment_check)
> +dotraplinkage void do_alignment_check(struct pt_regs *regs, long error_code)
Is this really an appropriate place to stick this function? Without any
whitespace, and even pushing out the "#undef" that was here before?
> +{
> + unsigned int trapnr = X86_TRAP_AC;
> + char str[] = "alignment check";
> + int signr = SIGBUS;
> +
> + RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU");
> +
> + if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
> + NOTIFY_STOP) {
Please unindent this code block.
> + cond_local_irq_enable(regs);
> + if (!user_mode(regs)) {
Comments please.
The comment about #AC being impossible in the kernel without the split
lock detection feature belongs here, not below.
> + if (!this_cpu_has(X86_FEATURE_SPLIT_LOCK_DETECT))
> + return;
Is this consistent with the code that was here before? Basically, if we
are in the kernel, get an #AC and end up here, we just return from this
function? Is that what DO_ERROR() did?
> + /*
> + * Only split lock can generate #AC from kernel. Warn
> + * and disable #AC for split lock on current CPU.
> + */
> + msr_clear_bit(MSR_TEST_CTL,
> + TEST_CTL_ENABLE_SPLIT_LOCK_DETECT_SHIFT);
> + WARN_ONCE(1, "A split lock issue is detected.\n");
Is it an issue? I'd probably say: "split lock operation detected"
> +
> +
> + return;
Extra whitespace.
> + }
> + /* Handle #AC generated from user code. */
> + do_trap(X86_TRAP_AC, SIGBUS, "alignment check", regs,
> + error_code, BUS_ADRALN, NULL);
> + }
> +}
> #undef IP
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt
From: Stanislaw Gruszka @ 2019-03-13 15:50 UTC (permalink / raw)
To: Tom Psyborg; +Cc: linux-wireless, kvalo, daniel
In-Reply-To: <CAKR_QV+gEJEE2+hwfE1wsF5mdEZVDGtNskivcpFUutGEbwKyKg@mail.gmail.com>
On Wed, Mar 13, 2019 at 03:41:50PM +0100, Tom Psyborg wrote:
> >> > It's just matter of sending already encrypted frames. All chipsets
> >> > handle that.
> >> >
> >> > Stanislaw
> >> >
> >>
> >> The question is how well all chipsets handle that. I've seen some lags
> >> too with MFP enabled connection. While being about 40-50% lower,
> >> throughput would still occasionally drop to very low values, like
> >> 800Kbps.
> >
> > The only reason I can image that might have impact on throughput
> > in this case is limited CPU power since encryption is done in
> > software. Would be good to compare with PA2 with nohwcrypte, if
> > there are similar lags. However MFP can require more CPU power.
> >
> > Stanislaw
> >
>
> nohwcrypt=y mfp=require: there was no throughput drop, no lag,
> measured about 80-85Mbps but the connection frozen after a minute or
> two. might be related to rekeying.
>
> CPU power cannot be the problem since I run it on laptop (2x2.20GHz)
It can be CPU power on AP, ath10k and ath9k also use software
encryption for MFP.
> hwcrypt enabled results are low, some lag but connection remained stable:
There should be no difference between enabling MFP with nohwcrypt and
without nohwcrypt, we will just return -EOPNOTSUPP at different point
from rt2x00mac_set_key:
if (!rt2x00_has_cap_hw_crypto(rt2x00dev))
return -EOPNOTSUPP;
<snip>
crypto.bssidx = rt2x00lib_get_bssidx(rt2x00dev, vif);
crypto.cipher = rt2x00crypto_key_to_cipher(key);
if (crypto.cipher == CIPHER_NONE)
return -EOPNOTSUPP;
However there are some few others points in the code where we check
rt2x00_has_cap_hw_crypto() as well, but all should work the same when
we report to mac80211 that the cipher is not supported.
Stanislaw
^ permalink raw reply
* Re: [linuxwifi] [RFC] iwlwifi: enable TX AMPDU for some iwldvm
From: Kevin Locke @ 2019-03-13 15:06 UTC (permalink / raw)
To: Grumbach, Emmanuel; +Cc: linuxwifi, linux-wireless, Coelho, Luciano
In-Reply-To: <cdd094bd29f1e20dc5577fcbad6a7b404e66407a.camel@intel.com>
On Wed, 2019-03-13 at 04:58 +0000, Grumbach, Emmanuel wrote:
> Just to align on expectations, I don't feel like enable A-MPDU by
> default regardless of what will come out of this. People stopped
> complaining after we disabled A-MPDU and the very very very few people
> that did need more throughput knew how to enable them with the module
> parameter. So, I don't plan to re-enable A-MPDU by default.
I understand. I disagree that very few people would benefit from
nearly doubling TCP throughput or that the fix is known/obvious.
However, if it's not worth the risk and/or effort, or there is no
reliable way to determine which devices/configurations are unaffected,
so be it. Resources are limited and that's totally understandable.
Let me know if there is anything else I can do to assist.
Thanks,
Kevin
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt
From: Tom Psyborg @ 2019-03-13 14:41 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo, daniel
In-Reply-To: <20190313140607.GE2003@redhat.com>
On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Wed, Mar 13, 2019 at 02:48:01PM +0100, Tom Psyborg wrote:
>> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> > On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
>> >> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> >> > On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
>> >> >> MFP can work with enabled HW crypt engine, but in this case
>> >> >> available bandwidth is reduced at least when connecting to
>> >> >> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
>> >> >> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
>> >> >> default to 0 in order to prevent unintentional bandwidth drop.
>> >> >>
>> >> >> Signed-off-by: Tomislav Po?ega <pozega.tomislav@gmail.com>
>> >> >> ---
>> >> >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
>> >> >> 1 files changed, 7 insertions(+), 4 deletions(-)
>> >> >>
>> >> >> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> >> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> >> index a03b528..bb8204d 100644
>> >> >> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> >> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> >> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct
>> >> >> rt2x00_dev
>> >> >> *rt2x00dev)
>> >> >> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
>> >> >> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
>> >> >>
>> >> >> + /* Experimental: Set MFP with HW crypto enabled. */
>> >> >> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390)
>> >> >> ||
>> >> >> + rt2x00_rt(rt2x00dev, RT6352))
>> >> >> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
>> >> >
>> >> > Is not that we support MFP in hardware. We just return -EOPNOTSUPP
>> >> > in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
>> >> > (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
>> >> > we fallback to software encryption.
>> >> >
>> >> > Please repost patch that enable MFP unconditionally with
>> >> > 'Cc: stable@vger.kernel.org' tag.
>> >> >
>> >> > Stanislaw
>> >> >
>> >>
>> >> No, I have not test any other chipsets besides the ones I enabled it
>> >> for. It is possible this would cause problems on other devices, so
>> >> just enable it for the known to work ones.
>> >
>> > It's just matter of sending already encrypted frames. All chipsets
>> > handle that.
>> >
>> > Stanislaw
>> >
>>
>> The question is how well all chipsets handle that. I've seen some lags
>> too with MFP enabled connection. While being about 40-50% lower,
>> throughput would still occasionally drop to very low values, like
>> 800Kbps.
>
> The only reason I can image that might have impact on throughput
> in this case is limited CPU power since encryption is done in
> software. Would be good to compare with PA2 with nohwcrypte, if
> there are similar lags. However MFP can require more CPU power.
>
> Stanislaw
>
nohwcrypt=y mfp=require: there was no throughput drop, no lag,
measured about 80-85Mbps but the connection frozen after a minute or
two. might be related to rekeying.
CPU power cannot be the problem since I run it on laptop (2x2.20GHz)
hwcrypt enabled results are low, some lag but connection remained stable:
root@OpenWrt:~# iperf -c 192.168.1.2 -i 1 -t 20 -P 4
------------------------------------------------------------
Client connecting to 192.168.1.2, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 4] local 192.168.1.1 port 36274 connected with 192.168.1.2 port 5001
[ 5] local 192.168.1.1 port 36276 connected with 192.168.1.2 port 5001
[ 3] local 192.168.1.1 port 36272 connected with 192.168.1.2 port 5001
[ 6] local 192.168.1.1 port 36278 connected with 192.168.1.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 1.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 5] 0.0- 1.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 3] 0.0- 1.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 6] 0.0- 1.0 sec 1.00 MBytes 8.39 Mbits/sec
[SUM] 0.0- 1.0 sec 4.00 MBytes 33.6 Mbits/sec
[ 4] 1.0- 2.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 1.0- 2.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 1.0- 2.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 1.0- 2.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 1.0- 2.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 5] 2.0- 3.0 sec 896 KBytes 7.34 Mbits/sec
[ 4] 2.0- 3.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 2.0- 3.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 2.0- 3.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 2.0- 3.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 3.0- 4.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 3.0- 4.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 3.0- 4.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 3.0- 4.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 3.0- 4.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 4.0- 5.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 4.0- 5.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 4.0- 5.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 4.0- 5.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 4.0- 5.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 5.0- 6.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 5.0- 6.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 5.0- 6.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 5.0- 6.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 5.0- 6.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 6.0- 7.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 6.0- 7.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 6.0- 7.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 6.0- 7.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 6.0- 7.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 7.0- 8.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 7.0- 8.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 7.0- 8.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 7.0- 8.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 7.0- 8.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 6] 8.0- 9.0 sec 896 KBytes 7.34 Mbits/sec
[ 4] 8.0- 9.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 5] 8.0- 9.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 3] 8.0- 9.0 sec 1.00 MBytes 8.39 Mbits/sec
[SUM] 8.0- 9.0 sec 3.88 MBytes 32.5 Mbits/sec
[ 4] 9.0-10.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 9.0-10.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 9.0-10.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 3] 9.0-10.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 9.0-10.0 sec 3.62 MBytes 30.4 Mbits/sec
[ 4] 10.0-11.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 10.0-11.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 10.0-11.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 10.0-11.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 10.0-11.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 11.0-12.0 sec 777 KBytes 6.36 Mbits/sec
[ 5] 11.0-12.0 sec 797 KBytes 6.53 Mbits/sec
[ 3] 11.0-12.0 sec 780 KBytes 6.39 Mbits/sec
[ 6] 11.0-12.0 sec 785 KBytes 6.43 Mbits/sec
[SUM] 11.0-12.0 sec 3.06 MBytes 25.7 Mbits/sec
[ 3] 12.0-13.0 sec 137 KBytes 1.12 Mbits/sec
[ 4] 12.0-13.0 sec 148 KBytes 1.21 Mbits/sec
[ 5] 12.0-13.0 sec 128 KBytes 1.05 Mbits/sec
[ 6] 12.0-13.0 sec 128 KBytes 1.05 Mbits/sec
[SUM] 12.0-13.0 sec 541 KBytes 4.43 Mbits/sec
[ 4] 13.0-14.0 sec 853 KBytes 6.99 Mbits/sec
[ 5] 13.0-14.0 sec 853 KBytes 6.99 Mbits/sec
[ 3] 13.0-14.0 sec 853 KBytes 6.99 Mbits/sec
[ 6] 13.0-14.0 sec 852 KBytes 6.98 Mbits/sec
[SUM] 13.0-14.0 sec 3.33 MBytes 27.9 Mbits/sec
[ 6] 14.0-15.0 sec 144 KBytes 1.18 Mbits/sec
[ 4] 14.0-15.0 sec 145 KBytes 1.19 Mbits/sec
[ 5] 14.0-15.0 sec 142 KBytes 1.17 Mbits/sec
[ 3] 14.0-15.0 sec 147 KBytes 1.20 Mbits/sec
[SUM] 14.0-15.0 sec 578 KBytes 4.73 Mbits/sec
[ 6] 15.0-16.0 sec 768 KBytes 6.29 Mbits/sec
[ 4] 15.0-16.0 sec 768 KBytes 6.29 Mbits/sec
[ 5] 15.0-16.0 sec 768 KBytes 6.29 Mbits/sec
[ 3] 15.0-16.0 sec 768 KBytes 6.29 Mbits/sec
[SUM] 15.0-16.0 sec 3.00 MBytes 25.2 Mbits/sec
[ 4] 16.0-17.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 16.0-17.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 16.0-17.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 16.0-17.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 16.0-17.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 5] 17.0-18.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 17.0-18.0 sec 896 KBytes 7.34 Mbits/sec
[ 4] 17.0-18.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 17.0-18.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 17.0-18.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 18.0-19.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 18.0-19.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 18.0-19.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 18.0-19.0 sec 1.00 MBytes 8.39 Mbits/sec
[SUM] 18.0-19.0 sec 3.62 MBytes 30.4 Mbits/sec
[ 6] 19.0-20.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 6] 0.0-20.1 sec 16.1 MBytes 6.73 Mbits/sec
[ 5] 19.0-20.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 5] 0.0-20.1 sec 16.1 MBytes 6.73 Mbits/sec
[ 4] 19.0-20.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 4] 0.0-20.1 sec 16.1 MBytes 6.73 Mbits/sec
[ 3] 19.0-20.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 19.0-20.0 sec 3.88 MBytes 32.5 Mbits/sec
[ 3] 0.0-20.1 sec 16.1 MBytes 6.73 Mbits/sec
[SUM] 0.0-20.1 sec 64.5 MBytes 26.9 Mbits/sec
ubuntu@ubuntu:~$ iperf -c 192.168.1.1 -i 1 -t 20 -P 4
------------------------------------------------------------
Client connecting to 192.168.1.1, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.2 port 48396 connected with 192.168.1.1 port 5001
[ 4] local 192.168.1.2 port 48398 connected with 192.168.1.1 port 5001
[ 5] local 192.168.1.2 port 48400 connected with 192.168.1.1 port 5001
[ 6] local 192.168.1.2 port 48402 connected with 192.168.1.1 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 896 KBytes 7.34 Mbits/sec
[ 5] 0.0- 1.0 sec 896 KBytes 7.34 Mbits/sec
[ 4] 0.0- 1.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 0.0- 1.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 0.0- 1.0 sec 3.50 MBytes 29.4 Mbits/sec
[ 4] 1.0- 2.0 sec 384 KBytes 3.15 Mbits/sec
[ 5] 1.0- 2.0 sec 384 KBytes 3.15 Mbits/sec
[ 3] 1.0- 2.0 sec 384 KBytes 3.15 Mbits/sec
[ 6] 1.0- 2.0 sec 384 KBytes 3.15 Mbits/sec
[SUM] 1.0- 2.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 5] 2.0- 3.0 sec 768 KBytes 6.29 Mbits/sec
[ 6] 2.0- 3.0 sec 768 KBytes 6.29 Mbits/sec
[ 4] 2.0- 3.0 sec 768 KBytes 6.29 Mbits/sec
[ 3] 2.0- 3.0 sec 896 KBytes 7.34 Mbits/sec
[SUM] 2.0- 3.0 sec 3.12 MBytes 26.2 Mbits/sec
[ 5] 3.0- 4.0 sec 384 KBytes 3.15 Mbits/sec
[ 3] 3.0- 4.0 sec 256 KBytes 2.10 Mbits/sec
[ 4] 3.0- 4.0 sec 384 KBytes 3.15 Mbits/sec
[ 6] 3.0- 4.0 sec 384 KBytes 3.15 Mbits/sec
[SUM] 3.0- 4.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 3] 4.0- 5.0 sec 768 KBytes 6.29 Mbits/sec
[ 4] 4.0- 5.0 sec 640 KBytes 5.24 Mbits/sec
[ 6] 4.0- 5.0 sec 640 KBytes 5.24 Mbits/sec
[ 5] 4.0- 5.0 sec 768 KBytes 6.29 Mbits/sec
[SUM] 4.0- 5.0 sec 2.75 MBytes 23.1 Mbits/sec
[ 3] 5.0- 6.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 6] 5.0- 6.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 5] 5.0- 6.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 4] 5.0- 6.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 5.0- 6.0 sec 5.12 MBytes 43.0 Mbits/sec
[ 4] 6.0- 7.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 5] 6.0- 7.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 3] 6.0- 7.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 6] 6.0- 7.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 6.0- 7.0 sec 5.00 MBytes 41.9 Mbits/sec
[ 4] 7.0- 8.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 3] 7.0- 8.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 6] 7.0- 8.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 5] 7.0- 8.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 7.0- 8.0 sec 5.38 MBytes 45.1 Mbits/sec
[ 6] 8.0- 9.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 3] 8.0- 9.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 5] 8.0- 9.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 4] 8.0- 9.0 sec 1.25 MBytes 10.5 Mbits/sec
[SUM] 8.0- 9.0 sec 5.50 MBytes 46.1 Mbits/sec
[ 5] 9.0-10.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 4] 9.0-10.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 6] 9.0-10.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 3] 9.0-10.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 9.0-10.0 sec 5.25 MBytes 44.0 Mbits/sec
[ 3] 10.0-11.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 6] 10.0-11.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 4] 10.0-11.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 5] 10.0-11.0 sec 1.25 MBytes 10.5 Mbits/sec
[SUM] 10.0-11.0 sec 5.00 MBytes 41.9 Mbits/sec
[ 5] 11.0-12.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 4] 11.0-12.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 6] 11.0-12.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 3] 11.0-12.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 11.0-12.0 sec 5.38 MBytes 45.1 Mbits/sec
[ 5] 12.0-13.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 6] 12.0-13.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 3] 12.0-13.0 sec 1.50 MBytes 12.6 Mbits/sec
[ 4] 12.0-13.0 sec 1.25 MBytes 10.5 Mbits/sec
[SUM] 12.0-13.0 sec 5.38 MBytes 45.1 Mbits/sec
[ 4] 13.0-14.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 5] 13.0-14.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 6] 13.0-14.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 3] 13.0-14.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 13.0-14.0 sec 5.00 MBytes 41.9 Mbits/sec
[ 3] 14.0-15.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 6] 14.0-15.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 4] 14.0-15.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 5] 14.0-15.0 sec 1.25 MBytes 10.5 Mbits/sec
[SUM] 14.0-15.0 sec 5.12 MBytes 43.0 Mbits/sec
[ 6] 15.0-16.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 4] 15.0-16.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 5] 15.0-16.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 15.0-16.0 sec 1.00 MBytes 8.39 Mbits/sec
[SUM] 15.0-16.0 sec 3.88 MBytes 32.5 Mbits/sec
[ 6] 16.0-17.0 sec 384 KBytes 3.15 Mbits/sec
[ 3] 16.0-17.0 sec 256 KBytes 2.10 Mbits/sec
[ 5] 16.0-17.0 sec 256 KBytes 2.10 Mbits/sec
[ 4] 16.0-17.0 sec 384 KBytes 3.15 Mbits/sec
[SUM] 16.0-17.0 sec 1.25 MBytes 10.5 Mbits/sec
[ 4] 17.0-18.0 sec 896 KBytes 7.34 Mbits/sec
[ 6] 17.0-18.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 5] 17.0-18.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 3] 17.0-18.0 sec 1.00 MBytes 8.39 Mbits/sec
[SUM] 17.0-18.0 sec 3.88 MBytes 32.5 Mbits/sec
[ 3] 18.0-19.0 sec 256 KBytes 2.10 Mbits/sec
[ 4] 18.0-19.0 sec 256 KBytes 2.10 Mbits/sec
[ 5] 18.0-19.0 sec 256 KBytes 2.10 Mbits/sec
[ 6] 18.0-19.0 sec 256 KBytes 2.10 Mbits/sec
[SUM] 18.0-19.0 sec 1.00 MBytes 8.39 Mbits/sec
[ 6] 19.0-20.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 6] 0.0-20.1 sec 20.8 MBytes 8.65 Mbits/sec
[ 4] 19.0-20.0 sec 1.12 MBytes 9.44 Mbits/sec
[ 4] 0.0-20.1 sec 19.6 MBytes 8.18 Mbits/sec
[ 3] 19.0-20.0 sec 1.38 MBytes 11.5 Mbits/sec
[ 3] 0.0-20.1 sec 20.1 MBytes 8.38 Mbits/sec
[ 5] 19.0-20.0 sec 1.38 MBytes 11.5 Mbits/sec
[SUM] 19.0-20.0 sec 5.25 MBytes 44.0 Mbits/sec
[ 5] 0.0-20.1 sec 19.6 MBytes 8.17 Mbits/sec
[SUM] 0.0-20.1 sec 80.1 MBytes 33.4 Mbits/sec
^ permalink raw reply
* Re: [RFC] mt76: add 3dBm for reporting txpower also for 1x1
From: Felix Fietkau @ 2019-03-13 14:21 UTC (permalink / raw)
To: Tom Psyborg; +Cc: Stanislaw Gruszka, linux-wireless, Lorenzo Bianconi
In-Reply-To: <CAKR_QV+Tmm1BdZ2rzpkg6OGnK74ie7TOPgf0FrjnOu7EqV_NnQ@mail.gmail.com>
On 2019-03-13 15:11, Tom Psyborg wrote:
> On 13/03/2019, Felix Fietkau <nbd@nbd.name> wrote:
>
>> The reason why we add 3dBm is because using two chains to transmit in
>> the worst case (from regulatory point of view) doubles the transmit
>> power (= +3dBm).
>
> An absurd idea that probably came from some misinformed regulatory
> boys. There is no way to have 3dBm higher output power just because an
> additional antenna exist. Even with 3x3 case it already proves as
> inconsistent since there is no 6dB decrease but 5dB.
Why would it be 6dB for 3x3? It's logarithmic:
2x2: 3dB
3x3: ~4.5dB
4x4: ~6dB
8x8: ~9dB
You may not get +3dB actual output, but you do get some boost from the
extra chain.
- Felix
^ permalink raw reply
* Re: [RFC] mt76: add 3dBm for reporting txpower also for 1x1
From: Tom Psyborg @ 2019-03-13 14:11 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Stanislaw Gruszka, linux-wireless, Lorenzo Bianconi
In-Reply-To: <795dd253-53db-d837-4da6-6016a096cdc7@nbd.name>
On 13/03/2019, Felix Fietkau <nbd@nbd.name> wrote:
> The reason why we add 3dBm is because using two chains to transmit in
> the worst case (from regulatory point of view) doubles the transmit
> power (= +3dBm).
An absurd idea that probably came from some misinformed regulatory
boys. There is no way to have 3dBm higher output power just because an
additional antenna exist. Even with 3x3 case it already proves as
inconsistent since there is no 6dB decrease but 5dB.
If this were to continue it would render 8x8 wifi AP useless.
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt
From: Stanislaw Gruszka @ 2019-03-13 14:06 UTC (permalink / raw)
To: Tom Psyborg; +Cc: linux-wireless, kvalo, daniel
In-Reply-To: <CAKR_QVLB9k0bGiRW9ON3PeQR1ZoMfWbrXg3W+Bg4N4G+9pAsZg@mail.gmail.com>
On Wed, Mar 13, 2019 at 02:48:01PM +0100, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> > On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
> >> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> >> > On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
> >> >> MFP can work with enabled HW crypt engine, but in this case
> >> >> available bandwidth is reduced at least when connecting to
> >> >> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
> >> >> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
> >> >> default to 0 in order to prevent unintentional bandwidth drop.
> >> >>
> >> >> Signed-off-by: Tomislav Po?ega <pozega.tomislav@gmail.com>
> >> >> ---
> >> >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
> >> >> 1 files changed, 7 insertions(+), 4 deletions(-)
> >> >>
> >> >> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> >> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> >> index a03b528..bb8204d 100644
> >> >> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> >> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> >> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct
> >> >> rt2x00_dev
> >> >> *rt2x00dev)
> >> >> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
> >> >> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
> >> >>
> >> >> + /* Experimental: Set MFP with HW crypto enabled. */
> >> >> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390) ||
> >> >> + rt2x00_rt(rt2x00dev, RT6352))
> >> >> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
> >> >
> >> > Is not that we support MFP in hardware. We just return -EOPNOTSUPP
> >> > in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
> >> > (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
> >> > we fallback to software encryption.
> >> >
> >> > Please repost patch that enable MFP unconditionally with
> >> > 'Cc: stable@vger.kernel.org' tag.
> >> >
> >> > Stanislaw
> >> >
> >>
> >> No, I have not test any other chipsets besides the ones I enabled it
> >> for. It is possible this would cause problems on other devices, so
> >> just enable it for the known to work ones.
> >
> > It's just matter of sending already encrypted frames. All chipsets
> > handle that.
> >
> > Stanislaw
> >
>
> The question is how well all chipsets handle that. I've seen some lags
> too with MFP enabled connection. While being about 40-50% lower,
> throughput would still occasionally drop to very low values, like
> 800Kbps.
The only reason I can image that might have impact on throughput
in this case is limited CPU power since encryption is done in
software. Would be good to compare with PA2 with nohwcrypte, if
there are similar lags. However MFP can require more CPU power.
Stanislaw
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt
From: Tom Psyborg @ 2019-03-13 13:48 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo, daniel
In-Reply-To: <20190313130910.GD2003@redhat.com>
On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
>> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>> > On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
>> >> MFP can work with enabled HW crypt engine, but in this case
>> >> available bandwidth is reduced at least when connecting to
>> >> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
>> >> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
>> >> default to 0 in order to prevent unintentional bandwidth drop.
>> >>
>> >> Signed-off-by: Tomislav Po?ega <pozega.tomislav@gmail.com>
>> >> ---
>> >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
>> >> 1 files changed, 7 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> index a03b528..bb8204d 100644
>> >> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> >> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct
>> >> rt2x00_dev
>> >> *rt2x00dev)
>> >> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
>> >> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
>> >>
>> >> + /* Experimental: Set MFP with HW crypto enabled. */
>> >> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390) ||
>> >> + rt2x00_rt(rt2x00dev, RT6352))
>> >> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
>> >
>> > Is not that we support MFP in hardware. We just return -EOPNOTSUPP
>> > in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
>> > (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
>> > we fallback to software encryption.
>> >
>> > Please repost patch that enable MFP unconditionally with
>> > 'Cc: stable@vger.kernel.org' tag.
>> >
>> > Stanislaw
>> >
>>
>> No, I have not test any other chipsets besides the ones I enabled it
>> for. It is possible this would cause problems on other devices, so
>> just enable it for the known to work ones.
>
> It's just matter of sending already encrypted frames. All chipsets
> handle that.
>
> Stanislaw
>
The question is how well all chipsets handle that. I've seen some lags
too with MFP enabled connection. While being about 40-50% lower,
throughput would still occasionally drop to very low values, like
800Kbps.
^ permalink raw reply
* Re: [RFC] mt76: add 3dBm for reporting txpower also for 1x1
From: Felix Fietkau @ 2019-03-13 13:38 UTC (permalink / raw)
To: Stanislaw Gruszka, linux-wireless; +Cc: Lorenzo Bianconi
In-Reply-To: <1552484061-4647-1-git-send-email-sgruszka@redhat.com>
On 2019-03-13 14:34, Stanislaw Gruszka wrote:
> It's not clear for my why we should add 3dBm for 2x2 devices
> and not for 1x1. 3dBm looks rater like minimal txpower and
> hardware transmit at 3dBm + dev->txpower_cur / 2 .
>
> With the change reported txpower value are closer to regulatory
> values, but honestly I have no idea what should be reported.
>
> Perhaps also some better comment should be added.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
The reason why we add 3dBm is because using two chains to transmit in
the worst case (from regulatory point of view) doubles the transmit
power (= +3dBm). There's no reason to do the same for 1x1.
- Felix
^ permalink raw reply
* [RFC] mt76: add 3dBm for reporting txpower also for 1x1
From: Stanislaw Gruszka @ 2019-03-13 13:34 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Stanislaw Gruszka
It's not clear for my why we should add 3dBm for 2x2 devices
and not for 1x1. 3dBm looks rater like minimal txpower and
hardware transmit at 3dBm + dev->txpower_cur / 2 .
With the change reported txpower value are closer to regulatory
values, but honestly I have no idea what should be reported.
Perhaps also some better comment should be added.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 851caabbecda..b04652729112 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -733,15 +733,9 @@ int mt76_get_txpower(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
int *dbm)
{
struct mt76_dev *dev = hw->priv;
- int n_chains = hweight8(dev->antenna_mask);
*dbm = dev->txpower_cur / 2;
-
- /* convert from per-chain power to combined
- * output on 2x2 devices
- */
- if (n_chains > 1)
- *dbm += 3;
+ *dbm += 3;
return 0;
}
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt
From: Stanislaw Gruszka @ 2019-03-13 13:09 UTC (permalink / raw)
To: Tom Psyborg; +Cc: linux-wireless, kvalo, daniel
In-Reply-To: <CAKR_QV+sFc6J97f5dtW9OtxGoEj5udB=fY5qAb3_QgF4jfqEVA@mail.gmail.com>
On Wed, Mar 13, 2019 at 02:02:32PM +0100, Tom Psyborg wrote:
> On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> > On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
> >> MFP can work with enabled HW crypt engine, but in this case
> >> available bandwidth is reduced at least when connecting to
> >> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
> >> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
> >> default to 0 in order to prevent unintentional bandwidth drop.
> >>
> >> Signed-off-by: Tomislav Po?ega <pozega.tomislav@gmail.com>
> >> ---
> >> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
> >> 1 files changed, 7 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> index a03b528..bb8204d 100644
> >> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
> >> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev
> >> *rt2x00dev)
> >> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
> >> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
> >>
> >> + /* Experimental: Set MFP with HW crypto enabled. */
> >> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390) ||
> >> + rt2x00_rt(rt2x00dev, RT6352))
> >> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
> >
> > Is not that we support MFP in hardware. We just return -EOPNOTSUPP
> > in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
> > (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
> > we fallback to software encryption.
> >
> > Please repost patch that enable MFP unconditionally with
> > 'Cc: stable@vger.kernel.org' tag.
> >
> > Stanislaw
> >
>
> No, I have not test any other chipsets besides the ones I enabled it
> for. It is possible this would cause problems on other devices, so
> just enable it for the known to work ones.
It's just matter of sending already encrypted frames. All chipsets
handle that.
Stanislaw
^ permalink raw reply
* Re: [PATCH 2/2] rt2x00: enable experimental MFP with HW crypt
From: Tom Psyborg @ 2019-03-13 13:02 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, kvalo, daniel
In-Reply-To: <20190313091252.GB2663@redhat.com>
On 13/03/2019, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Tue, Mar 12, 2019 at 08:11:42PM +0100, Tomislav Požega wrote:
>> MFP can work with enabled HW crypt engine, but in this case
>> available bandwidth is reduced at least when connecting to
>> Archer C7 (QCA9558). Enable the feature for known to work chipsets-
>> MT7620, RT3070 and RT5390. Userspace setting for ieee80211w should
>> default to 0 in order to prevent unintentional bandwidth drop.
>>
>> Signed-off-by: Tomislav Po?ega <pozega.tomislav@gmail.com>
>> ---
>> drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 11 +++++++----
>> 1 files changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> index a03b528..bb8204d 100644
>> --- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
>> @@ -9326,6 +9326,13 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev
>> *rt2x00dev)
>> ieee80211_hw_set(rt2x00dev->hw, SIGNAL_DBM);
>> ieee80211_hw_set(rt2x00dev->hw, SUPPORTS_PS);
>>
>> + /* Experimental: Set MFP with HW crypto enabled. */
>> + if (rt2x00_rt(rt2x00dev, RT3070) || rt2x00_rt(rt2x00dev, RT5390) ||
>> + rt2x00_rt(rt2x00dev, RT6352))
>> + ieee80211_hw_set(rt2x00dev->hw, MFP_CAPABLE);
>
> Is not that we support MFP in hardware. We just return -EOPNOTSUPP
> in rt2x00mac_set_key() when mac80211 will try to set MFP ciphers
> (since rt2x00crypto_key_to_cipher() will return CIPHER_NONE) and
> we fallback to software encryption.
>
> Please repost patch that enable MFP unconditionally with
> 'Cc: stable@vger.kernel.org' tag.
>
> Stanislaw
>
No, I have not test any other chipsets besides the ones I enabled it
for. It is possible this would cause problems on other devices, so
just enable it for the known to work ones.
^ permalink raw reply
* Re: [RFC 11/12] mt76usb: allocate urb and sg as linear data
From: Stanislaw Gruszka @ 2019-03-13 12:59 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <20190312163431.GF2611@localhost.localdomain>
On Tue, Mar 12, 2019 at 05:34:32PM +0100, Lorenzo Bianconi wrote:
> > Alloc sg table at the end of urb structure. This will increase
> > cache usage.
> >
>
> I am curious, have you observed any performance improvement doing so?
It's hard to measure that. Stressing net transfer with about 175 Mbit/s
by netperf (what is max I can get) only took about 15% of CPU for me
and net performance fluctuate so CPU pref stats vary too.
> > - if (dev->usb.sg_en) {
> > - urb->sg = devm_kcalloc(dev->dev, MT_SG_MAX_SIZE,
> > - sizeof(urb->sg), GFP_KERNEL);
FTR: Here is bug it should be sizeof(*urb->sg).
> > - if (!urb->sg)
> > - return -ENOMEM;
> > - }
> > + usb_init_urb(e->urb);
> > +
> > + if (dev->usb.sg_en)
> > + e->urb->sg = (struct scatterlist *)((u8 *)e->urb + sizeof(struct urb));
>
> You can avoid u8 cast doing:
> (struct scatterlist *)(e->urb + 1)
Cool trick!
Stanislaw
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox