Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP

From: Jakub Kicinski <kuba@kernel.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: "John Fastabend" <john.fastabend@gmail.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Andrii Nakryiko" <andrii.nakryiko@gmail.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Martin KaFai Lau" <kafai@fb.com>,
	"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
	"Andrii Nakryiko" <andriin@fb.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>,
	"Lorenz Bauer" <lmb@cloudflare.com>,
	"Andrey Ignatov" <rdna@fb.com>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP
Date: Wed, 25 Mar 2020 11:20:05 -0700	[thread overview]
Message-ID: <20200325112005.205d985a@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <20200325180638.el22n4ms6aau42r4@ast-mbp>

On Wed, 25 Mar 2020 11:06:38 -0700 Alexei Starovoitov wrote:
> On Tue, Mar 24, 2020 at 07:15:54PM -0700, Jakub Kicinski wrote:
> > It is the way to configure XDP today, so it's only natural to
> > scrutinize the attempts to replace it.   
> 
> No one is replacing it.

You're blocking extensions to the existing API, that means that part 
of the API is frozen and is being replaced.

> > Also I personally don't think you'd see this much push back trying to
> > add bpf_link-based stuff to cls_bpf, that's an add-on. XDP is
> > integrated very fundamentally with the networking stack at this point.
> >   
> > > Details are important and every case is different. So imo:
> > > converting ethtool to netlink - great stuff.
> > > converting netdev irq/queue management to netlink - great stuff too.
> > > adding more netlink api for xdp - really bad idea.  
> > 
> > Why is it a bad idea?  
> 
> I explained in three other emails. tldr: lack of ownership.

Those came later, I think, thanks.

Fine, maybe one day someone will find the extension you're proposing
useful. To me that's not a justification to freeze the existing API
(you said "adding more netlink api for xdp - really bad idea").

Besides, if you look at Toke's libxdp work (which exists), what's the
ownership of the attached program? Whichever application touched it
last?

The whole auto-detachment thing may work nicely in cls_bpf and
sub-programs attached to the root XDP program, but it's a bit hard 
to imagine how its useful for the singleton root XDP program.

> > There are plenty things which will only be available over netlink.
> > Configuring the interface so installing the XDP program is possible
> > (disabling features, configuring queues etc.). Chances are user gets
> > the ifindex of the interface to attach to over netlink in the first
> > place. The queue configuration (which you agree belongs in netlink)
> > will definitely get more complex to allow REDIRECTs to work more
> > smoothly. AF_XDP needs all sort of netlink stuff.  
> 
> sure. that has nothing to do with ownership of attachment.

AFAICT the allure to John is the uniform API, and no need for netlink.
I was explaining how that's a bad goal to have.

> > Netlink gives us the notification mechanism which is how we solve
> > coordination across daemons (something that BPF subsystem is only 
> > now trying to solve).  
> 
> I don't care about notifications on attachment and no one is trying to
> solve that as far as I can see. It's not a problem to solve in the first place.

Well, it's the existing solution to the "ownership" problem.
I think most people simply didn't know about it.