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 57D34A0093; Tue, 8 Nov 2022 14:29:16 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E98E0400D4; Tue, 8 Nov 2022 14:29:15 +0100 (CET) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 14AB54003C for ; Tue, 8 Nov 2022 14:29:14 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A74995C012C; Tue, 8 Nov 2022 08:29:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 08 Nov 2022 08:29:13 -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=fm1; t=1667914153; x= 1668000553; bh=1LVkI2soD8IVHqyLgqThAnQlEHmT7Eo9Bw86+bEpKJ0=; b=f 7g3L3CKdfMQ7cBUFzZn+Bxh4VBa4Crjv2Fcjn8xmVgG63YajKHuGyL4Dnx1cQY6Y HLMOM/T6r0F/FCAJdLQcJIrvLd/GalcCNXXd+NP+55vR1zMDBKhhw+701/LuH7Js HoBhanfw2a/rgVei7vW3agUgzsTdn5TS+i2OjxR2bVxETr8oGO640eAOJDkA3HqU ZIa0/quUK773n1gb+7HISnlAyg9Al9zvKgr29amxcRR4GhG50NjAfKCDL6dabywu GtK6UTis1XybM1TIc7N0JJ5ByOfPTy5B5KOx2PYRRr4oHlMq3S5n/OGKKisSFW7v jv3HIC/3qIpqJ8T4gxEyQ== 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=fm1; t=1667914153; x= 1668000553; bh=1LVkI2soD8IVHqyLgqThAnQlEHmT7Eo9Bw86+bEpKJ0=; b=n Qu7esiRxJd+iZAoB3CNkZ2XztDlbz08KEfypJOzbL681JobgLfi5iQg18tplHiir a9wpiwRmN0h51HUQ79RlWOgMcPWCEBrC1I2ZrU+habVzbhmxP5vtJK26W/QErgeI dx75+XCoA4U3fvuhDsspivl0dty53ZWuxETppZEmDNZJs80uiu/Pk77SjedBfrdr bBwOjX26yahrwX9SW94fsXyVpVTezDQ6vlNXcROt7fGqBQrey6s5Kg1HG4jzleYb H/zWHNnRAJDW/INzThsB3kFU05/PhcP4WQydGHSVSJdyu3NLpNvWLJJ2/E4a5LXF Hcexhf+dRioxCyHba6T3Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfedtgdehfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnheptdejieeifeehtdffgfdvleetueeffeehueejgfeuteeftddtieek gfekudehtdfgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Nov 2022 08:29:12 -0500 (EST) From: Thomas Monjalon To: Andrew Rybchenko Cc: Rongwei Liu , matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, Aman Singh , Yuying Zhang , Ferruh Yigit , dev@dpdk.org, rasland@nvidia.com Subject: Re: [PATCH v4] ethdev: add special flags when creating async transfer table Date: Tue, 08 Nov 2022 14:29:10 +0100 Message-ID: <2068231.htQpZWrp2x@thomas> In-Reply-To: <8e1d278e-f9db-26f3-ff5f-c12be9db1827@oktetlabs.ru> References: <125dc971-f3e6-b834-2488-c44047ef14b4@oktetlabs.ru> <8e1d278e-f9db-26f3-ff5f-c12be9db1827@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 08/11/2022 12:47, Andrew Rybchenko: > On 11/8/22 14:39, Andrew Rybchenko wrote: > > On 11/4/22 13:44, Rongwei Liu wrote: > >> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h > >> index 8858b56428..1eab12796f 100644 > >> --- a/lib/ethdev/rte_flow.h > >> +++ b/lib/ethdev/rte_flow.h > >> @@ -5186,6 +5186,34 @@ rte_flow_actions_template_destroy(uint16_t > >> port_id, > >> */ > >> struct rte_flow_template_table; > >> +/** > >> + * @warning > >> + * @b EXPERIMENTAL: this API may change without prior notice. > >> + * > >> + * Special optional flags for template table attribute. > >> + * Each bit stands for a table specialization > >> + * offering a potential optimization at PMD layer. > >> + * PMD can ignore the unsupported bits silently. > >> + */ > >> +enum rte_flow_template_table_specialize { > >> + /** > >> + * Specialize table for transfer flows which come only from wire. > >> + * It allows PMD not to allocate resources for non-wire > >> originated traffic. > >> + * This bit is not a matching criteria, just an optimization hint. > >> + * Flow rules which match non-wire originated traffic will be missed > >> + * if the hint is supported. > > Sorry, but if so, the hint changes behavior. Yes the hint may change behaviour. > Let's consider a rule which matches both VF originating and > wire originating traffic. Will the rule be missed (ignored) > regardless if the hint is supported or not? If the hint RTE_FLOW_TRANSFER_WIRE_ORIG is used, the PMD may assume the table won't be used for traffic which is not coming from wire ports. As a consequence, the table may be implemented on the path of wire traffic only. In this case, the traffic coming from virtual ports won't be affected by this table. To answer the question, a rule matching both virtual and wire traffic will be applied in a table affecting only wire traffic, so it will still apply (not completely ignored). If you really want to manage both types of traffic in this table, you must not use such hint. > I.e. it will not apply to wire originated traffic as well. > > >> + */ > >> + RTE_FLOW_TRANSFER_WIRE_ORIG = RTE_BIT32(0), > >> + /** > >> + * Specialize table for transfer flows which come only from vport > >> (e.g. VF, SF). > >> + * It allows PMD not to allocate resources for non-vport > >> originated traffic. > >> + * This bit is not a matching criteria, just an optimization hint. > >> + * Flow rules which match non-vport originated traffic will be > >> missed > >> + * if the hint is supported. > >> + */ > >> + RTE_FLOW_TRANSFER_VPORT_ORIG = RTE_BIT32(1), > >> +}; > >> + > >> /** > >> * @warning > >> * @b EXPERIMENTAL: this API may change without prior notice. > >> @@ -5201,6 +5229,10 @@ struct rte_flow_template_table_attr { > >> * Maximum number of flow rules that this table holds. > >> */ > >> uint32_t nb_flows; > >> + /** > >> + * Optional hint flags for PMD optimization. > >> + */ > >> + enum rte_flow_template_table_specialize specialize; > > > > > > IMHO it is not 100% correct to use enum for flag since > > RTE_FLOW_TRANSFER_WIRE_ORIG | RTE_FLOW_TRANSFER_VPORT_ORIG > > is not the enum member. uint32_t is a better option here since > > bits are defined as RTE_BIT32. enum should be mentioned in the > > description. I agree, let's not use enum. Instead we can mention the prefix of the defines in the comments.