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 C5936A055A; Tue, 25 Feb 2020 12:03:31 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3D69E1BC24; Tue, 25 Feb 2020 12:03:31 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 198153B5 for ; Tue, 25 Feb 2020 12:03:30 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 3EE6F6E58; Tue, 25 Feb 2020 06:03:28 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 25 Feb 2020 06:03:29 -0500 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=mesmtp; bh=IhwybmjoPPiv3D9EvjlBgM5ypkvSIM7Zgf2jolAQXzM=; b=pfHLCy7ld4bN 3THqDP6UmV3sZKAoxzrAr44jgWAT/SF6JkekfUePhRnboWLMVZB+WBBMSoYyJZGJ acq9gUSkoyEf9ir5LDsx5RBW+iqQ/kegz64QVusWJvtTqVA7D9G8NhSxU/FwZZ5M n0D7FSe9WDA+wE0YjD5Q5NQ7Kwk6RB8= 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=IhwybmjoPPiv3D9EvjlBgM5ypkvSIM7Zgf2jolAQX zM=; b=dPNAYr7RrvNbXDkAxps8kzMt8REmeuYZP8I9+gbgF5Z49h+06PIayeroE BbAhLV0lncW2ytqrRZkaE6a9zyLpk+zg92wUwf/xwelVY5s+fxg7HuiuhLhA6g8f Ni4GmzGDsJSM+pk2ycUBN8nlTFhjQRCZfftXwrykdx2Cd8+dtPYoXe8byf3o1xhH Le4dYL+MDtYSe487EbPfmlGXOKdZrObjZMkmAhpBAuVXVP1iSFkW4FfsC0d7BfS0 RwZmHqnVIRmB+wKkZguogH+0Nf1Lyu82sBdGUEqxY2vjO0XcDW8h9GsRsJg+/6k3 Ov7PQDTEWbJ+7vcXVcK6INQdDuALg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrledvgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 D668B3060F09; Tue, 25 Feb 2020 06:03:26 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit Cc: Neil Horman , John McNamara , Marko Kovacevic , dev@dpdk.org, Bruce Richardson , Konstantin Ananyev , David Marchand , Andrew Rybchenko , Ori Kam , Akhil Goyal Date: Tue, 25 Feb 2020 12:03:25 +0100 Message-ID: <8793457.2WqB4rESCP@xps> In-Reply-To: References: <20200130142003.2645765-1-ferruh.yigit@intel.com> <0fef6f04-1712-b502-245c-17986c604039@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] doc: deprecate using MAX values as array size 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" > > > Adding the deprecation notice as reminder for next ABI breakage release > > > (20.11). > > > This one time breakage is required to be able to extend enum/define > > > without breaking ABI. > > > > > > Signed-off-by: Ferruh Yigit > > > --- > > > +* lib: will fix extending some enum/define breaking the ABI. There are > > multiple > > > + samples in DPDK that enum/define terminated with a ``.*MAX.*`` value > > which is > > > + used by iterators, and arrays holding these values are sized with this > > > + ``.*MAX.*`` value. So extending this enum/define increases the ``.*MAX.*`` > > > + value which increases the size of the array and depending on how/where the > > > + array is used this may break the ABI. > > > + ``RTE_ETH_FLOW_MAX`` is one sample of the mentioned case, adding a > > new flow > > > + type will break the ABI because of ``flex_mask[RTE_ETH_FLOW_MAX]`` > > array > > > + usage in following public struct hierarchy: > > > + ``rte_eth_fdir_flex_conf -> rte_fdir_conf -> rte_eth_conf (in the middle)``. > > > + Need to identify this kind of usages and fix in 20.11, otherwise this blocks > > > + us extending existing enum/define. > > > + One solution can be using a fixed size array instead of ``.*MAX.*`` value. > > > We admit that the issue is there and we can discuss the possible solutions for this issue. > > For the deprecation notice. > Acked-by: Akhil Goyal I think we'll need a new coding style guideline to avoid shuch issue in future. Anyway, about fixing the issue in 20.11, Acked-by: Thomas Monjalon