From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id DAFD9A0524; Fri, 8 Jan 2021 15:27:35 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5A245140F00; Fri, 8 Jan 2021 15:27:35 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 081F4140EB3 for ; Fri, 8 Jan 2021 15:27:32 +0100 (CET) IronPort-SDR: HTnueUEn4cCVqFSLqCjXbq97qVqOXN6vq9B8JTsPYxbPUT9Bz/wECBrc+9w4+uJsXpreF2D6Ua gJtDx7xzjmDg== X-IronPort-AV: E=McAfee;i="6000,8403,9857"; a="174092745" X-IronPort-AV: E=Sophos;i="5.79,331,1602572400"; d="scan'208";a="174092745" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2021 06:27:30 -0800 IronPort-SDR: qN6qlZPY0OM6fmyDPLt9Lb5bzlClfwOS50IHAGFHYpbWKCNXzSftm2orxYHRAtFgjaOzQJ2jR4 EBUleaJsn0vw== X-IronPort-AV: E=Sophos;i="5.79,331,1602572400"; d="scan'208";a="398998689" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.237.192]) ([10.213.237.192]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2021 06:27:27 -0800 To: "Kinsella, Ray" , Thomas Monjalon , "Guo, Jia" , "Zhang, Qi Z" Cc: "Wu, Jingjing" , "Yang, Qiming" , "Wang, Haiyue" , "dev@dpdk.org" , "andrew.rybchenko@oktetlabs.ru" , "orika@nvidia.com" , "getelson@nvidia.com" , Dodji Seketeli References: <20201216085854.7842-1-jia.guo@intel.com> <27289607.Vi9ZVq1Shk@thomas> <2191627.gY80Bp0Rq6@thomas> From: Ferruh Yigit Message-ID: <5c90d107-8569-1c32-fa16-35068b983365@intel.com> Date: Fri, 8 Jan 2021 14:27:23 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type for ecpri 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 Sender: "dev" On 1/8/2021 12:38 PM, Kinsella, Ray wrote: > > >> -----Original Message----- >> From: Thomas Monjalon >> Sent: Friday 8 January 2021 10:24 >> To: Guo, Jia ; Zhang, Qi Z ; >> Yigit, Ferruh >> Cc: Wu, Jingjing ; Yang, Qiming >> ; Wang, Haiyue ; >> dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com; >> getelson@nvidia.com; Dodji Seketeli ; Kinsella, Ray >> >> Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type >> for ecpri >> >> 08/01/2021 10:22, Ferruh Yigit: >>> On 1/7/2021 1:33 PM, Thomas Monjalon wrote: >>>> 07/01/2021 13:47, Zhang, Qi Z: >>>>> From: Thomas Monjalon >>>>>> 07/01/2021 10:32, Guo, Jia: >>>>>>> From: Thomas Monjalon >>>>>>>> Sorry, it is a nack. >>>>>>>> BTW, it is probably breaking the ABI because of >> RTE_TUNNEL_TYPE_MAX. >>>>> >>>>> Yes that may break the ABI but fortunately the checking-abi- >> compatibility tool shows negative :) , thanks Ferruh' s guide. >>>>> https://github.com/ferruhy/dpdk/actions/runs/468859673 >>>> >>>> That's very strange. An enum value is changed. >>>> Why it is not flagged by libabigail? >>> >>> As long as the enum values not sent to the application and kept >> within >>> the library, changing their values shouldn't be problem. >> >> But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h so it >> is exposed to the application. >> I think it is a case of ABI breakage. >> > > Really a lot depends on context, Thomas is right it is hard to predict how these _MAX values are used. > > We have seen cases in the past where _MAX enumeration values have been used to size arrays the like - I don't immediately see that issue here. My understanding is that the only consumer of this enumeration is rte_eth_dev_udp_tunnel_port_add and rte_eth_dev_udp_tunnel_port_delete, right? On face value, impact looks negligible. > > I will take a look at why libabigail doesn't complain. > Application can use the enum, including MAX as they desire, we can't really assume anything there. In previous case, library was providing an enum value back to application. And the problem was application can use those values blindly and new unexpected values may cause trouble. For this case, even the application create a table with RTE_TUNNEL_TYPE_MAX size, library is not sending any type of this enum to application to cause any problem, at least abigail seems not able to finding any instance of it.