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 99388A04A8; Wed, 26 Jan 2022 12:21:38 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 259FC4271B; Wed, 26 Jan 2022 12:21:38 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by mails.dpdk.org (Postfix) with ESMTP id 7E44042716 for ; Wed, 26 Jan 2022 12:21:37 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 33AFD5803EF; Wed, 26 Jan 2022 06:21:36 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 26 Jan 2022 06:21:36 -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=lKvZRFsrOR9SYI F9vA1OySreSlnXrzCLATG5+AYMjP8=; b=EoKctGwu6ExEOoUEtmH2eY+X9sXzfp r/BGK7sDaRF76xDL4M8PnBdNnOmRhjwg8Ise2M+yt8RJZ3bcrCKJx4TwTJeE3rmR 13WxHGjU+VEs/3k0exy6FWZ2hmXLXXAR0d3oHiDJOJwa3P+xHwbz4WiYZauquMhS CNBf4BuKc+Bw9TYjobYv+as/iGRI4GlHGsF3LieskCt/E2SiJydRBLo+sbhiWKtC uug9ZEhM/8BhYuyb/EwmN513pH7OgAv+bZlNJ951WwamyXsre+osC9yall79ag0l BHF6Gb/1yHLb9bZIRl0akf1KUqeK7qIZdCULvS2gaVtBOXYub7oNn6bA== 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=lKvZRFsrOR9SYIF9vA1OySreSlnXrzCLATG5+AYMj P8=; b=eLE2+hSc8RN/b1/Lxix85OlLKD/fqYjDlkXorAFyLDuODY8gZGjYmkrK/ +6vdkSj63azPd6zKrcTMCOJ1Qn7q7mhQHyZY0MsmWzBSEijFGl02IHhuC2lhhOJd Eu/o5rng7L3FFD0CvTFh5WC8oyI+CW9XhnwqCC0oTd+HjPJXnTLgLwPWK3EGdetC B2aml1NAmvNsL7oMUwmcoaMvw4WcVnRkelwayHWiSrNwzXqixeSZmrZHz/UDyYtX QymqSHbJaUDUia89aM9gIN7wj4/gpWeDYNzz0sXG11GDBC/RvkeB7C4Kb29c0FuB 9EyE0ZuGGnnce6d3881s3qaWwRvbw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrfedugddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 26 Jan 2022 06:21:33 -0500 (EST) From: Thomas Monjalon To: Ori Kam , Bruce Richardson Cc: Jerin Jacob , Alexander Kozyrev , dpdk-dev , Ivan Malov , Andrew Rybchenko , Ferruh Yigit , "mohammad.abdul.awal@intel.com" , Qi Zhang , Jerin Jacob , Ajit Khaparde , David Marchand , Olivier Matz , Stephen Hemminger Subject: Re: [PATCH v2 01/10] ethdev: introduce flow pre-configuration hints Date: Wed, 26 Jan 2022 12:21:31 +0100 Message-ID: <8883807.CDJkKcVGEf@thomas> In-Reply-To: References: <20211006044835.3936226-1-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 26/01/2022 11:52, Bruce Richardson: > The scenario is as follows. Suppose we have the initial state as below: > > struct x_dev_cfg { > int x; > }; > > int > x_dev_cfg(int dev_id, struct x_dev_cfg *cfg) > { > struct x_dev *dev = x_devs[id]; > // some setup/config may go here > return dev->configure(cfg, sizeof(cfg)); // sizeof(cfg) == 4 > } > > Now, supposing we need to add in a new field into the config structure, a > very common occurance. This will indeed break the ABI, so we need to use > ABI versioning, to ensure that apps passing in the old structure, only call > a function which expects the old structure. Therefore, we need a copy of > the old structure, and a function to work on it. This gives this result: > > struct x_dev_cfg { > int x; > bool flag; // new field; > }; > > struct x_dev_cfg_v22 { // needed for ABI-versioned function > int x; > }; > > /* this function will only be called by *newly-linked* code, which uses > * the new structure */ > int > x_dev_cfg(int dev_id, struct x_dev_cfg *cfg) > { > struct x_dev *dev = x_devs[id]; > // some setup/config may go here > return dev->configure(cfg, sizeof(cfg)); // sizeof(cfg) is now 8 > } > > /* this function is called by apps linked against old version */ > int > x_dev_cfg_v22(int dev_id, struct x_dev_cfg_v22 *cfg) > { > struct x_dev *dev = x_devs[id]; > // some setup/config may go here > return dev->configure((void *)cfg, sizeof(cfg)); // sizeof(cfg) is still 4 > } > > With the above library code, we have different functions using the > different structures, so ABI compatibility is preserved - apps passing in a > 4-byte struct call a function using the 4-byte struct, while newer apps can > use the 8-byte version. > > The final part of the puzzle is then how drivers react to this change. > Originally, all drivers only use "x" in the config structure because that > is all that there is. That will still continue to work fine in the above > case, as both 4-byte and 8-byte structs have the same x value at the same > offset. i.e. no driver updates for x_dev is needed. > > On the other hand, if there are drivers that do want/need the new field, > they can also get to use it, but they do need to check for its presence > before they do so, i.e they would work as below: > > if (size_param > struct(x_dev_cfg_v22)) { // or "== struct(x_dev_cfg)" > // use flags field > } > > Hope this is clear now. Yes, this is the kind of explanation we need in our guideline doc. Alternatives can be documented as well. If we can list pros/cons in the doc, it will be easier to choose the best approach and to explain the choice during code review.