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 C2DBDA00C5; Tue, 15 Feb 2022 17:12:14 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6C6384113E; Tue, 15 Feb 2022 17:12:14 +0100 (CET) Received: from mail-108-mta230.mxroute.com (mail-108-mta230.mxroute.com [136.175.108.230]) by mails.dpdk.org (Postfix) with ESMTP id 9800F410F7 for ; Tue, 15 Feb 2022 17:12:13 +0100 (CET) Received: from filter006.mxroute.com ([140.82.40.27] 140.82.40.27.vultr.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta230.mxroute.com (ZoneMTA) with ESMTPSA id 17efe27da4e0005a20.003 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Tue, 15 Feb 2022 16:12:11 +0000 X-Zone-Loop: 46a41f400815467d61aa6f082010b0e9a802ba0ff63b X-Originating-IP: [140.82.40.27] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ashroe.eu; s=x; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:Cc:To: From:References:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jHHPA5dsJQKygr2riQN5jq8iJ6gIIDHmoijK/HOnn5s=; b=BUMhhj2fKdfec7S1g0agxlSAKj HRY/K47eBD+fbm7NqOcPsHfwJAiKBO3HAfVKS7fWC4jXAvXeHAcN2OqpaPwfx58DHvPkBl4lxrKYc /8WeltbAilZsJRD4HP8Ekbm3LNE9PYRkLEVYYonfhzccMw8WwkTrF4zmpcNCAkMJPScJ4B34cA95z K7gj/lFWEuKu3GlIrUIBdxD4WjxzbjwiwyV2Qtviavpygyf6OaJaPLdpb4Ue3NqJawXbeuGxb4P3s cPDyg8aQPXrKXoQ+XkiuoEhhsFYlnFHhEGmM+EC0zUdFcXQ2D20Q3MQLpIoWfKa4704UA7pQHLvBP wXGZaMpg==; References: <20201009034832.10302-1-kalesh-anakkur.purayil@broadcom.com> <8735kli9s7.fsf@mdr78.vserver.site> <87zgmsgrp8.fsf@mdr78.vserver.site> <5940456.YiXZdWvhHV@thomas> User-agent: mu4e 1.4.15; emacs 27.1 From: Ray Kinsella To: Thomas Monjalon 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 In-reply-to: <5940456.YiXZdWvhHV@thomas> Date: Tue, 15 Feb 2022 11:12:08 -0500 Message-ID: <87wnhwgld3.fsf@mdr78.vserver.site> MIME-Version: 1.0 Content-Type: text/plain X-AuthUser: mdr@ashroe.eu 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 Thomas Monjalon writes: > 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. :-) ... I like that plan. -- Regards, Ray K