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 A8F13A00C5; Tue, 15 Feb 2022 16:12:35 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 33DFF4113E; Tue, 15 Feb 2022 16:12:35 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id C59E6410F7 for ; Tue, 15 Feb 2022 16:12:33 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 639F05C0333; Tue, 15 Feb 2022 10:12:33 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 15 Feb 2022 10:12:33 -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=L1E7IULeeF9mqk 810NqiPvVdX6mjVTYsz7OKjbQTxhg=; b=crIzuOkp3qWzcx3cGCwiR8fkSEKwGb tF4OIr+A8NDt4uHGNl8QywDvhTFopMSAFG44woO70JGFNUJTc4D9VpNs+Gbu7U3P RfBr8oaFtcznev8DhHvEowzOCZFPUnM8SDUMw5dA3r7JIOA3TuUiHdueCuzzq1F3 9jJ71fP2R/uycBke9uFuxtck6RMZDkfnRRed3tVLDzHrSO1foVPvPJUgJD6MTDFP wtym9GXq0eIED/rbCOp5R7tK3STWYtqOI90ypAXrz4SqJwQacurKbOWlWpx8E3V/ 16lA9Z7VS/9jxnelchPOQKS/brFnyes8Cfnx03BrnVmA1Tx0Xcn48BKQ== 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=fm2; bh=L1E7IULeeF9mqk810NqiPvVdX6mjVTYsz7OKjbQTx hg=; b=VSJhpCBKnfsudqhcLKAFVatOvJ0vGJvT2Hc1rTd2boqAnRhXkqBGhNFU4 kqnVKKAntH+QH/q94btjH0dnIfnFMSSwmiYJn1CWHApJ77Pa0sdoiFPbXMictQwJ n0fJXrBEZ2MB0kdw8fZqDvTAXo6K8UyGO+b+8Mgqw5U/nV/E6H67EsgwPUwfpb/P j39RsLY+/ase2JoG+3S4Umh3scN1tJVOszt58aza/gOjIXv3I+Ho+MrA6Kb9x5CV 7OyxQMV5WrYLASaTMyRWy75Hrsplx/18NXC5+Bta+LM/U0Ows0cQoGryxjvoT7Fa 0izn8J/8CtigaJLBeFNjt2+6fUndQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrjeeggdejvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 15 Feb 2022 10:12:31 -0500 (EST) From: Thomas Monjalon To: Ray Kinsella Cc: Ferruh Yigit , Kalesh A P , dev@dpdk.org, ajit.khaparde@broadcom.com, asafp@nvidia.com, David Marchand , Andrew Rybchenko Subject: Re: [dpdk-dev] [PATCH v7 1/4] ethdev: support device reset and recovery events Date: Tue, 15 Feb 2022 16:12:29 +0100 Message-ID: <5940456.YiXZdWvhHV@thomas> In-Reply-To: <87zgmsgrp8.fsf@mdr78.vserver.site> References: <20201009034832.10302-1-kalesh-anakkur.purayil@broadcom.com> <8735kli9s7.fsf@mdr78.vserver.site> <87zgmsgrp8.fsf@mdr78.vserver.site> 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 15/02/2022 14:55, Ray Kinsella: > Ray Kinsella writes: > > Thomas Monjalon writes: > >> 14/02/2022 17:06, Ray Kinsella: > >>> Thomas Monjalon writes: > >>> > 14/02/2022 11:16, Ray Kinsella: > >>> >> Ray Kinsella writes: > >>> >> > Thomas Monjalon writes: > >>> >> >> We never know how this enum will be used by the application. > >>> >> >> The max value may be used for the size of an event array. > >>> >> >> It looks a real ABI issue unfortunately. > >>> >> > > >>> >> > Right - but we only really care about it when an array size based on MAX > >>> >> > is likely to be passed to DPDK, which doesn't apply in this case. > >>> > > >>> > I don't completely agree. > >>> > A developer may assume an event will never exceed MAX value. > >>> > However, after an upgrade of DPDK without app rebuild, > >>> > a higher event value may be received in the app, > >>> > breaking the assumption. > >>> > Should we consider this case as an ABI breakage? > >>> > >>> Nope - I think we should explicitly exclude MAX values from any > >>> ABI guarantee, as being able to change them is key to our be able to > >>> evolve DPDK while maintaining ABI stability. > >> > >> Or we can simply remove the MAX values so there is no confusion. > >> > >>> Consider what it means applying the ABI policy to a MAX value, you are > >>> in effect saying that that no value can be added to this enumeration > >>> until the next ABI version, for me this is very restrictive without a > >>> solid reason. > >> > >> I agree it is too much restrictive, that's why I am advocating > >> for their removal. > > > > I think that would be simplest yes - may require some rework of the > > sample code though. I will take a look at it. > > Thinking about this some more - we can't remove the MAX values between > now the next stable ABI. So we may need a short term plan, and long term > plan. > > Long term, I agree we look at every _MAX enumeration value and ask do we > need it. > > Short term (until the next ABI), we still need to answer the question do > we allow people to change _MAX values? There's a problem of incentive. We already said in the past that we should remove the _MAX values, but it doesn't happen because our time on this planet is limited. I think it would work if the developers have a special interest in such work. And guess what? Here there is a special interest to remove this one. If we are at the negotiation table, we could imagine a short-term exception if the long-term patch is available and reviewed.