From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: rte_mbuf.next in 2nd cacheline Date: Mon, 15 Jun 2015 15:20:22 +0200 Message-ID: <557ED116.7040508@6wind.com> References: <87110795-201A-4A1E-A4CC-A778AA7C8218@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: "Damjan Marion (damarion)" , "dev@dpdk.org" Return-path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 5464D5A53 for ; Mon, 15 Jun 2015 15:19:30 +0200 (CEST) In-Reply-To: <87110795-201A-4A1E-A4CC-A778AA7C8218@cisco.com> 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" Hi Damjan, On 06/10/2015 11:47 PM, Damjan Marion (damarion) wrote: > > Hi, > > We noticed 7% performance improvement by simply moving rte_mbuf.next field to the 1st cache line. > > Currently, it falls under /* second cache line - fields only used in slow path or on TX */ > but it is actually used at several places in rx fast path. (e.g.: i40e_rx_alloc_bufs() is setting that field to NULL). > > Is there anything we can do here (stop using next field, or move it to 1st cache line)? Agree, this is also something I noticed, see: http://dpdk.org/ml/archives/dev/2015-February/014400.html I did not have the time to do performance testing, but it's something I'd like to do as soon as I can. I don't see any obvious reason not to do it. It seems we currently just have enough room to do it (8 bytes are remaining in the first cache line when compiled in 64 bits). Regards, Olivier > > Thanks, > > Damjan > > > >