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.
