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 8B1CAA053D for ; Mon, 20 Jul 2020 16:37:42 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3B12A1BFE7; Mon, 20 Jul 2020 16:37:42 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 4BB9B1BFE3; Mon, 20 Jul 2020 16:37:38 +0200 (CEST) IronPort-SDR: wesBsxeK9Y68TeEXgNYpRmOAmMVYhHonn4/6VTNsY6Rc/aDrW2F4+Oj1gnqo2tViOlMnPvj0Gm Fw4nNxmCAzcA== X-IronPort-AV: E=McAfee;i="6000,8403,9687"; a="214598043" X-IronPort-AV: E=Sophos;i="5.75,375,1589266800"; d="scan'208";a="214598043" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2020 07:37:37 -0700 IronPort-SDR: vjl3c3MLVskN27iZ+leAXL6dF5s6D3m5y312LrZTKPap7DPBeMV4Uh9CyBAxB6HyxEhBxT7ZLc zMBvLAipLI8g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,375,1589266800"; d="scan'208";a="487743581" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga005.fm.intel.com with ESMTP; 20 Jul 2020 07:37:35 -0700 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 20 Jul 2020 07:37:36 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Mon, 20 Jul 2020 07:37:36 -0700 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.103) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 20 Jul 2020 07:37:36 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TnoHFrmMydf89/XkezWekRCpthpcBusOqjKvo4knJhzJ8N5PXHja6Y872fJ24r0YgAxeyYIr036p7liyaxwpNa0vV1cb6ZcadqBbpYYBzN8aVs3v4NFYm8Mq/wGJoouTOkN8z6QzfKGZmTTpY0Qn6I3XNMklXv6Am3u09VpXf+kZvrxQNqhZ7QDsxN1riqcR6RjHs2n1kbcPMcKnoJCS5/kVvJPdSUEKlV+oDcxjvDylGvpHRoYVN1hnTUus9WEdZ1DHy2uPRLv/XjENAP1JdLxEpCop20IWTtyM/fWwoXWiuG48Nm5LXM6N2pov6q9ipSOb7JcaHcIIy0QYa7TXRg== 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=0mCwQI1rw9+hCm1kpzhKJvJoveBOvw8dNVsWE4bmKVk=; b=mquQ5EtCGSni/TYYTOA1JV/c83TPzTY7UGDDFfKZBWDIRyL7yC+KWp6djfOfo72ChEdsDV3o/UTryzF5dYqc8BQg4Utd481Kp8qlwaR/IbUM/WTDdqzSd4j9FFlOWfrsA9k3IMeAr9TDfqqfsMuKbdJizfx4U8ZptSwzrvmXDbHABjTV8QpqdC1lFdF6a5r6hw6aIxwWtlfiEFzBBdxr3sjPIlNnI0ubYBGwq7wLbfAIw+GH7Q7BxtcF626oRvFT31zv/nN2Sdmem54s5wDym8gY4lPw58zXmQEAzoV9XM5BDBqXteBUaDBDqAh3sjbeqLx3BAXFVfuVnN3bsfBLJA== 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=0mCwQI1rw9+hCm1kpzhKJvJoveBOvw8dNVsWE4bmKVk=; b=wKMjx+z3P0o1uO19tUprnTEuw6r9giW12DeGezpd7s61+Z6J6CKgogth1sNbF0bb5glf3dczRPQEq2P9+5TekQPUe0c5qhTOK73RtI9v7WAmhxtuJx+7+VbjgmapSfuwZJUmjgjNpIgJrbhkU3yZXRP56t7Bz42Emo9DtincT24= Received: from BL0PR11MB2931.namprd11.prod.outlook.com (2603:10b6:208:7d::33) by BL0PR11MB3268.namprd11.prod.outlook.com (2603:10b6:208:67::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.23; Mon, 20 Jul 2020 14:37:35 +0000 Received: from BL0PR11MB2931.namprd11.prod.outlook.com ([fe80::ddc6:6f06:2d37:4427]) by BL0PR11MB2931.namprd11.prod.outlook.com ([fe80::ddc6:6f06:2d37:4427%5]) with mapi id 15.20.3174.030; Mon, 20 Jul 2020 14:37:35 +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+t0ku3os7PKMFnZakQmQ6A Date: Mon, 20 Jul 2020 14:37:35 +0000 Message-ID: References: <20200616162705.83575-1-ting.xu@intel.com> <20200709014825.13690-1-ting.xu@intel.com> In-Reply-To: <20200709014825.13690-1-ting.xu@intel.com> 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: 66e9d427-551e-4811-b823-08d82cba71a1 x-ms-traffictypediagnostic: BL0PR11MB3268: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wjTGnZEW4GNDdNBzax0CQrpn3PZKNi/BtDTor+bWu9rGbQ45SyWbqSzsSHxpc8oqB7E7kjttgUhEODNGJPMjMmDN/xndX/eDwX29cTOwyrWnrxrGPzDPQ6wXu0Ome57rnOCMrp9hvYtiH0Pgc386dIoSe8xPt0QqHR0TbWls8f/jG1eJjQNM5hNiluKsUT0VaLyHIxoUS5avBhfhzavreLwf12X9ouLe+UoF8RXyn/tOBxlBgtuSdHOHXGRMTHao4bcUrFiOScMCFRcgRcLuZAOwl051F2i7UvLcIujZq16xnFJXukWsnFUlSFJ/aaiH x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB2931.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(346002)(376002)(39860400002)(366004)(136003)(186003)(7696005)(86362001)(55016002)(4326008)(26005)(450100002)(478600001)(71200400001)(52536014)(33656002)(8676002)(66476007)(64756008)(66946007)(66556008)(9686003)(66446008)(76116006)(53546011)(8936002)(2906002)(83380400001)(6506007)(110136005)(5660300002)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: YSXw2JfhQbQMjwjax8HlhTu8jJpg0UDGhRlHcLAF3bIGuxMxF6xrXTovGiiycktgqE8YlLe+ykAm+aQdKKShlEQgfGyEi0HV5Ryh7USCrJ3zat8u06jbU0yYab8fPSLfnvnLqfsZJ102mq+4/E62+ip1FGf1fRTgRPilFukB7F/hjoN9Uf3laYovc1xlp+Mv1pgtUrvU9HIw0IHEIxdc5GSjpZ5sKrMVTxUKXxL/RCH0vhYWVw+7ZlbuCTzYKuvJVBRu52PHpHjKSWQ0tdzVBEOu8Qsl7loluF5MXzzmXHAGW8L6AT9z9mvtw3v2bJxmiw6CnfkeABsiyEezB+AiaYx2yhDc6qNq/F6/jCOCaP9ewlYoViNv0V2tCPLbiCHVgvruRv7sXPEBmxxFtUay6vThjhjYU4S/PJ8wRCgBDsM1CjH75uN+KpeJVx7it0NQeQwwKPS2kt5YQjgIsBLgC+JgNF8PAohj+KG1ctR6z61ClJ6R9WdUdk2aqJQWZs2c 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: BL0PR11MB2931.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 66e9d427-551e-4811-b823-08d82cba71a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2020 14:37:35.4024 (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: xWy/t4fRCDYBgqVZzw1oonbRs7q3TZlhnjuoqZ40B0wRKcGPe9jeicT9N1TKdnjMHCXbObgdE/VM43x92JRH6WY6bxzU86ejU5QFmeW0hOY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3268 X-OriginatorOrg: intel.com Subject: Re: [dpdk-stable] [PATCH v3] lib/table: fix cache alignment issue 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: , Errors-To: stable-bounces@dpdk.org Sender: "stable" > -----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 >=20 > 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. >=20 > Fixes: 8aa327214c ("table: hash") > Cc: stable@dpdk.org >=20 > Signed-off-by: Ting Xu >=20 > --- > v2->v3: Rebase > v1->v2: Correct patch time > --- > lib/librte_table/rte_table_hash_key16.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > 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]; >=20 > /* Cache line 2 */ > - uint8_t data[0]; > + uint8_t data[0] __rte_cache_aligned; > }; >=20 > struct rte_table_hash { > -- > 2.17.1 Hi Ting, This fix is breaking the execution for systems with cache line of 128 bytes= , as typically (on 64-bit systems) this structure would be 64-byte in size = and adding the __rte_cache_aligned would force doubling the size of this st= ructure through padding enforced by the compiler. Can you please confirm this is caused by check below failing in the table c= reate function: sizeof(struct rte_bucket_4_16) % 64) !=3D 0 Since all the other fields in this data structure are explicitly declared a= s 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 only take 32 bits on 32-bit systems. I am not sure why this did not = take place in your case, any thoughts? Not sure why we would run Soft NIC on 32-bit systems, might be better to di= sable Soft NIC for 32-bit systems. Thanks, Cristian