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 DCFCCA04AD; Mon, 24 Jan 2022 18:35:48 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6920541168; Mon, 24 Jan 2022 18:35:47 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by mails.dpdk.org (Postfix) with ESMTP id 104FA40040 for ; Mon, 24 Jan 2022 18:35:46 +0100 (CET) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 30D50580161; Mon, 24 Jan 2022 12:35:45 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 24 Jan 2022 12:35:45 -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; bh=qhO68BEly8sG80 XP+IgKQbyCLWeF01viy32W6DdoeHU=; b=rxFLWjlz0zVSpSBENKdq2xogoRcDAU hMLtFREd3uVvKtzvXOTKRTN5qzKTUpFPvrneHkZq35tiXq5x0eD4v/q9wo2hA/6p uzq5P/R9mMpdorrcnYd3KCqN69jL/vJFK7hVOOtjZ+CcPwGB7I0kv0SzB7zEq7hU +UdmwEnUqykCSUJmanRNmDti5NhShDUaaQp+30BAX8iTrA80XSlEIwRlUFqQQn08 iYXXGwX1DFtlgPR0VG3BX0YucK6VL5UiQxbbOKOM1899NBTR6Tprw7Aix9oT3plp kficuHflsnqDTnXk6f1jQ1xgfK3oK4efxc3yzJLQj3zcm7POmADV2vTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=qhO68BEly8sG80XP+IgKQbyCLWeF01viy32W6Ddoe HU=; b=gFg3HBKxNlWtgxWV8Krw3hRWFnahtTYxUT4Eu2eC2ez0f9VdvqfqW4ovS N61mHlOqh5ptH2vA8bztoQX4VJVtuarqOFTiS1HdyNp53ORxKTOx9ShKtVXT/cnM oB8HyEgX0cQlqABMyVjyK46XwGBg7bQrhqsXUMlz6YAQBXMOPZXnm7pwwwtJ4IMY umDlOMMYFcwKB5iEvS5Kih1LeMvddpi+ewNy/H47LRXulo4E75K4ZkqLs9vZ4N7d N/7xYTCXs/Da4spnaUCraNP+ilu+OyjsWsPDrpgYHyWvVS4ZOjX5asYFW8i71k7H JN+RGoYceunpiezvYTNvwRtosgeyg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvdeigddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhn rdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 24 Jan 2022 12:35:41 -0500 (EST) From: Thomas Monjalon To: Jerin Jacob Cc: Alexander Kozyrev , dev@dpdk.org, Ori Kam , Ivan Malov , Andrew Rybchenko , Ferruh Yigit , mohammad.abdul.awal@intel.com, Qi Zhang , Jerin Jacob , Ajit Khaparde , bruce.richardson@intel.com, david.marchand@redhat.com, olivier.matz@6wind.com, stephen@networkplumber.org Subject: Re: [PATCH v2 01/10] ethdev: introduce flow pre-configuration hints Date: Mon, 24 Jan 2022 18:35:40 +0100 Message-ID: <4371468.LvFx2qVVIh@thomas> In-Reply-To: References: <20211006044835.3936226-1-akozyrev@nvidia.com> <20220118153027.3947448-2-akozyrev@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 24/01/2022 15:36, Jerin Jacob: > On Tue, Jan 18, 2022 at 9:01 PM Alexander Kozyrev wrote: > > +struct rte_flow_port_attr { > > + /** > > + * Version of the struct layout, should be 0. > > + */ > > + uint32_t version; > > Why version number? Across DPDK, we are using dynamic function > versioning, I think, that would be sufficient for ABI versioning Function versioning is not ideal when the structure is accessed in many places like many drivers and library functions. The idea of this version field (which can be a bitfield) is to update it when some new features are added, so the users of the struct can check if a feature is there before trying to use it. It means a bit more code in the functions, but avoid duplicating functions as in function versioning. Another approach was suggested by Bruce, and applied to dmadev. It is assuming we only add new fields at the end (no removal), and focus on the size of the struct. By passing sizeof as an extra parameter, the function knows which fields are OK to use. Example: http://code.dpdk.org/dpdk/v21.11/source/lib/dmadev/rte_dmadev.c#L476