From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 514011DF721 for ; Wed, 12 Mar 2025 05:55:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741758944; cv=none; b=ez/VLJXs9sYDQUX6/ZXIRQBtavvRR5k9HKz3cxu/ABmpPcRgsFsLL9FsNeWHa22iiVdis4NckwHVu0KmmuBXZ1ZF+Sqys2a0f/sNcSrfqt+3+LHrvh+htajXgb/0V71hbkcMojZBpC3YFk/5OXxvuVIKJzquJPtpLdEFE3aNVUU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741758944; c=relaxed/simple; bh=alhU20ihOlc5cJCMuHBajEc7EUqehBtkqo5iRv29oVg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=sM3KouAxKiQvSg1Yy3xxYzZOgWj4qiHxICUK3pOQTAyLOLt3gOi6m8uI8xu1IiMEUUG3yyjNSP8sCHx+foDTPtE77BF5yRv/cpQcJxNDF6r82c2O0Y83+K4Qn4jUYL5Ul3A19LGGjzx1Z/xLkbknN8pguAXpQmR940Q2vbHLbtg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=daynix.com; spf=pass smtp.mailfrom=daynix.com; dkim=pass (2048-bit key) header.d=daynix-com.20230601.gappssmtp.com header.i=@daynix-com.20230601.gappssmtp.com header.b=eXPobSs1; arc=none smtp.client-ip=209.85.216.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=daynix.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=daynix.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=daynix-com.20230601.gappssmtp.com header.i=@daynix-com.20230601.gappssmtp.com header.b="eXPobSs1" Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-2fec13a4067so9801551a91.2 for ; Tue, 11 Mar 2025 22:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daynix-com.20230601.gappssmtp.com; s=20230601; t=1741758941; x=1742363741; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=oSOfwAcbQA4fo8Ww+ZUfjP/u2KZyMzcNTNHmT2zLzAs=; b=eXPobSs1pPcY2kkGUDTkUJAz6sPvL59IHQKGYSwAdKIup4QyjLYMD3b9smPrN4YSR5 +cejTYlr6XtbunhdGIME9KwDFaa0VKAwgMBHAWmmy3E6TLNrssg7dat/SBWkmS+qU2uI pv3St3becRp49oIv7FgZT2IPvvnTX8HvaKjBc+6ZT7vXI1Ggc1Cdw9JzOtj1PATClKmf zResMG/HZlIdbikSUHgeDPD7ASoiv6FZjEuBOi158kA966Gaa+s4JyA0lnkzsTrVRxlo s0GmGfBgIkmQ3qn8wW4bDdr2VyJn4pmqRb2zTENBVrXdmLcxct4AaY2dkChoruyUkhDQ TWJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741758941; x=1742363741; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=oSOfwAcbQA4fo8Ww+ZUfjP/u2KZyMzcNTNHmT2zLzAs=; b=bGSK4oksLUjiShX0dCNC3l/jhM/9ieghUBnA7279lbtA3Q/zJjXjT9qrH+is3g146Q m1/9FyIS5w3brsBJ9hOx9IwZK6JcSd2NxFth9bB6hBOI5MgxAI7jAxpO46vEzzQhkmDb H23TzMAeMJ+pVQXxKt4LNxkLkMF7XfDwiGe6ot2dGmPlHplSRowuK0FQvk3X4KwG0pMV Fc3CcRBVvPhLxyYyV/QW3dgMVS54zr4ZjLxdxU66rOo1a8lD0NJ5BSFc4vmiCqjPYGgv IMGfjc6AVdTI75xM5Le0BxX2yMIRrDSrlPtDdcDER3dfhMBOloIjFQoJyM5QDefDc9eh d+0Q== X-Forwarded-Encrypted: i=1; AJvYcCXjpRUgf7iTFro4fqfhnuvqEGtmbQuPsZZ50J7QSmqBcK+Zqg8BCO3klwWmN86oWymcram+7xpSZvW0ggA=@vger.kernel.org X-Gm-Message-State: AOJu0YzmHPYbQExbTQWcIZPC7bU7pMPIR+dngvzkJ+b0gW9cT1LcrboS 375JLbYFjtdAXdFGE7aVp2+w+GuMpLFmvlCz5marmOcRg8kdfJe1fHXCgLxZcmQ= X-Gm-Gg: ASbGncuGjSy3BMi821TsWM+n+qUbRzb2OT+P8KMExawBs2MxdIM/FaTfEut14BpInjx n8KcWsti2LT5aDBlG31qgtT6RUjmhFgEOVhRKjcIF7NOqOPjsxJIQUHS6PkNfIP2Zajv+reSwhr 0PHiUbqyMvh/z4mb6CvbaQiq2c+lQr01VSYlAguN/53FYlzOWtjPIWYRP0Rw3AjQOAS98oD6KK7 MOs/RJJtDRF15eEW2T+rNVaC8QgpwFkZxJ0BrdNYBrWES9rQhOO+dsyAM0DvmeVdIUr99aePR05 lJoVjo/YGdV+B1mLW8SNfmixwpsYil77c8AX68IXAzX4NGHeKyw2O+A7oA== X-Google-Smtp-Source: AGHT+IEnYwIq0Gmg9aXj/gdoHcpx7iSAd8arSmzyKfzCe7K3tIJUhpfLuzs4l56U190AWHzReGvYOg== X-Received: by 2002:a17:90b:48cc:b0:2ee:d371:3227 with SMTP id 98e67ed59e1d1-300ff104f1emr9530678a91.17.1741758941650; Tue, 11 Mar 2025 22:55:41 -0700 (PDT) Received: from [157.82.205.237] ([157.82.205.237]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-301190bbd78sm748839a91.39.2025.03.11.22.55.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Mar 2025 22:55:41 -0700 (PDT) Message-ID: <39c059c9-fe67-46e4-8c81-854a3de8d726@daynix.com> Date: Wed, 12 Mar 2025 14:55:36 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v9 3/6] tun: Introduce virtio-net hash feature To: Jason Wang Cc: Jonathan Corbet , Willem de Bruijn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , "Michael S. Tsirkin" , Xuan Zhuo , Shuah Khan , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-kselftest@vger.kernel.org, Yuri Benditovich , Andrew Melnychenko , Stephen Hemminger , gur.stavi@huawei.com, Lei Yang , Simon Horman References: <20250307-rss-v9-0-df76624025eb@daynix.com> <20250307-rss-v9-3-df76624025eb@daynix.com> <7978dfd5-8499-44f3-9c30-e53a01449281@daynix.com> <5e67a0a6-f613-4b0a-b64e-67f649e45c3e@daynix.com> Content-Language: en-US From: Akihiko Odaki In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2025/03/12 11:59, Jason Wang wrote: > On Tue, Mar 11, 2025 at 2:17 PM Akihiko Odaki wrote: >> >> On 2025/03/11 9:38, Jason Wang wrote: >>> On Mon, Mar 10, 2025 at 3:45 PM Akihiko Odaki wrote: >>>> >>>> On 2025/03/10 12:55, Jason Wang wrote: >>>>> On Fri, Mar 7, 2025 at 7:01 PM Akihiko Odaki 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 >>>>>> Tested-by: Lei Yang >>>>>> --- >>>>>> 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) { Regards, Akihiko Odaki > >> >> Regards, >> Akihiko Odaki >> > > Thanks >