From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id B6E6B1B28F; Tue, 13 Feb 2018 10:43:02 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2018 01:43:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,507,1511856000"; d="scan'208";a="26890932" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.35]) ([10.237.220.35]) by FMSMGA003.fm.intel.com with ESMTP; 13 Feb 2018 01:42:59 -0800 To: Jerin Jacob , Matan Azrad Cc: "dev@dpdk.org" , "stable@dpdk.org" , Thomas Monjalon , Konstantin Ananyev , Pavan Nikhilesh References: <20180212055439.6462-1-jerin.jacob@caviumnetworks.com> <20180212131343.13555-1-jerin.jacob@caviumnetworks.com> <20180212135046.GA16934@jerin> <20180212141123.GA18758@jerin> From: Ferruh Yigit Message-ID: <1942cf75-1e35-4a9a-7561-cd68b451b73f@intel.com> Date: Tue, 13 Feb 2018 09:42:59 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180212141123.GA18758@jerin> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3] ethdev: fix ethdev data alignment X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 09:43:04 -0000 On 2/12/2018 2:11 PM, Jerin Jacob wrote: > -----Original Message----- >> Date: Mon, 12 Feb 2018 14:02:17 +0000 >> From: Matan Azrad >> To: Jerin Jacob >> CC: "dev@dpdk.org" , "ferruh.yigit@intel.com" >> , "stable@dpdk.org" , Thomas >> Monjalon , Konstantin Ananyev >> , Pavan Nikhilesh >> >> Subject: RE: [dpdk-dev] [PATCH v3] ethdev: fix ethdev data alignment >> >> >> >> From: Jerin Jacob, Sent: Monday, February 12, 2018 3:51 PM >>> -----Original Message----- >>>> Date: Mon, 12 Feb 2018 13:44:54 +0000 >>>> From: Matan Azrad >>>> To: Jerin Jacob , "dev@dpdk.org" >>>> >>>> CC: "ferruh.yigit@intel.com" , "stable@dpdk.org" >>>> , Thomas Monjalon , >>> Konstantin >>>> Ananyev , Pavan Nikhilesh >>>> >>>> Subject: RE: [dpdk-dev] [PATCH v3] ethdev: fix ethdev data alignment >>>> >>>> Hi Jerin >>>> >>>> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] >>>>> The struct rte_eth_dev_data is used in ethdev fastpath routines and >>>>> it not aligned to cache line size. This patch fixes the ethdev data >>> alignment. >>>>> >>>>> The alignment was broken from the "first public release" changeset >>>>> where ethdev data address was aligned only to the first port. >>>>> Remaining ports alignment was defined by the size of the struct >>>>> (rte_eth_dev_data). This scheme is not guaranteed to be cache line >>>>> aligned all the time. >>>>> >>>>> "ethdev: add port ownership" change set introduced a >>>>> rte_eth_dev_shared_data container for port ownership change, This >>>>> resulted in rte_eth_dev->data memory for the first port also as >>>>> cache unaligned. >>>>> >>>>> Added a compiler alignment attribute to make sure rte_eth_dev->data >>>>> always cache aligned so that CPU/compiler >>>>> 1) Avoid sharing the element with another cache line >>>>> 2) Can load/store the elements in struct rte_eth_dev_data as >>>>> naturally aligned. >>>>> >>>>> Some platform like thunderX could see performance regression of 1% >>>>> at >>>>> "ethdev: add port ownership" change set with >>>>> 1 port/1 queue l3fwd application and this patch fixes that regression. >>>>> >>>>> example command: >>>>> sudo ./examples/l3fwd/build/l3fwd -c 0xff00 -- -p 0x1 --config="(0,0,9)" >>>>> >>>>> Fixes: af75078fece3 ("first public release") >>>>> Fixes: 5b7ba31148a8 ("ethdev: add port ownership") >>>> >>>> I don't think you need the add the 5b7ba31148a8 fix line. >>>> Maybe think about it in the next way: >>>> Is your fix can stay as a same fix before the port ownership feature >>> addition? >>>> If yes, You are not fixing it. >>> >>> I don't think so. 5b7ba31148a8 breaking the first port alignment case(as >>> mentioned in the commit log clearly). >>> First port alignment was correct prior to 5b7ba31148a8 change set >>> >>> Do you agree? >> >> No. >> The root cause of the issue this fix is fixing, is that the structure is not aligned, it is not relevant to port ownership. >> The port ownership just exposes it. > > My point is simple. First port alignment was correct prior to 5b7ba31148a8 change set. > it is broken from there. +1 for this logic, adding fixes line makes sense for me. > > It is minor thing. I let, ethdev maintainer to decide what to added in Fixes on apply. >