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. > > > 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.
