Add infrastructure for drivers to implement NoAck policy functionlity.
Driver like ath10k does not use the per-packet TID NoAck policy
configuration. Instead NoAck map is sent to the firmware/hardware
in control path. Firmware takes care of setting up QOS header and
hw with NoAck policy based on the TID NoAck map.
Drivers having this support should advertise it through a new hw_flag,
IEEE80211_HW_SUPPORTS_NOACK_POLICY, and must implement callback
set_noack_tid_bitmap(). Supporting drivers would receive TID NoAck map
through set_noack_tid_bitmap() instead of receiving as part of every
tx skb.
Signed-off-by: Vasanthakumar Thiagarajan <redacted>
---
include/net/mac80211.h | 15 +++++++++++++++
net/mac80211/cfg.c | 10 ++++++++--
net/mac80211/debugfs.c | 1 +
net/mac80211/driver-ops.h | 21 +++++++++++++++++++++
net/mac80211/iface.c | 4 ++++
net/mac80211/main.c | 4 ++++
net/mac80211/trace.h | 25 +++++++++++++++++++++++++
net/mac80211/tx.c | 3 ++-
net/mac80211/wme.c | 3 ++-
9 files changed, 82 insertions(+), 4 deletions(-)
Provides peer level NoAck policy configuration by extending
NL80211_CMD_SET_NOACK_MAP command with peer MAC address.
If user space does not give any peer mac address, the driver
should retain the existing functionality of applying the NoAck
policy for all the staions connected to the netdev. Peer specific
configuration takes precedence over netdev level configuration when
both are set by the user. Drivers supporting per-sta NoAck policy
must advertise the support through the extended flag index
NL80211_EXT_FEATURE_PER_STA_NOACK_MAP.
Signed-off-by: Vasanthakumar Thiagarajan <redacted>
---
include/net/cfg80211.h | 9 +++++++--
include/uapi/linux/nl80211.h | 12 +++++++++++-
net/mac80211/cfg.c | 1 +
net/wireless/nl80211.c | 12 +++++++++++-
net/wireless/rdev-ops.h | 7 ++++---
net/wireless/trace.h | 11 +++++++----
6 files changed, 41 insertions(+), 11 deletions(-)
@@ -5036,6 +5045,7 @@ enum nl80211_ext_feature_index {NL80211_EXT_FEATURE_LOW_POWER_SCAN,NL80211_EXT_FEATURE_HIGH_ACCURACY_SCAN,NL80211_EXT_FEATURE_DFS_OFFLOAD,+NL80211_EXT_FEATURE_PER_STA_NOACK_MAP,/* add new features before the definition below */NUM_NL80211_EXT_FEATURES,
Use per-peer noack tid bitmap, if it is configured,
when setting up the qos header. If no per-peer configuration
is set, use the existing nedev wide noack policy configuration.
Also modifies callback set_noack_tid_bitmap() with the provision
to send per-peer NoAck policy configuration to the drivers supporting
the NoAck offload functionality (IEEE80211_HW_SUPPORTS_NOACK_POLICY).
Signed-off-by: Vasanthakumar Thiagarajan <redacted>
---
include/net/mac80211.h | 7 +++++--
net/mac80211/cfg.c | 42 +++++++++++++++++++++++++++++++++++++-----
net/mac80211/driver-ops.h | 5 +++--
net/mac80211/iface.c | 2 +-
net/mac80211/sta_info.h | 3 +++
net/mac80211/trace.h | 9 ++++++---
net/mac80211/tx.c | 2 +-
net/mac80211/wme.c | 34 +++++++++++++++++++++++++++++++++-
8 files changed, 89 insertions(+), 15 deletions(-)
@@ -345,18 +345,50 @@ static int ieee80211_set_noack_map(struct wiphy *wiphy,u16noack_map){structieee80211_sub_if_data*sdata=IEEE80211_DEV_TO_SUB_IF(dev);+structsta_info*sta;+intret;-sdata->noack_map=noack_map;+if(!peer){+sdata->noack_map=noack_map;-if(!ieee80211_hw_check(&sdata->local->hw,SUPPORTS_NOACK_POLICY)){-ieee80211_check_fast_xmit_iface(sdata);-return0;+if(!ieee80211_hw_check(&sdata->local->hw,SUPPORTS_NOACK_POLICY)){+ieee80211_check_fast_xmit_iface(sdata);+return0;+}++if(!ieee80211_sdata_running(sdata))+return0;++returndrv_set_noack_tid_bitmap(sdata->local,sdata,NULL,+noack_map);}+/* NoAck policy is for a connected client on the dev */+if(!ieee80211_sdata_running(sdata))+return-ENETDOWN;++mutex_lock(&sdata->local->sta_mtx);++sta=sta_info_get_bss(sdata,peer);+if(!sta){+mutex_unlock(&sdata->local->sta_mtx);+return-ENOENT;+}++sta->noack_map=noack_map;++if(!ieee80211_hw_check(&sdata->local->hw,SUPPORTS_NOACK_POLICY)){+ieee80211_check_fast_xmit(sta);+mutex_unlock(&sdata->local->sta_mtx);return0;+}++ret=drv_set_noack_tid_bitmap(sdata->local,sdata,sta,noack_map);-returndrv_set_noack_tid_bitmap(sdata->local,sdata,noack_map);+mutex_unlock(&sdata->local->sta_mtx);++returnret;}staticintieee80211_add_key(structwiphy*wiphy,structnet_device*dev,
@@ -227,6 +227,38 @@ u16 ieee80211_select_queue(struct ieee80211_sub_if_data *sdata,}/**+*ieee80211_get_noack_map-GetTIDbitmapofNoAckpolicy.NoAckpolicy+*couldbedevicewideorper-station.+*+*@sdata:localsubif+*@mac:MACaddressofthereceiver+*/+u16ieee80211_get_noack_map(structieee80211_sub_if_data*sdata,constu8*mac)+{+structsta_info*sta;+u16noack_map=0;++/* Retrieve per-station noack_map config for the receiver, if any */++rcu_read_lock();++sta=sta_info_get(sdata,mac);+if(!sta){+rcu_read_unlock();+returnnoack_map;+}++noack_map=sta->noack_map;++rcu_read_unlock();++if(!noack_map)+noack_map=sdata->noack_map;++returnnoack_map;+}++/***ieee80211_set_qos_hdr-FillintheQoSheaderifthereisone.**@sdata:localsubif
This enables per-peer NoAck handling in mac80211 when
the functionality is not offloaded to the drivers.
Signed-off-by: Vasanthakumar Thiagarajan <redacted>
---
net/mac80211/main.c | 4 ++++
1 file changed, 4 insertions(+)
From: Johannes Berg <johannes@sipsolutions.net> Date: 2018-03-27 12:47:53
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
- * @set_noack_map: Set the NoAck Map for the TIDs.
+ * @set_noack_map: Set the NoAck Map for the TIDs. When peer is not %NULL NoAck
+ * map will be applied for that particular peer. When peer is %NULL NoAck
+ * map will be applied for all the connected stations (except the ones
+ * which already have per-peer TID map configured) on the netdev.
+ * Driver should return -ENOSPC when the it does not have room for
+ * additional entries for per-peer NoAck map.
I guess it should also set the default for new stations when the peer is
not given? At least that's how mac80211 would behave now, afaict.
The question is how that interacts with having enough space - are you
sure this is a concern?
* @NL80211_CMD_SET_NOACK_MAP: sets a bitmap for the individual TIDs whether
- * No Acknowledgement Policy should be applied.
+ * No Acknowledgement Policy should be applied. %NL80211_ATTR_MAC is used
+ * to apply No Acknowledgement policy for a particular connected station.
+ * Station specific NoAck policy configuration is valid only for STA's
+ * current connection, i.e. the configuration will not be used when the
+ * station connects back after disconnection/roaming.
+ * When user-space does not include %NL80211_ATTR_MAC, the No
+ * Acknowledgement Policy setting should be treated as per-netdev
+ * configuration.
Here you describe different semantics - i.e. you didn't describe the
"previous per-station settings are kept" part. I'm not sure that part
makes much sense anyhow?
johannes
From: Johannes Berg <johannes@sipsolutions.net> Date: 2018-03-27 12:53:07
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
+ * @IEEE80211_HW_SUPPORTS_NOACK_POLICY: Hardware (or driver) manages noack
+ * policy handling. Hardware (or driver) takes care of setting
+ * noack policy in the qos header and does not wait for the ack based
+ * on the noack TID map. Driver advertising this support must implement
+ * callback @set_noack_tid_bitmap to receive the user configured noack TID
+ * bitmap.
You'd safe some effort by reordering the nl80211 patch first, so you can
immediately introduce it with per-peer capability here.
quoted hunk
+++ b/net/mac80211/cfg.c
@@ -347,9 +347,15 @@ static int ieee80211_set_noack_map(struct wiphy *wiphy,sdata->noack_map=noack_map;-ieee80211_check_fast_xmit_iface(sdata);+if(!ieee80211_hw_check(&sdata->local->hw,SUPPORTS_NOACK_POLICY)){+ieee80211_check_fast_xmit_iface(sdata);+return0;+}-return0;+if(!ieee80211_sdata_running(sdata))+return0;++returndrv_set_noack_tid_bitmap(sdata->local,sdata,noack_map);
This doesn't seem right - you should do the fast xmit checks even if
calling the driver, no? And in fact, fast xmit should be permitted when
the noack is offloaded, so you shouldn't set sdata->noack_map in the
offloaded case at all.
Ah, and you do :-)
And then maybe you're indeed right and don't need to call the fast xmit
check in that place since it wouldn't have any effect either way.
johannes
From: Johannes Berg <johannes@sipsolutions.net> Date: 2018-03-27 12:54:16
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
+u16 ieee80211_get_noack_map(struct ieee80211_sub_if_data *sdata, const u8 *mac)
+{
+ struct sta_info *sta;
+ u16 noack_map = 0;
+
+ /* Retrieve per-station noack_map config for the receiver, if any */
+
+ rcu_read_lock();
+
+ sta = sta_info_get(sdata, mac);
+ if (!sta) {
+ rcu_read_unlock();
+ return noack_map;
+ }
+
+ noack_map = sta->noack_map;
+
+ rcu_read_unlock();
+
+ if (!noack_map)
+ noack_map = sdata->noack_map;
So this has an interesting corner case - should it be possible to have a
default noack_map that's non-zero, but override it with 0 for a specific
peer? It seems that it should be, which makes this code wrong.
johannes
From: Steve deRosier <hidden> Date: 2018-03-27 16:49:07
Hi Vasanthakumar,
On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
[off-list ref] wrote:
Adds infrastructure for driver to offload NoAck functionality, driver
like ath10k could make use of it. Also extends the current ndev wide
I'm not really much of a fan of adding a feature without some use of
the feature. Perhaps if drivers "like" ath10k could use it, maybe you
should add a patch(s) to the series where one of those drivers
actually uses the feature. An API without an example of use is also
harder to evaluate effectively.
Additionally, if it's relevant, adding use of the feature to hwsim
would both serve the above comment as well as provide testing
capability.
NoAck policy to per-station, with sta level NoAck policy configuration
userspace could selectively turn off/on Noack based on various connection
parameters of the station.
This is my own ignorance, perhaps from missing recent netdev
conferences - can you send a link to some documentation of what NoAck
is? Certain things in 802.11 use ack transmissions and
interoperability would be compromised if we didn't conform to spec. I
don't imagine that's what's going on here but I'd like to understand
what the heck NoAck is and I failed to bring up anything useful when I
Googled it.
- Steve
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
quoted
- * @set_noack_map: Set the NoAck Map for the TIDs.
+ * @set_noack_map: Set the NoAck Map for the TIDs. When peer is not
%NULL NoAck
+ * map will be applied for that particular peer. When peer is %NULL
NoAck
+ * map will be applied for all the connected stations (except the
ones
+ * which already have per-peer TID map configured) on the netdev.
+ * Driver should return -ENOSPC when the it does not have room for
+ * additional entries for per-peer NoAck map.
I guess it should also set the default for new stations when the peer
is
not given? At least that's how mac80211 would behave now, afaict.
Sure. May be setting -1 as the default value when the per-peer NoAck
policy is not
set would work.
The question is how that interacts with having enough space - are you
sure this is a concern?
This will not be an issue at lest for ath10k. This is mainly for a
(new)driver
which implements the offload but has limitation in supporting more than
certain
number of peers. Perhaps we can remove it now and add it when such
driver is
available?
quoted
* @NL80211_CMD_SET_NOACK_MAP: sets a bitmap for the individual TIDs
whether
- * No Acknowledgement Policy should be applied.
+ * No Acknowledgement Policy should be applied. %NL80211_ATTR_MAC is
used
+ * to apply No Acknowledgement policy for a particular connected
station.
+ * Station specific NoAck policy configuration is valid only for
STA's
+ * current connection, i.e. the configuration will not be used when
the
+ * station connects back after disconnection/roaming.
+ * When user-space does not include %NL80211_ATTR_MAC, the No
+ * Acknowledgement Policy setting should be treated as per-netdev
+ * configuration.
Here you describe different semantics - i.e. you didn't describe the
"previous per-station settings are kept" part. I'm not sure that part
makes much sense anyhow?
Not sure I got this comment right. As mentioned in the doc, the previous
settings
would be reset upon reconnection of the station and any ndev wide
configuration
will be used. As mentioned above, additionally default value will be set
to the
station to mark no per-station configuration is given so far.
Vasanth
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
quoted
+ * @IEEE80211_HW_SUPPORTS_NOACK_POLICY: Hardware (or driver) manages
noack
+ * policy handling. Hardware (or driver) takes care of setting
+ * noack policy in the qos header and does not wait for the ack based
+ * on the noack TID map. Driver advertising this support must
implement
+ * callback @set_noack_tid_bitmap to receive the user configured
noack TID
+ * bitmap.
Do you really need the ops method and the flag?
Ath10k would send NoAck policy configuration on control path
configuration.
It seems a new ops might be appropriate. Perhaps the ops alone is
sufficient
to know the capability?
This doesn't seem right - you should do the fast xmit checks even if
calling the driver, no? And in fact, fast xmit should be permitted when
the noack is offloaded, so you shouldn't set sdata->noack_map in the
offloaded case at all.
*sta)
test_sta_flag(sta, WLAN_STA_CLEAR_PS_FILT))
goto out;
- if (sdata->noack_map)
+ if (sdata->noack_map &&
+ !ieee80211_hw_check(&local->hw, SUPPORTS_NOACK_POLICY))
goto out;
Ah, and you do :-)
And then maybe you're indeed right and don't need to call the fast xmit
check in that place since it wouldn't have any effect either way.
On Tue, 2018-03-27 at 14:12 +0530, Vasanthakumar Thiagarajan wrote:
quoted
+u16 ieee80211_get_noack_map(struct ieee80211_sub_if_data *sdata,
const u8 *mac)
+{
+ struct sta_info *sta;
+ u16 noack_map = 0;
+
+ /* Retrieve per-station noack_map config for the receiver, if any */
+
+ rcu_read_lock();
+
+ sta = sta_info_get(sdata, mac);
+ if (!sta) {
+ rcu_read_unlock();
+ return noack_map;
+ }
+
+ noack_map = sta->noack_map;
+
+ rcu_read_unlock();
+
+ if (!noack_map)
+ noack_map = sdata->noack_map;
So this has an interesting corner case - should it be possible to have
a
default noack_map that's non-zero, but override it with 0 for a
specific
peer? It seems that it should be, which makes this code wrong.
I think 0 as the Noack configuration from user can also be a valid one
in the case
where user does not want any NoAck policy to be used for a particular
station even
when a non-zero NoAck configuration is set for ndev level. In this case,
the logic
may need to be modified so that the default non-zero configuration
(something like -1)
could be used to determine that the station has been never configured
with any NoAck
policy and use ndev level configuration. Does this sound reasonable?
Vasanth
Hi Vasanthakumar,
On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
[off-list ref] wrote:
quoted
Adds infrastructure for driver to offload NoAck functionality, driver
like ath10k could make use of it. Also extends the current ndev wide
I'm not really much of a fan of adding a feature without some use of
the feature. Perhaps if drivers "like" ath10k could use it, maybe you
should add a patch(s) to the series where one of those drivers
actually uses the feature. An API without an example of use is also
harder to evaluate effectively.
I agree driver patch using the new NoAck infrastructure would help with
understanding, ill post it once it is ready. But not sure the driver
patch
can be part of the same series.
Additionally, if it's relevant, adding use of the feature to hwsim
would both serve the above comment as well as provide testing
capability.
Does not seem like this offload feature is something applicable for
hwsim
especially mac80211 already offers the same functionality.
quoted
NoAck policy to per-station, with sta level NoAck policy configuration
userspace could selectively turn off/on Noack based on various
connection
parameters of the station.
This is my own ignorance, perhaps from missing recent netdev
conferences - can you send a link to some documentation of what NoAck
is? Certain things in 802.11 use ack transmissions and
interoperability would be compromised if we didn't conform to spec. I
don't imagine that's what's going on here but I'd like to understand
what the heck NoAck is and I failed to bring up anything useful when I
Googled it.
The NoAck configuration is a bitmap of tid which is used to set NoAck in
Qos
control field of the data frame for that particular tid. Perhaps you
could
look at Ack policy subfield section in 802.11 spec.
Vasanth
From: Arend van Spriel <arend.vanspriel@broadcom.com> Date: 2018-03-28 07:37:28
On 3/28/2018 8:09 AM, vthiagar@codeaurora.org wrote:
On 2018-03-27 22:18, Steve deRosier wrote:
quoted
Hi Vasanthakumar,
On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
[off-list ref] wrote:
quoted
Adds infrastructure for driver to offload NoAck functionality, driver
like ath10k could make use of it. Also extends the current ndev wide
I'm not really much of a fan of adding a feature without some use of
the feature. Perhaps if drivers "like" ath10k could use it, maybe you
should add a patch(s) to the series where one of those drivers
actually uses the feature. An API without an example of use is also
harder to evaluate effectively.
I agree driver patch using the new NoAck infrastructure would help with
understanding, ill post it once it is ready. But not sure the driver patch
can be part of the same series.
The API patches would go in mac80211-next tree and indeed the driver
patch would go through wireless-drivers-next tree. However, an option
would be to add the driver patch(es) as RFC in the series so Johannes
can ignore it and we still have an example to look at.
Regards,
Arend
On 3/28/2018 8:09 AM, vthiagar@codeaurora.org wrote:
quoted
On 2018-03-27 22:18, Steve deRosier wrote:
quoted
Hi Vasanthakumar,
On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
[off-list ref] wrote:
quoted
Adds infrastructure for driver to offload NoAck functionality,
driver
like ath10k could make use of it. Also extends the current ndev wide
I'm not really much of a fan of adding a feature without some use of
the feature. Perhaps if drivers "like" ath10k could use it, maybe you
should add a patch(s) to the series where one of those drivers
actually uses the feature. An API without an example of use is also
harder to evaluate effectively.
I agree driver patch using the new NoAck infrastructure would help
with
understanding, ill post it once it is ready. But not sure the driver
patch
can be part of the same series.
The API patches would go in mac80211-next tree and indeed the driver
patch would go through wireless-drivers-next tree. However, an option
would be to add the driver patch(es) as RFC in the series so Johannes
can ignore it and we still have an example to look at.
Sounds good. Ill try to include the driver patch in the next version.
Vasanth
From: Johannes Berg <johannes@sipsolutions.net> Date: 2018-03-28 08:03:35
On Wed, 2018-03-28 at 13:29 +0530, vthiagar@codeaurora.org wrote:
On 2018-03-28 13:07, Arend van Spriel wrote:
quoted
On 3/28/2018 8:09 AM, vthiagar@codeaurora.org wrote:
quoted
On 2018-03-27 22:18, Steve deRosier wrote:
quoted
Hi Vasanthakumar,
On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
[off-list ref] wrote:
quoted
Adds infrastructure for driver to offload NoAck functionality,
driver
like ath10k could make use of it. Also extends the current ndev wide
I'm not really much of a fan of adding a feature without some use of
the feature. Perhaps if drivers "like" ath10k could use it, maybe you
should add a patch(s) to the series where one of those drivers
actually uses the feature. An API without an example of use is also
harder to evaluate effectively.
I agree driver patch using the new NoAck infrastructure would help
with
understanding, ill post it once it is ready. But not sure the driver
patch
can be part of the same series.
The API patches would go in mac80211-next tree and indeed the driver
patch would go through wireless-drivers-next tree. However, an option
would be to add the driver patch(es) as RFC in the series so Johannes
can ignore it and we still have an example to look at.
FWIW, you can just include it as a regular [PATCH] - Kalle and I have a
way of dealing with that - he just assigns it over to me initially, and
I assign back once the prerequisites have landed.
johannes
From: Johannes Berg <johannes@sipsolutions.net> Date: 2018-03-28 08:04:04
I think 0 as the Noack configuration from user can also be a valid one
in the case
where user does not want any NoAck policy to be used for a particular
station even
when a non-zero NoAck configuration is set for ndev level. In this case,
the logic
may need to be modified so that the default non-zero configuration
(something like -1)
could be used to determine that the station has been never configured
with any NoAck
policy and use ndev level configuration. Does this sound reasonable?
Yes. You'll have to use int instead of u16 I guess, but that's
completely doable.
johannes
From: Johannes Berg <johannes@sipsolutions.net> Date: 2018-03-28 08:06:03
On Wed, 2018-03-28 at 10:24 +0530, vthiagar@codeaurora.org wrote:
quoted
The question is how that interacts with having enough space - are you
sure this is a concern?
This will not be an issue at lest for ath10k. This is mainly for a
(new)driver
which implements the offload but has limitation in supporting more than
certain
number of peers. Perhaps we can remove it now and add it when such
driver is
available?
Ok, that's good. Yes, I think that sounds better - I have a hard time
imagining a firmware/driver that has space for the station, but doesn't
automatically allocate a u16 bitmap as part of the station :-)
quoted
quoted
* @NL80211_CMD_SET_NOACK_MAP: sets a bitmap for the individual TIDs
whether
- * No Acknowledgement Policy should be applied.
+ * No Acknowledgement Policy should be applied. %NL80211_ATTR_MAC is
used
+ * to apply No Acknowledgement policy for a particular connected
station.
+ * Station specific NoAck policy configuration is valid only for
STA's
+ * current connection, i.e. the configuration will not be used when
the
+ * station connects back after disconnection/roaming.
+ * When user-space does not include %NL80211_ATTR_MAC, the No
+ * Acknowledgement Policy setting should be treated as per-netdev
+ * configuration.
Here you describe different semantics - i.e. you didn't describe the
"previous per-station settings are kept" part. I'm not sure that part
makes much sense anyhow?
Not sure I got this comment right. As mentioned in the doc, the previous
settings
would be reset upon reconnection of the station and any ndev wide
configuration
will be used. As mentioned above, additionally default value will be set
to the
station to mark no per-station configuration is given so far.
I just thought that there was a difference in how this applies to a
certain station.
Btw, we should probably also have a way to *delete* the per-station
configuration, so it uses the default again?
johannes
On Wed, 2018-03-28 at 10:24 +0530, vthiagar@codeaurora.org wrote:
quoted
quoted
The question is how that interacts with having enough space - are you
sure this is a concern?
This will not be an issue at lest for ath10k. This is mainly for a
(new)driver
which implements the offload but has limitation in supporting more
than
certain
number of peers. Perhaps we can remove it now and add it when such
driver is
available?
Ok, that's good. Yes, I think that sounds better - I have a hard time
imagining a firmware/driver that has space for the station, but doesn't
automatically allocate a u16 bitmap as part of the station :-)
quoted
quoted
quoted
* @NL80211_CMD_SET_NOACK_MAP: sets a bitmap for the individual TIDs
whether
- * No Acknowledgement Policy should be applied.
+ * No Acknowledgement Policy should be applied. %NL80211_ATTR_MAC is
used
+ * to apply No Acknowledgement policy for a particular connected
station.
+ * Station specific NoAck policy configuration is valid only for
STA's
+ * current connection, i.e. the configuration will not be used when
the
+ * station connects back after disconnection/roaming.
+ * When user-space does not include %NL80211_ATTR_MAC, the No
+ * Acknowledgement Policy setting should be treated as per-netdev
+ * configuration.
Here you describe different semantics - i.e. you didn't describe the
"previous per-station settings are kept" part. I'm not sure that part
makes much sense anyhow?
Not sure I got this comment right. As mentioned in the doc, the
previous
settings
would be reset upon reconnection of the station and any ndev wide
configuration
will be used. As mentioned above, additionally default value will be
set
to the
station to mark no per-station configuration is given so far.
I just thought that there was a difference in how this applies to a
certain station.
May be the doc needs more update
Btw, we should probably also have a way to *delete* the per-station
configuration, so it uses the default again?
Sure. How about setting it to default when the command is received with
no
NL80211_ATTR_NOACK_MAP attribute for a station?
Vasanth
From: Steve deRosier <hidden> Date: 2018-03-28 15:13:36
On Tue, Mar 27, 2018 at 11:09 PM, [off-list ref] wrote:
On 2018-03-27 22:18, Steve deRosier wrote:
quoted
Hi Vasanthakumar,
On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
[off-list ref] wrote:
quoted
Adds infrastructure for driver to offload NoAck functionality, driver
like ath10k could make use of it. Also extends the current ndev wide
I'm not really much of a fan of adding a feature without some use of
the feature. Perhaps if drivers "like" ath10k could use it, maybe you
should add a patch(s) to the series where one of those drivers
actually uses the feature. An API without an example of use is also
harder to evaluate effectively.
I agree driver patch using the new NoAck infrastructure would help with
understanding, ill post it once it is ready. But not sure the driver patch
can be part of the same series.
It can. I think both Arend and Johannes already covered it.
quoted
Additionally, if it's relevant, adding use of the feature to hwsim
would both serve the above comment as well as provide testing
capability.
Does not seem like this offload feature is something applicable for hwsim
especially mac80211 already offers the same functionality.
Well, if we desire hwsim to be able to test all the features of
mac80211 (which I don't know if that's true), then it would be
appropriate to place the functionality in hwsim as an optional
turn-on-able feature and have it utilize this API if it's turned on.
It actually would be nice to add it for that purpose. But, admittedly
it's a bit of work as you have to replicate the "hardware" offload
portion in hwsim which obviously you don't if you're working with
actual hardware that implements this feature.
I'd say it's a nice-to-have. If only to keep hwsim in-sync with
mac80211 features for testing. But, I admit I'm asking for work that
is perhaps out-of-scope.
All I really want is a driver that actually uses this as an example of use.
The NoAck configuration is a bitmap of tid which is used to set NoAck in Qos
control field of the data frame for that particular tid. Perhaps you could
look at Ack policy subfield section in 802.11 spec.
Thank you. Because you gave it a name, I thought we were talking about
something more...involved. I'd appreciate if you pointed out that
context in the commit comment of the first patch in the series.
Something mentioning the Ack policy subfield specifically would give
context for those of us trying to tie it to specific 802.11
specifications.
Thanks,
- Steve
On 2018-03-27 14:12, Vasanthakumar Thiagarajan wrote:
Use per-peer noack tid bitmap, if it is configured,
when setting up the qos header. If no per-peer configuration
is set, use the existing nedev wide noack policy configuration.
Also modifies callback set_noack_tid_bitmap() with the provision
to send per-peer NoAck policy configuration to the drivers supporting
the NoAck offload functionality (IEEE80211_HW_SUPPORTS_NOACK_POLICY).
Signed-off-by: Vasanthakumar Thiagarajan <redacted>
---
include/net/mac80211.h | 7 +++++--
net/mac80211/cfg.c | 42
+++++++++++++++++++++++++++++++++++++-----
net/mac80211/driver-ops.h | 5 +++--
net/mac80211/iface.c | 2 +-
net/mac80211/sta_info.h | 3 +++
net/mac80211/trace.h | 9 ++++++---
net/mac80211/tx.c | 2 +-
net/mac80211/wme.c | 34 +++++++++++++++++++++++++++++++++-
8 files changed, 89 insertions(+), 15 deletions(-)
Oops, we'll endup in NULL pointer dereference in accessing sta object
when ndev level
configuration is sent. Ill address this in the next version.
Vasanth