From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zoltan Kiss Subject: Re: Reshuffling of rte_mbuf structure. Date: Tue, 3 Nov 2015 11:44:22 +0000 Message-ID: <56389E16.4010407@linaro.org> References: <2014794.RrzFoKiHXW@xps13> <20151103002117.GA3665@mhcomputing.net> <20151103102042.GC15320@bricha3-MOBL3> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org To: Bruce Richardson , Matthew Hall Return-path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by dpdk.org (Postfix) with ESMTP id 6E1188E92 for ; Tue, 3 Nov 2015 12:44:14 +0100 (CET) Received: by wicll6 with SMTP id ll6so9628440wic.1 for ; Tue, 03 Nov 2015 03:44:14 -0800 (PST) In-Reply-To: <20151103102042.GC15320@bricha3-MOBL3> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Also, there could be places in the code where we change a set of continuous fields in the mbuf. E.g. ixgbe vector pmd receive function takes advantage of 128 bit vector registers and fill out rx_descriptor_fields1 with one instruction. But I guess there are other places too, and they are really hard to find with code analysis. A change in the mbuf structure would probably bring a plethora of nasty bugs due to this. On 03/11/15 10:20, Bruce Richardson wrote: > On Mon, Nov 02, 2015 at 07:21:17PM -0500, Matthew Hall wrote: >> On Mon, Nov 02, 2015 at 11:51:23PM +0100, Thomas Monjalon wrote: >>> But it is simpler to say that having an API depending of some options >>> is a "no-design" which could seriously slow down the DPDK adoption. >> >> What about something similar to how Java JNI works? It needed to support >> multiple Java JRE / JDK brands, implementations etc. Upon initialization, a >> function pointer array is created, and specific slots are filled with pointers >> to the real implementation of some native API functions you can call from >> inside your library to perform operations. >> >> In the DPDK case, we need flexible data instead of flexible function >> implementations. >> >> To do this there would be some pointer slots in the mbuf that are are filled >> with pointers to metadata for required DPDK features. The data could be placed >> in the following cachelines, using some reserved tailroom between the mbuf >> control block and the packet data block. Then the prefetch could be set up to >> prefetch only the used parts of the tailroom at any given point, to prevent >> unwanted slowdowns. >> >> Matthew. > > The trouble is that a lot of the metadata comes from the receive descriptor on > the RX code path, which is extremely sensitive to cache line usage. This is why > in the 1.8 changes to the mbuf, the data used by the RX code paths were all put > on the first cacheline. > > /Bruce >