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:

quoted

On Tue, Jul 30, 2019 at 03:59:15PM -0700, Jakub Kicinski wrote:

quoted

On Wed, 31 Jul 2019 03:48:19 +0900, Daniel T. Lee wrote:  

quoted

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.

quoted

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.

quoted

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

quoted

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.