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.

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.

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.

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.