netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Yonghong Song <yhs@fb.com>
Cc: <ast@fb.com>, <daniel@iogearbox.net>, <netdev@vger.kernel.org>,
	<kernel-team@fb.com>
Subject: Re: [RFC PATCH bpf-next 0/4] tools/bpf: bpftool: add net support
Date: Wed, 5 Sep 2018 19:51:09 +0200	[thread overview]
Message-ID: <20180905195109.7fcc8a10@cakuba> (raw)
In-Reply-To: <20180903182647.1244630-1-yhs@fb.com>

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?

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?

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?

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

>             prog_id 3194 tag 846d29c14d0d7d26 act []
>   ifindex 2 name handle_egress flags direct-action flags_gen [not_in_hw ]
>             prog_id 3193 tag 387d281be9fe77aa
>   ]     

  parent reply	other threads:[~2018-09-05 22:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-03 18:26 [RFC PATCH bpf-next 0/4] tools/bpf: bpftool: add net support Yonghong Song
2018-09-03 18:26 ` [RFC PATCH bpf-next 1/4] tools/bpf: sync kernel uapi header if_link.h to tools Yonghong Song
2018-09-03 18:26 ` [RFC PATCH bpf-next 2/4] tools/bpf: move bpf/lib netlink related functions into a new file Yonghong Song
2018-09-03 18:26 ` [RFC PATCH bpf-next 3/4] tools/bpf: add more netlink functionalities in lib/bpf Yonghong Song
2018-09-03 18:26 ` [RFC PATCH bpf-next 4/4] tools/bpf: bpftool: add net support Yonghong Song
2018-09-05 17:51 ` Jakub Kicinski [this message]
2018-09-05 19:17   ` [RFC PATCH bpf-next 0/4] " Yonghong Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180905195109.7fcc8a10@cakuba \
    --to=jakub.kicinski@netronome.com \
    --cc=ast@fb.com \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).