From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C4C438DD1 for ; Tue, 24 Jun 2025 00:50:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750726217; cv=none; b=GoPPVQKsFE9zMVqHehTdTdyC1xXs4aCwFEVJRv5xaNA6DL9/IpYnNLTvab2A3uiutHjPVZCCwoBqCxewO2XwEDx2OOLOYWCd4kJcXwlIpDZmOEyTv7d55ts+lIqLhvjFoDS1Ioek/bYGBtCu0nek7mzwCXGCFvnc26N4dw2THd0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750726217; c=relaxed/simple; bh=/auqGXR0o1/P/foYc6AgZw0KxuJdncmvKGkmkIKxkSQ=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Q1FaHYAQlH2ihFafmTtr5Bzwx0HtowJxgg0Zi77T8bSJEWvJEfzfHlpvsnmrmQGCN0mqJiv2d9EMueZ1nUBMZVAiI85HKAYisiaB1zv1gzG21DQIegRPMtjMHTVHM1PRZTT3sjoxRylihZMPl4LotRfJLHzHM8c5A6a9/QRAVHs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Hw2socHm; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Hw2socHm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1750726214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/auqGXR0o1/P/foYc6AgZw0KxuJdncmvKGkmkIKxkSQ=; b=Hw2socHmMCLeu7lfybV86LQsaGzvvR0Ih4xSp3uoPzn4YygUou62Q3H+WPoS8vx2MVHZ1P n6Zv7ywMGc+edyA1g+HR+KXvw6kaiwO6zp9qnkp/m3tknJHXZXetY11urVhHOLWAt86HHg VibpRpDiieYUPDMDR1OdK2bkX3zf828= Received: from mail-pj1-f70.google.com (mail-pj1-f70.google.com [209.85.216.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-407-9zofM5LBPlu6wIOqD3UlVw-1; Mon, 23 Jun 2025 20:50:12 -0400 X-MC-Unique: 9zofM5LBPlu6wIOqD3UlVw-1 X-Mimecast-MFC-AGG-ID: 9zofM5LBPlu6wIOqD3UlVw_1750726212 Received: by mail-pj1-f70.google.com with SMTP id 98e67ed59e1d1-313fab41f4bso6563516a91.0 for ; Mon, 23 Jun 2025 17:50:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750726211; x=1751331011; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/auqGXR0o1/P/foYc6AgZw0KxuJdncmvKGkmkIKxkSQ=; b=GCCTfkC+hfZY+aCfmrFnLPEKvdHkeHJOKyyZUgCJfu+ke7gltYA5jv7+WGLFi+Mktf apuJvc6nO5mI9qQNxq8RlkCNgQDkjqTl+jNUBn6vUKk5BtwpvOJs8cUdCONf73VUSS75 88yRE2uO1svsNt91H8xayF1ex+PtgaLUXiAI7IPsq7unD5JcVVEvQKSiiVqIBE9clI8q XgbXKqIROJ8iKN0u/hxXbAgjtrFMvDlZitgrJjfOGVo46hYvdveMFXZ0pItiFHJfJcfy twClWhF051TkcACL+5l4PvNDbndDKH3XmpOYkAhPks1SSsieDGkwhAEefkevXEAT7vmd ktXw== X-Forwarded-Encrypted: i=1; AJvYcCU+UKWg7r0nz99UPirkm1gPcKkjBb36s4L3/5qMv4nzf8b5BRw0lXhaWPeBbSHPdVYI4JeT8bojtUA=@vger.kernel.org X-Gm-Message-State: AOJu0YzuHL+ZVprpnfxkachuAKh4AG6qTvtaSDKzTD1g/FYuQzQy6mgw 6wCeJFBjwUvHHalcTdZ6e+xcyt9/+1NRNxG2r3WyGuMVBoHEmXgxhtOS6zBwboQP8+VDoWdYHLO zoHsNP0ZtX36ZlJCHF0q+/WxtvT/QUprSvnnXA3Fi5vuzwYibtotcmTZPsdbYDpcZx7ZcrLRVJa vVVbkXtFC9P+XO4BNSAywu9TbIdF3ZS+d0TfJl X-Gm-Gg: ASbGncvSpkY4jAzIvcfS5V1R00ew544UU9ooQ0dCNRhZHg7KoYBBb+MBuyKySmgWJL0 7u70ETLc69E//JU2Nvv+Lk7s55+34hyM0VjIjRpsnSNmkXOiYyLQ35wO5eVd5RlnOheYpEuLeje 4S244V X-Received: by 2002:a17:90a:d888:b0:313:f883:5d36 with SMTP id 98e67ed59e1d1-3159d61b385mr20481157a91.1.1750726211538; Mon, 23 Jun 2025 17:50:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH2mZ6TFzZC61NvgUQr50RK9GKr+Zt2TEe1NWxDOMMJSfnof6RsI9yY3mdeAsIKTHaPT/FkDTx1NOWeRFhiZ3M= X-Received: by 2002:a17:90a:d888:b0:313:f883:5d36 with SMTP id 98e67ed59e1d1-3159d61b385mr20481119a91.1.1750726211082; Mon, 23 Jun 2025 17:50:11 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250530-rss-v12-0-95d8b348de91@daynix.com> <20250530-rss-v12-1-95d8b348de91@daynix.com> <95cb2640-570d-4f51-8775-af5248c6bc5a@daynix.com> <4eaa7aaa-f677-4a31-bcc2-badcb5e2b9f6@daynix.com> <75ef190e-49fc-48aa-abf2-579ea31e4d15@daynix.com> <760e9154-3440-464f-9b82-5a0c66f482ee@daynix.com> In-Reply-To: From: Jason Wang Date: Tue, 24 Jun 2025 08:49:58 +0800 X-Gm-Features: AX0GCFuyvFlQ7RhA5QlpqKcUbeYXfBe9mHMJd9IBrNPZibzgOsK55WFol474x3I Message-ID: Subject: Re: [PATCH net-next v12 01/10] virtio_net: Add functions for hashing To: Yuri Benditovich Cc: "Michael S. Tsirkin" , Jonathan Corbet , Willem de Bruijn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , 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, Andrew Melnychenko , Stephen Hemminger , gur.stavi@huawei.com, Lei Yang , Simon Horman , Akihiko Odaki Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 23, 2025 at 10:28=E2=80=AFPM Yuri Benditovich wrote: > > On Mon, Jun 23, 2025 at 11:07=E2=80=AFAM Jason Wang = wrote: > > > > On Mon, Jun 23, 2025 at 1:40=E2=80=AFAM Yuri Benditovich > > wrote: > > > > > > > Yuri, can you help to clarify this? > > > > > > I see here several questions: > > > 1. Whether it is ok for the device not to indicate support for XXX_EX= hash type? > > > - I think, yes (strictly speaking, it was better to test that before > > > submitting the patches ) > > > 2. Is it possible that the guest will enable some XXX_EX hash type if > > > the device does not indicate that it is supported? > > > - No (I think this is part of the spec) > > > > There's another question, is the device allowed to fallback to > > VIRTIO_NET_HASH_TYPE_IPv6 if it fails to parse extensions? > MSFT expectations for that are at > https://learn.microsoft.com/en-us/windows-hardware/drivers/network/rss-ha= shing-types > If I read them correctly, the answer is "no" Ok, so I guess it implies the implementation should be ready to deal with arbitrary length of ipv6 options. > BTW, my personal opinion is that placing all these things with hash > calculations into kernel instead of ebpf does not make too much sense. If I remember correctly, we tried to enable it via eBPF, but failed due to the rejection of eBPF maintainers. Maybe we can revisit the idea. But anyhow the hardcoded logic might still be useful as eBPF is not guaranteed to work in all cases. Thanks > > > > > > 3. What to do if we migrate between systems with different > > > capabilities of hash support/reporting/whatever > > > - IMO, at this moment such case should be excluded and only mechanism > > > we have for that is the compatible machine version > > > - in some future the change of device capabilities can be communicate= d > > > to the driver and _probably_ the driver might be able to communicate > > > the change of device capabilities to the OS > > > > Are you suggesting implementing all hash types? Note that Akihiko > > raises the issue that in the actual implementation there should be a > > limitation of the maximum number of options. If such a limitation is > > different between src and dst, the difference could be noticed by the > > guest. > > > > > 4. Does it make sense to have fine configuration of hash types mask > > > via command-line? > > > - IMO, no. This would require the user to have too much knowledge > > > about RSS internals > > > > > > Please let me know if I missed something. > > > > > > > Thanks > > >