From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B64EAA0512; Wed, 3 Jun 2020 12:02:35 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D983F1C216; Wed, 3 Jun 2020 12:02:34 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id BF9261C1D7 for ; Wed, 3 Jun 2020 12:02:33 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 635315C00EE; Wed, 3 Jun 2020 06:02:33 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 03 Jun 2020 06:02:33 -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=fm1; bh= ede2sSZkEGZAG+XSctZPhhj60gOJ6Ct+QH20Uf32fwo=; b=ZoFG8jlFq6hXSOHO OVvV19TOj1of+/LLNKx90y7jmPqPmanxT9ph35ABil+xU5y2q5sxs3qtvWRW4OcE hfcSBH8DsXgWM63LxCjpyqnGC3NuED78F8JXEDgKjVw/vmDoc3h21Ik0v97qkBbZ TqrZKLnzcXoXIH0bdO5RtDri5ERZqfZRLYk/sX65XJe+TZF4zpx1P6CO3lWMarwL Rbs1+KUBqh/84AbFsc8Y3AP9eL0hMTSjpp5M8JH6hO5/R6P90HJ6FOSqDd6YuyLD oWO0iRNRUfZgVre5ssK8IqIUApi7gPRgYOGW+NfH6u2RhXoOhypoeRPNzddHzrEs JCGaVQ== 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=fm2; bh=ede2sSZkEGZAG+XSctZPhhj60gOJ6Ct+QH20Uf32f wo=; b=z0hMSfNAzLFOrAQ8tIJHFLJVeNvbG3QhOlWQ1LZoAvaz3VTaiUC48gsGh MgBPkYsfW3mfFyPTah0BwaaM9k4XkpH/Lma+I2msUXlWG51giJvEJQsw14s6H7NK Vlkd9wy5HP5wip16XdtojV6lef/TM7R3JUrK4Lkjm69Bzav/cjly3g3iH4prhfs6 ucPtos7KG8m8jxAd+Cc1PsRqXfEscm2XXFfY3lszG31smjQhEAYWi4yqCDTGKijG agVUUe0q6WBV5BUxayIDdP3TarV17atSVHvhkmmg/A0pVO9On3O/abv3QotKpUZr qJ6XkB36mLufBv2Ft2QFs/j6yyhRg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefledgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 24A503061856; Wed, 3 Jun 2020 06:02:32 -0400 (EDT) From: Thomas Monjalon To: Andrey Vesnovaty Cc: Ferruh Yigit , Andrew Rybchenko , Ori Kam , dev@dpdk.org Date: Wed, 03 Jun 2020 12:02:30 +0200 Message-ID: <318236911.yWikKUQR1j@thomas> In-Reply-To: <20200520091801.30163-1-andrey.vesnovaty@gmail.com> References: <20200520091801.30163-1-andrey.vesnovaty@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC] add flow action context API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" 20/05/2020 11:18, Andrey Vesnovaty: > This commit introduces extension of DPDK flow action API enabling > modification of single rte_flow_action. > > Motivation and example > === > Adding or removing one or more queues to RSS actions cloned in multiple > flow rules imposes per rule toll for current DPDK flow API; the scenario > requires for each flow sharing cloned RSS action: > - call `rte_flow_destroy()` > - call `rte_flow_create()` with modified RSS action > > In order to prevent the overhead of multiple RSS flow rules reconfiguration > API for in-place flow action modification introduced in this commit. It seems there is an usability improvement with this new API. If I understand well, the main motivation is to improve the performance? The PMD implementation should try to keep a shared object to benefit of the performance improvement, right? The existing rte_flow API functions are: rte_flow_validate() rte_flow_create() rte_flow_destroy() rte_flow_flush() rte_flow_query() rte_flow_isolate() rte_flow_get_aged_flows() > + # added in 20.08 > + rte_flow_action_ctx_create; > + rte_flow_action_ctx_destoy; > + rte_flow_action_ctx_modify; > + rte_flow_action_ctx_query; We had "create", "destroy", "query", but no "modify" capability. The new API is adding 2 things in my opinion: - shared action object - "modify" capability (is "update" a better wording?) About the wording, do we need "ctx"? I feel rte_flow_action is a good enough prefix for this API, and should be documented as a shared action object. I think the word "object" is more meaningful than "context". Am I missing something? > + /** > + * Describes action context. > + * > + * Enables multiple rules reference the same action by id/ctx. > + * > + * No action specific struct here (void*) since it can be any > + * action type. > + */ > + RTE_FLOW_ACTION_TYPE_CTX, Why do we need a new action type? > @@ -101,6 +101,28 @@ struct rte_flow_ops { > + /** See rte_flow_action_ctx_destoy() */ > + void *(*action_ctx_create) > + (struct rte_eth_dev *dev, > + const struct rte_flow_action *action, > + struct rte_flow_error *error); > + /** See rte_flow_action_ctx_create() */ > + int (*action_ctx_destroy) > + (struct rte_eth_dev *dev, > + void *ctx, > + struct rte_flow_error *error); > + /** See rte_flow_action_ctx_modify() */ > + int (*action_ctx_modify) > + (struct rte_eth_dev *dev, > + void *ctx, > + const void *action_conf, > + struct rte_flow_error *error); > + /** See rte_flow_action_ctx_query() */ > + int (*action_ctx_query) > + (struct rte_eth_dev *dev, > + const void *ctx, > + void *data, > + struct rte_flow_error *error); API functions are directly linked to PMD ops, it looks simple and good.