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 D7AF841BAE; Thu, 2 Feb 2023 12:33:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6BA5E406A2; Thu, 2 Feb 2023 12:33:31 +0100 (CET) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 349E040689 for ; Thu, 2 Feb 2023 12:33:30 +0100 (CET) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C10735C0114; Thu, 2 Feb 2023 06:33:29 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Thu, 02 Feb 2023 06:33:29 -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=1675337609; x= 1675424009; bh=iTDo+VT4jZQzTrTDuK3XTbDRrNYLX7WfGTArK9ViohQ=; b=R yQQiUoZ9RkJ/POie3OKjzf9bC65nlxoagk8tWUWzZShemjEWcp9YYXw7nMI3wpuH ahuBgn43D0JUtA4DW+HpOctGBIxpbHYRqNzylMl2irVxDdbsW0pX1tjP3lFrQLWJ ZO7/OT60hPfxncB3RATUlNa3+F3hxEcq/c8k0qkKG0B3E6byZmecdMSuk7wuw3So TLE+HJO9ucSQBQiQPH/X12cAg7O5BtrI5KncC3QWPxkBdkOOPhlklBctz44kIg9O mvZCGLB3Zok61dME/D9G02GpoIBJPBV6SuVwVrlrSU/LvXIm+asUyDWTbNLiU8Gr fEFz9h1ibtjQr3Oun/YdA== 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=1675337609; x= 1675424009; bh=iTDo+VT4jZQzTrTDuK3XTbDRrNYLX7WfGTArK9ViohQ=; b=a ReWw/vavjhuWjUNNjQl/sM17pzVg3Uw5ulKpYLAOUdTBCHVKYgRKY07ZnP2haweA 6IoGiWsnGvW4hvrlXmwPII0rw2Ah/+XTCpTAqFwqkYmM6T6cmZdAewcorxinGvcz 2HYMC9Louuxcq93L8DR4E0Cb90Mpo5lp00drg2oB/yj6dXDc/aW1U3RL4yGGAPsR 7CaOm41dOVKMO3CS5Ie+wOY7Kdn4oGIr81pGSBKvjTK5YwiteJ/9m8ZrMS4kboas IAyrFMD0CPLVZRa0OABXVOzb9nmZM2nRw1rx9q7qVm8k2J9Q5XpcIqBgSWN5vRnl JaWIK7GPR1WEl92pOKxqg== 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:33:28 -0500 (EST) From: Thomas Monjalon To: Rongwei Liu Cc: dev@dpdk.org, matan@nvidia.com, viacheslavo@nvidia.com, orika@nvidia.com, rasland@nvidia.com, Aman Singh , Yuying Zhang , Ferruh Yigit , Andrew Rybchenko Subject: Re: [PATCH v8] ethdev: add optimization hints in flow template table Date: Thu, 02 Feb 2023 12:33:26 +0100 Message-ID: <5085921.31r3eYUQgx@thomas> In-Reply-To: <20230202111927.2450863-1-rongweil@nvidia.com> References: <20221114115946.1074787-1-rongweil@nvidia.com> <20230202111927.2450863-1-rongweil@nvidia.com> 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 12:19, Rongwei Liu: > 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 flow template table and 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 flow 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. > > Approach 1 needs to specify the hint in each flow rule that 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. > > By default, there is no hint, so nothing change. > There is no guarantee that the hints will be effective in the driver. > The application functionality must not rely on the hints. > > Signed-off-by: Rongwei Liu > Acked-by: Ori Kam Andrew gave this recent comment on v7: " Anyway, hint itself is OK and makes sense. Hopefully documentation highlights that pattern match is required. If so, Acked-by: Andrew Rybchenko " Given the lines below, I assume the documentation is OK. > +This attribute is not mandatory for driver 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. > +The application functionality must not rely on the hints, > +they are not replacing the matching criteria of flow rules. [...] > +/**@{@name Flags for template table attribute. > + * Each bit is an optional hint for table specialization, > + * offering a potential optimization at driver layer. > + * The driver can ignore the hints silently. > + * The hints do not replace any matching criteria. > + */ > +/** > + * 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. > + */ > +#define RTE_FLOW_TABLE_SPECIALIZE_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. > + */ > +#define RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_VPORT_ORIG RTE_BIT32(1) > +/**@}*/ [...] > + /** > + * Optional hint flags for driver optimization. > + * The effect may vary in the different drivers. > + * The functionality must not rely on the hints. > + * Value is composed with RTE_FLOW_TABLE_SPECIALIZE_* based on application > + * design choices. > + * Misused hints may mislead the driver, it may result in an undefined behavior. > + */ > + uint32_t specialize; Acked-by: Thomas Monjalon