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 E76E34240F; Wed, 18 Jan 2023 17:19:05 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DBDAE40223; Wed, 18 Jan 2023 17:19:05 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id CF7E2400D6 for ; Wed, 18 Jan 2023 17:19:03 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 157213200124; Wed, 18 Jan 2023 11:19:00 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 18 Jan 2023 11:19:00 -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=1674058739; x= 1674145139; bh=QD+LF32bcQu4S2f78QF6YRfD5Lr5+t2sXY8mu6BtiMM=; b=b yNgjVjxlC08uYpNjKUic7/c10g9qU09M1fsMfKZJetMlLDLsQ1WJqUblr8BfHyOb 60FD2z0Kw48Jspz0Kltn0amOUtPEXePxUcO29FhfjdHALrdRbhLHspHcTtJ1Qyp8 Tfeb4+mKxiqqTtHVCoEXla1Sea/lGebnbrEpIY/fIdDsKO90iUVYoDJjtej5+ddf 0xSliUTmqkROlCHdEP2f7KAvz1RlbLZTTIUhqOsqo7u80m1ZkToVDnnEF8RiLOad ZPnKRqsiGHoUnQ01/70GaIGhqpnuhMhPZHurNTHq6tbJQ2MTF/ljxCQZ7z1OYXnX O2KMwIElIBpxJUTW7yr0A== 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=1674058739; x= 1674145139; bh=QD+LF32bcQu4S2f78QF6YRfD5Lr5+t2sXY8mu6BtiMM=; b=H QeX76SyWUUX6l0E5FISXARUmJ7o7XWpAWSu0OoOHn770KBSiUZLiQepjVYLnauZv UAwav+G3mluWQFoykrVpYmc6rEYah/d4mmd7FEIxmfgG5CG+KVFCJ9OKjTkiQOAF ss/3MVlqhJQ/MuPgbrLQEpFmI91IwVCpt1pKUPzxmG9JrVs9AWPq8kAzzP9NVzij +f8S9fqk4dcrCEAQBw59SutmJMGoghuHlhfjt101Z8JMCNlLMrQ6jzk5Beq6TTur XXPvkaRJG3lW2TGaurmLYHQ36M+gk5EqKPIWH59cYAEPlaU/XdeARpjKhL3RyDSe zgdUG/aIIBv9wZYEhI+Gg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddtkedgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 18 Jan 2023 11:18:57 -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, 18 Jan 2023 17:18:55 +0100 Message-ID: <13070250.ZYm5mLc6kN@thomas> In-Reply-To: <1f7972ac-ad64-bde4-554d-d3ee1afbc324@oktetlabs.ru> References: <51e583ea-4446-fea5-af74-dfe75d37f05c@oktetlabs.ru> <20221114115946.1074787-1-rongweil@nvidia.com> <1f7972ac-ad64-bde4-554d-d3ee1afbc324@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 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 :) 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. 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. 2. Add specialization flag into template table attribute: template table 3 = transfer VPORT_ORIG pattern eth / ipv4 src is 255.255.255.255 / end flow rule = template_table 3 pattern eth / ipv4 src is 1.1.1.1 / end The pattern template 3 can be used only to match flows coming from vports. > (2) is simply done on different level - much earlier, before > flow rules creation. Since resources allocation is assumed to > be done on table creation, we need to know the purpose of the > table in advance to optimize resources allocation. Actually in both cases we get the hint at template table creation. But in solution 2 we are not creating a redundant pattern matching, and we don't need to check it in flow rules, so it is more efficient. > Since (2) is *not a matching criteria*, but just a hint, (1) > flow rules must have matching criteria anyway. No we don't need the matching criteria ANY_VPORT with solution (2) because we are already matching on an IP src which is a vport. > > +Table Attribute: Specialize > > +^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > + > > +Application can help optimizing underlayer resources and insertion rate > > +by specializing template table. > > +Specialization is done by providing hints > > +in the template table attribute ``specialize``. > > + > > +This attribute is not mandatory for each PMD to implement. > > +If a hint is not supported, it will be silently ignored, > > +and no special optimization is done. > > + > > +If a table is specialized, the application should make sure the rules > > +comply with the table attribute. > > If a table is specialized, the application must make sure that > all flow rules added to the table have pattern which implies > corresponding matching criteria. For example if a table is > specialized to be wire-origin only, pattern should have > represented port item with ethdev which corresponds to a > physical port (or any other item which matches packets > coming from wire only). No need of a matching criteria strictly mapping the hint. Here the hint is SPECIALIZE_TRANSFER_VPORT_ORIG and the rules can match on an IP src which is assigned to a vport. So there is no need to strictly match the vport itself in the rule. Hope it make thinks clear. We can improve the commit log as I wrote above.