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 ED336EB64DD for ; Fri, 30 Jun 2023 00:54:28 +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 54EBB2ACAA for ; Fri, 30 Jun 2023 00:54:28 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 45FF79866ED for ; Fri, 30 Jun 2023 00:54:28 +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 387AD9866EB; Fri, 30 Jun 2023 00:54:28 +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 1E9039866E7; Fri, 30 Jun 2023 00:54:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e4;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_---0VmFnduE_1688086460; Date: Fri, 30 Jun 2023 08:54:20 +0800 From: Heng Qi To: Parav Pandit , "Michael S. Tsirkin" Cc: "virtio-comment@lists.oasis-open.org" , "virtio-dev@lists.oasis-open.org" , Yuri Benditovich , Xuan Zhuo , Jason Wang Message-ID: <20230630005420.GC77232@h68b04307.sqa.eu95> References: <20230628123131-mutt-send-email-mst@kernel.org> <20230628132122-mutt-send-email-mst@kernel.org> <20230628152125-mutt-send-email-mst@kernel.org> <4132affe-9b97-a81f-ad57-50ed4341678b@linux.alibaba.com> <20230629074627-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [virtio-dev] RE: [virtio-comment] RE: [PATCH v19] virtio-net: support inner header hash On Thu, Jun 29, 2023 at 04:59:28PM +0000, Parav Pandit wrote: > > > > From: Michael S. Tsirkin > > Sent: Thursday, June 29, 2023 7:48 AM > > > > > > struct virtio_net_hash_config reserved is fine. > > > > > > +1. > > > > > > Inner header hash is orthogonal to RSS, and it's fine to have its own > > > structure and commands. > > > There is no need to send additional RSS fields when we configure inner > > > header hash. > > > > > > Thanks. > > > > Not RSS, hash calculations. It's not critical, but I note that practically you said > > you will enable this with symmetric hash so it makes sense to me to send this in > > the same command with the key. > > > > In the v19, we have, > > +\item[VIRTIO_NET_F_HASH_TUNNEL] Requires VIRTIO_NET_F_CTRL_VQ along with VIRTIO_NET_F_RSS or VIRTIO_NET_F_HASH_REPORT. > > So it is done along with rss, so in same struct as rss config is fine. Do you mean having both virtio_net_rss_config and virtio_net_hash_config have enabled_hash_types? Like this: struct virtio_net_rss_config { le32 hash_types; le16 indirection_table_mask; struct rss_rq_id unclassified_queue; struct rss_rq_id indirection_table[indirection_table_length]; le16 max_tx_vq; u8 hash_key_length; u8 hash_key_data[hash_key_length]; + le32 enabled_tunnel_types; }; struct virtio_net_hash_config { le32 hash_types; - le16 reserved[4]; + le32 enabled_tunnel_types; + le16 reserved[2]; u8 hash_key_length; u8 hash_key_data[hash_key_length]; }; If yes, this should have been discussed in v10 [1] before, enabled_tunnel_types in virtio_net_rss_config will follow the variable length field and cause misalignment. If we let the inner header hash reuse the virtio_net_hash_config structure, it can work, but the only disadvantage is that the configuration of the inner header hash and *RSS*(not hash calculations) becomes somewhat coupled. Just imagine: If the driver and the device negotiated VIRTIO_NET_F_HASH_TUNNEL and VIRTIO_NET_F_RSS, but did not negotiate VIRTIO_NET_F_HASH_REPORT, 1. then if we only want to configure the inner header hash (such as enabled_tunnel_types), it is good for us to send virtio_net_hash_config alone; 2. but then if we want to configure the inner header hash and RSS (such as indirection table), we need to send all virtio_net_rss_config and virtio_net_hash_config once, because virtio_net_rss_config now does not carry enabled_tunnel_types due to misalignment. So, I think the following structure will make it clearer to configure inner header hash and RSS/hash calculation. But in any case, if we still propose to reuse virtio_net_hash_config proposal, I am ok, no objection: 1. The supported_tunnel_types are placed in the device config space; 2. Reserve the following structure: struct virtnet_hash_tunnel { le32 enabled_tunnel_types; }; 3. Reserve the SET command for enabled_tunnel_types and remove the GET command for enabled_tunnel_types. [1] https://lists.oasis-open.org/archives/virtio-dev/202303/msg00317.html Thanks a lot! --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org