[PATCH] tap: fix build of tap_bpf_program

[Long Li]

> Subject: Re: [PATCH] tap: fix build of tap_bpf_program
> 
> 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?

I haven't seen usage in the support cases we have handled. Given support cases represent very small percent of actual usage, I suspect it's still being used.
> 
> 
> @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?