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.