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 CB39BA0524; Fri, 8 Jan 2021 11:43:32 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 58BD3140F52; Fri, 8 Jan 2021 11:43:32 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 80C5E140F40 for ; Fri, 8 Jan 2021 11:43:30 +0100 (CET) IronPort-SDR: zJkdOucG7sWDvHzgcCwvQvVecemHa2SIhuT9Saa6Fww0wRa33N+ht7wQyzKN+zSMIbizl2j2cs gjjb3i0CniNQ== X-IronPort-AV: E=McAfee;i="6000,8403,9857"; a="165265182" X-IronPort-AV: E=Sophos;i="5.79,330,1602572400"; d="scan'208";a="165265182" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2021 02:43:29 -0800 IronPort-SDR: J5fwvxBjuGJvoOvhBCAvnQYaZaKY8MBUgxv+MBs3l5CU3AF2nWQgLvP+E9wIv+p+JOrzoE2Ole OLrSyQMhRKug== X-IronPort-AV: E=Sophos;i="5.79,330,1602572400"; d="scan'208";a="398949831" 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 02:43:26 -0800 To: 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 , ray.kinsella@intel.com References: <20201216085854.7842-1-jia.guo@intel.com> <27289607.Vi9ZVq1Shk@thomas> <2191627.gY80Bp0Rq6@thomas> From: Ferruh Yigit Message-ID: <76ec1db3-b739-330b-97d9-d99fc9110328@intel.com> Date: Fri, 8 Jan 2021 10:43:23 +0000 MIME-Version: 1.0 In-Reply-To: <2191627.gY80Bp0Rq6@thomas> 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 10:23 AM, Thomas Monjalon wrote: > 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. > Yes it is exposed to the application. But in runtime does it exchanged between library and application is the issue I think. For this case it seems it is not, so not an ABI break.