[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181209181737.62c0568b@cakuba.netronome.com>
Date: Sun, 9 Dec 2018 18:17:37 -0800
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Björn Töpel <bjorn.topel@...il.com>
Cc: magnus.karlsson@...el.com, magnus.karlsson@...il.com,
ast@...nel.org, daniel@...earbox.net, netdev@...r.kernel.org,
Björn Töpel
<bjorn.topel@...el.com>, brouer@...hat.com, u9012063@...il.com,
qi.z.zhang@...el.com
Subject: Re: [PATCH bpf-next 6/7] xsk: load a builtin XDP program on
XDP_ATTACH
On Fri, 7 Dec 2018 12:44:30 +0100, Björn Töpel wrote:
> From: Björn Töpel <bjorn.topel@...el.com>
>
> This commit extends the XDP_ATTACH bind option by loading a builtin
> XDP program.
>
> The builtin program is the simplest program possible to redirect a
> frame to an attached socket. In restricted C it would look like this:
>
> SEC("xdp")
> int xdp_prog(struct xdp_md *ctx)
> {
> return bpf_xsk_redirect(ctx);
> }
>
> For many XDP socket users, this program would be the most common one.
>
> The builtin program loaded via XDP_ATTACH behaves, from an
> install-to-netdev/uninstall-from-netdev point of view, different from
> regular XDP programs. The easiest way to look at it is as a 2-level
> hierarchy, where regular XDP programs has precedence over the builtin
> one.
>
> If no regular XDP program is installed to the netdev, the builtin will
> be install. If the builtin program is installed, and a regular is
> installed, the regular XDP will have precedence over the builtin one.
>
> Further, if a regular program is installed, and later removed, the
> builtin one will automatically be installed.
>
> The sxdp_flags field of struct sockaddr_xdp gets two new options
> XDP_BUILTIN_SKB_MODE and XDP_BUILTIN_DRV_MODE, which maps to the
> corresponding XDP netlink install flags.
>
> Signed-off-by: Björn Töpel <bjorn.topel@...el.com>
Why not add this functionality to libbpf? Libbpf would really benefit
from better AF_XDP support, this would be a trivial part of it.
Are we going to stop here or take the next logical step of not invoking
the BPF program (and paying retpoline cost) at all if we know its the
"built-in/just redirect to the xsk" program? Because if the answer is
"yes" we could just cut to the chase we can avoid all this unnecessary
complexity.
Powered by blists - more mailing lists