Re: [RFC 0/4] wireless: Per-sta NoAck and offload support

[Steve deRosier]

On Tue, Mar 27, 2018 at 11:09 PM,   wrote:
> On 2018-03-27 22:18, Steve deRosier wrote:
>>
>> Hi Vasanthakumar,
>>
>> On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
>>  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.
>
>
> 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.


>>
>> 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

Re: [RFC 0/4] wireless: Per-sta NoAck and offload support

[Johannes Berg]

On Wed, 2018-03-28 at 13:29 +0530, vthia...@codeaurora.org wrote:
> On 2018-03-28 13:07, Arend van Spriel wrote:
> > On 3/28/2018 8:09 AM, vthia...@codeaurora.org wrote:
> > > On 2018-03-27 22:18, Steve deRosier wrote:
> > > > Hi Vasanthakumar,
> > > > 
> > > > On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
> > > >  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.
> > > 
> > > 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

Re: [RFC 0/4] wireless: Per-sta NoAck and offload support

[vthiagar]

On 2018-03-28 13:07, Arend van Spriel wrote:

On 3/28/2018 8:09 AM, vthia...@codeaurora.org wrote:

On 2018-03-27 22:18, Steve deRosier wrote:

Hi Vasanthakumar,

On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
 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.


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

Re: [RFC 0/4] wireless: Per-sta NoAck and offload support

[Arend van Spriel]

On 3/28/2018 8:09 AM, vthia...@codeaurora.org wrote:

On 2018-03-27 22:18, Steve deRosier wrote:

Hi Vasanthakumar,

On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
 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.


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

Re: [RFC 0/4] wireless: Per-sta NoAck and offload support

[vthiagar]

On 2018-03-27 22:18, Steve deRosier wrote:

Hi Vasanthakumar,

On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
 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.


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.





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

Re: [RFC 0/4] wireless: Per-sta NoAck and offload support

[Steve deRosier]

Hi Vasanthakumar,

On Tue, Mar 27, 2018 at 1:42 AM, Vasanthakumar Thiagarajan
 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

[RFC 0/4] wireless: Per-sta NoAck and offload support

[Vasanthakumar Thiagarajan]

Adds infrastructure for driver to offload NoAck functionality, driver
like ath10k could make use of it. Also extends the current ndev wide
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.

Vasanthakumar Thiagarajan (4):
  mac80211: Add NoAck policy functionality offload infrastructure
  nl80211/mac80211: Extend NoAck policy command with peer MAC address
  mac80211: Apply per-peer NoAck tid bitmap configuration
  mac80211: Advertise per-peer NoAck policy support

 include/net/cfg80211.h   |  9 +++--
 include/net/mac80211.h   | 18 ++
 include/uapi/linux/nl80211.h | 12 +++-
 net/mac80211/cfg.c   | 45 +---
 net/mac80211/debugfs.c   |  1 +
 net/mac80211/driver-ops.h| 22 ++
 net/mac80211/iface.c |  4 
 net/mac80211/main.c  |  8 
 net/mac80211/sta_info.h  |  3 +++
 net/mac80211/trace.h | 28 +++
 net/mac80211/tx.c|  3 ++-
 net/mac80211/wme.c   | 35 +-
 net/wireless/nl80211.c   | 12 +++-
 net/wireless/rdev-ops.h  |  7 ---
 net/wireless/trace.h | 11 +++
 15 files changed, 202 insertions(+), 16 deletions(-)

-- 
1.9.1