From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com
 [209.85.212.173]) by dpdk.org (Postfix) with ESMTP id EAC93C42A
 for <dev@dpdk.org>; Wed, 17 Jun 2015 16:05:17 +0200 (CEST)
Received: by wiwd19 with SMTP id d19so134790481wiw.0
 for <dev@dpdk.org>; Wed, 17 Jun 2015 07:05:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:organization
 :user-agent:in-reply-to:references:mime-version
 :content-transfer-encoding:content-type;
 bh=wAoT4EGm+JPqW05SZX4sBefh+gKywH4Qt6OI9vr7nkc=;
 b=dGoUpziVZE9Z5XH0Jd+8JIlSJ253Jqan5BHidALqcbPyXI21q2TAmWfjdQkKuVeGAm
 PbxGL5iyHNtpnRo2ckDWKIpcopYiqw/WTHGIdXYWdCdO+K2K3coEf3paUuQGlTbeQ6fo
 nF6B72JJ8PTGcr0pLFmi4sUPhZ1mwZkb+CwTiQrZY2lTm3MnMGk8UsmlvEOHypM4H0Ii
 ZrifntJrrFPB5I/Ba3B/cXgk64LMnfqL5ttbf7OdvXEVlc3VXzk39y+dzRT5UbvxhYno
 VVu2MtTiRFbzJPIOG3J9honZ5S7WTsZIFv8Q3JK6akq+VGad8F5sn1lM4HXR2N31d/p5
 I5BQ==
X-Gm-Message-State: ALoCoQkw+4s1Xk1eIKunq+fL6OZQcBkG545YyDzwJKdygicDb/mNuJa7W5j2BNVkg4HQV2ummtXe
X-Received: by 10.194.5.135 with SMTP id s7mr6312819wjs.115.1434549917795;
 Wed, 17 Jun 2015 07:05:17 -0700 (PDT)
Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136])
 by mx.google.com with ESMTPSA id i6sm7016078wjf.29.2015.06.17.07.05.15
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 17 Jun 2015 07:05:16 -0700 (PDT)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: "Damjan Marion (damarion)" <damarion@cisco.com>
Date: Wed, 17 Jun 2015 16:04:16 +0200
Message-ID: <1938787.pNZKqKsuVM@xps13>
Organization: 6WIND
User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; )
In-Reply-To: <68EBE73B-D251-4297-BFE2-E2D2A3AEFD33@cisco.com>
References: <87110795-201A-4A1E-A4CC-A778AA7C8218@cisco.com>
 <20150615141258.GA580@bricha3-MOBL3>
 <68EBE73B-D251-4297-BFE2-E2D2A3AEFD33@cisco.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: dev@dpdk.org
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: Wed, 17 Jun 2015 14:05:18 -0000

2015-06-17 13:55, Damjan Marion:
> 
> > On 15 Jun 2015, at 16:12, Bruce Richardson <bruce.richardson@intel.com> wrote:
> > 
> > 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 never 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 multi-segment
> > mbuf, it's likely to be a big packet, so we have more processing time available
> > 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 chained mbufs.
> Why they are less important than ones using rx offload? This is something people 
> should be able to configure on build time.
> That should not be too hard to achieve with set of macros. I can come up with the patch...

Having a build-time configuration of mbuf totally breaks the idea of having
some shared libraries.