From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <simon.kagstrom@netinsight.net>
Received: from ernst.netinsight.se (ernst.netinsight.se [194.16.221.21])
 by dpdk.org (Postfix) with SMTP id 541208DA1
 for <dev@dpdk.org>; Tue,  8 Sep 2015 12:40:59 +0200 (CEST)
Received: from [10.100.1.152] (unverified [10.100.1.152]) by
 ernst.netinsight.se
 (EMWAC SMTPRS 0.83) with SMTP id <B0030912569@ernst.netinsight.se>;
 Tue, 08 Sep 2015 12:40:50 +0200
Message-ID: <55EEBB33.6050300@netinsight.net>
Date: Tue, 08 Sep 2015 12:40:51 +0200
From: =?windows-1252?Q?Simon_K=E5gstr=F6m?=
 <simon.kagstrom@netinsight.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, 
 "dev@dpdk.org" <dev@dpdk.org>
References: <20150831144110.4a7afa27@miho>	<55ED3D9A.7070607@6wind.com>	<2601191342CEEE43887BDE71AB97725836A83CBA@irsmsx105.ger.corp.intel.com>	<55ED5A6A.1000803@6wind.com>	<55ED69BA.4010803@netinsight.net>
 <20150907134324.2d418bd4@miho>
 <2601191342CEEE43887BDE71AB97725836A83E71@irsmsx105.ger.corp.intel.com>
 <55ED85EB.2030102@netinsight.net>
 <2601191342CEEE43887BDE71AB97725836A841A7@irsmsx105.ger.corp.intel.com>
In-Reply-To: <2601191342CEEE43887BDE71AB97725836A841A7@irsmsx105.ger.corp.intel.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] [PATCH v2] mbuf/ip_frag: Move mbuf chaining to
	common code
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, 08 Sep 2015 10:40:59 -0000

On 2015-09-08 01:21, Ananyev, Konstantin wrote:
>>
>> Thanks. I got it wrong anyway, what I wanted was to be able to handle
>> the day when nb_segs changes to a 16-bit number, but then it should
>> really be
>>
>>   ... >= 1 << (sizeof(head->nb_segs) * 8)
>>
>> anyway. I'll fix that and also add a warning that the implementation
>> will do a linear search to find the tail entry.
> 
> Probably just me, but I can't foresee the situation when  we would need to increase nb_segs to 16 bits.
> Looks like an overkill to me.

I don't think it will happen either, but with this solution, this
particular piece of code will work regardless. The value is known at
compile-time anyway, so it should not be a performance issue.

// Simon