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 9C03DC6FD20 for ; Tue, 21 Mar 2023 21:32:36 +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 9A7C42A89E for ; Tue, 21 Mar 2023 21:32:32 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 3035298644C for ; Tue, 21 Mar 2023 21:32:32 +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 283F098643D; Tue, 21 Mar 2023 21:32:32 +0000 (UTC) Mailing-List: contact virtio-comment-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 1730998643E for ; Tue, 21 Mar 2023 21:32:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-MC-Unique: 6gMpKYVhN3iaHuBFeOVZPg-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679434348; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aV4bKCFB5hnhtm38s9fF5Wde6nY5XGm/Cz9c/vv7ysE=; b=L85zrnUBU6ArtLO/gD847T9t8u1ydfpcE0Gwh5qXkFQAcycqCXIlJli20P7zGSKeRu DN97PduQUNP8JExE130V+7aPQnxvwIPqKWposmHaZUVXRMe66BYfQXJOh716a0DQk0u2 Zi8X3dQoThBXAMtGXto63O81e0jubis6engcpsaZI3C734FXsrTRsqKyCJ/LfAMCGixn rsnmhO2/7VZV6icPumHxIy7wutzcd34qyHesI72RRtvmi+XuMhRRSFWgD97bX61yOiTy k9RBeaFZBMGk/8xnaF/8kX4JXAxWdtLKKFFbRhSdq2AkG8MOeRSQigO9j7x9ulkjFP9I Vpcg== X-Gm-Message-State: AO0yUKWVkkYog31NSsS9ZD/01cVyKWri0wyND4pgWK9OwiV+OA4VVyqp mXjIiNTpwDlUVVuYwFBGKyEg+Iljp+r6BYmsgFXOR/J1COpiONesHOIctDUF/fSJi2O7CoLMJgH waez1e+rnkGagBHVHiCxn4RGqsTCttX6YOA== X-Received: by 2002:a5d:4ec9:0:b0:2cb:9d29:7242 with SMTP id s9-20020a5d4ec9000000b002cb9d297242mr3295599wrv.27.1679434347885; Tue, 21 Mar 2023 14:32:27 -0700 (PDT) X-Google-Smtp-Source: AK7set88MAlxpGygTW+c2RgPbWOCZzBR+QkUyKnP83OcLMGbSZo5R/PgeBClfw8FslQL9LPa2hd9OQ== X-Received: by 2002:a5d:4ec9:0:b0:2cb:9d29:7242 with SMTP id s9-20020a5d4ec9000000b002cb9d297242mr3295589wrv.27.1679434347585; Tue, 21 Mar 2023 14:32:27 -0700 (PDT) Date: Tue, 21 Mar 2023 17:32:23 -0400 From: "Michael S. Tsirkin" To: Parav Pandit Cc: Heng Qi , Alvaro Karsz , "virtio-dev@lists.oasis-open.org" , "virtio-comment@lists.oasis-open.org" , Jason Wang , Yuri Benditovich , Xuan Zhuo Message-ID: <20230321172742-mutt-send-email-mst@kernel.org> References: <20230320111840.64039-1-hengqi@linux.alibaba.com> <20230320144625-mutt-send-email-mst@kernel.org> <3a1969e7-2c4d-b64e-33b2-57311d73fb45@linux.alibaba.com> <20230321033449-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [virtio-comment] Re: [virtio-dev] Re: [PATCH v11] virtio-net: support inner header hash On Tue, Mar 21, 2023 at 07:46:14PM +0000, Parav Pandit wrote: > > > From: Michael S. Tsirkin > > Sent: Tuesday, March 21, 2023 3:37 AM > > > > On Tue, Mar 21, 2023 at 04:19:17AM +0000, Parav Pandit wrote: > > > One (this proposal) is solving spread to different RSS queues. > > > > Spread is mostly ok with modern protocols though. > Yes. > > It seems to optimize for a specific monitoring solution. > > > Monitoring is a critical part of the infrastructure. > So, if a point solution is useful, at least I don't see a negative of it especially when there is a user of it. Yes. I'd like to include just the protocols that genuinely benefit though, so we can avoid the churn of adding more and more tunneling protocols as they appear. That's why I am trying to find out whether limiting this to just classic GRE is ok (and maybe GRE IPv6). I also feel if symmetry is needed we need support for xor based thing with a mask, playing with toeplitz is fragile due to e.g. IPv4/IPv6 headers being different length. > > > Another one is finding out which exact packet to drop/pass when queue usage > > is high. (ebpf/tc other ways to solve it). > > > > > > Ebpf sounds cooler than the real offload implementation in the hw device at > > the current level. > > > I remember Jason's good talk on the ebpf a few years back, which is possible > > when done in sw on the hypervisor. > > > > I was talking about classic bpf though. no state. > > > Packet processing logic requires to keep track of past tunnel data and counters across many queues for fairness. > This involves stateful ness of past/current data. > > Even with outer header entropy, multiple tunnels can steer to a small set of queues, because num_tunnel >= num_queues. > Hence, fairness is orthogonal. Yes I was not talking about fairness. that was addressed adequately with a security note I feel. -- MST This publicly archived list offers a means to provide input to the OASIS Virtual I/O Device (VIRTIO) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: virtio-comment-subscribe@lists.oasis-open.org Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org List help: virtio-comment-help@lists.oasis-open.org List archive: https://lists.oasis-open.org/archives/virtio-comment/ Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists Committee: https://www.oasis-open.org/committees/virtio/ Join OASIS: https://www.oasis-open.org/join/ 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 16CFDC6FD20 for ; Tue, 21 Mar 2023 21:32:32 +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 6826C2B008 for ; Tue, 21 Mar 2023 21:32:31 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 5287B986450 for ; Tue, 21 Mar 2023 21:32:31 +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 3B2A698643D; Tue, 21 Mar 2023 21:32:31 +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 2880698643E for ; Tue, 21 Mar 2023 21:32:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-MC-Unique: N9HYogHSPJ2lne-QlWI_tg-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679434348; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aV4bKCFB5hnhtm38s9fF5Wde6nY5XGm/Cz9c/vv7ysE=; b=P9sZPR5d6ux+zJGrQEbBT+6j/YG5ypg+M+FgDDa5aBXui89jRvflUAd5ZhEVKBVzbK Kbcffa7f316/QUov5eP3dWrPBtWoBYdD/SM8KX8AC/z/WiK4mck8Mbttamti5p9y1KGQ 6zo1hg72Qw6fNEPAKPVB+or8yDY12hjwizffMNJT25VREvSu8A4ILs9qOyPzoWFBf+OQ f0rM/ZIcv8I2wZSXqAjXitOQ6NQ73Fv5P3vhI/k9Lo1oyU6H+rXS4SQH5vU3u2NkyWd3 KN2vnXIpyQebyrXdaKYMJlT5zLU6kIuhSb3Nau+dLDgR0hhfBLYG5pTVRJUb9bOFP5e4 fOrQ== X-Gm-Message-State: AO0yUKVNHxUyZaa1qMh/EdkKpQHlMERgS5wS0yK+LJmmNWlSa7CIenzm BH72FPZ1pL/Oy/IAENRX5evsApG79XV0550MPHonlBoe8jyjwoFOwZvzYBF5XxgHWpRN7RtiMuN GxHK2K3yexwhaApYjkviXWQJ00IIG X-Received: by 2002:a5d:4ec9:0:b0:2cb:9d29:7242 with SMTP id s9-20020a5d4ec9000000b002cb9d297242mr3295601wrv.27.1679434347885; Tue, 21 Mar 2023 14:32:27 -0700 (PDT) X-Google-Smtp-Source: AK7set88MAlxpGygTW+c2RgPbWOCZzBR+QkUyKnP83OcLMGbSZo5R/PgeBClfw8FslQL9LPa2hd9OQ== X-Received: by 2002:a5d:4ec9:0:b0:2cb:9d29:7242 with SMTP id s9-20020a5d4ec9000000b002cb9d297242mr3295589wrv.27.1679434347585; Tue, 21 Mar 2023 14:32:27 -0700 (PDT) Date: Tue, 21 Mar 2023 17:32:23 -0400 From: "Michael S. Tsirkin" To: Parav Pandit Cc: Heng Qi , Alvaro Karsz , "virtio-dev@lists.oasis-open.org" , "virtio-comment@lists.oasis-open.org" , Jason Wang , Yuri Benditovich , Xuan Zhuo Message-ID: <20230321172742-mutt-send-email-mst@kernel.org> References: <20230320111840.64039-1-hengqi@linux.alibaba.com> <20230320144625-mutt-send-email-mst@kernel.org> <3a1969e7-2c4d-b64e-33b2-57311d73fb45@linux.alibaba.com> <20230321033449-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: [virtio-dev] Re: [PATCH v11] virtio-net: support inner header hash On Tue, Mar 21, 2023 at 07:46:14PM +0000, Parav Pandit wrote: > > > From: Michael S. Tsirkin > > Sent: Tuesday, March 21, 2023 3:37 AM > > > > On Tue, Mar 21, 2023 at 04:19:17AM +0000, Parav Pandit wrote: > > > One (this proposal) is solving spread to different RSS queues. > > > > Spread is mostly ok with modern protocols though. > Yes. > > It seems to optimize for a specific monitoring solution. > > > Monitoring is a critical part of the infrastructure. > So, if a point solution is useful, at least I don't see a negative of it especially when there is a user of it. Yes. I'd like to include just the protocols that genuinely benefit though, so we can avoid the churn of adding more and more tunneling protocols as they appear. That's why I am trying to find out whether limiting this to just classic GRE is ok (and maybe GRE IPv6). I also feel if symmetry is needed we need support for xor based thing with a mask, playing with toeplitz is fragile due to e.g. IPv4/IPv6 headers being different length. > > > Another one is finding out which exact packet to drop/pass when queue usage > > is high. (ebpf/tc other ways to solve it). > > > > > > Ebpf sounds cooler than the real offload implementation in the hw device at > > the current level. > > > I remember Jason's good talk on the ebpf a few years back, which is possible > > when done in sw on the hypervisor. > > > > I was talking about classic bpf though. no state. > > > Packet processing logic requires to keep track of past tunnel data and counters across many queues for fairness. > This involves stateful ness of past/current data. > > Even with outer header entropy, multiple tunnels can steer to a small set of queues, because num_tunnel >= num_queues. > Hence, fairness is orthogonal. Yes I was not talking about fairness. that was addressed adequately with a security note I feel. -- MST --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org