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 897FF231C
 for <dev@dpdk.org>; Tue, 25 Oct 2016 15:14:14 +0200 (CEST)
Received: from lfbn-1-5996-232.w90-110.abo.wanadoo.fr ([90.110.195.232]
 helo=[192.168.1.13])
 by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <olivier.matz@6wind.com>)
 id 1bz1bg-0000zM-3L; Tue, 25 Oct 2016 15:17:34 +0200
To: =?UTF-8?Q?Morten_Br=c3=b8rup?= <mb@smartsharesystems.com>, dev@dpdk.org
References: <98CBD80474FA8B44BF855DF32C47DC359EA8B1@smartserver.smartshare.dk>
From: Olivier Matz <olivier.matz@6wind.com>
Message-ID: <1fb6b9cd-341c-1aaa-6a9f-56b758af772e@6wind.com>
Date: Tue, 25 Oct 2016 15:14:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Icedove/45.2.0
MIME-Version: 1.0
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC359EA8B1@smartserver.smartshare.dk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [dpdk-dev] mbuf changes
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: Tue, 25 Oct 2016 13:14:14 -0000

Hi,

On 10/24/2016 05:49 PM, Morten Brørup wrote:
> And here’s something new to think about:
> 
> m->next already reveals if there are more segments to a packet. Which
> purpose does m->nb_segs serve that is not already covered by m->next?
> 

I was asking myself the same question some time ago:
http://dpdk.org/ml/archives/dev/2016-May/039483.html

But it seems nb_segs is useful for PMDs on TX side, to
anticipate how many descriptors a packet will use in the
TX ring. It can also help a PMD to check that this packet
is supported by the hardware (too many segments) without
browsing the list.

So finally I think it should be kept in the mbuf. But as
suggested by Bruce, it could go in the second cache line,
since m->next is also there, at the condition that this
field is set to 1 in mbuf_free().

Regards,
Olivier