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 99BC2A0598; Tue, 21 Apr 2020 12:09:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 02E5F1C08C; Tue, 21 Apr 2020 12:09:58 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id C7F9E1C07E for ; Tue, 21 Apr 2020 12:09:56 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 07AB558032C; Tue, 21 Apr 2020 06:09:55 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 21 Apr 2020 06:09:55 -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= 2+ABoSTKHWtAILVbQpFEfyjoUnrJySkfrvhnvCP2pS0=; b=WyJuGIvJlaFy5m0O 8lzhCBsJztd4+IUwOrrub1Z/XP95/xny+F5qk9gZpLFJV8bZbISeq2M1o2uSRgcQ l+JkuO3pisel1kZYNWVNehdfKiP32KvE2DdzL90A14Rsq5pkYWCmxNCaLAPrxBtP MTCNHvRZ3WUOFdWl0KB2/bKZNhHZF0vebXTmtF91csBenHrf8nQKXeYK29AsGJ8O nIClGSs0uT8wYkBG7/BNwUtmIDw9CH4I+naeauwGnguqSOvbYAedHZrTrWUonUG0 qtQOvA+GnwsqjvRPWje1hTeih6J9si9YQ6O9zkaGbxyBRKsdKFxJZT/sCgRlAXbl Yvf1Ow== 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=2+ABoSTKHWtAILVbQpFEfyjoUnrJySkfrvhnvCP2p S0=; b=SwL8mybVFNi+AZr7Vh8CNUWc0a/K9ff4G6UPmZiChnjs75kc8oEZcffS/ IappRyZ4bjC98sGgWFb/aqwnbe93BDSe0glZyq7V8z/xKCueuhv8nR8x0weNAiQQ dbK2GSfpXNX5QGK1MqlAV3xQ2IYBuY7Jcj2jjdDnMxC+2tchd2PNa1cbD//JVEHU 2cvIveTZxTMd551YjGk45xJ3frcczBamTuU/ZDwwnqVlpIaC04GMPIXgZFqVZ0Uo hGyBi6d7Ufil6K0GJeUWeXeatmDt6j40XryOOWhTEU133DmddWqfYlvF/0zDlmdy 4+XAh5zPG2H0P7E8FinKEM93S1ung== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeehgddvgecutefuodetggdotefrodftvf 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 F0C50328005E; Tue, 21 Apr 2020 06:09:52 -0400 (EDT) From: Thomas Monjalon To: Bill Zhou , Ferruh Yigit Cc: Ori Kam , Matan Azrad , "wenzhuo.lu@intel.com" , "jingjing.wu@intel.com" , "bernard.iremonger@intel.com" , "john.mcnamara@intel.com" , "marko.kovacevic@intel.com" , "arybchenko@solarflare.com" , dev@dpdk.org Date: Tue, 21 Apr 2020 12:09:49 +0200 Message-ID: <21747191.6Emhk5qWAg@thomas> In-Reply-To: References: <20200410094631.31330-1-dongz@mellanox.com> <3422085.0RtB02Ng89@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] ethdev: support flow aging 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" 21/04/2020 12:04, Ferruh Yigit: > On 4/20/2020 5:10 PM, Thomas Monjalon wrote: > > 20/04/2020 16:06, Ferruh Yigit: > >> On 4/18/2020 10:44 AM, Thomas Monjalon wrote: > >>> 18/04/2020 07:04, Bill Zhou: > >>>> From: Ferruh Yigit > >>>>> On 4/14/2020 9:32 AM, Dong Zhou wrote: > >>>>>> --- a/lib/librte_ethdev/rte_ethdev.h > >>>>>> +++ b/lib/librte_ethdev/rte_ethdev.h > >>>>>> @@ -3015,6 +3015,7 @@ enum rte_eth_event_type { > >>>>>> RTE_ETH_EVENT_NEW, /**< port is probed */ > >>>>>> RTE_ETH_EVENT_DESTROY, /**< port is released */ > >>>>>> RTE_ETH_EVENT_IPSEC, /**< IPsec offload related event */ > >>>>>> + RTE_ETH_EVENT_FLOW_AGED,/**< New aged-out flows is detected > >>>>> */ > >>>>>> RTE_ETH_EVENT_MAX /**< max value of this enum */ > >>>>>> }; > >>>>> > >>>>> > >>>>> Just recognized that this is failing in ABI check [1], as far as last time for a > >>>>> similar enum warning a QAT patch has been dropped, should this need to > >>>>> wait for > >>>>> 20.11 too? > >>>> > >>>> This patch is commonly used for flow aging, there are 2 other patches have > >>>> implement flow aging in mlx5 driver reply to this patch. > > [...] > >>> These MAX values in enums are a pain. > >>> We can try to think what can be done, waiting 20.11. > >>> Not sure there is a solution, except hijacking an existing value > >>> not used in the PMD, waiting the definitive value in 20.11... > >> > >> Dropping from the tree as of now, to not cause more merge conflicts, we can add > >> it later when issue is resolved. > > > > Thanks for dropping, that's the right thing to do > > when a patch is breaking ABI check. > > > > After some thoughts, I think it is acceptable to make a v3 > > which ignore this specific enum change. I explain my thought below: > > > > An enum can accept a new value at 2 conditions: > > - added as last value (not changing old values) > > - new value not used by existing API > > > > The value RTE_ETH_EVENT_FLOW_AGED meet the above 2 conditions: > > - only RTE_ETH_EVENT_MAX is changed, which is consistent > > - new value sent to the app only if the app registered for it > > > > Same here, as far as I can see it is safe to get this change. > > If any DPDK API returns this enum, either as return of the API or as output > parameter, this still can be problem, because application may use that returned > value, this was the concern in the QAT sample. > > But here application registers an event and DPDK library process callback for > it, so application callbacks won't be called for anything that application > doesn't already know about, in that respect this should be safe for old > applications. > > Not sure if we can generalize above two conditions for all enum changes, but we > can investigate them case by case as we get the warnings. > > > So, except if I miss something, I suggest we add this exception: > > Allow new value in rte_eth_event_type if added just before RTE_ETH_EVENT_MAX. > > In other words, allow changing the value of RTE_ETH_EVENT_MAX. > > The file to add such exception is devtools/libabigail.abignore. > > > > OK to exception. v3 was sent. I hope we'll get a v4 with justification for the exception.