From: Johannes Berg <johannes@sipsolutions.net>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: David Miller <davem@davemloft.net>,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
daniel@iogearbox.net, ast@kernel.org
Subject: Re: [RFC 1/3] bpf/wireless: add wifimon program type
Date: Tue, 18 Apr 2017 11:55:49 +0200 [thread overview]
Message-ID: <1492509349.2472.15.camel@sipsolutions.net> (raw)
In-Reply-To: <20170414185144.GB41922@ast-mbp.thefacebook.com> (sfid-20170414_205150_417889_20631AEB)
On Fri, 2017-04-14 at 11:51 -0700, Alexei Starovoitov wrote:
>
> so today only 'len' field is needed,
Correct, the other __sk_buff fields don't apply.
It's more of an XDP model (with data/data_end), but as the SKB might be
non-linear at this point I prefer to have the SKB so that skb data
access (skb_copy_bits equivalent) works.
> but the plan to add wifi specific
> stuff to bpf context?
Maybe, maybe not.
> If so, adding these very wifi specific fields to __sk_buff will
> confuse other program types,
I don't think this is true - the verifier still checks that you can't
actually use them. It might confuse authors though, if not documented
well.
> so new program type (like you did) and new 'struct bpf_wifi_md' are
> probably cleaner.
The problem is that I still need struct __wifi_sk_buff or so, and need
to internally let it operate like an SKB, since I need
bpf_skb_load_bytes().
Now, bpf_helpers declares bpf_skb_load_bytes() to take an argument of
type "struct __sk_buff *", and thus I either need to provide an alias
to it, or cast every time I use this function.
> Physically the R1 register to bpf program will still be 'struct
> sk_buff', but from bpf program side it will be:
> struct bpf_wifi_md {
> __u32 len;
> __u32 wifi_things;
> };
Right, that would work immediately if it's only about the extra fields.
But it's more about being able to call bpf_skb_load_bytes() easily.
I don't even know if I want to add *any* wifi_things here at all. I
don't actually have much data available directly at this point, or at
least not in a format that would be useful, so I think it'd be better
to have a BPF helper function to obtain wifi_things outside of the
struct itself, passing the struct bpf_wifi_md * (and thus getting
struct sk_buff * in the kernel code) to it.
> At the same time if most of the __sk_buff fields can be useful to
> wifimon, then just use it as-is (without restricting to 'len' only)
> and add wifi specific fields to it with a comment.
No, I don't think they can ever be useful.
johannes
next prev parent reply other threads:[~2017-04-18 9:55 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 ` [RFC 1/3] bpf/wireless: add wifimon program type Johannes Berg
2017-04-12 14:27 ` 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 [this message]
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=1492509349.2472.15.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.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.