From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 8A9CB5957 for ; Mon, 26 May 2014 14:22:46 +0200 (CEST) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WotxB-0001aX-RV; Mon, 26 May 2014 14:24:46 +0200 Message-ID: <53833224.50903@6wind.com> Date: Mon, 26 May 2014 14:23:00 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: "Gilmore, Walter E" , "dev@dpdk.org" References: <1399647038-15095-1-git-send-email-olivier.matz@6wind.com> <1399647038-15095-4-git-send-email-olivier.matz@6wind.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH RFC 03/11] mbuf: remove rte_ctrlmbuf X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 12:22:46 -0000 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