Message-ID: <025abc6b-6389-46b2-d2ac-4e6bf176e51f@fb.com>
Date:   Wed, 5 Sep 2018 12:17:59 -0700
From:   Yonghong Song <yhs@...com>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
CC:     <ast@...com>, <daniel@...earbox.net>, <netdev@...r.kernel.org>,
        <kernel-team@...com>
Subject: Re: [RFC PATCH bpf-next 0/4] tools/bpf: bpftool: add net support



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
>>    ]

Powered by blists - more mailing lists