From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E0E0BA0526; Tue, 21 Jul 2020 23:16:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 796761C0AE; Tue, 21 Jul 2020 23:16:49 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 5742E1C07E; Tue, 21 Jul 2020 23:16:47 +0200 (CEST) IronPort-SDR: ZP/O4PM0nWU4Nqv8sioCt6/2k2KT6HvPyGG/ValCao5LfGtlvrCT1whBLQ+W0fhujSJvuBNJWI vVWMP1f03EIg== X-IronPort-AV: E=McAfee;i="6000,8403,9689"; a="235096771" X-IronPort-AV: E=Sophos;i="5.75,380,1589266800"; d="scan'208";a="235096771" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2020 14:16:46 -0700 IronPort-SDR: RuYaowmbAXD7z9jZyJzONrd2QgQvblfEE8t26hfhePjtWux6f5qoACMCTr7GQa0iULAHTq+s/a f4Q/bDjNnSTw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,380,1589266800"; d="scan'208";a="326490239" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by FMSMGA003.fm.intel.com with ESMTP; 21 Jul 2020 14:16:46 -0700 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 21 Jul 2020 14:16:45 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.108) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 21 Jul 2020 14:16:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c0YFb/s2/9V99iWThu/+64XUn5fK8+0gOKNS4I43E8aRhlz8pqFpMgenMlSCtMiXyK1IqdUIW7fftZ70F6Wzmd41t+axmdk2ZHmapiB2rthEoFhk5kY1BEx7+XVl/pZ8ClEUEdCO30W24valmxEbmEphIs1KJYlelaR4K2bQqpgKqzt0DWOO0Nc9y7ji8BxoFh3X9mR0ocUKm1lO0y2tkdkJchpeI2bPkQ5aKibcOk8gmM5YDUUm31WSm3VryAg46BYZHH5+5wPUC/zyiU1vekk8xXffWUb3gOOk0JUagBZPvYmWDoS0Eg0bHk2Vxc4O8IXK8t3t19vQlFugr0y3Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t2AiHW+2CSOrrN9hW3mSgf+NWw1EZ2aLBK3gLgsgADo=; b=bGZvpO6uWRyRDdk4vwn2mZb7VxH+kai+1Aw5PVrWIznNqz6Pqcf23+Wqfjk3IJYLmu6HZIt10R4mB8+XwwQfeOe2PKofzWKIy87pFGIG1HSPiL5QvSA947G/xqiwggRVZRj/pKszd14DsrjRoQooagX7vq3UMdwVJVVEivE7VrZ6D+roTiiSSd2fUFGcsa8LUZaYXHe+J5mGJFlneScFZv9MhjQC0kbYwEQQg4FnZpVwzlNFSFThT9Bp1qA62EIkJHVQiHE+9xLIJINeVLEDlma9dXNqEzIljsrlHtjEvsaSoIQumMGf3AsYMFoTIo6vBoyAQKhg19NSBIgKu8YCrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t2AiHW+2CSOrrN9hW3mSgf+NWw1EZ2aLBK3gLgsgADo=; b=AUG7Y1KUa3ct3PEtxPSfRbGmAvzIBX9uyYH3M3yhpM2P5zDlpbNwVcP5jXEobQnfScSGKHNgnYY3CEXGprS+48dP7jqnzb1Mu5MbXma+6URWTA9Sx1kJxYatES8tJUHQyOJTUvX2BpZUXjBufDSDcOi8v00ZPVAIaBTF7Hlko9w= Received: from BYAPR11MB2935.namprd11.prod.outlook.com (2603:10b6:a03:82::24) by BYAPR11MB2758.namprd11.prod.outlook.com (2603:10b6:a02:c9::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.24; Tue, 21 Jul 2020 21:16:44 +0000 Received: from BYAPR11MB2935.namprd11.prod.outlook.com ([fe80::d514:54b4:8e58:2061]) by BYAPR11MB2935.namprd11.prod.outlook.com ([fe80::d514:54b4:8e58:2061%3]) with mapi id 15.20.3195.026; Tue, 21 Jul 2020 21:16:44 +0000 From: "Dumitrescu, Cristian" To: "Xu, Ting" , "dev@dpdk.org" CC: "stable@dpdk.org" Thread-Topic: [PATCH v3] lib/table: fix cache alignment issue Thread-Index: AQHWVZKQotqfiF+t0ku3os7PKMFnZakQmQ6AgAD30YCAAQsIYA== Date: Tue, 21 Jul 2020 21:16:44 +0000 Message-ID: References: <20200616162705.83575-1-ting.xu@intel.com> <20200709014825.13690-1-ting.xu@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.2.0.6 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [109.79.55.254] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1defc0f3-383b-4dbe-978f-08d82dbb5ed6 x-ms-traffictypediagnostic: BYAPR11MB2758: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2KWAwu71kziOf9OQnO4d1/wOetytTq70tpWllY8yYP4e07bwYKF3bEQJIOVBPhyL5MLp4jf2OFQ5k6Qdu4yePUl/trAgeYMo8BUWVHXYVVE1U4Er592rAD4+W6Uw6O59iL1pUvRxu+5EcKC+SXtraUMgJwN7GFvBt3R1IOCk+w/W2IYZgTj/+2jzWzkE4CzR9CnE8FiMGg2NzT7mmjWLqoEY9zEHEjfVYOeJmQ2cAnzJVPpL0t/dcHoIFmbnyWdNuWWOCuCMkDIAygVDZBcFeyy19rwnrbMsPRKLidhk5Msnwq5Bo9mS3RTOKYG1EPXU x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2935.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39850400004)(366004)(396003)(136003)(376002)(5660300002)(186003)(76116006)(66556008)(86362001)(66476007)(66446008)(64756008)(8936002)(478600001)(66946007)(71200400001)(33656002)(52536014)(8676002)(83380400001)(55016002)(4326008)(450100002)(6506007)(110136005)(316002)(9686003)(26005)(2906002)(53546011)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: Xg6/ENa8GtMrFqASDUy70pz+ajQIoK2U4wIRfGQuUka7yn0VZXnE2fXN5lF17xuY7BimiOsOU5UcHP+aylrnizggryRSk5ZNTjtS8znbyLntN6dmXVlBeXQJk+aelXb4liPPFjR7AStd8Q5nFlpQQVLoXF3fF80FNyIag1ElLK/qt2JdZMDoFL/PVRzZGVF+/Za121uN1JLhTAXE2IZvg0GDfanoc5O0Ndx2KGocXkp9vcoCfldoPmVKKl6Zota/oWbbnmPZUPRCTZo6Y6mrd9yYoW6l+oTtX+VsLVDx8VyFazh2IoeypfB89Ijsjr4D4RNnNSEvRipk4arb/BOv6Gy2Dpag+/vWtHZLHqBG7deePnqJBaobNdEu5JeqPBi2d3dpojPFJ5g5Jtt55Z9K2tjPlkiv9fe7/Nem37ZWpHcfvzIdWVqSeFvPYUyS7pT06cW0PvWXM3uM40PJdJwA5K3o6JHsdfh0P+0AdZL4G1w= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2935.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1defc0f3-383b-4dbe-978f-08d82dbb5ed6 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2020 21:16:44.4542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U747lGZqTe9W5ZUi4Rf2lMTcpHfMkS7Ow/VqYjFaR0A/eYVLNvfLasCuDPYShkRQLarpEcFRygCY7DEOX92N5uC9X6cHMB7w0gFJKT+8vwo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2758 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3] lib/table: fix cache alignment issue X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Xu, Ting > Sent: Tuesday, July 21, 2020 6:16 AM > To: Dumitrescu, Cristian ; dev@dpdk.org > Cc: stable@dpdk.org > Subject: RE: [PATCH v3] lib/table: fix cache alignment issue >=20 > Hi, Cristian >=20 > > -----Original Message----- > > From: Dumitrescu, Cristian > > Sent: Monday, July 20, 2020 10:38 PM > > To: Xu, Ting ; dev@dpdk.org > > Cc: stable@dpdk.org > > Subject: RE: [PATCH v3] lib/table: fix cache alignment issue > > > > > > > > > -----Original Message----- > > > From: Xu, Ting > > > Sent: Thursday, July 9, 2020 2:48 AM > > > To: dev@dpdk.org > > > Cc: Dumitrescu, Cristian ; Xu, Ting > > > ; stable@dpdk.org > > > Subject: [PATCH v3] lib/table: fix cache alignment issue > > > > > > When create softnic hash table with 16 keys, it failed on 32bit > > > environment because of the structure rte_bucket_4_16 alignment issue. > > > Add __rte_cache_aligned to ensure correct cache align. > > > > > > Fixes: 8aa327214c ("table: hash") > > > Cc: stable@dpdk.org > > > > > > Signed-off-by: Ting Xu > > > > > > --- > > > v2->v3: Rebase > > > v1->v2: Correct patch time > > > --- > > > lib/librte_table/rte_table_hash_key16.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/lib/librte_table/rte_table_hash_key16.c > > > b/lib/librte_table/rte_table_hash_key16.c > > > index 2cca1c924..5e1665c15 100644 > > > --- a/lib/librte_table/rte_table_hash_key16.c > > > +++ b/lib/librte_table/rte_table_hash_key16.c > > > @@ -44,7 +44,7 @@ struct rte_bucket_4_16 { > > > uint64_t key[4][2]; > > > > > > /* Cache line 2 */ > > > - uint8_t data[0]; > > > + uint8_t data[0] __rte_cache_aligned; > > > }; > > > > > > struct rte_table_hash { > > > -- > > > 2.17.1 > > > > Hi Ting, > > > > This fix is breaking the execution for systems with cache line of 128 b= ytes, > as > > typically (on 64-bit systems) this structure would be 64-byte in size a= nd > > adding the __rte_cache_aligned would force doubling the size of this > > structure through padding enforced by the compiler. > > > > Can you please confirm this is caused by check below failing in the tab= le > > create function: > > sizeof(struct rte_bucket_4_16) % 64) !=3D 0 > > >=20 > The result of sizeof(struct rte_bucket_4_16) is 124 byte in this case, an= d this > is the direct reason causing this failure. >=20 > > Since all the other fields in this data structure are explicitly declar= ed as 64- > bit > > fields, due to the alignment rules I was expecting the compiler to add = a 32- > bit > > padding field after the "next" field, which is a pointer that would onl= y take > 32 > > bits on 32-bit systems. I am not sure why this did not take place in yo= ur > case, > > any thoughts? > > >=20 > It shows that the size of the field struct rte_bucket_4_16 *next in struc= t > rte_bucket_4_16 is only 32 bits. And there is no padding added by the > compiler in my and the reporter's case. > I tried to add a 32 bits pad field after the field next manually, and the= result is > correct then. > Is it because in 32-bit system, the compiler will not extend the 32 bits = pointer > to 64 bits, since the 32 bits size has already matched the cache line? >=20 > > Not sure why we would run Soft NIC on 32-bit systems, might be better t= o > > disable Soft NIC for 32-bit systems. > > >=20 My proposed solution, which IMO provides the cleanest and most readable way= to fix / maintain this code: #ifdef RTE_ARCH_64 struct rte_bucket_4_16 { //current definition of this struct }; #else struct rte_bucket_4_16 { //definition with padding fields for the 32-bit pointers to keep this stru= ct to a multiple of 64 bytes }; #endif We need to apply the same for 8-byte key and 32-byte key hash functions fro= m the same folder. What do you think, Ting? > To be honest, I do not know why we should run softnic on 32-bit system, I > was just assigned this specific bug. It seems there is a complete test ca= se for > validation team to test softnic in 32-bit system. > I am not sure is it OK to tell the validation team that we should disable= softnic > in 32-bit system now. Or we should fix this issue this time and discuss a= bout > the problem later? >=20 > Thanks! >=20 > > Thanks, > > Cristian