[PATCH bpf] selftests/bpf: Support when CONFIG_VXLAN=m

[PATCH bpf] selftests/bpf: Support when CONFIG_VXLAN=m

[Alan Maguire]

If CONFIG_VXLAN is 'm', struct vxlanhdr will not be in vmlinux.h.
Add a ___local variant to support cases where vxlan is a module.

Fixes: 8517b1abe5ea ("selftests/bpf: Integrate test_tc_tunnel.sh tests into test_progs")
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
---
 .../selftests/bpf/progs/test_tc_tunnel.c      | 21 ++++++++++++-------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
index 7330c61b5730..7376df405a6b 100644
--- a/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
+++ b/tools/testing/selftests/bpf/progs/test_tc_tunnel.c
@@ -23,7 +23,12 @@ static const int cfg_udp_src = 20000;
 	(((__u64)len & BPF_ADJ_ROOM_ENCAP_L2_MASK)	\
 	 << BPF_ADJ_ROOM_ENCAP_L2_SHIFT)
 
-#define	L2_PAD_SZ	(sizeof(struct vxlanhdr) + ETH_HLEN)
+struct vxlanhdr___local {
+	__be32 vx_flags;
+	__be32 vx_vni;
+};
+
+#define	L2_PAD_SZ	(sizeof(struct vxlanhdr___local) + ETH_HLEN)
 
 #define	UDP_PORT		5555
 #define	MPLS_OVER_UDP_PORT	6635
@@ -154,7 +159,7 @@ static __always_inline int __encap_ipv4(struct __sk_buff *skb, __u8 encap_proto,
 		l2_len = ETH_HLEN;
 		if (ext_proto & EXTPROTO_VXLAN) {
 			udp_dst = VXLAN_UDP_PORT;
-			l2_len += sizeof(struct vxlanhdr);
+			l2_len += sizeof(struct vxlanhdr___local);
 		} else
 			udp_dst = ETH_OVER_UDP_PORT;
 		break;
@@ -195,12 +200,12 @@ static __always_inline int __encap_ipv4(struct __sk_buff *skb, __u8 encap_proto,
 		flags |= BPF_F_ADJ_ROOM_ENCAP_L2_ETH;
 
 		if (ext_proto & EXTPROTO_VXLAN) {
-			struct vxlanhdr *vxlan_hdr = (struct vxlanhdr *)l2_hdr;
+			struct vxlanhdr___local *vxlan_hdr = (struct vxlanhdr___local *)l2_hdr;
 
 			vxlan_hdr->vx_flags = VXLAN_FLAGS;
 			vxlan_hdr->vx_vni = VXLAN_VNI;
 
-			l2_hdr += sizeof(struct vxlanhdr);
+			l2_hdr += sizeof(struct vxlanhdr___local);
 		}
 
 		if (bpf_skb_load_bytes(skb, 0, l2_hdr, ETH_HLEN))
@@ -285,7 +290,7 @@ static __always_inline int __encap_ipv6(struct __sk_buff *skb, __u8 encap_proto,
 		l2_len = ETH_HLEN;
 		if (ext_proto & EXTPROTO_VXLAN) {
 			udp_dst = VXLAN_UDP_PORT;
-			l2_len += sizeof(struct vxlanhdr);
+			l2_len += sizeof(struct vxlanhdr___local);
 		} else
 			udp_dst = ETH_OVER_UDP_PORT;
 		break;
@@ -325,12 +330,12 @@ static __always_inline int __encap_ipv6(struct __sk_buff *skb, __u8 encap_proto,
 		flags |= BPF_F_ADJ_ROOM_ENCAP_L2_ETH;
 
 		if (ext_proto & EXTPROTO_VXLAN) {
-			struct vxlanhdr *vxlan_hdr = (struct vxlanhdr *)l2_hdr;
+			struct vxlanhdr___local *vxlan_hdr = (struct vxlanhdr___local *)l2_hdr;
 
 			vxlan_hdr->vx_flags = VXLAN_FLAGS;
 			vxlan_hdr->vx_vni = VXLAN_VNI;
 
-			l2_hdr += sizeof(struct vxlanhdr);
+			l2_hdr += sizeof(struct vxlanhdr___local);
 		}
 
 		if (bpf_skb_load_bytes(skb, 0, l2_hdr, ETH_HLEN))
@@ -639,7 +644,7 @@ static int decap_internal(struct __sk_buff *skb, int off, int len, char proto)
 			olen += ETH_HLEN;
 			break;
 		case VXLAN_UDP_PORT:
-			olen += ETH_HLEN + sizeof(struct vxlanhdr);
+			olen += ETH_HLEN + sizeof(struct vxlanhdr___local);
 			break;
 		}
 		break;
-- 
2.39.3

Re: [PATCH bpf] selftests/bpf: Support when CONFIG_VXLAN=m

[Alexis Lothoré]

Hello,

On Thu Jan 15, 2026 at 5:34 PM CET, Alan Maguire wrote:
> If CONFIG_VXLAN is 'm', struct vxlanhdr will not be in vmlinux.h.
> Add a ___local variant to support cases where vxlan is a module.

Just a naive question: for ebpf selftests, aren't we assuming a
dependency on a "fixed" kernel configuration (ie
tools/testing/selftests/bpf/{config,config.vm,config.<arch}), which
enables most of the features as built-in ? 

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH bpf] selftests/bpf: Support when CONFIG_VXLAN=m

[Alan Maguire]

On 16/01/2026 08:30, Alexis Lothoré wrote:
> Hello,
> 
> On Thu Jan 15, 2026 at 5:34 PM CET, Alan Maguire wrote:
>> If CONFIG_VXLAN is 'm', struct vxlanhdr will not be in vmlinux.h.
>> Add a ___local variant to support cases where vxlan is a module.
> 
> Just a naive question: for ebpf selftests, aren't we assuming a
> dependency on a "fixed" kernel configuration (ie
> tools/testing/selftests/bpf/{config,config.vm,config.<arch}), which
> enables most of the features as built-in ? 
> 

It's a good question - my take here is that we also need to remember 
that most folks interactions with BPF happen via distro kernels. Most distros 
tend to modularize their configs more extensively, and they also want to use 
the BPF selftests to qualify the particular config combination they have
so that they can be sure that users have a good BPF experience.
Often issues arise from this, and distro folks either report or post
fixes. This is all good, so if the only cost is a bit more flexibility
in the test environment, I'd say it's well worth supporting that. In
particular blockers to selftests compilation cause problems for this
process.

There are of course cases where having a very old toolchain or a highly
incompatible configuration that aren't supportable, but in general where there
is low-hanging fruit in making tests a bit more flexible, it's worth doing I 
think.

Alan

> Alexis
> 

Re: [PATCH bpf] selftests/bpf: Support when CONFIG_VXLAN=m

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko <andrii@kernel.org>:

On Thu, 15 Jan 2026 16:34:57 +0000 you wrote:
> If CONFIG_VXLAN is 'm', struct vxlanhdr will not be in vmlinux.h.
> Add a ___local variant to support cases where vxlan is a module.
> 
> Fixes: 8517b1abe5ea ("selftests/bpf: Integrate test_tc_tunnel.sh tests into test_progs")
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> ---
>  .../selftests/bpf/progs/test_tc_tunnel.c      | 21 ++++++++++++-------
>  1 file changed, 13 insertions(+), 8 deletions(-)

Here is the summary with links:
  - [bpf] selftests/bpf: Support when CONFIG_VXLAN=m
    https://git.kernel.org/bpf/bpf-next/c/47d440d0a5bb

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH bpf] selftests/bpf: Support when CONFIG_VXLAN=m

[Alexis Lothoré]

Hi Alan,

On Fri Jan 16, 2026 at 10:32 AM CET, Alan Maguire wrote:
> On 16/01/2026 08:30, Alexis Lothoré wrote:
>> Hello,
>> 
>> On Thu Jan 15, 2026 at 5:34 PM CET, Alan Maguire wrote:
>>> If CONFIG_VXLAN is 'm', struct vxlanhdr will not be in vmlinux.h.
>>> Add a ___local variant to support cases where vxlan is a module.
>> 
>> Just a naive question: for ebpf selftests, aren't we assuming a
>> dependency on a "fixed" kernel configuration (ie
>> tools/testing/selftests/bpf/{config,config.vm,config.<arch}), which
>> enables most of the features as built-in ? 
>> 
>
> It's a good question - my take here is that we also need to remember 
> that most folks interactions with BPF happen via distro kernels. Most distros 
> tend to modularize their configs more extensively, and they also want to use 
> the BPF selftests to qualify the particular config combination they have
> so that they can be sure that users have a good BPF experience.
> Often issues arise from this, and distro folks either report or post
> fixes. This is all good, so if the only cost is a bit more flexibility
> in the test environment, I'd say it's well worth supporting that. In
> particular blockers to selftests compilation cause problems for this
> process.
>
> There are of course cases where having a very old toolchain or a highly
> incompatible configuration that aren't supportable, but in general where there
> is low-hanging fruit in making tests a bit more flexible, it's worth doing I 
> think.

With a bit of delay: ok, thanks for your input. To clarify, my point was
not really about challenging your change but rather that I was not sure
about the policy here; supporting only the CI selftests configuration,
VS supporting other kernel configurations like distro configs (at the
cost of duplicating a bit kernel data strutures definitions).

Thanks,

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH bpf] selftests/bpf: Support when CONFIG_VXLAN=m

[Alexei Starovoitov]

On Mon, Jan 19, 2026 at 5:00 AM Alexis Lothoré
<alexis.lothore@bootlin.com> wrote:
>
> Hi Alan,
>
> On Fri Jan 16, 2026 at 10:32 AM CET, Alan Maguire wrote:
> > On 16/01/2026 08:30, Alexis Lothoré wrote:
> >> Hello,
> >>
> >> On Thu Jan 15, 2026 at 5:34 PM CET, Alan Maguire wrote:
> >>> If CONFIG_VXLAN is 'm', struct vxlanhdr will not be in vmlinux.h.
> >>> Add a ___local variant to support cases where vxlan is a module.
> >>
> >> Just a naive question: for ebpf selftests, aren't we assuming a
> >> dependency on a "fixed" kernel configuration (ie
> >> tools/testing/selftests/bpf/{config,config.vm,config.<arch}), which
> >> enables most of the features as built-in ?
> >>
> >
> > It's a good question - my take here is that we also need to remember
> > that most folks interactions with BPF happen via distro kernels. Most distros
> > tend to modularize their configs more extensively, and they also want to use
> > the BPF selftests to qualify the particular config combination they have
> > so that they can be sure that users have a good BPF experience.
> > Often issues arise from this, and distro folks either report or post
> > fixes. This is all good, so if the only cost is a bit more flexibility
> > in the test environment, I'd say it's well worth supporting that. In
> > particular blockers to selftests compilation cause problems for this
> > process.
> >
> > There are of course cases where having a very old toolchain or a highly
> > incompatible configuration that aren't supportable, but in general where there
> > is low-hanging fruit in making tests a bit more flexible, it's worth doing I
> > think.
>
> With a bit of delay: ok, thanks for your input. To clarify, my point was
> not really about challenging your change but rather that I was not sure
> about the policy here; supporting only the CI selftests configuration,
> VS supporting other kernel configurations like distro configs (at the
> cost of duplicating a bit kernel data strutures definitions).

All development efforts are focusing on selftest/bpf/config only.
We don't pay attention to what distros and hyperscalers enable or disable.
Small patches like this are fine, but they will bit rot
and if they cause issues down the line they will get reverted.