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.
