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

[Ferruh Yigit]

On 6/12/2018 3:02 PM, Ophir Munk wrote:
> Please note that other than cloning iproute2 we also need to install clang and llvm tools versions 3.7 and upper.
> Not sure there are clang and llvm packages of the required versions for the common distributions. 
> I compiled the tools source code and installed them manually.

Hi Keith, Thomas,

What do you suggest on this patch?

The "tap_bpf_program.c" is already withing the tap pmd this patch improves the
doc about how to compile it, although it may not be so user friendly as Keith
pointed, I believe better to get doc improvement here.

And there is a code update "+#include "bpf_api.h", which includes a iproute2
header, I am not sure about this one and how to manage this dependency.

> 
>> -----Original Message-----
>> From: Wiles, Keith [mailto:keith.wiles at intel.com]
>> Sent: Tuesday, June 12, 2018 4:53 PM
>> To: Thomas Monjalon <thomas at monjalon.net>
>> Cc: dev at dpdk.org; Ophir Munk <ophirmu at mellanox.com>; Pascal Mazon
>> <pascal.mazon at 6wind.com>; Olga Shern <olgas at mellanox.com>
>> Subject: Re: [dpdk-dev] [PATCH v1] net/tap: explain how to compile eBPF C
>> file
>>
>>
>>
>>> On Jun 12, 2018, at 8:44 AM, Thomas Monjalon <thomas at monjalon.net>
>> wrote:
>>>
>>> 12/06/2018 15:33, Wiles, Keith:
>>>>
>>>>> On Jun 12, 2018, at 7:58 AM, Thomas Monjalon
>> <thomas at monjalon.net> wrote:
>>>>>
>>>>> 12/06/2018 14:36, Wiles, Keith:
>>>>>>
>>>>>>> On Jun 12, 2018, at 7:26 AM, Thomas Monjalon
>> <thomas at monjalon.net> wrote:
>>>>>>>
>>>>>>> 11/06/2018 18:35, Wiles, Keith:
>>>>>>>>
>>>>>>>>> On Jun 11, 2018, at 11:06 AM, Ophir Munk
>> <ophirmu at 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
>