On 3/23/20 1:23 PM, Toke Høiland-Jørgensen wrote: >>>> I agree here. And yes, I've been working on extending bpf_link into >>>> cgroup and then to XDP. We are still discussing some cgroup-specific >>>> details, but the patch is ready. I'm going to post it as an RFC to get >>>> the discussion started, before we do this for XDP. >>> >>> Well, my reason for being skeptic about bpf_link and proposing the >>> netlink-based API is actually exactly this, but in reverse: With >>> bpf_link we will be in the situation that everything related to a netdev >>> is configured over netlink *except* XDP. +1 >> >> One can argue that everything related to use of BPF is going to be >> uniform and done through BPF syscall? Given variety of possible BPF >> hooks/targets, using custom ways to attach for all those many cases is >> really bad as well, so having a unifying concept and single entry to >> do this is good, no? > > Well, it depends on how you view the BPF subsystem's relation to the > rest of the kernel, I suppose. I tend to view it as a subsystem that > provides a bunch of functionality, which you can setup (using "internal" > BPF APIs), and then attach that object to a different subsystem > (networking) using that subsystem's configuration APIs. > again, +1. bpf syscall is used for program related manipulations like load and unload. Attaching that program to an object has a type unique solution - e.g., netlink for XDP and ioctl for perf_events.
