From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id 5464D5A53
 for <dev@dpdk.org>; Mon, 15 Jun 2015 15:19:30 +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.2:DHE_RSA_AES_128_CBC_SHA1:128)
 (Exim 4.80) (envelope-from <olivier.matz@6wind.com>)
 id 1Z4UMz-00084M-NC; Mon, 15 Jun 2015 15:24:15 +0200
Message-ID: <557ED116.7040508@6wind.com>
Date: Mon, 15 Jun 2015 15:20:22 +0200
From: Olivier MATZ <olivier.matz@6wind.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.6.0
MIME-Version: 1.0
To: "Damjan Marion (damarion)" <damarion@cisco.com>, 
 "dev@dpdk.org" <dev@dpdk.org>
References: <87110795-201A-4A1E-A4CC-A778AA7C8218@cisco.com>
In-Reply-To: <87110795-201A-4A1E-A4CC-A778AA7C8218@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] rte_mbuf.next in 2nd cacheline
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2015 13:19:30 -0000

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
> 
> 
> 
>