From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: "Daniel T. Lee" <danieltimlee@gmail.com>,
Stephen Hemminger <stephen@networkplumber.org>,
David Ahern <dsahern@gmail.com>,
Jesper Dangaard Brouer <brouer@redhat.com>,
John Fastabend <john.fastabend@gmail.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>,
netdev@vger.kernel.org
Subject: Re: [PATCH 0/2] tools: bpftool: add net (un)load command to load XDP
Date: Tue, 30 Jul 2019 16:17:56 -0700 [thread overview]
Message-ID: <20190730231754.efh3fj4mnsbv445l@ast-mbp> (raw)
In-Reply-To: <20190730155915.5bbe3a03@cakuba.netronome.com>
On Tue, Jul 30, 2019 at 03:59:15PM -0700, Jakub Kicinski wrote:
> 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?
I don't think it has anything to do with 'unix philosophy'.
Here the proposal to teach bpftool to attach xdp progs.
I see nothing wrong with that.
Another reason is iproute2 is still far away from adopting libbpf.
So all the latest goodness like BTF, introspection, etc will not
be available to iproute2 users for some time.
Even when iproute2 is ready it would be convenient for folks like me
(who need to debug stuff in production) to remember cmd line of
bpftool only to introspect the server. Debugging often includes
detaching/attaching progs. Not only doing 'bpftool p s'.
If bpftool was taught to do equivalent of 'ip link' that would be
very different story and I would be opposed to that.
next prev parent reply other threads:[~2019-07-30 23:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-30 18:48 [PATCH 0/2] tools: bpftool: add net (un)load command to load XDP Daniel T. Lee
2019-07-30 18:48 ` [PATCH 1/2] tools: bpftool: add net load command to load XDP on interface Daniel T. Lee
2019-07-31 9:38 ` Jesper Dangaard Brouer
2019-07-31 10:08 ` Jesper Dangaard Brouer
2019-07-31 18:23 ` Daniel T. Lee
2019-07-30 18:48 ` [PATCH 2/2] tools: bpftool: add net unload command to unload " Daniel T. Lee
2019-07-30 20:04 ` [PATCH 0/2] tools: bpftool: add net (un)load command to load XDP Andrii Nakryiko
2019-07-30 22:59 ` Jakub Kicinski
2019-07-30 23:17 ` Alexei Starovoitov [this message]
2019-07-31 0:07 ` Jakub Kicinski
2019-07-31 0:23 ` Alexei Starovoitov
2019-07-31 1:21 ` Jakub Kicinski
2019-07-31 1:52 ` Alexei Starovoitov
2019-07-31 9:29 ` Jesper Dangaard Brouer
2019-07-31 21:59 ` David Ahern
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=20190730231754.efh3fj4mnsbv445l@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=danieltimlee@gmail.com \
--cc=dsahern@gmail.com \
--cc=jakub.kicinski@netronome.com \
--cc=john.fastabend@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
/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