From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id B0B402C01 for ; Tue, 19 Jul 2016 17:28:29 +0200 (CEST) Received: from alille-653-1-293-182.w90-1.abo.wanadoo.fr ([90.1.53.182] helo=[192.168.1.13]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bPWz9-0004tr-5v; Tue, 19 Jul 2016 17:31:04 +0200 To: "Richardson, Bruce" References: <1468936875-1652-1-git-send-email-olivier.matz@6wind.com> <20160719144018.GA10912@bricha3-MOBL3> <59AF69C657FD0841A61C55336867B5B035AA7BC6@IRSMSX103.ger.corp.intel.com> Cc: "dev@dpdk.org" , "jerin.jacob@caviumnetworks.com" , "thomas.monjalon@6wind.com" From: Olivier Matz Message-ID: Date: Tue, 19 Jul 2016 17:28:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <59AF69C657FD0841A61C55336867B5B035AA7BC6@IRSMSX103.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for mbuf structure 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: Tue, 19 Jul 2016 15:28:29 -0000 On 07/19/2016 05:07 PM, Richardson, Bruce wrote: > > >> -----Original Message----- >> From: Olivier Matz [mailto:olivier.matz@6wind.com] >> Sent: Tuesday, July 19, 2016 4:04 PM >> To: Richardson, Bruce >> Cc: dev@dpdk.org; jerin.jacob@caviumnetworks.com; >> thomas.monjalon@6wind.com >> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI change for mbuf >> structure >> >> Hi Bruce, >> >> On 07/19/2016 04:40 PM, Bruce Richardson wrote: >>> On Tue, Jul 19, 2016 at 04:01:15PM +0200, Olivier Matz wrote: >>>> For 16.11, the mbuf structure will be modified implying ABI breakage. >>>> Some discussions already took place here: >>>> http://www.dpdk.org/dev/patchwork/patch/12878/ >>>> >>>> Signed-off-by: Olivier Matz >>>> --- >>>> doc/guides/rel_notes/deprecation.rst | 6 ++++++ >>>> 1 file changed, 6 insertions(+) >>>> >>>> diff --git a/doc/guides/rel_notes/deprecation.rst >>>> b/doc/guides/rel_notes/deprecation.rst >>>> index f502f86..2245bc2 100644 >>>> --- a/doc/guides/rel_notes/deprecation.rst >>>> +++ b/doc/guides/rel_notes/deprecation.rst >>>> @@ -41,3 +41,9 @@ Deprecation Notices >>>> * The mempool functions for single/multi producer/consumer are >> deprecated and >>>> will be removed in 16.11. >>>> It is replaced by rte_mempool_generic_get/put functions. >>>> + >>>> +* ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: >>>> +some >>>> + fields will be reordered to facilitate the writing of >>>> +``data_off``, >>>> + ``refcnt``, and ``nb_segs`` in one operation. Indeed, some >>>> +platforms >>>> + have an overhead if the store address is not naturally aligned. >>>> +The >>>> + useless ``port`` field will also be removed at the same occasion. >>>> -- >>> >>> Have we fully bottomed out on the mbuf changes. I'm not sure that once >>> patches start getting considered for merge, new opinions may come >>> forward. For instance, is the "port" field really "useless"? >>> >>> Would it not be better to put in a less specific deprecation notice? >>> What happens if this notice goes in and the final changes are >>> different from those called out here? >> >> Yes, you are right. What about the following text? >> >> ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: some >> fields may be reordered to facilitate the writing of ``data_off``, >> ``refcnt``, and ``nb_segs`` in one operation. Indeed, some platforms have >> an overhead if the store address is not naturally aligned. The ``port`` >> field may also be removed at the same occasion. >> > Better. Two suggestions: > 1. change "Indeed" to "because" and join the sentences. > 2. change the last sentence to be even more general: "Other mbuf fields, such as the port field, may be moved or removed as part of this mbuf work". It's much better indeed ;) Thanks Bruce, I'll submit a v2.