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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81581C4332F for ; Fri, 25 Nov 2022 15:53:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229901AbiKYPxj (ORCPT ); Fri, 25 Nov 2022 10:53:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42732 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229814AbiKYPx2 (ORCPT ); Fri, 25 Nov 2022 10:53:28 -0500 Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6B78C490B1; Fri, 25 Nov 2022 07:53:16 -0800 (PST) Received: (Authenticated sender: i.maximets@ovn.org) by mail.gandi.net (Postfix) with ESMTPSA id 3B44324000F; Fri, 25 Nov 2022 15:51:13 +0000 (UTC) Message-ID: Date: Fri, 25 Nov 2022 16:51:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Cc: i.maximets@ovn.org, dev@openvswitch.org, linux-kernel@vger.kernel.org, Eric Dumazet , linux-kselftest@vger.kernel.org, Jakub Kicinski , Paolo Abeni , Shuah Khan , "David S. Miller" Content-Language: en-US To: Adrian Moreno , Aaron Conole , netdev@vger.kernel.org References: <20221122140307.705112-1-aconole@redhat.com> <20221122140307.705112-2-aconole@redhat.com> <83a0b3e4-1327-c1c4-4eb4-9a25ff533d1d@redhat.com> From: Ilya Maximets Subject: Re: [ovs-dev] [RFC net-next 1/6] openvswitch: exclude kernel flow key from upcalls In-Reply-To: <83a0b3e4-1327-c1c4-4eb4-9a25ff533d1d@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/25/22 16:29, Adrian Moreno wrote: > > > On 11/23/22 22:22, Ilya Maximets wrote: >> On 11/22/22 15:03, Aaron Conole wrote: >>> When processing upcall commands, two groups of data are available to >>> userspace for processing: the actual packet data and the kernel >>> sw flow key data.  The inclusion of the flow key allows the userspace >>> avoid running through the dissection again. >>> >>> However, the userspace can choose to ignore the flow key data, as is >>> the case in some ovs-vswitchd upcall processing.  For these messages, >>> having the flow key data merely adds additional data to the upcall >>> pipeline without any actual gain.  Userspace simply throws the data >>> away anyway. >> >> Hi, Aaron.  While it's true that OVS in userpsace is re-parsing the >> packet from scratch and using the newly parsed key for the OpenFlow >> translation, the kernel-porvided key is still used in a few important >> places.  Mainly for the compatibility checking.  The use is described >> here in more details: >>    https://docs.kernel.org/networking/openvswitch.html#flow-key-compatibility >> >> We need to compare the key generated in userspace with the key >> generated by the kernel to know if it's safe to install the new flow >> to the kernel, i.e. if the kernel and OVS userpsace are parsing the >> packet in the same way. >> > > Hi Ilya, > > Do we need to do that for every packet? > Could we send a bitmask of supported fields to userspace at feature > negotiation and let OVS slowpath flows that it knows the kernel won't > be able to handle properly? It's not that simple, because supported fields in a packet depend on previous fields in that same packet. For example, parsing TCP header is generally supported, but it won't be parsed for IPv6 fragments (even the first one), number of vlan headers will affect the parsing as we do not parse deeper than 2 vlan headers, etc. So, I'm afraid we have to have a per-packet information, unless we can somehow probe all the possible valid combinations of packet headers. > > >> On the other hand, OVS today doesn't check the data, it only checks >> which fields are present.  So, if we can generate and pass the bitmap >> of fields present in the key or something similar without sending the >> full key, that might still save some CPU cycles and memory in the >> socket buffer while preserving the ability to check for forward and >> backward compatibility.  What do you think? >> >> >> The rest of the patch set seems useful even without patch #1 though. >> >> Nit: This patch #1 should probably be merged with the patch #6 and be >> at the end of a patch set, so the selftest and the main code are updated >> at the same time. >> >> Best regards, Ilya Maximets. >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> > > Thanks