From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <xms:csaeXsyoHTvcu2pNl4NfeYwy2a5M88ebfWBfni3R6WscZ0MGrIaWNg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeehgddvgecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs
 ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph
 epjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr
 rghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth
X-ME-Proxy: <xmx:csaeXlo6Q92s6bR6K3iH2fiw3-98VeBbvJx6PQbz8bPbCqSVPON9Bw>
 <xmx:csaeXuiaMY7FlHH95LO-6dDkImIlqQaUqVhlgtxMLHNC5tgD6kqPzg>
 <xmx:csaeXqj3Pb2MGJZ9gfapLTeDADGEcBivZbj__OsliOXAZGrKW3eWrg>
 <xmx:csaeXtlPEgPnR5IABs7ajlmlcbQvB9EGX6sxI7HmfbSJA1E7mt_KZA>
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 <thomas@monjalon.net>
To: Bill Zhou <dongz@mellanox.com>, Ferruh Yigit <ferruh.yigit@intel.com>
Cc: Ori Kam <orika@mellanox.com>, Matan Azrad <matan@mellanox.com>,
 "wenzhuo.lu@intel.com" <wenzhuo.lu@intel.com>,
 "jingjing.wu@intel.com" <jingjing.wu@intel.com>,
 "bernard.iremonger@intel.com" <bernard.iremonger@intel.com>,
 "john.mcnamara@intel.com" <john.mcnamara@intel.com>,
 "marko.kovacevic@intel.com" <marko.kovacevic@intel.com>,
 "arybchenko@solarflare.com" <arybchenko@solarflare.com>, dev@dpdk.org
Date: Tue, 21 Apr 2020 12:09:49 +0200
Message-ID: <21747191.6Emhk5qWAg@thomas>
In-Reply-To: <d51006c6-20d6-c172-36fb-6254cb6a6044@intel.com>
References: <20200410094631.31330-1-dongz@mellanox.com>
 <3422085.0RtB02Ng89@thomas> <d51006c6-20d6-c172-36fb-6254cb6a6044@intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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 <ferruh.yigit@intel.com>
> >>>>> 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.