Thanks for the feedback.

>>    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);
>>
> Did you look at rte_bpf_load()?
> Basically it works with already pre-loaded into memory bpf program.
> In fact, rte_bpf_elf_load() calls it internally after reading elf
> sections, resolving external references, etc.
> Would it meet your needs?

Yes, I think we could create our own elf_image_load() function that uses rte_bpf_load().
I understand that we don't want to have a bunch of specific variants of load-functions in dpdk,
specially if they are not used in any example or usecase.

> AFAIK linux BPF is restricted to work with a single argument only.
> I don't want DPDK version to fork too far away from 'canonical' version.
> Though, as I said above, nothing prevents you to create a struct
> with several fields, and pass pointer to that struct to your BPF program.
> Would such approach work for you?

Good alternative idea. We will test this approach.
I guess we will use the RTE_BPF_ARG_PTR as an argument for the program in this case.

Just as sidenote: we have also had a glance at
https://github.com/iovisor/ubpf
as an alternative. This is a standalone BPF VM lib, but with Apache 2.0 license and it's not bound to the dpdk log framework.
I have no views on benefits using this in dpdk, but it might be an input for future talks about a common library / collaboration.

Thanks again.
Bjorn