[dpdk-dev] [PATCH RFC 03/11] mbuf: remove rte_ctrlmbuf
Olivier MATZ
olivier.matz at 6wind.com
Mon May 26 14:23:00 CEST 2014
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
More information about the dev
mailing list