On Tue, 30 Jul 2019 17:23:39 -0700, Alexei Starovoitov wrote: > On Tue, Jul 30, 2019 at 05:07:25PM -0700, Jakub Kicinski wrote: > > Nothing meaning you disagree it's duplicated effort and unnecessary > > LoC the community has to maintain, review, test..? > > I don't see duplicated effort.
Could you walk me through a scenario where, say, a new xdp attachment flag is added? How can there be support in both bpftool and iproute2 for specifying it without modifying both? How can we say we want to make iproute2 use libbpf instead of it's own library to avoid duplicated effort on the back end, and at the same time claim having two tools do the same thing is no duplication 🤯 > > Duplicating the same features in bpftool will only diminish the > > incentive for moving iproute2 to libbpf. > > not at all. why do you think so? Because iproute2's BPF has fallen behind so the simplest thing is to just contribute to bpftool. But iproute2 is the tool set for Linux networking, we can't let it bit rot :( Admittedly that's just me reading the tea leaves. > > 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. IMHO vaguely competent users of Linux networking will know ip link. If they are not vaguely competent, they should not attach XDP programs to interfaces by hand... > > 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 I think this came up when bpftool net was added and I never really understood it. > > > 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. I think the fact that we already have an implementation in iproute2, which is at the risk of bit rot is more important to me that the hypothetical scenario where everyone knows to just use bpftool (for XDP, for TC it's still iproute2 unless there's someone crazy enough to reimplement the TC functionality :)) I'm not sure we can settle our differences over email :) I have tremendous respect for all the maintainers I CCed here, if nobody steps up to agree with me I'll concede the bpftool net battle entirely :)
