Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP

David Ahern
2020-03-24T01:01:40Z

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.