On 2025/03/12 11:59, Jason Wang wrote:

On Tue, Mar 11, 2025 at 2:17 PM Akihiko Odaki [off-list ref] wrote:

quoted

On 2025/03/11 9:38, Jason Wang wrote:

quoted

On Mon, Mar 10, 2025 at 3:45 PM Akihiko Odaki [off-list ref] wrote:

quoted

On 2025/03/10 12:55, Jason Wang wrote:

quoted

On Fri, Mar 7, 2025 at 7:01 PM Akihiko Odaki [off-list ref] wrote:

quoted

Hash reporting
==============

Allow the guest to reuse the hash value to make receive steering
consistent between the host and guest, and to save hash computation.

RSS
===

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 <redacted>
Tested-by: Lei Yang <redacted>
---
    Documentation/networking/tuntap.rst |   7 ++
    drivers/net/Kconfig                 |   1 +
    drivers/net/tap.c                   |  68 ++++++++++++++-
    drivers/net/tun.c                   |  98 +++++++++++++++++-----
    drivers/net/tun_vnet.h              | 159 ++++++++++++++++++++++++++++++++++--
    include/linux/if_tap.h              |   2 +
    include/linux/skbuff.h              |   3 +
    include/uapi/linux/if_tun.h         |  75 +++++++++++++++++
    net/core/skbuff.c                   |   4 +
    9 files changed, 386 insertions(+), 31 deletions(-)

[...]

quoted

quoted

quoted

quoted

Let's has a consistent name for this and the uapi to be consistent
with TUNSETIFF/TUNGETIFF. Probably TUNSETVNETHASH and
tun_vnet_ioctl_gethash().

They have different semantics so they should have different names.
TUNGETIFF reports the value currently set while TUNGETVNETHASHCAP
reports the value that can be set later.

I'm not sure I will get here. I meant a symmetric name

TUNSETVNETHASH and TUNVETVNETHASH.

TUNGETVNETHASHCAP does not correspond to TUNGETIFF. The correspondence
of ioctl names is as follows:
TUNGETFEATURES - TUNGETVNETHASHCAP

TUNGETFEATURES returns the value set from TUNSETIFF. This differs from
TUNGETVNETHASHCAP semantic which just return the capabilities.

+static inline long tun_vnet_ioctl_gethashcap(void __user *argp)
+{
+       static const struct tun_vnet_hash cap = {
+               .flags = TUN_VNET_HASH_REPORT | TUN_VNET_HASH_RSS,
+               .types = VIRTIO_NET_SUPPORTED_HASH_TYPES
+       };
+
+       return copy_to_user(argp, &cap, sizeof(cap)) ? -EFAULT : 0;
+}

TUNGETFEATURES doesn't' help too much for non-persist TAP as userspace
knows what value it set before.

quoted

TUNSETIFF - TUNSETVNETHASH
TUNGETIFF - no corresponding ioctl for the virtio-net hash features

And this sounds odd and a hint for a incomplete uAPI as userspace
needs to know knowing what can set before doing TUNSETVNETHASH.

You are confused with TUNGETFEATURES and TUNGETIFF. Below is the code 
that implements TUNGETFEATURES:
if (cmd == TUNGETFEATURES) {
	/* Currently this just means: "what IFF flags are valid?".
	 * This is needed because we never checked for invalid flags on
	 * TUNSETIFF.
	 */
	return put_user(IFF_TUN | IFF_TAP | IFF_NO_CARRIER |
			TUN_FEATURES, (unsigned int __user*)argp);
} else if (cmd == TUNSETQUEUE) {

Regards,
Akihiko Odaki

quoted

Regards,
Akihiko Odaki

Thanks