From: "Toke Høiland-Jørgensen" <firstname.lastname@example.org> To: Edward Cree <email@example.com>, John Fastabend <firstname.lastname@example.org>, Alexei Starovoitov <email@example.com> Cc: Daniel Borkmann <firstname.lastname@example.org>, Alexei Starovoitov <email@example.com>, Martin KaFai Lau <firstname.lastname@example.org>, Song Liu <email@example.com>, Yonghong Song <firstname.lastname@example.org>, Marek Majkowski <email@example.com>, Lorenz Bauer <firstname.lastname@example.org>, Alan Maguire <email@example.com>, Jesper Dangaard Brouer <firstname.lastname@example.org>, David Miller <email@example.com>, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH bpf-next v3 1/5] bpf: Support chain calling multiple BPF programs after each other Date: Tue, 22 Oct 2019 20:07:42 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Edward Cree <firstname.lastname@example.org> writes: > On 17/10/2019 13:11, Toke Høiland-Jørgensen wrote: >> I think there's a conceptual disconnect here in how we view what an XDP >> program is. In my mind, an XDP program is a stand-alone entity tied to a >> particular application; not a library function that can just be inserted >> into another program. > To me, an XDP (or any other eBPF) program is a function that is already > being 'inserted into another program', namely, the kernel. It's a > function that's being wired up to a hook in the kernel. Which isn't > so different to wiring it up to a hook in a function that's wired up to > a hook in the kernel (which is what my proposal effectively does). Yes, see: Different mental models leading to different notions of what is the natural way to do things :) >> Setting aside that for a moment; the reason I don't think this belongs >> in userspace is that putting it there would carry a complexity cost that >> is higher than having it in the kernel. > Complexity in the kernel is more expensive than in userland. There are > several reasons for this, such as: > * The kernel's reliability requirements are stricter — a daemon that > crashes can be restarted, a kernel that crashes ruins your day. > * Userland has libraries available for many common tasks that can't be > used in the kernel. > * Anything ABI-visible (which this would be) has to be kept forever even > if it turns out to be a Bad Idea™, because We Do Not Break > Userspace™. To me, the first and last of those are actually arguments for putting this into the kernel (from the consuming application's PoV). Surely we want something that's reliable and well-supported? ;) > The last of these is the big one, and means that wherever possible the > proper course is to prototype functionality in userspace, and then > once the ABI is solid and known-useful, it can move to the kernel if > there's an advantage to doing so To me, the prototyping was the tail call-based stuff Facebook and Cloudflare has been doing, and this is an attempt to synthesise that into something that we can actually agree to support as part of the XDP feature set. >> - Add a new dependency to using XDP (now you not only need the kernel >> and libraries, you'll also need the daemon). > You'll need *a* daemon. You won't be tied to a specific > implementation. But the point is that I *want* this to be a specific implementation; or rather, a specific interface. I.e., I want this to be an interface that people can rely on being available, rather than have a proliferation of slightly different ways to achieve this that are subtly incompatible. >> - Keeping track of which XDP programs are loaded and attached to >> each interface > There's already an API to query this. There's an API, but the daemon still has to deal with it. > You would probably want an atomic cmpxchg operation, so that you can > detect if someone else is fiddling with XDP and scream noisy warnings. Yup, probably going to do some sort of atomic program replace API in any case :) >> - Some kind of interface with the verifier; if an app does >> xdpd_rpc_load(prog), how is the verifier result going to get back >> to the caller? > The daemon will get the verifier log back when it tries to update the > program; it might want to do a bit of translation before passing it > on, but an RPC call can definitely return errors to the caller. I wasn't implying that it was impossible to report errors over RPC. I was saying that you "a bit of translation" is not as trivial as you make it out to be... > In the Ideal World of kernel dynamic linking, of course, each app prog > gets submitted to the verifier by the app to create a floating function > in the kernel that's not bound to any XDP hook (app gets its verifier > responses at this point) I believe this is what Alexei means by "indirect calls". That is different, though, because it implies that each program lives as a separate object in the kernel - and so it might actually work. What you were talking about (until this paragraph) was something that was entirely in userspace, and all the kernel sees is a blob of the eBPF equivalent of `cat *.so > my_composite_prog.so`. -Toke
next prev parent reply other threads:[~2019-10-22 18:07 UTC|newest] Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-07 17:20 [PATCH bpf-next v3 0/5] xdp: Support multiple programs on a single interface through chain calls Toke Høiland-Jørgensen 2019-10-07 17:20 ` [PATCH bpf-next v3 1/5] bpf: Support chain calling multiple BPF programs after each other Toke Høiland-Jørgensen 2019-10-07 20:42 ` Alexei Starovoitov 2019-10-08 8:07 ` Toke Høiland-Jørgensen 2019-10-09 1:51 ` Alexei Starovoitov 2019-10-09 8:03 ` Toke Høiland-Jørgensen 2019-10-10 4:41 ` Alexei Starovoitov 2019-10-14 12:35 ` Toke Høiland-Jørgensen 2019-10-14 17:08 ` John Fastabend 2019-10-14 18:48 ` Toke Høiland-Jørgensen 2019-10-15 16:30 ` Edward Cree 2019-10-15 16:42 ` Toke Høiland-Jørgensen 2019-10-15 18:33 ` Edward Cree 2019-10-17 12:11 ` Toke Høiland-Jørgensen 2019-10-22 17:27 ` Edward Cree 2019-10-22 18:07 ` Toke Høiland-Jørgensen [this message] 2019-11-12 2:51 ` static and dynamic linking. Was: [PATCH bpf-next v3 1/5] bpf: Support chain calling multiple BPF Alexei Starovoitov 2019-11-12 16:20 ` Toke Høiland-Jørgensen 2019-11-12 19:52 ` Alexei Starovoitov 2019-11-12 21:25 ` Edward Cree 2019-11-12 23:18 ` Alexei Starovoitov 2019-11-13 18:30 ` Edward Cree 2019-11-13 18:51 ` Andrii Nakryiko 2019-11-15 2:13 ` Alexei Starovoitov 2019-11-15 16:56 ` John Fastabend 2019-11-12 23:25 ` John Fastabend 2019-11-13 0:21 ` Alexei Starovoitov 2019-11-13 5:33 ` John Fastabend 2019-11-15 1:50 ` Alexei Starovoitov 2019-11-15 16:39 ` John Fastabend 2019-11-14 15:41 ` Toke Høiland-Jørgensen 2019-11-12 16:32 ` Edward Cree 2019-11-15 11:48 ` Lorenz Bauer 2019-11-15 23:02 ` Alexei Starovoitov 2019-11-18 13:29 ` Lorenz Bauer 2019-10-21 23:51 ` [PATCH bpf-next v3 1/5] bpf: Support chain calling multiple BPF programs after each other Edward Cree 2019-10-16 2:28 ` Alexei Starovoitov 2019-10-16 8:27 ` Jesper Dangaard Brouer 2019-10-16 10:35 ` Daniel Borkmann 2019-10-16 11:16 ` Toke Høiland-Jørgensen 2019-10-16 13:51 ` Toke Høiland-Jørgensen 2019-10-19 20:09 ` bpf indirect calls Alexei Starovoitov 2019-10-20 10:58 ` Toke Høiland-Jørgensen 2019-10-25 16:30 ` Alexei Starovoitov 2019-10-27 12:15 ` Toke Høiland-Jørgensen 2019-10-09 10:19 ` [PATCH bpf-next v3 1/5] bpf: Support chain calling multiple BPF programs after each other Jesper Dangaard Brouer 2019-10-09 17:57 ` Alexei Starovoitov 2019-10-07 17:20 ` [PATCH bpf-next v3 2/5] bpf: Add support for setting chain call sequence for programs Toke Høiland-Jørgensen 2019-10-07 20:38 ` Daniel Borkmann 2019-10-08 8:09 ` Toke Høiland-Jørgensen 2019-10-07 17:20 ` [PATCH bpf-next v3 3/5] tools: Update bpf.h header for program chain calls Toke Høiland-Jørgensen 2019-10-07 17:20 ` [PATCH bpf-next v3 4/5] libbpf: Add syscall wrappers for BPF_PROG_CHAIN_* commands Toke Høiland-Jørgensen 2019-10-07 17:20 ` [PATCH bpf-next v3 5/5] selftests: Add tests for XDP chain calls Toke Høiland-Jørgensen 2019-10-07 18:58 ` [PATCH bpf-next v3 0/5] xdp: Support multiple programs on a single interface through " John Fastabend 2019-10-08 8:42 ` Toke Høiland-Jørgensen
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH bpf-next v3 1/5] bpf: Support chain calling multiple BPF programs after each other' \ /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
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).