From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
"Stephen Hemminger" <stephen@networkplumber.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Alexei Starovoitov" <ast@kernel.org>,
"Martin KaFai Lau" <kafai@fb.com>,
"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
"David Miller" <davem@davemloft.net>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
brouer@redhat.com, "Anton Protopopov" <aspsk2@gmail.com>,
"Stanislav Fomichev" <sdf@fomichev.me>,
"Yoel Caspersen" <yoel@kviknet.dk>
Subject: Re: [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP)
Date: Fri, 23 Aug 2019 12:27:13 +0200 [thread overview]
Message-ID: <20190823122713.73450a4b@carbon> (raw)
In-Reply-To: <CAEf4BzZxb7qZabw6aDVaTqnhr3AGtwEo+DbuBR9U9tJr+qVuyg@mail.gmail.com>
On Wed, 21 Aug 2019 13:30:09 -0700
Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> On Tue, Aug 20, 2019 at 4:47 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> >
> > iproute2 uses its own bpf loader to load eBPF programs, which has
> > evolved separately from libbpf. Since we are now standardising on
> > libbpf, this becomes a problem as iproute2 is slowly accumulating
> > feature incompatibilities with libbpf-based loaders. In particular,
> > iproute2 has its own (expanded) version of the map definition struct,
> > which makes it difficult to write programs that can be loaded with both
> > custom loaders and iproute2.
> >
> > This series seeks to address this by converting iproute2 to using libbpf
> > for all its bpf needs. This version is an early proof-of-concept RFC, to
> > get some feedback on whether people think this is the right direction.
> >
> > What this series does is the following:
> >
> > - Updates the libbpf map definition struct to match that of iproute2
> > (patch 1).
>
>
> Hi Toke,
>
> Thanks for taking a stab at unifying libbpf and iproute2 loaders. I'm
> totally in support of making iproute2 use libbpf to load/initialize
> BPF programs. But I'm against adding iproute2-specific fields to
> libbpf's bpf_map_def definitions to support this.
>
> I've proposed the plan of extending libbpf's supported features so
> that it can be used to load iproute2-style BPF programs earlier,
> please see discussions in [0] and [1]. I think instead of emulating
> iproute2 way of matching everything based on user-specified internal
> IDs, which doesn't provide good user experience and is quite easy to
> get wrong, we should support same scenarios with better declarative
> syntax and in a less error-prone way. I believe we can do that by
> relying on BTF more heavily (again, please check some of my proposals
> in [0], [1], and discussion with Daniel in those threads). It will
> feel more natural and be more straightforward to follow. It would be
> great if you can lend a hand in implementing pieces of that plan!
>
> I'm currently on vacation, so my availability is very sparse, but I'd
> be happy to discuss this further, if need be.
>
> [0] https://lore.kernel.org/bpf/CAEf4BzbfdG2ub7gCi0OYqBrUoChVHWsmOntWAkJt47=FE+km+A@mail.gmail.com/
> [1] https://www.spinics.net/lists/bpf/msg03976.html
>
> > - Adds functionality to libbpf to support automatic pinning of maps when
> > loading an eBPF program, while re-using pinned maps if they already
> > exist (patches 2-3).
For production use-cases, libbpf really need an easier higher-level API
for re-using pinned maps, for establishing shared maps between
programs. The existing libbpf API bpf_object__pin_maps() and
bpf_object__unpin_maps(), which don't re-use pinned maps, are not
really usable, because they pin/unpin ALL maps in the ELF file.
What users really need is an easy way to specify, on a per map basis,
what kind of pinning and reuse/sharing they want. E.g. like iproute2
have, "global", "object-scope", and "no-pinning". ("ifindex-scope" would
be nice for XDP).
Today users have to split/reimplement bpf_prog_load_xattr(), and
use/add bpf_map__reuse_fd(). Which is that I ended doing for
xdp-cpumap-tc[2] (used in production at ISP) resulting in 142 lines of
extra code[3] that should have been hidden inside libbpf. And worse,
in this solution[4] the maps for reuse-pinning is specified in the code
by name. Thus, they cannot use a generic loader. That I why, I want
to mark the maps via a pinning member, like iproute2.
I really hope this moves in a practical direction, as I have the next
production request lined up (also from an ISP), and I hate to have to
advice them to choose the same route as [3].
[2] https://github.com/xdp-project/xdp-cpumap-tc/
[3] https://github.com/xdp-project/xdp-cpumap-tc/blob/master/src/xdp_iphash_to_cpu_user.c#L262-L403
[4] https://github.com/xdp-project/xdp-cpumap-tc/blob/master/src/xdp_iphash_to_cpu_user.c#L431-L441
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2019-08-23 10:27 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-20 11:47 [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP) Toke Høiland-Jørgensen
2019-08-20 11:47 ` [RFC bpf-next 1/5] libbpf: Add map definition struct fields from iproute2 Toke Høiland-Jørgensen
2019-08-20 11:47 ` [RFC bpf-next 2/5] libbpf: Add support for auto-pinning of maps with reuse on program load Toke Høiland-Jørgensen
2019-08-20 11:47 ` [RFC bpf-next 3/5] libbpf: Add support for specifying map pinning path via callback Toke Høiland-Jørgensen
2019-08-20 11:47 ` [RFC bpf-next 4/5] iproute2: Allow compiling against libbpf Toke Høiland-Jørgensen
2019-08-22 8:58 ` Daniel Borkmann
2019-08-22 10:43 ` Toke Høiland-Jørgensen
2019-08-22 11:45 ` Daniel Borkmann
2019-08-22 12:04 ` Toke Høiland-Jørgensen
2019-08-22 12:33 ` Daniel Borkmann
2019-08-22 13:38 ` Toke Høiland-Jørgensen
2019-08-22 13:45 ` Daniel Borkmann
2019-08-22 15:28 ` Toke Høiland-Jørgensen
2019-08-20 11:47 ` [RFC bpf-next 5/5] iproute2: Support loading XDP programs with libbpf Toke Høiland-Jørgensen
2019-08-21 19:26 ` [RFC bpf-next 0/5] Convert iproute2 to use libbpf (WIP) Alexei Starovoitov
2019-08-21 21:00 ` Toke Høiland-Jørgensen
2019-08-22 7:52 ` Andrii Nakryiko
2019-08-22 10:38 ` Toke Høiland-Jørgensen
2019-08-21 20:30 ` Andrii Nakryiko
2019-08-21 21:07 ` Toke Høiland-Jørgensen
2019-08-22 7:49 ` Andrii Nakryiko
2019-08-22 8:33 ` Daniel Borkmann
2019-08-22 11:48 ` Toke Høiland-Jørgensen
2019-08-22 11:49 ` Toke Høiland-Jørgensen
2019-08-23 6:31 ` Andrii Nakryiko
2019-08-23 11:29 ` Toke Høiland-Jørgensen
2019-08-28 20:40 ` Andrii Nakryiko
2020-02-03 7:29 ` Andrii Nakryiko
2020-02-03 19:34 ` Toke Høiland-Jørgensen
2020-02-04 0:56 ` Andrii Nakryiko
2020-02-04 1:46 ` David Ahern
2020-02-04 3:41 ` Andrii Nakryiko
2020-02-04 4:52 ` David Ahern
2020-02-04 5:00 ` Andrii Nakryiko
2020-02-04 8:25 ` Toke Høiland-Jørgensen
2020-02-04 18:47 ` Andrii Nakryiko
2020-02-04 19:19 ` Toke Høiland-Jørgensen
2020-02-04 19:29 ` Andrii Nakryiko
2020-02-04 21:56 ` Toke Høiland-Jørgensen
2020-02-04 22:12 ` David Ahern
2020-02-04 22:35 ` Toke Høiland-Jørgensen
2020-02-04 23:13 ` David Ahern
2020-02-05 10:37 ` Toke Høiland-Jørgensen
2020-02-04 8:27 ` Toke Høiland-Jørgensen
2019-08-23 10:27 ` Jesper Dangaard Brouer [this message]
2019-08-28 20:23 ` Andrii Nakryiko
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=20190823122713.73450a4b@carbon \
--to=brouer@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=aspsk2@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=songliubraving@fb.com \
--cc=stephen@networkplumber.org \
--cc=toke@redhat.com \
--cc=yhs@fb.com \
--cc=yoel@kviknet.dk \
/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).