From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id EBC86C674 for ; Thu, 16 Jun 2016 13:34:37 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 16 Jun 2016 04:34:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,480,1459839600"; d="scan'208";a="988704177" Received: from dhunt5-mobl.ger.corp.intel.com (HELO [10.237.220.29]) ([10.237.220.29]) by fmsmga001.fm.intel.com with ESMTP; 16 Jun 2016 04:34:35 -0700 To: Olivier MATZ , Jan Viktorin 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> Cc: dev@dpdk.org, jerin.jacob@caviumnetworks.com, shreyansh.jain@nxp.com From: "Hunt, David" Message-ID: <57628ECB.1030108@intel.com> Date: Thu, 16 Jun 2016 12:34:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <57626A22.2020604@6wind.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v12 0/3] mempool: add external mempool manager X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 11:34:38 -0000 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.