On 2024/09/24 22:05, Simon Horman wrote:
On Tue, Sep 24, 2024 at 11:01:12AM +0200, Akihiko Odaki 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>
...
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
...
@@ -333,8 +336,10 @@ static long tun_set_vnet_be(struct tun_struct *tun, int __user *argp)
return -EFAULT;
if (be) {
+ struct tun_vnet_hash_container *vnet_hash = rtnl_dereference(tun->vnet_hash);
+
if (!(tun->flags & TUN_VNET_LE) &&
- (tun->vnet_hash.flags & TUN_VNET_HASH_REPORT))
+ vnet_hash && (vnet_hash->flags & TUN_VNET_HASH_REPORT))
Hi Odaki-san,
I am wondering if the above should this be vnet_hash->common.flags?
I am seeing this:
../drivers/net/tun.c:342:44: error: ‘struct tun_vnet_hash_container’ has no member named ‘flags’
342 | vnet_hash && (vnet_hash->flags & TUN_VNET_HASH_REPORT))
...
You are right. I couldn't notice this error because I was testing
without CONFIG_TUN_VNET_CROSS_LE; I'll test with the configuration and
submit a new version with fix.
Regards,
Akihiko Odaki