Re: [PATCH] tap: fix build of tap_bpf_program

[Ferruh Yigit <ferruh.yigit@amd.com>]

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@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@networkplumber.org>
>>>>>  
>>>>
>>>> Agree, this seems done by mistake as part of batch update,
>>>>
>>>> Acked-by: Ferruh Yigit <ferruh.yigit@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?