[PATCH] tap: fix build of tap_bpf_program

[Loftus, Ciara]

> On 7/20/2023 8:45 AM, Ferruh Yigit wrote:
> > On 7/19/2023 5:12 PM, Stephen Hemminger wrote:
> >> On Wed, 19 Jul 2023 11:03:36 +0100
> >> Ferruh Yigit <ferruh.yigit at amd.com> wrote:
> >>
> >>> On 7/19/2023 11:00 AM, Ferruh Yigit wrote:
> >>>> On 7/17/2023 8:15 PM, Stephen Hemminger wrote:
> >>>>> The tap_bpf_program.c is not built as part of normal DPDK
> >>>>> EAL environment. It is intended to be built standalone
> >>>>> and does not use rte_common.h.
> >>>>>
> >>>>> This reverts the related change from
> >>>>> commit ef5baf3486e0 ("replace packed attributes")
> >>>>>
> >>>>> Note: this patch will cause expected warnings from checkpatch
> >>>>> because the code involved is not used directly in DPDK environment.
> >>>>>
> >>>>> Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
> >>>>>
> >>>>
> >>>> Agree, this seems done by mistake as part of batch update,
> >>>>
> >>>> Acked-by: Ferruh Yigit <ferruh.yigit at amd.com>
> >>>>
> >>>>
> >>>> But I can't update the bpf file at all, if I am not missing something I
> >>>
> >>> * I can't *compile* the bpf file ...
> >>>
> >>>> am not sure if we should get just this update or have a patch/patchset
> >>>> that fixes the build.
> >>>>
> >>>> @Ophir, how the bpf file is compiled? And did you test it recently?
> >>>>
> >>>> I am using command from the documentation:
> >>>> `clang -O2 -emit-llvm -c tap_bpf_program.c -o - | llc -march=bpf
> >>>> -filetype=obj -o tap_bpf_program.o`
> >>
> >> It looks like this won't work because it was expecting to be able
> >> to find header files from older version of iproute2.  These are not
> >> distributed, and the change to support libbpf in iproute2 makes the
> >> current versions not work.
> >>
> >> As a stopgap, will look back in history and see what version of header
> >> files will at least get a working build.
> >>
> >> From there, need to replace how the conversion of .o to array works.
> >> Would prefer to use dlopen() to read the ELF file rather than expecting
> >> developers to hack together their own tools.
> >>
> >> Not sure how much effort is really needed here. This is only being
> >> used for the case of rte_flow with multiq RSS. Probably, no one ever
> >> used it.
> >>
> >
> > Should we remove the file, instead of fixing '__rte_packed'?
> >
> 
> +Long, and af_xdp maintainers,
> 
> @Long, do you know if this bfp code is still in use somewhere, if so is
> the user interested in fixing/maintaining the code?
> 
> 
> @Ciara, @Qi, do you see any benefit to keep/extend this kind of bfp file
> usage? Do you think is this something to invest more?

If the code is still being used I would agree with Stephen that using dlopen or libbpf to load the eBPF code would be preferable. The current steps are difficult to follow.