Re: [PATCH net v3] net: xdp: account for layer 3 packets in generic skb handler

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Tue, Apr 28, 2020 at 09:51:13AM -0700, Jakub Kicinski wrote:
> > > Kinda same story as XDP egress, folks may be asking for it but that
> > > doesn't mean it makes sense.  
> > 
> > Well I do also happen to think that XDP egress is a good idea ;)
> 
> I was planning not to get involved in that conversation any more,
> let's move on :P

getting involved like arguing till last men standing is not something
people appreciate, but expressing your opinion in xdp egress thread
is certainly valuable.

> > That I can agree with - generic XDP should follow the semantics of
> > native XDP, not the other way around. But that's what we're doing here
> > (with the pseudo-MAC header approach), isn't it? Whereas if we were
> > saying "just write your XDP programs to assume only L3 packets" we would
> > be creating a new semantic for generic XDP...
> 
> But you do see the problem this creates on redirect already, right?
> Do we want to support all that? Add an if in the redirect fast path?
> There will _never_ be native XDP for WireGuard, it just doesn't make
> sense. 
> 
> Generic XDP is not a hook in its own right, frame is already firmly
> inside the stack, XDP is on the perimeter.

I think the proper fix here is to disallow generic xdp on l3 devices.
imo the only use case for generic xdp is to provide fallback for
heterogeneous fleet of servers. On most of the machines XDP program
will be using native XDP, but some servers might have either old
kernel or old hw and in such cases generic XDP saves the day.
XDP programmer doens't need to special case their user and kernel side
for long tail of servers where performance doesn't matter.

cls_bpf addresses the use case for folks that want to process
ingress/egress traffic on l3 netdev. I don't think there is a need
for xdp based solution in addition to cls_bpf. It's going to be
much more limited comparing to cls_bpf.