netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: David Miller <davem@davemloft.net>
Cc: 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: Wed, 12 Apr 2017 17:30:40 +0200	[thread overview]
Message-ID: <1492011040.2855.18.camel@sipsolutions.net> (raw)
In-Reply-To: <20170412.111913.497795978751789475.davem@davemloft.net>

On Wed, 2017-04-12 at 11:19 -0400, David Miller wrote:
> 
> > 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.
> 
> I would advise against this, let the parsing part use __sk_buff and
> therefore have maximum flexibility.  You really cannot predict the
> future, so in my opinion it might be unwise to constrain at this
> point.

So my point with the wifi_info() function to call from the BPF program
was just that putting something that's not already in struct sk_buff
into __sk_buff doesn't really make a lot of sense - we still have to
actually build it somewhere/somehow without knowing if it's going to be
needed by the program. We already have things like prog->cb_access and
prog->dst_needed now, but I'm not sure we want to blow that up much.

At the same time, technically I *do* have the information in skb->cb,
but the format thereof is something I really wouldn't want to let
trickle into the ABI. Therefore, I think if somebody needs something
like the bitrate, we should have a wifi_info() function that can return
the bitrate (among other things) without having to pre-build the data.
We can still cache it in mac80211 if multiple programs are there, dunno
if that makes sense.

Nevertheless, I think if I don't use __sk_buff as the program argument
then things get really messy, so I'll stick to that, and avoid adding
anything to it as much as possible.

johannes

  reply	other threads:[~2017-04-12 15:30 UTC|newest]

Thread overview: 16+ 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 ` [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
     [not found]   ` <20170412110726.9689-3-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-12 14:29     ` Johannes Berg
     [not found]       ` <1492007347.2855.12.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-12 15:22         ` David Miller
     [not found]           ` <20170412.112212.441025205054195351.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2017-04-12 15:25             ` Johannes Berg
2017-04-13  6:00   ` Johannes Berg
     [not found] ` <20170412110726.9689-1-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-12 14:27   ` [RFC 1/3] bpf/wireless: add wifimon program type Johannes Berg
     [not found]     ` <1492007254.2855.10.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-12 15:19       ` David Miller
2017-04-12 15:30         ` Johannes Berg [this message]
     [not found]           ` <1492011040.2855.18.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
2017-04-14 18:51             ` Alexei Starovoitov
2017-04-18  9:55               ` Johannes Berg
2017-04-18 10:58                 ` Daniel Borkmann
     [not found]                   ` <58F5F148.1090700-FeC+5ew28dpmcu3hnIyYJQ@public.gmane.org>
2017-04-18 11:28                     ` Johannes Berg
2017-04-18 11:35                       ` Johannes Berg
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=1492011040.2855.18.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).