On Tue, Jan 25, 2022 at 9:52 AM Vincent Li <vincent.mc.li@xxxxxxxxx> wrote:
>
> this is macro I suspected in my implementation that could cause issue with BTF
>
> #define ENABLE_VTEP 1
> #define VTEP_ENDPOINT (__u32[]){0xec48a90a, 0xee48a90a, 0x1f48a90a,
> 0x2048a90a, }
> #define VTEP_MAC (__u64[]){0x562e984c3682, 0x582e984c3682,
> 0x5eaaed93fdf2, 0x5faaed93fdf2, }
> #define VTEP_NUMS 4
>
> On Tue, Jan 25, 2022 at 9:38 AM Vincent Li <vincent.mc.li@xxxxxxxxx> wrote:
> >
> > Hi
> >
> > While developing Cilium VTEP integration feature
> > https://github.com/cilium/cilium/pull/17370, I found a strange issue
> > that seems related to BTF and probably caused by my specific
> > implementation, the issue is described in
> > https://github.com/cilium/cilium/issues/18616, I don't know much about
> > BTF and not sure if my implementation is seriously flawed or just some
> > implementation bug or maybe not compatible with BTF. Strangely, the
> > issue appears related to number of VTEPs I use, no problem with 1 or 2
> > VTEP, 3, 4 VTEPs will have problem with BTF, any guidance from BTF
> > experts are appreciated :-).
> >
> > Thanks
> >
> > Vincent
Sorry for previous top post
it looks the compiler compiles the cilium bpf_lxc.c to bpf_lxc.o
differently and added " [21] .rodata.cst32 PROGBITS
0000000000000000 00011e68" when following macro exceeded 2 members
#define VTEP_ENDPOINT (__u32[]){0xec48a90a, 0xee48a90a, 0x1f48a90a,
0x2048a90a, }
no ".rodata.cst32" compiled in bpf_lxc.o when above VTEP_ENDPOINT
member <=2. any reason why compiler would do that?
