From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: rte_mbuf.next in 2nd cacheline Date: Wed, 17 Jun 2015 16:04:16 +0200 Message-ID: <1938787.pNZKqKsuVM@xps13> References: <87110795-201A-4A1E-A4CC-A778AA7C8218@cisco.com> <20150615141258.GA580@bricha3-MOBL3> <68EBE73B-D251-4297-BFE2-E2D2A3AEFD33@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: "Damjan Marion (damarion)" Return-path: 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 ; Wed, 17 Jun 2015 16:05:17 +0200 (CEST) Received: by wiwd19 with SMTP id d19so134790481wiw.0 for ; Wed, 17 Jun 2015 07:05:17 -0700 (PDT) In-Reply-To: <68EBE73B-D251-4297-BFE2-E2D2A3AEFD33@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" 2015-06-17 13:55, Damjan Marion: > > > On 15 Jun 2015, at 16:12, Bruce Richardson 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.