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:

quoted

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.

quoted

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.
  

quoted

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.

quoted

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.

quoted

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.