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 C49DC4240D; Wed, 18 Jan 2023 13:07:28 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 65EB5400D6; Wed, 18 Jan 2023 13:07:28 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id 0BF614003F for ; Wed, 18 Jan 2023 13:07:27 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 51443320051E; Wed, 18 Jan 2023 07:07:25 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 18 Jan 2023 07:07:26 -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=1674043644; x= 1674130044; bh=JbOc0KIbh+vdEwDpU/Q2NnTt3FV8LRGNd1SYteyNMh0=; b=C VMjit0M64H+4TvXuU4Xo+r/D6HHr11vdRRq1grJAANPEWYpCQ05ISfA3hcY4LhEX UogQyR1hXtUVWRPnm7e+cXx8kt2XBw7dEltI31iG4O4GcDKyPntYUzZYwiNIQyOW /Txazf5DyDbMHPI6TG4PaUZWQkeS0AEE5iERKML4kWONF24lAQfr+ebBYVikPufd SQlatyD5/0uYXR5nk783ekOxU4Sznawq09uZYKHHw+LUWHIM0YesxYnrokVAUtiA aHJg9WUejeQxrJjaXzO6PsaOVB1yPJeZBnjV3ypLHjlf66K4o2yl+m/aUFOQJ7cn 9tuBH9dbore6TbE/+aG2A== 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=1674043644; x= 1674130044; bh=JbOc0KIbh+vdEwDpU/Q2NnTt3FV8LRGNd1SYteyNMh0=; b=D tppZ5/hWT9SLFcsP4Ler2fWpYR2tXp2NfGc2UU45Q4yFTyR1RqvwwaOb9wAhQEIK B8Y73oYdhGK6mkkJTCy91HAINmNO+HijBcJZaBMvR7LlI9MCHgo7jmV2F5Ox2Wd7 GX/ZnarNIIGNK6UM3uKdv3BHaH4rDqmPW2Td1Vul55kgsbqRr0rn2sLaA1j/ish2 ZvHWUZCQPQ4VZvVgvw3xx8CJSvy6XWhDu7vPaOsJdnd7gbaU9Vi/gXweVPg8lByz gLcXxNZxctb7TwxKYVOb3NkulfVRfPP5N82wYhM2dYIVp9nYHbMKrK2J8DJIwQib ZTXrCHUoWTI2sIjBFmsug== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddtkedgfeeiucetufdoteggodetrfdotf 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 07:07:23 -0500 (EST) From: Thomas Monjalon To: Viacheslav Ovsiienko Cc: dev@dpdk.org, matan@nvidia.com, rasland@nvidia.com, orika@nvidia.com, andrew.rybchenko@oktetlabs.ru, ivan.malov@oktetlabs.ru, ferruh.yigit@amd.com Subject: Re: [RFC] ethdev: sharing indirect actions between ports Date: Wed, 18 Jan 2023 13:07:22 +0100 Message-ID: <12784039.iMDcRRXYNz@thomas> In-Reply-To: <20221228165433.18185-1-viacheslavo@nvidia.com> References: <20221228165433.18185-1-viacheslavo@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 28/12/2022 17:54, Viacheslav Ovsiienko: > The RTE Flow API implements the concept of shared objects, > known as indirect actions (RTE_FLOW_ACTION_TYPE_INDIRECT). > An application can create the indirect action of desired > type and configuration with rte_flow_action_handle_create > call and then specify the obtained action handle in multiple > flows. > > The initial concept supposes the action handle has strict > attachment to the port it was created on and to be used > exclusively in the flows being installed on the port. > > Nowadays the multipath network topologies are quite common, > packets belonging to the same connection might arrive and > be sent over multiple ports, and there is the raising demand > to handle these "spread" connections. To fulfil this demand > it is proposed to extend indirect action sharing across the > multiple ports. This kind of sharing would be extremely useful > for the meters and counters, allowing to manage the single > connection over the multiple ports. > > This cross-port object sharing is hard to implement in > generic way merely with software on the upper layers, but > can be provided by the driver over the single hardware > instance, where multiple ports reside on the same physical > NIC and share the same hardware context. > > To allow this action sharing application should specify > the "host port" during flow configuring to claim the intention > to share the indirect actions. All indirect actions reside within > "host port" context and can be shared in flows being installed I don't like the word "host" because it may refer to the host CPU. Also if I understand well, the application must choose one port between all ports of the NIC and keep using the same. I guess we don't want to create a NIC id. So I would suggest to rename to nic_ref_port or something like that. > on the host port and on all the ports referencing this one. Not "all the ports" but only on sibling ports (ports of the same NIC). > If sharing between host and port being configured is not supported > the configuration should be rejected with error. There might be > multiple independent (mutual exclusive) sharing domains with > dedicated host and referencing ports. > > To manage the shared indirect action any port from sharing domain > can be specified. To share or not the created action is up to > application, no API change is needed. [...] > + /** > + * Port to base shared objects on. > + */ > + uint16_t host_port_id; Is it a DPDK ethdev port ID? You should add this feature to the release notes and in rte_flow guide. PS: please Cc ethdev maintainers.