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 <olivier.matz at 6wind.com> >> --- >> 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. Thanks, Olivier