Re: [dpdk-dev] [PATCH v1] net/tap: explain how to compile eBPF C file

["Wiles, Keith" <keith.wiles@intel.com>]

> On Jun 12, 2018, at 8:44 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
> 
> 12/06/2018 15:33, Wiles, Keith:
>> 
>>> On Jun 12, 2018, at 7:58 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
>>> 
>>> 12/06/2018 14:36, Wiles, Keith:
>>>> 
>>>>> On Jun 12, 2018, at 7:26 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
>>>>> 
>>>>> 11/06/2018 18:35, Wiles, Keith:
>>>>>> 
>>>>>>> On Jun 11, 2018, at 11:06 AM, Ophir Munk <ophirmu@mellanox.com> wrote:
>>>>>>> 
>>>>>>> This commit explains how to manually compile the C source file
>>>>>>> tap_bpf_program.c into an ELF file using the clang compiler.
>>>>>>> The code in tap_bpf_program.c requires definitions found in iproute2
>>>>>>> source code. This commit suggests cloning the iproute2 git tree and
>>>>>>> include its path in the clang command. It also adds inclusion of file
>>>>>>> bpf_api.h (required for eBPF definitions) which is located in iproute2
>>>>>>> source tree. For more details refer to TAP documentation.
>>>>>>> This commit is related to commits [1] and [2].
>>>>>> 
>>>>>> Normally I would have suggested that eBPF be disable in the TAP driver as it requires external code and programs, but that ship has sailed.
>>>>> 
>>>>> The external programs are required only to generate new instructions,
>>>>> changing the behaviour of the BPF program.
>>>>> Currently, the instructions for RSS behaviour are provided.
>>>>> 
>>>>>> I would like to see building the tap_bpf_program.o as a target in the Makefile, this way the developer can just run the ‘make bpf_program’ target and it would be simpler and less error prone.
>>> 
>>> As explained in the documentation, for now there is a dependency on iproute2
>>> for the compilation of this BPF program.
>>> So we cannot make it as simple as a "make command".
>>> Probably that we can rework it to change the dependency.
>>> I heard there are some good BPF libraries available now?
>> 
>> Well the dependence of iproute2 is really no different then requiring say libnuma, they just have to pull the code first to type the ‘make bpf_program’ right?
> 
> The iproute2 dependency is different because it is not a library.
> The .h file is never packaged.
> So we need to download the sources and set -I to this directory.

To eliminate the -I problem the clone could be done inside the tap directory and -I ./iproute2/include used, right?
The make target could even clone the code into the tap directory, which means we can solve these problems you are pointing out.

Go ahead and do what you want here, but making it harder for the developer should not be our normally mode of operation.

> 
> 
>> If that is the case then a make target make sense to me. If iproute2 is not found then an error, right?
> 
> 
>>>>> For this to happen, we need to improve the tools.
>>>> 
>>>> In what way do we need to improve the tools and which tools are we talking about. Building the .o file below appears to be a simple set of command lines. I have a question in my original email about what tool.
>>> 
>>> The .o file is only the an intermediate file.
>>> The next step (numbered as 5 in this patch) is to extract the section
>>> of BPF instructions to be uploaded in the kernel.
>>> This step must be done by a "tool". Ophir did it by hacking tc,
>>> but it is not upstreamed yet.
>>> There could be other ways (possibly easier) to achieve the same result.
>> 
>> Please change the doc to reflect the tool is not upstreamed yet and the developer needs to figure out how to extract the data from the binary.
>> 
>> I used objdump -j l3_l4 -s tap_bpf_program.o and got a hex dump of the l3_l4 section
>> 
>> 0000 bf160000 00000000 61681000 00000000 <Ascii characters>
>> ...
>> 
>> Someone schooled in the art of Python coding should be able to convert that output to a ‘C’ data array. :-)
>> 
>>> 
>>>>> It is a work in progress.
>>> 
>>> Contributions are welcome.
>>> 
>>>>> This is a very first step to use Linux BPF with DPDK.
>>>>> If there are more interests, we should really streamline its usage
>>>>> for all parts of DPDK which runs on top of some kernel code.
>>>> 
>>>> streamlining other parts of DPDK would be nice, but we are now talking about the tap/eBPF patch.
>> 
>> Regards,
>> Keith

Regards,
Keith