On 6/30/26 10:04 AM, Toke Høiland-Jørgensen wrote:

David Ahern [off-list ref] writes:

quoted

On 6/30/26 4:00 AM, Toke Høiland-Jørgensen wrote:

quoted

quoted

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).

quoted

quoted

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...

quoted

quoted

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?

Seems to me the fib_lookup for xdp needs to return the bottom device,
not the vlan device, for forwarding to work. That's why I added the
fields to the struct. That allows the program to push the vlan header if
required. My preference (dream?) was that Tx path had support to tell
the redirect the vlan and h/w added it on send.

But really, once stacked devices come into play, I just wanted to make
sure thought is given to different use cases. As you know the lookup
struct if hard bound to 64B and it is trying to cover a lot of use cases.