On 6/29/26 9:08 AM, Toke Høiland-Jørgensen wrote: > David Ahern <[email protected]> writes: > >> On 6/23/26 9:05 PM, Avinash Duduskar wrote: >>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h >>> index 89b36de5fdbb..e00f0392e728 100644 >>> --- a/include/uapi/linux/bpf.h >>> +++ b/include/uapi/linux/bpf.h >>> @@ -3532,6 +3532,29 @@ union bpf_attr { >>> * Use the mark present in *params*->mark for the fib >>> lookup. >>> * This option should not be used with >>> BPF_FIB_LOOKUP_DIRECT, >>> * as it only has meaning for full lookups. >>> + * **BPF_FIB_LOOKUP_VLAN** >> >> This flag should not be needed. Patches for vlan support were never >> submitted (I have them in some old branch). Since the vlan params are >> initialized to 0, no new flag should be needed. Besides, these are >> output parameters. > > There's no enforcement from the kernel side of the parameters being > zero, though? So we do need the flag for feature detection; unless we > expect applications to do that out of band? But then we'd need a > mechanism to do that which could be... the presence of the flag in the > ENUM (and thus in BTF)? :) >
This is output direction - return from the fib lookup. 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.
