From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Damjan Marion (damarion)" <damarion@cisco.com>
Subject: Re: rte_mbuf.next in 2nd cacheline
Date: Wed, 17 Jun 2015 13:55:57 +0000
Message-ID: <68EBE73B-D251-4297-BFE2-E2D2A3AEFD33@cisco.com>
References: <87110795-201A-4A1E-A4CC-A778AA7C8218@cisco.com>
 <557ED116.7040508@6wind.com> <20150615134409.GA7500@bricha3-MOBL3>
 <2601191342CEEE43887BDE71AB97725836A0A838@irsmsx105.ger.corp.intel.com>
 <557EDB91.9010503@6wind.com> <20150615141258.GA580@bricha3-MOBL3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "dev@dpdk.org" <dev@dpdk.org>
To: Bruce Richardson <bruce.richardson@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75])
 by dpdk.org (Postfix) with ESMTP id 5E03BC42A
 for <dev@dpdk.org>; Wed, 17 Jun 2015 15:56:01 +0200 (CEST)
In-Reply-To: <20150615141258.GA580@bricha3-MOBL3>
Content-Language: en-US
Content-ID: <82F20E46BCF9FA48A8F0E2BDED06E9ED@emea.cisco.com>
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>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>


> On 15 Jun 2015, at 16:12, Bruce Richardson <bruce.richardson@intel.com> w=
rote:
>=20
> The next pointers always start out as NULL when the mbuf pool is created.=
 The
> only time it is set to non-NULL is when we have chained mbufs. If we neve=
r have
> any chained mbufs, we never need to touch the next field, or even read it=
 - since
> we have the num-segments count in the first cache line. If we do have a m=
ulti-segment
> mbuf, it's likely to be a big packet, so we have more processing time ava=
ilable
> and we can then take the hit of setting the next pointer.

There are applications which are not using rx offload, but they deal with c=
hained mbufs.
Why they are less important than ones using rx offload? This is something p=
eople=20
should be able to configure on build time.
That should not be too hard to achieve with set of macros. I can come up wi=
th the patch...

Thanks,

Damjan=