On Wed, Mar 12, 2025 at 1:55 PM Akihiko Odaki akihiko.odaki@daynix.com wrote:
On 2025/03/12 11:59, Jason Wang wrote:
On Tue, Mar 11, 2025 at 2:17 PM Akihiko Odaki akihiko.odaki@daynix.com wrote:
On 2025/03/11 9:38, Jason Wang wrote:
On Mon, Mar 10, 2025 at 3:45 PM Akihiko Odaki akihiko.odaki@daynix.com wrote:
On 2025/03/10 12:55, Jason Wang wrote:
On Fri, Mar 7, 2025 at 7:01 PM Akihiko Odaki akihiko.odaki@daynix.com wrote: > > 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 akihiko.odaki@daynix.com > Tested-by: Lei Yang leiyang@redhat.com > --- > 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(-) >
[...]
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.
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) {
Right.
Thanks
Regards, Akihiko Odaki
Regards, Akihiko Odaki
Thanks