From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 403FFADA7 for ; Fri, 12 Jun 2015 05:22:53 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 11 Jun 2015 20:22:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,599,1427785200"; d="scan'208";a="741898624" Received: from pgsmsx102.gar.corp.intel.com ([10.221.44.80]) by fmsmga002.fm.intel.com with ESMTP; 11 Jun 2015 20:22:51 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by PGSMSX102.gar.corp.intel.com (10.221.44.80) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 12 Jun 2015 11:22:49 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.129]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.168]) with mapi id 14.03.0224.002; Fri, 12 Jun 2015 11:22:48 +0800 From: "Zhang, Helin" To: "Ananyev, Konstantin" , Olivier MATZ , "O'Driscoll, Tim" , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v6 01/18] mbuf: redefine packet_type in rte_mbuf Thread-Index: AQHQpL8NxVg2woMc/kWebGXNcsVPBQ== Date: Fri, 12 Jun 2015 03:22:47 +0000 Message-ID: References: <1432284264-17376-1-git-send-email-helin.zhang@intel.com> <1433144045-30847-1-git-send-email-helin.zhang@intel.com> <1433144045-30847-2-git-send-email-helin.zhang@intel.com> <556C1478.9040005@6wind.com> <26FA93C7ED1EAA44AB77D62FBE1D27BA54D536B3@IRSMSX102.ger.corp.intel.com> <55784A82.6020801@6wind.com> <2601191342CEEE43887BDE71AB97725836A078D6@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725836A078D6@irsmsx105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v6 01/18] mbuf: redefine packet_type in rte_mbuf X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 03:22:54 -0000 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Wednesday, June 10, 2015 11:40 PM > To: Olivier MATZ; O'Driscoll, Tim; Zhang, Helin; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v6 01/18] mbuf: redefine packet_type in > rte_mbuf >=20 > Hi Olivier, >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier MATZ > > Sent: Wednesday, June 10, 2015 3:33 PM > > To: O'Driscoll, Tim; Zhang, Helin; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v6 01/18] mbuf: redefine packet_type in > > rte_mbuf > > > > Hi Tim, Helin, > > > > On 06/02/2015 03:27 PM, O'Driscoll, Tim wrote: > > > > > >> -----Original Message----- > > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier MATZ > > >> Sent: Monday, June 1, 2015 9:15 AM > > >> To: Zhang, Helin; dev@dpdk.org > > >> Subject: Re: [dpdk-dev] [PATCH v6 01/18] mbuf: redefine packet_type > > >> in rte_mbuf > > >> > > >> Hi Helin, > > >> > > >> +CC Neil > > >> > > >> On 06/01/2015 09:33 AM, Helin Zhang wrote: > > >>> In order to unify the packet type, the field of 'packet_type' in > > >>> 'struct rte_mbuf' needs to be extended from 16 to 32 bits. > > >>> Accordingly, some fields in 'struct rte_mbuf' are re-organized to > > >>> support this change for Vector PMD. As 'struct rte_kni_mbuf' for > > >>> KNI should be right mapped to 'struct rte_mbuf', it should be > > >>> modified accordingly. In addition, Vector PMD of ixgbe is disabled > > >>> by default, as 'struct rte_mbuf' changed. > > >>> To avoid breaking ABI compatibility, all the changes would be > > >>> enabled by RTE_UNIFIED_PKT_TYPE, which is disabled by default. > > >> > > >> What are the plans for this compile-time option in the future? > > >> > > >> I wonder what are the benefits of having this option in terms of > > >> ABI compatibility: when it is disabled, it is ABI-compatible but > > >> the packet-type feature is not present, and when it is enabled we > > >> have the feature but it breaks the compatibility. > > >> > > >> In my opinion, the v5 is preferable: for this kind of features, I > > >> don't see how the ABI can be preserved, and I think packet-type > > >> won't be the only feature that will modify the mbuf structure. I > > >> think the process described here should be applied: > > >> http://dpdk.org/browse/dpdk/tree/doc/guides/rel_notes/abi.rst > > >> > > >> (starting from "Some ABI changes may be too significant to > > >> reasonably maintain multiple versions of"). > > >> > > >> > > >> Regards, > > >> Olivier > > >> > > > > > > This is just like the change that Steve (Cunming) Liang submitted > > > for Interrupt Mode. We have the same problem in both cases: we > > want to find a way to get the features included, but need to comply > > with our ABI policy. So, in both cases, the proposal is to add a > > config option to enable the change by default, so we maintain backward > compatibility. Users that want these changes, and are willing to accept t= he > associated ABI change, have to specifically enable them. > > > > > > We can note in the Deprecation Notices in the Release Notes for 2.1 > > > that these config options will be removed in 2.2. The features > > will then be enabled by default. > > > > > > This seems like a good compromise which allows us to get these change= s into > 2.1 but avoids breaking the ABI policy. > > > > Sorry for the late answer. > > > > After some thoughts on this topic, I understand that having a > > compile-time option is perhaps a good compromise between keeping > > compatibility and having new features earlier. > > > > I'm just afraid about having one #ifdef in the code for each new > > feature that cannot keep the ABI compatibility. > > What do you think about having one option -- let's call it > > "CONFIG_RTE_NEXT_ABI" --, that is disabled by default, and that would > > surround any new feature that breaks the ABI? >=20 > I am not Tim/Helin, but really like that idea :) Konstantin It seems more guys like Oliver's idea of introducing CONFIG_RTE_NEXT_ABI. A= ny objections? If none, I will rework my patches with that. - Helin >=20 >=20 > > > > This would have several advantages: > > - only 2 cases (on or off), the combinatorial is smaller than > > having one option per feature > > - all next features breaking the abi can be identified by a grep > > - the code inside the #ifdef can be enabled in a simple operation > > by Thomas after each release. > > > > Thomas, any comment? > > > > Regards, > > Olivier > >