From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 29B98C77B60 for ; Thu, 27 Apr 2023 02:28:42 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id 5A86D2A823 for ; Thu, 27 Apr 2023 02:28:41 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 55A12986652 for ; Thu, 27 Apr 2023 02:28:41 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id 4B01A986288; Thu, 27 Apr 2023 02:28:41 +0000 (UTC) Mailing-List: contact virtio-dev-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 37A9D986641; Thu, 27 Apr 2023 02:28:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=hengqi@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0Vh5MawF_1682562509; Message-ID: <5463159d-daa2-101b-6abf-ea7aa4f40bd0@linux.alibaba.com> Date: Thu, 27 Apr 2023 10:28:29 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: "Michael S. Tsirkin" Cc: virtio-dev@lists.oasis-open.org, virtio-comment@lists.oasis-open.org, Parav Pandit , Jason Wang , Yuri Benditovich , Xuan Zhuo References: <20230423073532.105636-1-hengqi@linux.alibaba.com> <20230425165659-mutt-send-email-mst@kernel.org> <19e6d4e6-e3d8-7eca-4d54-d113b4cc5504@linux.alibaba.com> <20230426104538-mutt-send-email-mst@kernel.org> From: Heng Qi In-Reply-To: <20230426104538-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [virtio-dev] Re: [virtio-comment] [PATCH v13] virtio-net: support inner header hash 在 2023/4/26 下午10:48, Michael S. Tsirkin 写道: > On Wed, Apr 26, 2023 at 10:14:30PM +0800, Heng Qi wrote: >> This does not mean that every device needs to implement and support all of >> these, they can choose to support some protocols they want. >> >> I add these because we have scale application scenarios for modern protocols >> VXLAN-GPE/GENEVE: >> >> +\item In scenarios where the same flow passing through different tunnels is expected to be received in the same queue, >> + warm caches, lessing locking, etc. are optimized to obtain receiving performance. >> >> >> Maybe the legacy GRE, VXLAN-GPE and GENEVE? But it has a little crossover. >> >> Thanks. > But VXLAN-GPE/GENEVE can use source port for entropy. > > It is recommended that the UDP source port number > be calculated using a hash of fields from the inner packet > > That is best because > it allows end to end control and is protocol agnostic. Yes. I agree with this, I don't think we have an argument on this point right now.:) For VXLAN-GPE/GENEVE or other modern tunneling protocols, we have to deal with scenarios where the same flow passes through different tunnels. Having them hashed to the same rx queue, is hard to do via outer headers. > All that is missing is symmetric Toepliz and all is well? The scenarios above or in the commit log also require inner headers. Thanks. > --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org