On 9/5/18 10:51 AM, Jakub Kicinski wrote:
On Mon, 3 Sep 2018 11:26:43 -0700, Yonghong Song wrote:
The functionality to dump network driver and tc related bpf programs
are added. Currently, users can already use "ip link show <dev>"
and "tc filter show dev <dev> ..." to dump bpf program attachment
information for xdp programs and tc bpf programs.
The implementation here allows bpftool as a central place for
bpf introspection and users do not need to revert to other tools.
Also, we can make command simpler to dump bpf related information,
e.g., "bpftool net" is able to dump all xdp and tc bpf programs.
Why not implement this best-effort, unreliable (name spaces) additional
output the same way we added bpffs support, make it a flag to existing
list commands?
Do you mean to implement something like "bpftool -n prog" to show the
attachments for net-related bpf programs? I feel a separate command
"net" is better since it intends to show the context of the bpf program
as the same program may be installed in different places. This is
similar to other commands like "cgroup" and "perf".
My knee jerk reaction is that this is duplication of work. iproute2 can
show us the filters and xdp programs very easily. Will we add programs
attached to sockets as well? And lwtunnels? bpfilter?
This has been discussed in iovisor meeting, but let me summarize here.
I understand that iproute2 ip/tc can do exactly what I implemented here.
The implementation here is mostly from user experience point of view.
People worried about bpf performance/memory cost in the data center. So
they often ask what bpf programs are running in any host and what is the
context (attachment point) of all bpf programs? Most these engineers
are not networking/bpf/kernel engineers. So yes, we will need
to add programs attached to sockets, lwtunnels and bpfilters etc. later.
This may be a lower priority for me now since FB does not use them yet.
Currently, we already use bpftool do prog/map perf/cgroup dumps.
Extending bpftool is easier for user than using a different command
as not everybody is very familiar to esp. tc.
Would you be able to give us a convincing user scenario? What kind of
information is the user looking for? Are there going to be other
sub-commands to the 'net' object?
As of now, it just dumped bpf related information with prog_id (plus
other attachment specific information) so users can correlate back to
the program itself. No plan to add other sub-commands (except "dev
<name>") at this point.
For example,
$ bpftool net
xdp [
]
netdev_filters [
ifindex 2 name handle_icmp flags direct-action flags_gen [not_in_hw ]
How do you handle shared blocks here? Does the user really care about
the flags? What about ordering of filters?
shared block is not handled here. This can be added later.
yes, I can remove flags_gen. For "flags", may or may not. Will go
through dumped info and remove those not really needed.
The order of filters will be based on ifindex first and inside ifindex,
attached to class first, attached to qdisc second, attached to
root/clsact last.
prog_id 3194 tag 846d29c14d0d7d26 act []
ifindex 2 name handle_egress flags direct-action flags_gen [not_in_hw ]
prog_id 3193 tag 387d281be9fe77aa
]
