> -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz at 6wind.com] > Sent: Monday, September 08, 2014 9:22 AM > To: Richardson, Bruce; dev at dpdk.org > Subject: Re: [PATCH v2 3/6] mbuf: remove rte_ctrlmbuf > > Hi Bruce, > > On 08/28/2014 05:42 PM, Bruce Richardson wrote: > > From: Olivier Matz <olivier.matz at 6wind.com> > > > > The initial role of rte_ctrlmbuf is to carry generic messages (data > > pointer + data length) but it's not used by the DPDK or it applications. > > Keeping it implies: > > - loosing 1 byte in the rte_mbuf structure > > - having some dead code rte_mbuf.[ch] > > > > This patch removes this feature. Thanks to it, it is now possible to > > simplify the rte_mbuf structure by merging the rte_pktmbuf structure > > in it. This is done in next commit. > > > > Signed-off-by: Olivier Matz <olivier.matz at 6wind.com> > > > > * Updated patch to HEAD. > > * Modified patch to retain the old function names for ctrl mbufs as > > macros. This helps with app compatibility, and allows the concept > > of a control mbuf to be reintroduced via a single-bit flag in > > a future change. > > * Updated the packet framework ip_pipeline example application to > > work following this change. > > > > Changes in v2: > > * Fixed whitespace errors introduced by this patch flagged by checkpatch > > > > Signed-off-by: Bruce Richardson <bruce.richardson at intel.com> > > To be honest, I'm not convinced that keeping the old function names > is really required, but I suppose you had good reasons to reintroduce > them. Just for information, is it for compatibility purpose or is there > a real wish to reintroduce a sort of control mbuf in the future ? > > Acked-by: Olivier Matz <olivier.matz at 6wind.com>
Compatibility primarily. However, it's a useful enough concept, and can be controlled by having a single-bit flag as done in my second patch set. /Bruce