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 F3BE5A0526; Tue, 21 Jul 2020 07:16:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2CA4B1BFFC; Tue, 21 Jul 2020 07:16:01 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id F0C3F1BFFB; Tue, 21 Jul 2020 07:15:58 +0200 (CEST) IronPort-SDR: RBWT2eGS5zxctUJ0ihfir1zkm9kV169C4X6ld2TUeCe3W/qd32rVUYPQwbDDF8wwxZTDgOT8v9 slNLVtkIdNyg== X-IronPort-AV: E=McAfee;i="6000,8403,9688"; a="214727583" X-IronPort-AV: E=Sophos;i="5.75,377,1589266800"; d="scan'208";a="214727583" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jul 2020 22:15:57 -0700 IronPort-SDR: g6rG+0lwH5Zg9d68gT51zPRpIv4Q9jOwp8rcQKFJ9UnL9Il4d4GTRh15YYbRjYtP5Cd2SOQUCT JZbkjsuRT2KA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,377,1589266800"; d="scan'208";a="319781318" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga002.fm.intel.com with ESMTP; 20 Jul 2020 22:15:57 -0700 Received: from fmsmsx152.amr.corp.intel.com (10.18.125.5) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 20 Jul 2020 22:15:57 -0700 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by FMSMSX152.amr.corp.intel.com (10.18.125.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 20 Jul 2020 22:15:56 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.107) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 20 Jul 2020 22:15:57 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dLZIIaz5zUzum8ZqqouFElE7UYLh+qnhMj4xd6GyqcLbu55zgDnb9HGlwELRqYyKUa5Ph6gP+bn+TxhQ97lW9iQQGiKKfFreXyxAkAOcO+WoFJ1rrb/YLVQvDw8sIhfRoWj81yu+nnTjGSAW7IrIIQ+8b+HZc02044x1LfG7v7QWrp7/FidB+PnBcbD3k5DUwbVTUkZTDJJQt5fTiZOtBdSE+QTp4AKHj02hwZD5x0ZyEQ2iDD/bWITmaF3orIDeLO39DgxYoR8vxXzhjwIpd4dn1qW8WaRWzQHdMVUZHvSQvtNocGon/RFPdwxnIah7ZdFj0ZMxeIr9FduIOY5yNA== 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=0J0QJ0mMmpfyD0sL/K+3TFXniPA1gtWtm/8HucLE9f4=; b=En+h256RcQ16TWvRaynDDUWDI3Un7tnW8mQcsp6TBiVPokMYBWw/WWOsYwWrd9He6UhCpVciaQ+qljrNmP+b48s4VcjfBNDn7Q7fzImi4dfuNz3embhKdj0PTnSvyZMDxIOa06s6WLa3h/um5CBP7gS2iJKeU/URlZbnuNdapEXjsy7B6u59TC+CcM69vBu0NOD3xFGe+a58VdaG0LCJoGF5w73E8NMi4Qp6/m9aV/cAa2MMk5e7oVgN7K0kcOlrUgFDj+arWwMJ7eRLNAfE0LL6c8a5VSaI5t/0g+wRJTygKFzGZGSq+pSMlWXxC4R/C3P1pCvBapt5WC0Cgqs/eA== 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=0J0QJ0mMmpfyD0sL/K+3TFXniPA1gtWtm/8HucLE9f4=; b=rsmNfblOxFX1yglNSdGbEENj54BxtIh1GlqZq0zJMHlwWVT+VY1XtqAUZLm/gTJklcWFlw9tDK7ieLn/9XE6IFxwtJVFPVXSRIlJSirBrTFsHQ1D4rRQTHIESDP8egBTawaJWwT1y8BHjyceD4ESTdQpnc94tgMLXTg69fKBIAg= Received: from CY4PR1101MB2310.namprd11.prod.outlook.com (2603:10b6:910:1b::16) by CY4PR11MB1430.namprd11.prod.outlook.com (2603:10b6:910:b::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.23; Tue, 21 Jul 2020 05:15:55 +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.3195.023; Tue, 21 Jul 2020 05:15:55 +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+wLUK9TegiOOkDMqkQm3iAgADTONA= Date: Tue, 21 Jul 2020 05:15:55 +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.219] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9929bdb4-5171-4852-8fb9-08d82d35257b x-ms-traffictypediagnostic: CY4PR11MB1430: 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: G61EajIwv7PVKO80uLfZ+CLLViv2U/67cUiOrwmH4DY62B6AkaAUbcUuoQkFrPVMGan12Uket9Ke51aIEfH/IYMqKF2L0EHF9ulke0RcJLsf+9pCFcY9N1QHBBKcAf855JLEaZcc7c1e4lLhwTxEGFeTAkUOfKTYGH/tLLKaDgvibq/E9JHuw2zQwT3ExObbOgnoNYLAz3A5zV2irlD1j8ZE71E9vUcZQzOHt3zqxrngIiVfYJcHhqbz8KoGIyNeJ6dmoh2nVgdp4HV6GFaORHNSlGEQU1h8vCDLVjIWPmcjRnX5IQLzrozM9dLJQGDm 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)(376002)(396003)(39860400002)(366004)(6506007)(71200400001)(53546011)(8676002)(66446008)(7696005)(2906002)(33656002)(186003)(66556008)(66476007)(9686003)(64756008)(8936002)(5660300002)(55016002)(26005)(52536014)(76116006)(83380400001)(66946007)(478600001)(450100002)(4326008)(316002)(110136005)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: lmh+0i23zWEuTHL7Bv7iZV5HpbC+XA4L4ZulYI5GBSlDSlsK9m/GtVTR4IfKtGlwBYWLQS4k6c7MP00G2IGzMbyqKZv7/4+Cy33Oa/gX8zbd9DfJw3fcAKs/i2ZWpOBRZvX8oD2cKLqrOepLtkrZLV7c25+WpWUBuL2REBkp2ztiuAL1QXhW6eEO+mJm3MeZq2LlZN5JOTiVVMwkMuARmo1GW4GCnfPQpz4u61/KflKu/teWmamJ1EqE/mWE4xe5ya0skAZVJZc1xVL/Bhd7fobq33mXQf07mKczRcgx3N4djpmqdJE/RCibpAsrqa2vhA/JWs6VxImJDi/NVcRP/JmjoT6jO4FeZYS2W4YJs6rQ0VZ7l0k/GD9foVpAg6A62PWE6DXnkneCClTKHqCZizp5ns77tp5ttZTRc3iZykg8cApAMrDh3EG0sKIUR0yeUJOksyDJ2FkKz+j0EZWgIi9MmwcX9hdM8AHEDrZHR4mxrR+nqwgUcaY6SrqejJHW 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: 9929bdb4-5171-4852-8fb9-08d82d35257b X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2020 05:15:55.7461 (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: YwSC2OiU+ZBdAfcjBdHkI9F2Gj2X6DRqDAjQ0uh5a110/dg5fSNcXHJeFyzmg5A5MmuGym4dPm7dsxBel7O+MQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1430 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" Archived-At: List-Archive: 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 >=20 >=20 >=20 > > -----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 >=20 > Hi Ting, >=20 > This fix is breaking the execution for systems with cache line of 128 byt= es, 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. >=20 > 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 >=20 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? >=20 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 compi= ler in my and the reporter's case. I tried to add a 32 bits pad field after the field next manually, and the r= esult is correct then. Is it because in 32-bit system, the compiler will not extend the 32 bits po= inter 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 To be honest, I do not know why we should run softnic on 32-bit system, I w= as 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 s= oftnic in 32-bit system now. Or we should fix this issue this time and disc= uss about the problem later? Thanks! > Thanks, > Cristian