On Tue, Mar 24, 2020 at 12:22:47PM -0700, John Fastabend wrote:

quoted

Well, I wasn't talking about any of those subsystems, I was talking
about networking :)

My experience has been that networking in the strict sense of XDP no
longer exists on its own without cgroups, flow dissector, sockops,
sockmap, tracing, etc. All of these pieces are built, patched, loaded,
pinned and otherwise managed and manipulated as BPF objects via libbpf.

Because I have all this infra in place for other items its a bit odd
imo to drop out of BPF apis to then swap a program differently in the
XDP case from how I would swap a program in any other place. I'm
assuming ability to swap links will be enabled at some point.

Granted it just means I have some extra functions on the side to manage
the swap similar to how 'qdisc' would be handled today but still not as
nice an experience in my case as if it was handled natively.

Anyways the netlink API is going to have to call into the BPF infra
on the kernel side for verification, etc so its already not pure
networking.

quoted

In particular, networking already has a consistent and fairly
well-designed configuration mechanism (i.e., netlink) that we are
generally trying to move more functionality *towards* not *away from*
(see, e.g., converting ethtool to use netlink).

True. But BPF programs are going to exist and interop with other
programs not exactly in the networking space. Actually library calls
might be used in tracing, cgroups, and XDP side. It gets a bit more
interesting if the "same" object file (with some patching) runs in both
XDP and sockops land for example.

Thanks John for summarizing it very well.
It looks to me that netlink proponents fail to realize that "bpf for
networking" goes way beyond what netlink is doing and capable of doing in the
future. BPF_*_INET_* progs do core networking without any smell of netlink
anywhere. "But, but, but, netlink is the way to configure networking"... is
simply not true. Even in years before BPF sockets and syscalls were the way to
do it. netlink has plenty of awesome properties, but arguing that it's the
only true way to do networking is not matching the reality.
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.