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 B3AFFA0526 for ; Wed, 22 Jul 2020 04:16:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 75BF31BFE9; Wed, 22 Jul 2020 04:16:39 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id CFA95199BC; Wed, 22 Jul 2020 04:16:32 +0200 (CEST) IronPort-SDR: yu0vPG+LSjHBbkUFJfeiNE79VkhsSlk2t7rA5Q0d0B3gLPr12JeGxthVaCRgSYa4P5upT3FcvG vBmDeAWPf4HQ== X-IronPort-AV: E=McAfee;i="6000,8403,9689"; a="214903607" X-IronPort-AV: E=Sophos;i="5.75,381,1589266800"; d="scan'208";a="214903607" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Jul 2020 19:16:31 -0700 IronPort-SDR: +5HoRiYfzNGuMmuF+daB3mGe5FeA5YJjivfXBThPQed9bxjUsDb0rgrA9eeHF+OdgKaF+m5dR4 Hozjaqh2InLw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,381,1589266800"; d="scan'208";a="328072201" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga007.jf.intel.com with ESMTP; 21 Jul 2020 19:16:31 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 21 Jul 2020 19:16:31 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 21 Jul 2020 19:16:31 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 21 Jul 2020 19:16:31 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.42) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 21 Jul 2020 19:16:27 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T+o+/U1ujtT74/ed9G3HeZ9TbxD2GjPliQxeVLPYQj0WQF0b+f8o9BoXLGIMrtHL7GqSCPiNH/r7M6KFDxkpkbksEZs/9E3lzi63Xl3lEUs0XR0Jqp3TnuW/Sl9UrDnMqbEOncThh/mkrTftAkbdROE29o4vIYLrK7VAEW3exa6BvPH/8+qUFoLTUG00yQql7GY5LBoAw1n+anYmi2PREda2k1oQkAqutx8d1tTkvkQWsAcL+lleOTI+coWwpaj37PkEmItkcUu5gq2V1YuXa64shWX2y2aI+pkpF2BSfF+UnjqkYHleR7l8UHuoN1mW/XtYdQt2wnWOE3mDRXR0kw== 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=gHpX0F1ePib6olBkWr5JRW5DxzFUXmXSPjXYrZ3+QTs=; b=EAdj1uP/w6/h54nQhNItZAhsME9G+WXfPv4/JO2tGPHsha5MpydJnLsxc4MtpiOqZwrm4O3qCgNMJjcUI/zdL5rizaIs6dpTGFDiJrO1dcn3FY3Ctl6bZe8TsvK9rMrwH/iXGG4cXFHVLyKbojjkesBsDHyCrtnrHOUCARaswHRhH2vv83bBnQyEn14JuxsHdDL5ectfyJ/FahRNRAuo3GA6s+KvPNcdkpPuIjAz4XnaU8zdYxp6bdso0Vl1lLrPf+k9s4I5nR0FF73aNrcIEfDr3aQD1hRDC//uKNJ76apKgPLyKhLMISX9d6fQfj9R3EAkOXr/sQ7rcTORG5LQBQ== 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=gHpX0F1ePib6olBkWr5JRW5DxzFUXmXSPjXYrZ3+QTs=; b=FzdSgUBHKaOl/GMTDixNu8nA66C6R15vWNvBuRHAhxDkzZLCLHkRQ3eDAPKZu5LZ9WU9aLBrA6bf+rKf+5/smvsK1sXAolp9SeAQ7xnX4j0w0uq4+7vB0VP5NIPBoKwNiOAaqLeAouDvFPAAGngJvD+n6A1CSai9KbM1kRY6wTY= Received: from CY4PR1101MB2310.namprd11.prod.outlook.com (2603:10b6:910:1b::16) by CY4PR11MB1382.namprd11.prod.outlook.com (2603:10b6:903:2e::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.25; Wed, 22 Jul 2020 02:16:26 +0000 Received: from CY4PR1101MB2310.namprd11.prod.outlook.com ([fe80::2497:a5ff:5152:7782]) by CY4PR1101MB2310.namprd11.prod.outlook.com ([fe80::2497:a5ff:5152:7782%10]) with mapi id 15.20.3216.021; Wed, 22 Jul 2020 02:16:26 +0000 From: "Xu, Ting" To: "Dumitrescu, Cristian" , "dev@dpdk.org" CC: "stable@dpdk.org" Thread-Topic: [PATCH v3] lib/table: fix cache alignment issue Thread-Index: AQHWVZKQgTGo9v+wLUK9TegiOOkDMqkQm3iAgADTONCAAS6iAIAAUx2g Date: Wed, 22 Jul 2020 02:16:26 +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-product: dlpe-windows dlp-reaction: no-action 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: [192.198.147.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2a99d077-f96b-4146-45ab-08d82de53d1a x-ms-traffictypediagnostic: CY4PR11MB1382: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CXRzbXGn6+48pbNfex0DyWITKN7kOxUQKEI3mR0Ho1BOFsUh1NeR9ZdNUeiGHW/rTb+JlgOQtom5BM/nS301xOvuNN25dqh4Erhp9C0dPe7IrpeVMOXM/RLUB5caL7DIWebbRdDI6Fex9XECrvXa6/QIX1PpDvU5Zr6iBi7tTIclf7Nr51CkiSk51yccFCQehKSl5o3lUPMwmIUBeK+enkD32D0dI0a+QNG73EWzB5eW7sC1RimPaYv/k59CTCqHwYUTHn1XJ9+qa8cS1Vpa7/NtNBnmq7LOsD0Mg/1ty3mF9XE9REqAuTK44DJIgM5V x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1101MB2310.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(366004)(376002)(396003)(39860400002)(33656002)(478600001)(86362001)(26005)(186003)(53546011)(6506007)(7696005)(66946007)(4326008)(76116006)(52536014)(55016002)(66446008)(66476007)(450100002)(8936002)(8676002)(66556008)(64756008)(9686003)(2906002)(5660300002)(71200400001)(316002)(83380400001)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: TI4Wuyd1Q1rjPbgDhvi/Np9ZQGnuxZZlS6pU49MfRxxW/hd1rJBbwy8ECiZHc/e7+4nRtYLz8DwQpo1eWdw8j1zTXxfPk4fv+fDk4aH7rTRALUAw+cohHXr2QCV8LwO/bpGwnfjWdsw1YhsvJYIkYDf9ebKPUF0t2VAHXI/vtLS8pKpGoMuIb3YIoHBeXL7V+1xNRT9hv7D4+qlDyWWcbAEhowyBvFK48+kkvdQ9d4R5gQQYWK2vcXlnCKMX4bBcMycPPHgfxREgAChiKRHTTTYyQGaJKm1+G7RXtLKbKzUuppBAO0vCflFtNY4ydsGWw5XHKMfVYmBpIPZxNPrMQgIsytAdHMGzn1XJgtwfflrDO8S65ndZWOGTXth6iGh8YJu3oscjoIYE+Uhhrz2GpS7dmPUpvwZhXvFljavdtx9JXEMI6bOc11nReCw12G5TwggTfPXyP1XhJrTpzKnb0a7QyCXXfmGli2WOST3ibGBt9W0CXecXWwN1p3Q92Tl1 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: CY4PR1101MB2310.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a99d077-f96b-4146-45ab-08d82de53d1a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 02:16:26.7993 (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: YhJqw2LIxIcF/yU8rI83afP19ovpj34fTTJUIenexo/KQaFH6n6RDa/MXiB7sxSP+7sOOVVVx0uLkMvpeI7Yew== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1382 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" Hi, Cristian, > -----Original Message----- > From: Dumitrescu, Cristian > Sent: Wednesday, July 22, 2020 5:17 AM > To: Xu, Ting ; dev@dpdk.org > Cc: stable@dpdk.org > Subject: RE: [PATCH v3] lib/table: fix cache alignment issue >=20 >=20 >=20 > > -----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 > > > > Hi, Cristian > > > > > -----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 issu= e. > > > > 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 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 structure through padding enforced by the compiler. > > > > > > Can you please confirm this is caused by check below failing in the > > > table create function: > > > sizeof(struct rte_bucket_4_16) % 64) !=3D 0 > > > > > > > The result of sizeof(struct rte_bucket_4_16) is 124 byte in this case, > > and this is the direct reason causing this failure. > > > > > Since all the other fields in this data structure are explicitly > > > declared 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 > > > only take > > 32 > > > bits on 32-bit systems. I am not sure why this did not take place in > > > your > > case, > > > any thoughts? > > > > > > > It shows that the size of the field struct rte_bucket_4_16 *next in > > struct > > 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? > > > > > Not sure why we would run Soft NIC on 32-bit systems, might be > > > better to 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: >=20 > #ifdef RTE_ARCH_64 >=20 > struct rte_bucket_4_16 { > //current definition of this struct > }; >=20 > #else >=20 > struct rte_bucket_4_16 { > //definition with padding fields for the 32-bit pointers to keep this > struct to a multiple of 64 bytes }; >=20 > #endif >=20 > We need to apply the same for 8-byte key and 32-byte key hash functions > from the same folder. >=20 > What do you think, Ting? >=20 Thanks for your advice. I think it makes sense. I have updated a new patch version based on this method, could you please h= elp review? Thanks! > > 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 case 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 about the problem later? > > > > Thanks! > > > > > Thanks, > > > Cristian