From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 9C66C569A for ; Thu, 9 Jul 2015 18:01:57 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 09 Jul 2015 09:01:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,441,1432623600"; d="scan'208";a="761340143" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.63]) by orsmga002.jf.intel.com with SMTP; 09 Jul 2015 09:01:51 -0700 Received: by (sSMTP sendmail emulation); Thu, 09 Jul 2015 17:01:50 +0025 Date: Thu, 9 Jul 2015 17:01:50 +0100 From: Bruce Richardson To: Thomas Monjalon Message-ID: <20150709160149.GF8408@bricha3-MOBL3> References: <1435585344-26652-1-git-send-email-john.mcnamara@intel.com> <1597388.Dhvyq33s8s@xps13> <20150708131034.GA5708@bricha3-MOBL3> <2534416.XSNtN7mPxB@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2534416.XSNtN7mPxB@xps13> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v3 7/7] abi: announce mbuf addition for ieee1588 in DPDK 2.2 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: Thu, 09 Jul 2015 16:01:58 -0000 On Thu, Jul 09, 2015 at 05:51:16PM +0200, Thomas Monjalon wrote: > 2015-07-08 14:10, Bruce Richardson: > > On Mon, Jul 06, 2015 at 03:16:01PM +0200, Thomas Monjalon wrote: > > > 2015-07-02 16:16, John McNamara: > > > > --- a/doc/guides/rel_notes/abi.rst > > > > +++ b/doc/guides/rel_notes/abi.rst > > > > Deprecation Notices > > > > ------------------- > > > > + > > > > +* In DPDK 2.1 the IEEE1588/802.1AS support in the i40e driver makes use of the > > > > + ``udata64`` field in the mbuf to pass the timesync register index to the > > > > + user. In DPDK 2.2 this will be moved to a new field in the mbuf. > > > > > > We need more acknowledgements for this decision, as stated here: > > > http://dpdk.org/browse/dpdk/tree/doc/guides/guidelines/versioning.rst#n51 > > > > Why can't this new field just be added at the end of cache line 1 (the second > > cache line) of the mbuf? That would avoid any ABI breakage and would mean we > > can just put the change in in this release, instead of waiting. > > Are you sure that (because of __rte_cache_aligned) the size of the structure > is never increased with this new field? > Please confirm your opinion. This is checked at compile time by the test app. 930 static int 931 test_mbuf(void) 932 { 933 RTE_BUILD_BUG_ON(sizeof(struct rte_mbuf) != RTE_CACHE_LINE_SIZE * 2); .... So if a change does result in an increase the mbuf size, by causing overflow in either the first or the second cache line, we will get compiler errors in the build because of it. Therefore, such changes are pretty easy to test by compiling up on our supported targets. /Bruce