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
