On Fri, 14 Aug 2020 08:56:48 +0200 Jason A. Donenfeld wrote: > On Thu, Aug 13, 2020 at 11:01 PM Jakub Kicinski <k...@kernel.org> wrote: > > > I had originally dropped this patch, but the issue kept coming up in > > > user reports, so here's a v4 of it. Testing of it is still rather slim, > > > but hopefully that will change in the coming days. > > > > Here an alternative patch, untested: > > Funny. But come on now... Why would we want to deprive our users of > system consistency?
We should try for consistency between xdp and cls_bpf instead. > Doesn't it make sense to allow users to use the same code across > interfaces? You actually want them to rewrite their code to use a > totally different trigger point just because of some weird kernel > internals between interfaces? We're not building an abstraction over the kernel stack so that users won't have to worry how things work. Users need to have a minimal understanding of how specific hooks integrate with the stack and what they are for. And therefore why cls_bpf is actually more efficient to use in L3 tunnel case. > Why not make XDP more useful and more generic across interfaces? It's > very common for systems to be receiving packets with a heavy ethernet > card from the current data center, in addition to receiving packets > from a tunnel interface connected to a remote data center, with a need > to run the same XDP program on both interfaces. Why not support that > kind of simplicity? > > This is _actually_ something that's come up _repeatedly_. This is a > real world need from real users who are doing real things. Why not > help them? I'm sure it comes up repeatedly because we don't return any errors, so people waste time investigating why it doesn't work. > It's not at the expense of any formal consistency, or performance, or > even semantic perfection. It costs very little to support these > popular use cases.
