All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Jesper Dangaard Brouer <brouer@redhat.com>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, xdp-newbies@vger.kernel.org
Subject: Re: [PATCH v3 net-next RFC] Generic XDP
Date: Sat, 15 Apr 2017 00:18:19 +0200	[thread overview]
Message-ID: <58F14AAB.50201@iogearbox.net> (raw)
In-Reply-To: <20170414192814.GD41922@ast-mbp.thefacebook.com>

On 04/14/2017 09:28 PM, Alexei Starovoitov wrote:
> On Fri, Apr 14, 2017 at 11:05:25AM +0200, Jesper Dangaard Brouer wrote:
>>>
>>> We are consistently finding that there is this real need to
>>> communicate XDP capabilities, or somehow verify that the needs
>>> of an XDP program can be satisfied by a given implementation.
>>
>> I fully agree that we need some way to express capabilities[1]
>>
>>> Maximum headroom is just one.
>
> I don't like the idea of asking program author to explain capabilities
> to the kernel. Right now the verifier already understands more about
> the program than human does. If the verifier cannot deduct from the
> insns what program will be doing, it's pretty much guarantee
> that program author has no idea either.
> If we add 'required_headroom' as an extra flag to BPF_PROG_LOAD,
> the users will just pass something like 64 or 128 whereas the program
> might only be doing IPIP encap and that will cause kernel to
> provide extra headroom for no good reason or reject the program
> whereas it could have run just fine.

Fully agree, such an extension is likely to be used wrongly or with
some default size as we have right now with XDP_PACKET_HEADROOM to
cover most use cases in order to not bother the user to deal with
this resp. not to complicate things more.

> So I very much agree with this part:
>> ... or somehow verify that the needs
>> of an XDP program can be satisfied by a given implementation.
>
> we already have cb_access, dst_needed, xdp_adjust_head flags
> that verifier discovers in the program.
> For headroom we need one more. The verifier can see
> the constant passed into bpf_xdp_adjust_head().
> It's trickier if it's a variable, but the verifier can estimate min/max
> of the variable already and worst case it can say that it
> will be XDP_PACKET_HEADROOM.

+1, we should try hard to reuse such information from the verifier
to determine specific requirements the program has, and check against
them at prog attach time. This works okay so far for the already
mentioned bits in struct bpf_prog, and could be further extended.

> If the program is doing variable length bpf_xdp_adjust_head(),
> the human has no idea how much they need and cannot tell kernel anyway.

  reply	other threads:[~2017-04-14 22:18 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-12 18:54 [PATCH v3 net-next RFC] Generic XDP David Miller
2017-04-12 19:54 ` David Ahern
2017-04-13  2:08   ` David Miller
2017-04-13  2:16     ` David Ahern
2017-04-12 21:30 ` Stephen Hemminger
2017-04-12 21:49   ` Eric Dumazet
2017-04-13  1:55     ` David Miller
2017-04-13  1:54   ` David Miller
2017-04-13  4:20 ` Alexei Starovoitov
2017-04-13  6:10   ` Johannes Berg
2017-04-13 15:38     ` David Miller
2017-04-14 19:41       ` Alexei Starovoitov
2017-04-18  9:47         ` Johannes Berg
2017-04-18 23:09           ` Alexei Starovoitov
2017-04-13 15:37   ` David Miller
2017-04-13 19:22     ` Johannes Berg
2017-04-13 20:01       ` David Miller
2017-04-14  8:07         ` Johannes Berg
2017-04-14 19:09           ` Alexei Starovoitov
2017-04-14  9:05     ` Jesper Dangaard Brouer
2017-04-14 19:28       ` Alexei Starovoitov
2017-04-14 22:18         ` Daniel Borkmann [this message]
2017-04-14 22:30         ` Jakub Kicinski
2017-04-15  0:46           ` Alexei Starovoitov
2017-04-15  1:47             ` Jakub Kicinski
2017-04-16 20:26             ` Jesper Dangaard Brouer
2017-04-17 19:49               ` David Miller
2017-04-17 23:04                 ` Alexei Starovoitov
2017-04-17 23:33                   ` Daniel Borkmann
2017-04-18 18:46                   ` David Miller
2017-04-18 23:05                     ` Alexei Starovoitov
2017-04-13  6:48 ` Michael Chan
2017-04-13 15:38   ` David Miller
2017-04-13 15:57 ` Daniel Borkmann
2017-04-13 16:04   ` David Miller
2017-04-13 17:13 ` aa5c2fd79f: net/core/dev.c:#suspicious_rcu_dereference_check()usage kernel test robot
2017-04-13 17:13   ` kernel test robot

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=58F14AAB.50201@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=brouer@redhat.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=xdp-newbies@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.