Re: [dpdk-dev] [PATCH v2 3/6] mbuf: remove rte_ctrlmbuf

["Richardson, Bruce" <bruce.richardson@intel.com>]

> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Monday, September 08, 2014 9:22 AM
> To: Richardson, Bruce; dev@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@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@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@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@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