From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id E57CD41BAE; Thu, 2 Feb 2023 12:29:34 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 89FAF406A2; Thu, 2 Feb 2023 12:29:34 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 2F33240689 for ; Thu, 2 Feb 2023 12:29:33 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 855B55C01B0; Thu, 2 Feb 2023 06:29:31 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 02 Feb 2023 06:29:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1675337371; x= 1675423771; bh=ahowoMNVA/WChurMFFD9szBHSmbf0CNzs0UoJAw+vVs=; b=P qK1mRG+xIqFVvhFArgqR7mfhXAESe2QEDY3fi/YumbXorOLEza18bosi7vTqCjRw DEkteEcREhXx0J6njR2shMuMFPB+WwyNBJWVR1l5Cff6WfiOtrLg5HXI6FdNUspd i8B3JIAZmxXpCHU9q+Po/jHA6AFc6hyNpdeKK2yABkQLhdHegQ1gvrvwIf+9ODNx d/zaGEz+AnJ0vmlS9FZDcC/OSbg/7uUPO3fRr4Ay4RGfn7B0Q/J6mmraRtbJ7h7J H1cj7sWbSJf9F/YNss7AB19A81hx1KrUBQi7ep4XPom/Bm8UNGIh+8Sowg4hIlhN NDmHcoRv+pIQe/jwRMAqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1675337371; x= 1675423771; bh=ahowoMNVA/WChurMFFD9szBHSmbf0CNzs0UoJAw+vVs=; b=O DoE22Ddu8sMKzRF1i/+D8njFwbWLWpHXjlUQK25wTopD3rU5V5K7JCZEq1DLdOud MIddWEuxzPshoPlaYJAUypE+oG6jtVBnhe9UIF2bR+xcqhCZkWK+xlHRhARcL+g0 JWsUXN81YbWpsGnV4Mzo9WqtoHJ8eqsXqjETYZ48buB4Hz+InsBbr3KVA6lSYShP q7E08Yb8HiMAZp9UP+cj4FEtl08ro+76HS238V83uDG3nqdyecdJglJ1avJfRXUU Cen63nyto45oADl2oLLFp/b6+0a+TNnkdkOT3Xu4yyi3PJ6MsSZcfoauj3fLRpSn 11AjrmuNU3z1eYgV+7lQg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefkedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Feb 2023 06:29:29 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit , Andrew Rybchenko , Yuying Zhang Cc: Rongwei Liu , matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, Aman Singh , dev@dpdk.org, rasland@nvidia.com, jerinj@marvell.com Subject: Re: [PATCH v7] ethdev: add special flags when creating async transfer table Date: Thu, 02 Feb 2023 12:29:28 +0100 Message-ID: <12425652.O9o76ZdvQC@thomas> In-Reply-To: <0f546992-dbd8-6d86-3d87-015a3dae98ee@oktetlabs.ru> References: <51e583ea-4446-fea5-af74-dfe75d37f05c@oktetlabs.ru> <2309073.BjyWNHgNrj@thomas> <0f546992-dbd8-6d86-3d87-015a3dae98ee@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 02/02/2023 10:21, Andrew Rybchenko: > On 2/1/23 16:48, Thomas Monjalon wrote: > > 01/02/2023 12:38, Andrew Rybchenko: > >> On 2/1/23 14:18, Thomas Monjalon wrote: > >>> 01/02/2023 12:10, Andrew Rybchenko: > >>>> On 2/1/23 13:58, Thomas Monjalon wrote: > >>>>> 01/02/2023 11:17, Andrew Rybchenko: > >>>>>> On 1/18/23 19:18, Thomas Monjalon wrote: > >>>>>>> 18/01/2023 08:28, Andrew Rybchenko: > >>>>>>>> On 11/14/22 14:59, Rongwei Liu wrote: > >>>>>>>>> In case flow rules match only one kind of traffic in a flow table, > >>>>>>>>> then optimization can be done via allocation of this table. > >>>>>>>>> Such optimization is possible only if the application gives a hint > >>>>>>>>> about its usage of the table during initial configuration. > >>>>>>>>> > >>>>>>>>> The transfer domain rules may process traffic from wire or vport, > >>>>>>>>> which may correspond to two kinds of underlayer resources. > >>>>>>>>> That's why the first two hints introduced in this patch are about > >>>>>>>>> wire and vport traffic specialization. > >>>>>>>>> Wire means traffic arrives from the uplink port while vport means > >>>>>>>>> traffic initiated from VF/SF. > >>>>>>>>> > >>>>>>>>> There are two possible approaches for providing the hints. > >>>>>>>>> Using IPv4 as an example: > >>>>>>>>> 1. Use pattern item in both template table and flow rules. > >>>>>>>>> > >>>>>>>>> pattern_template: pattern ANY_VPORT / eth / ipv4 is 1.1.1.1 / end > >>>>>>>>> async flow create: pattern ANY_VPORT / eth / ipv4 is 1.1.1.2 / end > >>>>>>>>> > >>>>>>>>> "ANY_VPORT" needs to be present in each flow rule even if it's > >>>>>>>>> just a hint. No value to match because matching is already done by > >>>>>>>>> IPv4 item. > >>>>>>>>> > >>>>>>>>> 2. Add special flags into table_attr. > >>>>>>>>> > >>>>>>>>> template_table 0 create table_id 0 group 1 transfer vport_orig > >>>>>>>>> > >>>>>>>>> Approach 1 needs to specify the pattern in each flow rule which wastes > >>>>>>>>> memory and is not user friendly. > >>>>>>>>> This patch takes the 2nd approach and introduces one new member > >>>>>>>>> "specialize" into rte_flow_table_attr to indicate possible flow table > >>>>>>>>> optimization. > >>>>>>>> > >>>>>>>> The above description is misleading. It alternates options (1) > >>>>>>>> and (2), but in fact (2) requires (1) as well. > >>>>>>> > >>>>>>> Yes the above description may be misleading > >>>>>>> and it seems you are misleaded :) > >>>>>> > >>>>>> It is not my intention. If it is only my problem, I'm OK to > >>>>>> step back. > >>>>> > >>>>> It's OK to explain and check everything is OK, no worries. > >>>>> Thanks for reviewing. > >>>>> > >>>>>>> I will explain below why the option (2) doesn't require (1). > >>>>>>> I think we should apply the same example to both cases to make it clear: > >>>>>>> > >>>>>>> 1. Use pattern item in both template table and flow rules: > >>>>>>> > >>>>>>> template table 3 = transfer pattern ANY_VPORT / eth / ipv4 src is 255.255.255.255 / end > >>>>>>> flow rule = template_table 3 pattern ANY_VPORT / eth / ipv4 src is 1.1.1.1 / end > >>>>>>> > >>>>>>> The pattern template 3 will be used only to match flows coming from vports. > >>>>>>> ANY_VPORT needs to be present in each flow rule. > >>>>>> > >>>>>> It looks like I lost something here. Why do we need to specify > >>>>>> it in each flow rule if the matching is already fixed in > >>>>>> template table? > >>>>> > >>>>> I think that's how template tables are designed. > >>>>> Ori, please could you point us to the relevant documentation? > >>>>> > >>>>>>> ANY_VPORT matching is redundant with IP src 1.1.1.1 because > >>>>>>> the user knows 1.1.1.1 is the IP of a vport. > >>>>>> > >>>>>> What should happen if a packet with src IP 1.1.1.1 comes from > >>>>>> the wire? Almost anything could come from network. > >>>>> > >>>>> It a packet comes from a wired port AND > >>>>> the PMD did an optimization based on this hint, > >>>>> then the packet could be not matched. > >>>> > >>>> So, the hint changes matching results and therefore becomes > >>>> a strange (extra) matching criteria under specific > >>>> circumstance. It sounds bad. > >>> > >>> In this case, the user made a wrong assumption. > >>> If the user does not do a mistake, the behavior should be the same > >>> whether the hint is used or ignored. > >>> > >>>> So, good application must use > >>>> real (always) matching criteria when composing flow rules. > >>> > >>> Of course, nothing replaces matching criteria. > >>> > >>>> So, RTE flow API should provide a way to write a good > >>>> application without extra pain. > >>>> That's why I'm saying that (2) requires (1) anyway. > >>> > >>> I don't follow this sentence. > >>> If you mean with hint, flow matching is still required, then yes, > >>> this is what I emphasized in my rewrite of the case (2) below. > >>> > >>>> It does not say that hint is not required at all. > >>>> It is still useful for resources usage optimization if > >>>> application knows how it is going to use particular table. > >>> > >>> Yes, that's an optional optimization. > >>> It should not change the rules, > >>> and it should not change the functional behavior > >>> if the user does not do mistakes. > >> > >> So, we basically agree on the topic, but my goal here is a bit > >> bigger. Make it easier for a user to avoid mistakes. May be it > >> is stupid goal :) and all efforts are vain. > >> If we have a match item with similar functionality it would be > >> easy to just put it into a pattern. Otherwise, it could be > >> complicated, have high chances to be skipped and rely on > >> implicit matching criteria imposed by the hint on the HW > >> which takes it into account. > > > > We may highlight in the doc that the functional behaviour must not rely > > on the hints. It is only optional optimization and effects may vary > > with differents driver. > > What do you think? I don't know what else to do about user mistakes :) > > As I said - add corresponding pattern items. I think I get it now. You suggest to have pattern items for VPORT and PHY_PORT, so the user won't be tempted to use hint for such matching? We used to have RTE_FLOW_ITEM_TYPE_PHY_PORT, we could think about it. > Anyway, hint itself is OK and makes sense. Hopefully > documentation highlights that pattern match is required. Yes we did an effort to highlight what are hints in the last version. > If so, > > Acked-by: Andrew Rybchenko