From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 6A5638E7B for ; Tue, 3 Nov 2015 11:20:46 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 03 Nov 2015 02:20:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,238,1444719600"; d="scan'208";a="841392193" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.208.62]) by orsmga002.jf.intel.com with SMTP; 03 Nov 2015 02:20:43 -0800 Received: by (sSMTP sendmail emulation); Tue, 03 Nov 2015 10:20:42 +0025 Date: Tue, 3 Nov 2015 10:20:42 +0000 From: Bruce Richardson To: Matthew Hall Message-ID: <20151103102042.GC15320@bricha3-MOBL3> References: <2014794.RrzFoKiHXW@xps13> <20151103002117.GA3665@mhcomputing.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151103002117.GA3665@mhcomputing.net> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Reshuffling of rte_mbuf structure. 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: Tue, 03 Nov 2015 10:20:47 -0000 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