All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Cc: Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>
Subject: Re: [RFC 1/3] bpf/wireless: add wifimon program type
Date: Wed, 12 Apr 2017 16:27:34 +0200	[thread overview]
Message-ID: <1492007254.2855.10.camel@sipsolutions.net> (raw)
In-Reply-To: <20170412110726.9689-1-johannes@sipsolutions.net> (sfid-20170412_130910_059795_2268F0CA)

On Wed, 2017-04-12 at 13:07 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
> 
> Add a new program type for wifi monitor interfaces. This program
> type can
>  * access __sk_buff, but only skb->len
>  * call bpf_skb_load_bytes()
> 
> The program type is only enabled when something selects the new
> Kconfig symbol WANT_BPF_WIFIMON, which will be done by mac80211
> in a follow-up patch.

This works. An example BPF program is here:
https://p.sipsolutions.net/ca32264f2b705e5e.txt

I haven't really done any performance measurements and only tested it
in a virtual environment, but it's nice to see that in principle I can
get it working relatively easily.

One thing I'm not so sure about is the usage of __sk_buff.

Clearly, I need to pass the struct sk_buff internally for
bpf_skb_load_bytes() to work. However, using __sk_buff seems a bit
strange since I only let the program access the len field.

Perhaps adding a __wifi_sk_buff would work, but then clang will
probably complain if you pass that to bpf_skb_load_bytes().

The alternative will be to add any wifi fields we might need eventually
to __sk_buff, which perhaps isn't such a big deal since accesses are
optimized away anyway through convert_ctx_access.

Instead it may make more sense to just have a "wifi_info(skb, info)"
function you can call, e.g. with a structure that has various fields
and flags to see which you care about.

johannes

WARNING: multiple messages have this Message-ID (diff)
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Daniel Borkmann <daniel-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>,
	Alexei Starovoitov <ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [RFC 1/3] bpf/wireless: add wifimon program type
Date: Wed, 12 Apr 2017 16:27:34 +0200	[thread overview]
Message-ID: <1492007254.2855.10.camel@sipsolutions.net> (raw)
In-Reply-To: <20170412110726.9689-1-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> (sfid-20170412_130910_059795_2268F0CA)

On Wed, 2017-04-12 at 13:07 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> Add a new program type for wifi monitor interfaces. This program
> type can
>  * access __sk_buff, but only skb->len
>  * call bpf_skb_load_bytes()
> 
> The program type is only enabled when something selects the new
> Kconfig symbol WANT_BPF_WIFIMON, which will be done by mac80211
> in a follow-up patch.

This works. An example BPF program is here:
https://p.sipsolutions.net/ca32264f2b705e5e.txt

I haven't really done any performance measurements and only tested it
in a virtual environment, but it's nice to see that in principle I can
get it working relatively easily.

One thing I'm not so sure about is the usage of __sk_buff.

Clearly, I need to pass the struct sk_buff internally for
bpf_skb_load_bytes() to work. However, using __sk_buff seems a bit
strange since I only let the program access the len field.

Perhaps adding a __wifi_sk_buff would work, but then clang will
probably complain if you pass that to bpf_skb_load_bytes().

The alternative will be to add any wifi fields we might need eventually
to __sk_buff, which perhaps isn't such a big deal since accesses are
optimized away anyway through convert_ctx_access.

Instead it may make more sense to just have a "wifi_info(skb, info)"
function you can call, e.g. with a structure that has various fields
and flags to see which you care about.

johannes

  parent reply	other threads:[~2017-04-12 14:27 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-12 11:07 [RFC 1/3] bpf/wireless: add wifimon program type Johannes Berg
2017-04-12 11:07 ` Johannes Berg
2017-04-12 11:07 ` [RFC 2/3] cfg80211: add API to attach monitor filter program Johannes Berg
2017-04-12 11:07 ` [RFC 3/3] mac80211: support bpf monitor filter Johannes Berg
2017-04-12 14:29   ` Johannes Berg
2017-04-12 14:29     ` Johannes Berg
2017-04-12 15:22     ` David Miller
2017-04-12 15:22       ` David Miller
2017-04-12 15:25       ` Johannes Berg
2017-04-12 15:25         ` Johannes Berg
2017-04-13  6:00   ` Johannes Berg
2017-04-12 14:27 ` Johannes Berg [this message]
2017-04-12 14:27   ` [RFC 1/3] bpf/wireless: add wifimon program type Johannes Berg
2017-04-12 15:19   ` David Miller
2017-04-12 15:19     ` David Miller
2017-04-12 15:30     ` Johannes Berg
2017-04-14 18:51       ` Alexei Starovoitov
2017-04-14 18:51         ` Alexei Starovoitov
2017-04-18  9:55         ` Johannes Berg
2017-04-18 10:58           ` Daniel Borkmann
2017-04-18 11:28             ` Johannes Berg
2017-04-18 11:28               ` Johannes Berg
2017-04-18 11:35               ` Johannes Berg
2017-04-12 19:47 ` Marcel Holtmann
2017-04-12 19:47   ` Marcel Holtmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1492007254.2855.10.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.