On 09/25/2017 06:01 PM, Alexei Starovoitov wrote:
On Mon, Sep 25, 2017 at 01:02:04PM +0200, Daniel Borkmann wrote:On 09/25/2017 11:41 AM, Daniel Borkmann wrote:On 09/25/2017 11:25 AM, Jesper Dangaard Brouer wrote:On Sun, 24 Sep 2017 20:07:11 +0200 Eric Leblond <eric@xxxxxxxxx> wrote:Hello, bpf_load is implementing the set_link_xdp_fd() function and it seems this function is not available in libbpf.I also ran into this problem, when I wanted to switch my XDP programs into using tools/lib/bpf/.Right.E.g.: https://github.com/netoptimizer/prototype-kernel/commit/5397e596c30416763Should it be the case or should it be part of another library ?I'm not sure... maybe Alexei, Daniel or Wang have an opinion?It seems that none of the actual attach infra is handled in tools/lib/bpf/, meaning neither attaching the fd to kprobes/ uprobes/tracepoints nor tc or xdp, so adding a special case only for xdp into the lib feels that we probably might be better off putting this either into its own mini lib on top of that,That could potentially go to tools/lib/xdp/, probably would be the best option.I'm afraid it may spiral out of control. If we create such dirs, we'd need one for xdp, tc, cgroup, tracepoint, kprobe. Differentiating the libraries by type of attach point is imo too fine grained. Why not to put everything into toos/lib/bpf ? New file for netlink stuff is easy enough and we can gatekeep it with some knob in the Makefile, so perf build won't need to include it.
Personally, I don't really have a strong opinion on that. This could probably be made a bit modular for each attach handler with the option to compile some of them out if not desired, so could work as well.