Re: librte_bpf: roadmap or any specific plans for this library

[David Marchand <david.marchand@redhat.com>]

Hello,

On Tue, Apr 26, 2022 at 10:34 AM Björn Svensson A
<bjorn.a.svensson@est.tech> wrote:
>
> Hi all,
> I hope this is the correct maillist for this topic.

Yes it is.
I copied the maintainer and people that might be interested in this topic.


>
> DPDK provides the nice library `librte_bpf` to load and execute eBPF bytecode
> and we would like to broaden our usage of this library.
>
> Today there are hints that this library might have been purpose built to enable inspection or modification of packets;
> for example the eBPF program is expected to only use a single input argument, pointing to data of some sort.
> We believe it would be beneficial to be able to use this library to run generic eBPF programs as well,
> as an alternative to run them as RX- TX-port/queue callbacks (i.e. generic programs which only uses supported features)
>
> I have seen some discussions regarding moving towards using a common library with the kernel implementation of bpf,
> but I couldn't figure out the outcome.

I don't think there was progress on this.


> My question is if there any plans to evolve this library or would improvements possibly be accepted?
>
> Here are some improvements we are interested to look into:
>
> * Add additional API for loading eBPF code.
>   Today it's possible to load eBPF code from an ELF file, but having an API to load code from an ELF image from memory
>   would open up for other ways to manage eBPF code.
>
>   Example of the new API:
>     struct rte_bpf *
>     rte_bpf_elf_image_load(const struct rte_bpf_prm *prm, char *image,
>                            size_t size, const char *sname);
>
> * Add support of more than a single input argument.
>   There are cases when additional information is needed. Being able to use more than a single input argument
>   would help when running generic eBPF programs.
>
>   Example of change:
>        struct rte_bpf_prm {
>        ...
>     -    struct rte_bpf_arg prog_arg; /**< eBPF program input arg description */
>     +    uint32_t nb_args;
>     +    struct rte_bpf_arg prog_args[EBPF_FUNC_MAX_ARGS]; /**< eBPF program input args */
>        };

All I can tell, is that this proposal breaks ABI.
This is a blocker to get it accepted until next ABI breakage window opens.


-- 
David Marchand