Re: [RFC PATCH v2 0/5] eBPF RSS support for virtio-net

[Toke Høiland-Jørgensen]

Jason Wang <jasowang@redhat.com> writes:

> On 2020/11/19 下午7:13, Andrew Melnychenko wrote:
>> This set of patches introduces the usage of eBPF for packet steering
>> and RSS hash calculation:
>> * RSS(Receive Side Scaling) is used to distribute network packets to
>> guest virtqueues by calculating packet hash
>> * Additionally adding support for the usage of RSS with vhost
>>
>> The eBPF works on kernels 5.8+
>> On earlier kerneld it fails to load and the RSS feature is reported
>> only without vhost and implemented in 'in-qemu' software.
>>
>> Implementation notes:
>> Linux TAP TUNSETSTEERINGEBPF ioctl was used to set the eBPF program.
>> Added libbpf dependency and eBPF support.
>> The eBPF program is part of the qemu and presented as an array
>> of BPF ELF file data.
>> The compilation of eBPF is not part of QEMU build and can be done
>> using provided Makefile.ebpf(need to adjust 'linuxhdrs').
>> Added changes to virtio-net and vhost, primary eBPF RSS is used.
>> 'in-qemu' RSS used in the case of hash population and as a fallback option.
>> For vhost, the hash population feature is not reported to the guest.
>>
>> Please also see the documentation in PATCH 5/5.
>>
>> I am sending those patches as RFC to initiate the discussions and get
>> feedback on the following points:
>> * Fallback when eBPF is not supported by the kernel
>> * Live migration to the kernel that doesn't have eBPF support
>> * Integration with current QEMU build
>> * Additional usage for eBPF for packet filtering
>>
>> Known issues:
>> * hash population not supported by eBPF RSS: 'in-qemu' RSS used
>> as a fallback, also, hash population feature is not reported to guests
>> with vhost.
>> * big-endian BPF support: for now, eBPF isn't supported on
>> big-endian systems. Can be added in future if required.
>> * huge .h file with eBPF binary. The size of .h file containing
>> eBPF binary is currently ~5K lines, because the binary is built with debug 
>> information.
>> The binary without debug/BTF info can't be loaded by libbpf.
>> We're looking for possibilities to reduce the size of the .h files.
>
>
> Adding Toke for sharing more idea from eBPF side.
>
> We had some discussion on the eBPF issues:
>
> 1) Whether or not to use libbpf. Toke strongly suggest to use libbpf
> 2) Whether or not to use BTF. Toke confirmed that if we don't access any 
> skb metadata, BTF is not strictly required for CO-RE. But it might still 
> useful for e.g debugging.
> 3) About the huge (5K lines, see patch #2 Toke). Toke confirmed that we 
> can strip debug symbols, but Yuri found some sections can't be stripped, 
> we can keep discussing here.

I just tried simply running 'strip' on a sample trivial XDP program,
which brought its size down from ~5k to ~1k and preserved the BTF
information without me having to do anything.

As a side note, though, instead of embedding the BPF program into a .h,
you could simply ship it as a .o and load it from the file system. We do
that with xdp-tools and install the bpf object files into /usr/$LIB/bpf/.

-Toke