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 AEA25A0C4C; Tue, 5 Oct 2021 19:56:37 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3D98A41420; Tue, 5 Oct 2021 19:56:37 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id DDAD341419 for ; Tue, 5 Oct 2021 19:56:35 +0200 (CEST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 593DE5C0156; Tue, 5 Oct 2021 13:56:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 05 Oct 2021 13:56:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= UTQ1HVoyqIYqOtnsoHM7DT0WO8toyquNmFQbzGbQqzY=; b=GVPApmwdvVaUF+M6 TsNPQggyfRXG1ayp8fkRZD7cm/hjP08jf9byZ/IpqW+q7wskA9pvSYxcELMaO495 vvYuo6yEXb6AY3fhsDbAEjRAi9PKqvLTZ9XxRGvgL1jvZJbYtjhs8AiyY6AYth/O 6Mj4GHMR/ravJe+J/KVZnY5RKFy1B4HCjASf6+IMD9He7XcCowB1bQ1xdz7NH/I7 d3SBvnohqM8fI7vyryl5rmI3py7kwLMw33vzMzzX2pGSZ2cqwJz3S/O31kN8i05v IdpORoVKSyCdZW+IlrMT7UGDrYwa4FcsjIUHCY9JUgOwGCFrnvTyTRVJ2ZessiAb kaix1w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=UTQ1HVoyqIYqOtnsoHM7DT0WO8toyquNmFQbzGbQq zY=; b=e9t9yfvHX79WeAdoVRIOD4jRAudd59j7LpuKCJWU8vlRHTcJ008RqEemS sVXZSsr3YeHE9r2DdpqVaN73QpghQAnlEqVMqldwqogpZ3cPaIKZcfcnX8VduUgb nbuf/f06QpfadsEGqEBpbKyBvl3hR68X1T/sleNDySAlzBu6UD8yZrgcf0r0F0Dh HQIPX6GQihpwHOXgcRFKO6+yhuDzBNZryBfc9Kthe4XhhmQg7puAlSl/A3PBuyOU RZ3mjhtlJsV2rjlZteq5iYP5IBY3Tf1/MZh+vUhjlYYF5TV9oxX2ZRvc+JOVkw9p fxZ19MoM/PbRu2xDqI5ZsJGrBr8VA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudelgedguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 5 Oct 2021 13:56:33 -0400 (EDT) From: Thomas Monjalon To: Ivan Malov Cc: dev@dpdk.org, Andrew Rybchenko , Xiaoyun Li , Ori Kam , Ferruh Yigit , Ray Kinsella Date: Tue, 05 Oct 2021 19:56:30 +0200 Message-ID: <8088650.46bvbtDH9c@thomas> In-Reply-To: <20211005003604.31684-1-ivan.malov@oktetlabs.ru> References: <20210907125157.3843-1-ivan.malov@oktetlabs.ru> <20211005003604.31684-1-ivan.malov@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] ethdev: let apps find transfer admin port for a given ethdev 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 Sender: "dev" 05/10/2021 02:36, Ivan Malov: > Introduce a helper API to let applications find transfer > admin port for a given ethdev to avoid failures when > managing "transfer" flows through unprivileged ports. Please explain what is transfer admin port. We may find a simpler wording. > --- a/lib/ethdev/rte_flow.h > +++ b/lib/ethdev/rte_flow.h > + * > + * Communicating "transfer" flows via unprivileged ethdevs may not > + * be possible. In order to pick the ethdev suitable for that, the ethdev -> port > + * application should use @p rte_flow_pick_transfer_proxy(). > */ > uint32_t transfer:1; [...] > +/** Please insert an one-line description here. > + * An application receiving packets on a given ethdev may want to have their > + * processing offloaded to the e-switch lying beneath this ethdev by means Is "e-switch" a common word? Or should we say "embedded switch"? > + * of maintaining "transfer" flows. However, it need never use this exact > + * ethdev as an entry point for such flows to be managed through. More to > + * that, this particular ethdev may be short of privileges to control the > + * e-switch. Instead, the application should find an admin ethdev sitting > + * on top of the same e-switch to be used as the entry point (a "proxy"). I recognize the nice right-alignment, but I think this text can be shorter. > + * > + * This API is a helper to find such "transfer proxy" for a given ethdev. > + * > + * @note > + * If the PMD serving @p port_id doesn't have the corresponding method > + * implemented, the API will return @p port_id via @p proxy_port_id. > + * > + * @param port_id > + * ID of the ethdev in question The rest of the API says "port", not "ethdev". Here I would suggest "ID of the port to look from." > + * @param[out] proxy_port_id > + * ID of the "transfer proxy" > + * > + * @return > + * 0 on success, a negative error code otherwise > + */ > +__rte_experimental > +int > +rte_flow_pick_transfer_proxy(uint16_t port_id, uint16_t *proxy_port_id, > + struct rte_flow_error *error);