From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH RFC 03/11] mbuf: remove rte_ctrlmbuf Date: Mon, 26 May 2014 14:23:00 +0200 Message-ID: <53833224.50903@6wind.com> References: <1399647038-15095-1-git-send-email-olivier.matz@6wind.com> <1399647038-15095-4-git-send-email-olivier.matz@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: "Gilmore, Walter E" , "dev-VfR2kkLFssw@public.gmane.org" Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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