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 4820CA00C4; Thu, 4 Jun 2020 19:23:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9C27D1D5D8; Thu, 4 Jun 2020 19:23:09 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 6D47F1D5CE for ; Thu, 4 Jun 2020 19:23:07 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9E5F35C0194; Thu, 4 Jun 2020 13:23:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 04 Jun 2020 13:23:06 -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= ojCHp1Rx4cxv2tq5zRNb2XTpLr1AIv+iwE9mU7ro7+Y=; b=b9k0IUJfeOcnXpJW zbcch2s+xjGgcsWqzK+h4mIUp4YJXxVA8yR/1i1mT19MKB3kLMfZ7rsInexGoFfV fc02zZ9I5gKF1RAx62nOEz8yUcezSJWtwLIJl79NlDOXa5YXIQ4gwECg1iCshtx9 DUdOJg02gWHyPNq44tv5L0swYkW28LxS1lCeJtIyO6iqVTXE8ljsbH4laGtTuiWP X0dht732/pknj1IoJUMWR//aJGkQY64wbJY+Z8AgByf2XuBfsHV5GLpHkOy+EiKB Pdt0zqdlIV4oAiv5ACRj8LaLb00cJwpaATYHcBbK+y+wAJBWLCvRfdCrsiDgbFhD 5pJFJg== 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=ojCHp1Rx4cxv2tq5zRNb2XTpLr1AIv+iwE9mU7ro7 +Y=; b=AMHHOCB9QYoiaMMQsiyNBVuOsn778L6owH4SOdWDMQk71hHpdM4JmS/kq 3PGNVdQy9s5+3Fc2kzlRN+0EsoSN53ClwN68WbZz9akKR8E+CJgCf1AAUF3ip7xb yGOQqfXVmTVtROvH6zXxaZEyomUd22xvF2iXUn0gADGnkDejgxr/JEuFBCF0UQ1/ suHhZGS8kz97/IM1ABmMBjstCadOPbOkQn7paeJxoKt1jevKaSoYAO7Pn3iCY9ti Qjxel53SDAcwreNN+fkqEs0vU3l2CHrovGhYD5nCDCkBHW7twmVOht7p36ftqNZU g/P6fK4FYz8dwTp/Hv1bFNZxntgYQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeguddguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgr lhhonhdrnhgvth 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 667DF3280065; Thu, 4 Jun 2020 13:23:05 -0400 (EDT) From: Thomas Monjalon To: Andrey Vesnovaty Cc: dev@dpdk.org, Ferruh Yigit , Andrew Rybchenko , Ori Kam , dev@dpdk.org Date: Thu, 04 Jun 2020 19:23:04 +0200 Message-ID: <2468319.zLU6FhoSUI@thomas> In-Reply-To: References: <20200520091801.30163-1-andrey.vesnovaty@gmail.com> <318236911.yWikKUQR1j@thomas> 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" 04/06/2020 13:12, Andrey Vesnovaty: > Thomas Monjalon wrote: > > 20/05/2020 11:18, Andrey Vesnovaty: > > 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?) > > Naming is one of the most challenging parts of this RFC. > Some similarity I have found in existing code is > rte_mtr_policer_actions_update() > Is there any existing code having update/modify semantics? Except one callback in librte_fib, no DPDK API has "modify" in its name. You can find the word "update" in the API of multiple DPDK libs. I would like having the opinion of a native english speaker here. > > 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? > > CTX comes for the fact that each flow_rule doesn't have an ownership for > the given action but operates inside some context (shared action context > actually). > As mentioned above, naming is one of the most challenging parts of this > RFC. I think we can replace "context" with "object" in the explanations. The functions could be named without "ctx": - rte_flow_action_create - rte_flow_action_destroy - rte_flow_action_update - rte_flow_action_query > > > + /** > > > + * 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? > > > Because it's not an action itself but a reference/handle to it. Sorry I don't understand when RTE_FLOW_ACTION_TYPE_CTX has to be used. There is no mention of RTE_FLOW_ACTION_TYPE_CTX in the explanations.