[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190731002338.d4lp2grsmm3aaav3@ast-mbp>
Date: Tue, 30 Jul 2019 17:23:39 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc: "Daniel T. Lee" <danieltimlee@...il.com>,
Stephen Hemminger <stephen@...workplumber.org>,
David Ahern <dsahern@...il.com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
John Fastabend <john.fastabend@...il.com>,
Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>, netdev@...r.kernel.org
Subject: Re: [PATCH 0/2] tools: bpftool: add net (un)load command to load XDP
On Tue, Jul 30, 2019 at 05:07:25PM -0700, Jakub Kicinski wrote:
> On Tue, 30 Jul 2019 16:17:56 -0700, Alexei Starovoitov wrote:
> > 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.
>
> Nothing meaning you disagree it's duplicated effort and unnecessary
> LoC the community has to maintain, review, test..?
I don't see duplicated effort.
> > 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.
>
> Duplicating the same features in bpftool will only diminish the
> incentive for moving iproute2 to libbpf.
not at all. why do you think so?
> And for folks who deal
> with a wide variety of customers, often novices maintaining two
> ways of doing the same thing is a hassle :(
It's not the same thing.
I'm talking about my experience dealing with 'wide variety of bpf customers'.
They only have a fraction of their time to learn one tool.
Making every bpf customer learn ten tools is not an option.
> > 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'.
>
> Let's just put the two commands next to each other:
>
> ip link set xdp $PROG dev $DEV
>
> bpftool net attach xdp $PROG dev $DEV
>
> Are they that different?
yes.
they're different tools with they own upgrade/rollout cycle
>
> > If bpftool was taught to do equivalent of 'ip link' that would be
> > very different story and I would be opposed to that.
>
> Yes, that'd be pretty clear cut, only the XDP stuff is a bit more
> of a judgement call.
bpftool must be able to introspect every aspect of bpf programming.
That includes detaching and attaching anywhere.
Anyone doing 'bpftool p s' should be able to switch off particular
prog id without learning ten different other tools.
iproute2 is a small bit of it. There is cgroup and tracing too.
bpftool should be one tool to do everything directly related to bpf.
Powered by blists - more mailing lists