From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Hunt, David" <david.hunt@intel.com>
Subject: Re: [PATCH v12 0/3] mempool: add external mempool manager
Date: Thu, 16 Jun 2016 12:34:35 +0100
Message-ID: <57628ECB.1030108@intel.com>
References: <1465919341-3209-1-git-send-email-david.hunt@intel.com>
 <1465976824-83823-1-git-send-email-david.hunt@intel.com>
 <20160615121358.5ef9f142@pcviktorin.fit.vutbr.cz>
 <57614043.9090603@intel.com> <57614402.6020708@6wind.com>
 <576183AD.8070200@intel.com> <576184F7.3040206@6wind.com>
 <576259A2.4090200@intel.com> <57626787.6090709@6wind.com>
 <57626992.9020009@intel.com> <57626A22.2020604@6wind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, jerin.jacob@caviumnetworks.com, shreyansh.jain@nxp.com
To: Olivier MATZ <olivier.matz@6wind.com>,
 Jan Viktorin <viktorin@rehivetech.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
 by dpdk.org (Postfix) with ESMTP id EBC86C674
 for <dev@dpdk.org>; Thu, 16 Jun 2016 13:34:37 +0200 (CEST)
In-Reply-To: <57626A22.2020604@6wind.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 16/6/2016 9:58 AM, Olivier MATZ wrote:
>>>
>>> So I don't think we should have more cache misses whether it's
>>> placed at the beginning or at the end. Maybe I'm missing something...
>>>
>>> I still believe it's better to group the 2 fields as they are
>>> tightly linked together. It could be at the end if you see better
>>> performance.
>>>
>>
>> OK, I'll leave at the end because of the performance hit.
>
> Sorry, my message was not clear.
> I mean, having both at the end. Do you see a performance
> impact in that case?
>

I ran multiple more tests, and average drop I'm seeing on an older 
server reduced to 1% average (local cached use-case), with 0% change on 
a newer Haswell server, so I think at this stage we're safe to put it up 
alongside pool_data. There was 0% reduction when I moved both to the 
bottom of the struct. So on the Haswell, it seems to have minimal impact 
regardless of where they go.

I'll post the patch up soon.

Regards,
Dave.