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 4E63141B9F; Wed, 1 Feb 2023 14:48:57 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3A26042D0B; Wed, 1 Feb 2023 14:48:57 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id F226942D0B for ; Wed, 1 Feb 2023 14:48:54 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 90F365C017F; Wed, 1 Feb 2023 08:48:54 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 01 Feb 2023 08:48:54 -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=1675259334; x= 1675345734; bh=BUzSFZQmg1aAFGO+TsFYgoTIhohCmz6OawshqDBbc78=; b=Q i+e4+6Lq070AkFpfFTYxeMBim+L7aJ2POkxK8ebIJ3paf70o/C9rBtp3kaCZ7TmF s5keBOoqHuw4MX6Ez6Cmr3DiCyWSpldLldIiVFdd6qjfZtH96yZGJ0hksGuaVDbs Mqmvx16NJhTyDd0tT9q8OVwuFEy6ZNLh4GZq7q7CCCnqvnH5J3D+4aadLTg61pda CQl6F9yiG5wyhhhfSwHijJXTk2wCbV3B++rd+sRZXUMvjPlyyE50qjxg5PLUzTvv MSeIMHEzCTa5s3lSsLfcRfqa3EkjdseNRrLuaSDCLldlGLgG1LGNvEoRWXJimnNy 9VaZ15/92CIaZMohw/PFw== 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=1675259334; x= 1675345734; bh=BUzSFZQmg1aAFGO+TsFYgoTIhohCmz6OawshqDBbc78=; b=X HU0ZndfpNSvmIX+fE9J113cyBu+fkPaN0uLEiVjic7W/eL2DgjjZoD0KFTmEbqHW pXIrFAYObGXZziCT66VuV7egEDNKcRvWBgQJSAsm4BCfKKMPpr3NfpbczhrQ8Njt EvMp+mSuBBSYpyzMJIskdp7Bh7tk26CB8SxJO4tuFKDff3oexoLvCO/Wv6rOfwUR nx3OaYBqz468X2jkukpIEdpLcRAyIzhVzIwOTxRc1/ZFelOeTDknQaPVexI6I1Oi vMxrfsD8u45dpgEFnYfdFD/paIKn/foWKeTHHWVrlN+zP02UdSfFhqXcluKhRFqF TIRzTkdWfSz8NelxVdxKw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefiedgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 1 Feb 2023 08:48:53 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit , Andrew Rybchenko Cc: Rongwei Liu , matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, Aman Singh , Yuying Zhang , dev@dpdk.org, rasland@nvidia.com, jerinj@marvell.com Subject: Re: [PATCH v7] ethdev: add special flags when creating async transfer table Date: Wed, 01 Feb 2023 14:48:51 +0100 Message-ID: <2309073.BjyWNHgNrj@thomas> In-Reply-To: <1f05e083-8b0c-4ebf-a0f8-0b3c559cbc8c@oktetlabs.ru> References: <51e583ea-4446-fea5-af74-dfe75d37f05c@oktetlabs.ru> <6867333.18pcnM708K@thomas> <1f05e083-8b0c-4ebf-a0f8-0b3c559cbc8c@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 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 :)