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 E9CC368BB for ; Mon, 9 Jun 2014 17:50:55 +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 1Wu1sb-0003X0-4H; Mon, 09 Jun 2014 17:53:04 +0200 Message-ID: <5395D814.7020000@6wind.com> Date: Mon, 09 Jun 2014 17:51:48 +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: Cristian Dumitrescu References: <1401905319-8882-1-git-send-email-cristian.dumitrescu@intel.com> <1401905319-8882-23-git-send-email-cristian.dumitrescu@intel.com> <53957A4E.6090401@6wind.com> <3EB4FA525960D640B5BDFFD6A3D891261B1C2354@IRSMSX102.ger.corp.intel.com> <5395A4F6.7050609@6wind.com> <3EB4FA525960D640B5BDFFD6A3D891261B1C2415@IRSMSX102.ger.corp.intel.com> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891261B1C2415@IRSMSX102.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [v2 22/23] Packet Framework IPv4 pipeline sample app 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, 09 Jun 2014 15:50:56 -0000 Cristian, Please see some comments below. On 06/09/2014 03:25 PM, Dumitrescu, Cristian wrote: > 1. As the name implies, pktmbuf should be used for packets and ctrlmbuf > should be used for control messages . IMHO using pktmbuf to control > messages is a confusing workaround. If ctrlmbuf are removed, the name pktmbuf would change in mbuf. But anyway, to me it's not confusing at all to store data in a packet, even if it's a data from a core to another. > 2. Pktmbuf has a lot of overhead that is not needed in order to send > short messages between cores. Pktmbuf has a lot of pointers and other > fields that do not make sense for messages. I don't think we want people > to say DPDK is difficult to use because e.g. sending 2 bytes from core A > to core B requires initializing a bunch of pointers and other fields > that do not make sense. All the fields that should be initialized in a packet mbuf are reset in rte_pktmbuf_reset() so the user won't have anything to do. But using pktmbuf is not the only solution, you can use a private application structure without duplicating code (see below). > 3. Once we start using pktmbuf to send messages, it is likely that other > people will follow this example, and they might do it incorrectly. I > don't think we want to see emails on this list from people asking e.g: > > i) Why does my app segfaults, when all I want to do is send 2 bytes from > core A to core B? > > ii) Why does my app segfaults when core A writes a message to a NIC TX > queue? Why would the application segfaults? Indeed, if you misuse any function, it could segfault but is it a reason for not implementing the feature? > Using an app dependent structure requires duplicating the work to > create/free the pool of such structures, and alloc/free mechanism. And > then some people will ask why are we not using ctrlmbuf, as long as > ctrlmbuf exists in DPDK. In this case, I would say that rte_mempool functions are enough to allocate/free. If the ctrlmbuf structure is composed of a data array and a length field, you only need: rte_mempool_get(mp, &ctrlmbuf); memcpy(ctrlmbuf->buf, my_data, my_data_len); ctrlmbuf->len = my_data_len; > I think that, as long as we have ctrlmbuf and pktmbuf in DPDK, we should > follow the existing model. We should not look for workarounds that we > know we plan to change anyway, we should look for the right solution. We > both agree we need to refresh pktmbuf and ctrlmbuf, but my point is we > should not do changes as long as we don't know what the agreed solution > will look like? I agree, we should debate on what is the right solution, that's precisely what I'm doing. To decide if ctrlmbuf should be kept or changed, we should: - understand its use-case if any and see what ctrlmbuf features are required - understand why it should be included in rte_mbuf or not: in my opinion there is no reason to do it, and it this has a cost (ex: 1 byte lost in mbuf, mbuf fields badly organized) Regards, Olivier