[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200324115349.6447f99b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Tue, 24 Mar 2020 11:53:49 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: Andrii Nakryiko <andrii.nakryiko@...il.com>,
John Fastabend <john.fastabend@...il.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
Andrii Nakryiko <andriin@...com>,
"David S. Miller" <davem@...emloft.net>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Lorenz Bauer <lmb@...udflare.com>,
Andrey Ignatov <rdna@...com>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing
program when attaching XDP
On Tue, 24 Mar 2020 11:57:45 +0100 Toke Høiland-Jørgensen wrote:
> > If everyone is using libbpf, does kernel system (bpf syscall vs
> > netlink) matter all that much?
>
> This argument works the other way as well, though: If libbpf can
> abstract the subsystem differences and provide a consistent interface to
> "the BPF world", why does BPF need to impose its own syscall API on the
> networking subsystem?
Hitting the nail on the head there, again :)
Once upon a time when we were pushing for libbpf focus & unification,
one of my main motivations was that a solid library that most people
use give us the ability to provide user space abstractions.
As much as adding new kernel interfaces "to rule them all" is fun, it
has a real cost.
Powered by blists - more mailing lists