On Fri, 2018-10-05 at 06:00 +0000, Kalle Valo wrote:
>
> So I'm not sure what to do with this. A bpf type of filtering system in
> mac80211 would be nice
Yes, I think we really need to start implementing that sooner rather
than later. I had something, must see if I can find time for it.
> but then again we cannot benefit from HW offloading.
Yes, that's a concern. But how big of a concern is it really?
This patch only talks about "allow an AP" etc. and so while important,
power isn't the _utmost_ concern like on mobile. Given an efficient
filtering solution in software, would that be sufficient?
johannes
On 2018-10-18 13:59, Johannes Berg wrote:
>> So I'm not sure what to do with this. A bpf type of filtering system
>> in
>> mac80211 would be nice
>
> Yes, I think we really need to start implementing that sooner rather
> than later. I had something, must see if I can find time for it.
>
>> but then again we cannot benefit from HW offloading.
>
> Yes, that's a concern. But how big of a concern is it really?
>
> This patch only talks about "allow an AP" etc. and so while important,
> power isn't the _utmost_ concern like on mobile. Given an efficient
> filtering solution in software, would that be sufficient?
Assume in a scenario where there are multiple APs (One Center AP and
Multiple repeater AP) in same operating channel.
Clients present in Neighbor APs causing higher traffic.
when we try to filter desire client packets,
In HW offload case, all Neighbor BSS packets are filtered by HW. so
there is no impact in CPU load. AP performance not get impacted.
In bpf (enabling monitor mode) case, all Neighbor BSS packets get
filtered by software. It will consume CPU load which will impact AP
performance.
Irrespective of how many neighbor APs present in the topology, HW
offload take care of neighbor BSS filtering. Hence no impact in CPU
load.
so we decided to use HW offload. To use our HW offload feature, we ended
up in vendor command approach.
Karthikeyan
On Tue, 2018-11-20 at 08:10 +0530, Karthikeyan Periyasamy wrote:
> > This patch only talks about "allow an AP" etc. and so while important,
> > power isn't the _utmost_ concern like on mobile. Given an efficient
> > filtering solution in software, would that be sufficient?
>
> Assume in a scenario where there are multiple APs (One Center AP and
> Multiple repeater AP) in same operating channel.
> Clients present in Neighbor APs causing higher traffic.
>
> when we try to filter desire client packets,
> In HW offload case, all Neighbor BSS packets are filtered by HW. so
> there is no impact in CPU load. AP performance not get impacted.
> In bpf (enabling monitor mode) case, all Neighbor BSS packets get
> filtered by software. It will consume CPU load which will impact AP
> performance.
>
> Irrespective of how many neighbor APs present in the topology, HW
> offload take care of neighbor BSS filtering. Hence no impact in CPU
> load.
> so we decided to use HW offload. To use our HW offload feature, we ended
> up in vendor command approach.
Sure. I guess my question was intended more along the lines of "how much
CPU impact would you be able to live with?" :-)
At the same time, what happens today actually? Do all frames from non-
associated clients come up to the host? If so, is this not a problem for
all APs, not just ath10k?
And if they don't come up, what feature requires this? Sorry for the
vague questions, but I'm not really sure what this is all about. If
there's a need for these frames, wouldn't we need a generic way of
enabling receiving them, and perhaps even signalling hostapd with them?
Also, what are the statistics and what do you intend to use them for?
johannes
On 2019-01-26 02:19, Johannes Berg wrote:
>
> Sure. I guess my question was intended more along the lines of "how
> much
> CPU impact would you be able to live with?" :-)
As much as no CPU impact.
> At the same time, what happens today actually? Do all frames from non-
> associated clients come up to the host? If so, is this not a problem
> for
> all APs, not just ath10k?
>
Today, without this patch. No frames from non-associated clients come up
to the host in AP mode.
> And if they don't come up, what feature requires this? Sorry for the
> vague questions, but I'm not really sure what this is all about. If
> there's a need for these frames, wouldn't we need a generic way of
> enabling receiving them, and perhaps even signalling hostapd with them?
Steering application use this feature in their logical part of client
steering.
This feature allow an application to configure filtering rules to
capture from
stations that are active on the operating channel but not associated to
this AP.
It also allow to get the statistics information of the configured non
associated stations.
Ath10k driver use HW filter to capture other BSS frames and drop these
packets
after collecting statistics information of configured non associated
stations.
QCA vendor command/attr details:
https://w1.fi/cgit/hostap/commit/?id=6b21df0bb7a261ef890a02d1fef95ffa5ff54cfc
> Also, what are the statistics and what do you intend to use them for?
In this patch, we are providing the below information as a statistics of
non associated stations.
- MAC address
- Last received signal strength
- Time stamp of the last received signal strength
Thanks,
Karthikeyan
On Mon, 2019-01-28 at 10:19 +0530, Karthikeyan Periyasamy wrote:
> > At the same time, what happens today actually? Do all frames from non-
> > associated clients come up to the host? If so, is this not a problem
> > for all APs, not just ath10k?
>
> Today, without this patch. No frames from non-associated clients come up
> to the host in AP mode.
So it's not just _filtering_ but also enabling to see them, right?
> > And if they don't come up, what feature requires this? Sorry for the
> > vague questions, but I'm not really sure what this is all about. If
> > there's a need for these frames, wouldn't we need a generic way of
> > enabling receiving them, and perhaps even signalling hostapd with them?
>
> Steering application use this feature in their logical part of client
> steering.
But there aren't even any steering applications that are open source or
anything like that, right?
I don't see why we should include this upstream. Clearly you can use
this for whatever you like to do with your driver in non-upstream
builds, and you can open-source this code, but if there are no
applications that could possibly use it upstream why bother?
johannes