On Wed, 31 Jul 2019 03:48:19 +0900, Daniel T. Lee wrote: > Currently, bpftool net only supports dumping progs loaded on the > interface. To load XDP prog on interface, user must use other tool > (eg. iproute2). By this patch, with `bpftool net (un)load`, user can > (un)load XDP prog on interface.
I don't understand why using another tool is a bad thing :( What happened to the Unix philosophy? I remain opposed to duplicating iproute2's functionality under bpftool net :( The way to attach bpf programs in the networking subsystem is through the iproute2 commends - ip and tc.. It seems easy enough to add a feature to bpftool but from a perspective of someone adding a new feature to the kernel, and wanting to update user space components it's quite painful :( So could you describe to me in more detail why this is a good idea? Perhaps others can chime in? > $ ./bpftool prog > ... > 208: xdp name xdp_prog1 tag ad822e38b629553f gpl > loaded_at 2019-07-28T18:03:11+0900 uid 0 > ... > $ ./bpftool net load id 208 xdpdrv enp6s0np1 > $ ./bpftool net > xdp: > enp6s0np1(5) driver id 208 > ... > $ ./bpftool net unload xdpdrv enp6s0np1 > $ ./bpftool net > xdp: > ... > > The word 'load' is used instead of 'attach', since XDP program is not > considered as 'bpf_attach_type' and can't be attached with > 'BPF_PROG_ATTACH'. In this context, the meaning of 'load' is, prog will > be loaded on interface. > > While this patch only contains support for XDP, through `net (un)load`, > bpftool can further support other prog attach types. > > XDP (un)load tested on Netronome Agilio.
