On Sat, Oct 12, 2024 at 6:29 PM Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> wrote: > > On 2024/10/09 17:14, Jason Wang wrote: > > On Tue, Oct 8, 2024 at 2:55 PM Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> wrote: > >> > >> RSS is a receive steering algorithm that can be negotiated to use with > >> virtio_net. Conventionally the hash calculation was done by the VMM. > >> However, computing the hash after the queue was chosen defeats the > >> purpose of RSS. > >> > >> Another approach is to use eBPF steering program. This approach has > >> another downside: it cannot report the calculated hash due to the > >> restrictive nature of eBPF steering program. > >> > >> Introduce the code to perform RSS to the kernel in order to overcome > >> thse challenges. An alternative solution is to extend the eBPF steering > >> program so that it will be able to report to the userspace, but I didn't > >> opt for it because extending the current mechanism of eBPF steering > >> program as is because it relies on legacy context rewriting, and > >> introducing kfunc-based eBPF will result in non-UAPI dependency while > >> the other relevant virtualization APIs such as KVM and vhost_net are > >> UAPIs. > >> > >> Signed-off-by: Akihiko Odaki <akihiko.odaki@xxxxxxxxxx> > >> --- > >> drivers/net/tap.c | 11 +++++- > >> drivers/net/tun.c | 57 ++++++++++++++++++++------- > >> drivers/net/tun_vnet.h | 96 +++++++++++++++++++++++++++++++++++++++++---- > >> include/linux/if_tap.h | 4 +- > >> include/uapi/linux/if_tun.h | 27 +++++++++++++ > >> 5 files changed, 169 insertions(+), 26 deletions(-) > >> [...] > >> diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h > >> index d11e79b4e0dc..4887f97500a8 100644 > >> --- a/include/uapi/linux/if_tun.h > >> +++ b/include/uapi/linux/if_tun.h > >> @@ -75,6 +75,14 @@ > >> * > >> * The argument is a pointer to &struct tun_vnet_hash. > >> * > >> + * The argument is a pointer to the compound of the following in order if > >> + * %TUN_VNET_HASH_RSS is set: > >> + * > >> + * 1. &struct tun_vnet_hash > >> + * 2. &struct tun_vnet_hash_rss > >> + * 3. Indirection table > >> + * 4. Key > >> + * > > > > Let's try not modify uAPI. We can introduce new ioctl if necessary. > > 2, 3, and 4 are new additions. Adding a separate ioctl for them means we > need to call two ioctls to configure RSS and it is hard to design the > interactions with them. > > For example, if we set TUN_VNET_HASH_RSS with TUNSETVNETHASH before > setting struct tun_vnet_hash_rss with another ioctl, tuntap will enable > RSS with undefined parameters. Setting struct tun_vnet_hash_rss with > TUN_VNET_HASH_RSS unset also sounds unreasnoable. > > Letting the new ioctl set TUN_VNET_HASH_RSS does not help either. > TUNSETVNETHASH still sets the bitmask of allowed hash types so RSS will > depend on two ioctls. I meant let's avoid introducing an ioctl with function 1 in one patch, and adding 2,3,4 in exactly the same ioctl in the following. It breaks the uABI consistency and bisection. We can add all in one patch. Thanks
