David Ahern <[email protected]> writes: > On 6/30/26 4:00 AM, Toke Høiland-Jørgensen wrote: >>> It does not make sense to require a flag to get lookup output. vlan >>> proto of 0 is not valid, so it is a clear indication that the vlan >>> output parameters were not set during the lookup. >> >> Okay, so we could just unconditionally set the VLAN fields, but if we >> start rewriting the ifindex that would be a change of the existing >> behaviour that could break existing applications, no? > > Consistently dealing with upper devices is one of the reasons I never > sent patches for vlan support. > > xdp support is at the driver layer for real (physical) devices. The fib > lookup is going to return the vlan device index - a virtual device. > Support for xdp should not be propagated to virtual devices; it goes > against the intent of xdp. Any trip down this path will have to decide > how to handle vlan-in-vlan use cases. Where is the line drawn for fast > networking?
Right, which is why we need building blocks that makes it possible for XDP programs to do the right thing in the BPF code :) A helper that resolves the parent could be used for stacked VLANs as well (just calling the helper multiple times). >> Specifically, if an XDP application has a table of the interfaces it >> forwards between, today they'd get a VLAN interface ifindex, which would >> not be in that table, and the application would return XDP_PASS. Whereas >> if we change the ifindex and populate the VLAN tag, suddenly the >> interface would be in the table, but because the application doesn't >> read the returned VLAN tag, it will end up sending packets out without >> tagging them, leading to broken forwarding. > > I have not followed developments over the past few years. Does XDP have > support for vlan acceleration in the Tx path now? You really want that > to deal with vlans and not replicating s/w processing in ebpf. It does not, no. There's TX metadata for AF_XDP, but VLAN support is not in there (see include/uapi/linux/if_xdp.h). Doesn't mean software VLAN handling can't be useful, though; there are use cases other than the very high end where XDP can speed things up even if it has to write a VLAN tag or two... >> So if we don't want the flag, we'd need some other mechanism to resolve >> the parent ifindex, AFAICT? Maybe a xdp_get_parent_ifindex() kfunc, say? >> That could also be made generic for other stacked interface types, I >> suppose. >> >> WDYT? > > dealing with stacked devices is hard :-) > > What is the return is a bond device or a vlan on a bond device? Well, bond devices have XDP support, so you can just redirect to those :) But yeah, each type of stacked device would need to pass different information through to the XDP program, and the program would need to support those. Building a single XDP program that supports all of them will require quite a bit of code, and would probably not perform super well. But most deployments have distinct subsets of features they need, so this does not have to be a blocker, IMO? -Toke
