From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <damarion@cisco.com>
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74])
 by dpdk.org (Postfix) with ESMTP id 16F946849
 for <dev@dpdk.org>; Wed, 10 Jun 2015 23:47:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=cisco.com; i=@cisco.com; l=446; q=dns/txt; s=iport;
 t=1433972874; x=1435182474;
 h=from:to:subject:date:message-id:content-id:
 content-transfer-encoding:mime-version;
 bh=cmx6y0guXxBM0RjEBy0GlD+BWU2mPxvE1qLZusZyocM=;
 b=PuUnJqSu/7nqbeMMdkZ1dESbsXheUOelS8z9ZGqCKdyOVP2q/Y4SI7fR
 OPddyf+CHfDoDaIkjo7thSvSq0gAK1zTyggfICtXVgJ2BqCoMsmHTnyoE
 gfm+gqanCUmK4iyiF0VkwNyYzEJZlKBLtM3XIWw9UIyqvNfMD4wnwf+KX w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BMBADsr3hV/4cNJK1cgxABgTi+CQmBUodLOBQBAQEBAQEBgQqEKTpRAT5CJwSIQZ5rs2cBAQEBBgEBAQEBAQEbk2eBFgWTSos2jUaKNSSDeII1gQEBAQE
X-IronPort-AV: E=Sophos;i="5.13,589,1427760000"; 
   d="scan'208";a="6201779"
Received: from alln-core-2.cisco.com ([173.36.13.135])
 by rcdn-iport-3.cisco.com with ESMTP; 10 Jun 2015 21:47:52 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87])
 by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5ALlrta012849
 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)
 for <dev@dpdk.org>; Wed, 10 Jun 2015 21:47:53 GMT
Received: from xmb-aln-x01.cisco.com ([169.254.2.185]) by
 xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 10
 Jun 2015 16:47:52 -0500
From: "Damjan Marion (damarion)" <damarion@cisco.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: rte_mbuf.next in 2nd cacheline
Thread-Index: AQHQo8caRiJzxo5OE0esWvWQH/eOLg==
Date: Wed, 10 Jun 2015 21:47:52 +0000
Message-ID: <87110795-201A-4A1E-A4CC-A778AA7C8218@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.15.244]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4AB1C783E65199408E3356F7CE0D7E3E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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: Wed, 10 Jun 2015 21:47:54 -0000


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 p=
ath or on TX */
but it is actually used at several places in rx fast path. (e.g.: i40e_rx_a=
lloc_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)?

Thanks,

Damjan