On Tue, Nov 03, 2020 at 03:32:55PM -0700, David Ahern wrote: > On 11/3/20 10:47 AM, Alexei Starovoitov wrote: > > since David is deaf to technical arguments, > It is not that I am "deaf to technical arguments"; you do not like my > response. > > The scope of bpf in iproute2 is tiny - a few tc modules (and VRF but it > does not need libbpf) which is a small subset of the functionality and > commands within the package. When Hangbin sent this patch set I got excited that finally tc command will start working with the latest bpf elf files. Currently "tc" supports 4 year old files which caused plenty of pain to bpf users. I got excited, but now I've realized that this patch set will make it worse. The bpf support in "tc" command instead of being obviously old and obsolete will be sort-of working with unpredictable delay between released kernel and released iproute2 version. The iproute2 release that suppose to match kernel release will be meaningless. More so, the upgrade of shared libbpf.so can make older iproute2/tc to do something new and unpredictable. The user experience will be awful. Not only the users won't know what to expect out of 'tc' command they won't have a way to debug it. All of it because iproute2 build will take system libbpf and link it as shared library by default. So I think iproute2 must not use libbpf. If I could remove bpf support from iproute2 I would do so as well. The current state of iproute2 is hurting bpf ecosystem and proposed libbpf+iproute2 integration will make it worse.
