Re: [PATCH RFC 03/11] mbuf: remove rte_ctrlmbuf

[Olivier MATZ <olivier.matz-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>]

Hi Walt,

> The purpose of this structure is to send commands, events or any other type
> of information between user application tasks (normally from a manager
> task).  It has been there since the beginning in the original design and
> it's up to the user to define what is in the data field and how they
> wish to use it.  It's one thing to fix a bug but to remove a structure
> like this because you don't see it use in the other parts is asking for
> trouble with customers.

To me, there is nothing that we cannot do without this structure:
depending on the use-case, it could be replaced with the same
functionalities by:

- a packet mbuf, in this case the user pointer would be stored in
   the packet data for instance. In the worst case, I would agree to
   add a flag telling that the mbuf carries control data.

- an application private structure which would contain the pointer,
   the data len (if any), plus any other field that could be useful
   for the application. This structure can be allocated in a mempool.

- nothing! I mean: if the application only wants to carry a pointer,
   why would it need an additional structure to point to it? The
   application can just give the pointer to its private data without
   allocating a control mbuf for that.

To be honnest, I don't see in which case it is useful to have this
additional structure. This modification is motivated by a gain of
bytes in the mbuf and a rationalization of the rte_mbuf structure.

I can add a documentation, for instance in the commit log, about how
the rte_ctrlmbuf could be replaced by something equivalent in different
situations. Are you fine with this?

If we find use cases where rte_ctrlmbuf is required, another idea would
be to keep this structure, but make it independant of rte_mbuf.

Regards,
Olivier