Patch Comment List
List patch comments
GET /api/patches/74595/comments/?format=api
[ { "id": 116476, "web_url": "https://patches.dpdk.org/comment/116476/", "msgid": "<BYAPR11MB2935565CF64827508D474F16EB790@BYAPR11MB2935.namprd11.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR11MB2935565CF64827508D474F16EB790@BYAPR11MB2935.namprd11.prod.outlook.com", "date": "2020-07-22T08:26:48", "subject": "Re: [dpdk-dev] [PATCH v4] lib/table: fix cache alignment issue", "submitter": { "id": 19, "url": "https://patches.dpdk.org/api/people/19/?format=api", "name": "Cristian Dumitrescu", "email": "cristian.dumitrescu@intel.com" }, "content": "> +#ifdef RTE_ARCH_64\n> struct rte_bucket_4_32 {\n> \t/* Cache line 0 */\n> \tuint64_t signature[4 + 1];\n> @@ -46,6 +47,22 @@ struct rte_bucket_4_32 {\n> \t/* Cache line 3 */\n> \tuint8_t data[0];\n> };\n> +#else\n> +struct rte_bucket_4_32 {\n> +\t/* Cache line 0 */\n> +\tuint64_t signature[4 + 1];\n> +\tuint64_t lru_list;\n> +\tstruct rte_bucket_4_32 *next;\n> +\tuint32_t pad;\n> +\tuint64_t next_valid;\n> +\n> +\t/* Cache lines 1 and 2 */\n> +\tuint64_t key[4][4];\n> +\n> +\t/* Cache line 3 */\n> +\tuint8_t data[0];\n> +};\n> +#endif\n> \n\nHi Ting,\n\nYes, it looks good, but as mentioned previously please do the same on the other files in the same folder and add the changes to your patch, as we need to keep all these files in sync:\n\nrte_table_hash_key8.c, struct rte_bucket_4_8\nrte_table_hash_key32.c, struct rte_bucket_4_32\n\nThanks,\nCristian", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 7FF28A0526;\n\tWed, 22 Jul 2020 10:26:58 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 32F611BFD1;\n\tWed, 22 Jul 2020 10:26:57 +0200 (CEST)", "from mga18.intel.com (mga18.intel.com [134.134.136.126])\n by dpdk.org (Postfix) with ESMTP id C598A1BFBA;\n Wed, 22 Jul 2020 10:26:55 +0200 (CEST)", "from orsmga001.jf.intel.com ([10.7.209.18])\n by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 22 Jul 2020 01:26:54 -0700", "from fmsmsx103.amr.corp.intel.com ([10.18.124.201])\n by orsmga001.jf.intel.com with ESMTP; 22 Jul 2020 01:26:54 -0700", "from fmsmsx161.amr.corp.intel.com (10.18.125.9) by\n FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Wed, 22 Jul 2020 01:26:53 -0700", "from FMSEDG001.ED.cps.intel.com (10.1.192.133) by\n FMSMSX161.amr.corp.intel.com (10.18.125.9) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Wed, 22 Jul 2020 01:26:53 -0700", "from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.174)\n by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id\n 14.3.439.0; Wed, 22 Jul 2020 01:26:50 -0700", "from BYAPR11MB2935.namprd11.prod.outlook.com (2603:10b6:a03:82::24)\n by BY5PR11MB3943.namprd11.prod.outlook.com (2603:10b6:a03:185::17)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Wed, 22 Jul\n 2020 08:26:48 +0000", "from BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061]) by BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061%3]) with mapi id 15.20.3195.026; Wed, 22 Jul 2020\n 08:26:48 +0000" ], "IronPort-SDR": [ "\n vpkkUbuu3DaJ/3VCuX9tHzBUfBzu3N7x2OcWSLEF//IEQ+9qC4sZuneNR2XduE4MAhyGAftW3+\n hGX5fG5jIXyg==", "\n Db0ZNMeuQO66nclgEeHtyjg2lSh5a13MQTK5JrYeaVfk+b6dLNgBiDZnicNR8n2Tl9UNqMv7mh\n DHm3NR8np9IA==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9689\"; a=\"137795384\"", "E=Sophos;i=\"5.75,381,1589266800\"; d=\"scan'208\";a=\"137795384\"", "E=Sophos;i=\"5.75,381,1589266800\"; d=\"scan'208\";a=\"362645247\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=i2AJscWhxZIY1RBUwHE3bNjul3oN9T073MZPXedqRPNi6Omvq61W1tCCRlzXx0FZS+KnaIVFXgfrGaWyW3URBL6JuiSscuGNvJ1kYfIdnwH+uaXecbxXdO6ef0naglAQGbxZTKqDSXQLt85qCvrrrXZQJGvcHKmN8UCbPE3cPpaGqQEIvPdyyDuxUpxcUYw8odHHSDgYaLvS/DUsrNBKIx2aQNzy0tFDQ+C1MpB+OGzcTA8QARGQTOX9HqdY6qfNYA2hcHEq+97AzE1mgKAzNGdVIVeeYv0PvgIu1gQnUkukqQ6VYlpWUsWsiEGt8lAO6l+WAyd1y50+s03OftloUg==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=JOx5LjY1pG092/xsnqYxk4igM/WQgfnP5rEBWQmxTWA=;\n b=PchykL4SV9f2wfKI7e7f5VngTAnVEcvx2LhPy3brCOT5ob81QuXlACb8Z/3ow6qmf0QbBirWtsKzz73FI9wRW2wkfGUhdW9ZhBP6KR0M0EYkq2vbVhDmyOsOy3s/APQ390h4/omfUwthx/ULOuDLz5HTOSOsUB9dNVE4RYp6GX7LCQtRlY1ibMttmxGbgVXv4OcLc7VzWQhsYz+sMf6lfU1vsHOt+wAHj24vu++ef9KnvXU1QLLAD0ET9V3gqTqs7Z3BkNYQeczoaF52woBkE68xDXBkPuzYe26CHsr44ZUW6IiKM/3wxekvMwTpLybI1HDhiS1TIhsGiX4gvSAGTg==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;\n s=selector2-intel-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=JOx5LjY1pG092/xsnqYxk4igM/WQgfnP5rEBWQmxTWA=;\n b=q98u9/4j3U05RleNGGZeaSOxVJ+axqUJ4ch4EtSMdNDVXWDVyoPvtCIMDvMPZUibHGmbgydmAYO0ew3cpr7O+6XGMBfY1LYu6lwfLsBqiL1X2u9bcTxSvPlfyw2UpgBqHnmr3vDbKSzGC5W7xaSjmoMwYM1zX7HSE9vabZFUP08=", "From": "\"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>", "To": "\"Xu, Ting\" <ting.xu@intel.com>, \"dev@dpdk.org\" <dev@dpdk.org>", "CC": "\"stable@dpdk.org\" <stable@dpdk.org>", "Thread-Topic": "[PATCH v4] lib/table: fix cache alignment issue", "Thread-Index": "AQHWX82i+KTf+DtoXESWs1iJ7M+JEakTQuIA", "Date": "Wed, 22 Jul 2020 08:26:48 +0000", "Message-ID": "\n <BYAPR11MB2935565CF64827508D474F16EB790@BYAPR11MB2935.namprd11.prod.outlook.com>", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>", "In-Reply-To": "<20200722021628.17194-1-ting.xu@intel.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "dlp-version": "11.5.1.3", "dlp-reaction": "no-action", "dlp-product": "dlpe-windows", "authentication-results": "intel.com; dkim=none (message not signed)\n 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": "94b91c8d-bb07-4c47-3969-08d82e18fa49", "x-ms-traffictypediagnostic": "BY5PR11MB3943:", "x-ms-exchange-transport-forked": "True", "x-microsoft-antispam-prvs": "\n <BY5PR11MB3943CC8293BF2BD8DA3E9D4BEB790@BY5PR11MB3943.namprd11.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:8882;", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam": "BCL:0;", "x-microsoft-antispam-message-info": "\n DFPmLFo/zzfVNQDCHsc4X3z59hAysylJV95kNSn/ir3+4TToMYrpSp0/+aNnX37S7rsipXnFOGD/dkI5+64mHzsWgoC7tfSemVrM5SFVH2dD4kvv4A+YlgjuXOyQMbBRptcL0xrceRQBiCQjWobrnuB0pWJAYRQXBfPNQnXNiylGdncfn/5SCQxeDOP9zpPBEvcFkrGHpKoMQ+884AcjWKIfoYQqPU6guGeH74gwXOnXkR9C2Gx25knB2P3FBqx9ZrTXfjYRcnUMFbiov+8u8FI26OOZMgOlBaE3ma5vL5kl4cuHcrdnJKPtpgWwSUr1", "x-forefront-antispam-report": "CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BYAPR11MB2935.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFTY:;\n SFS:(4636009)(366004)(39860400002)(396003)(376002)(136003)(346002)(33656002)(26005)(316002)(110136005)(71200400001)(8936002)(4744005)(2906002)(86362001)(5660300002)(4326008)(66556008)(450100002)(52536014)(7696005)(66446008)(478600001)(9686003)(55016002)(8676002)(186003)(76116006)(66946007)(66476007)(6506007)(64756008);\n DIR:OUT; SFP:1102;", "x-ms-exchange-antispam-messagedata": "\n WJ9ATAq7FcsYXF3rtSgY9ovn2FjDDXnbtfcv3mEKc+eKDZPXnd1onb5pqMI4wN8lRLfng6d2z+ppA7lp4Nj3Pikd7qAqrEQRCES6VnIqapbZiBpVEAsT4FfKL+zJEW9h9B8nBItEUhvGIwUFVoDKrHrBTWTAimA3WRSvkxBwLKOdFCvSmpBn1GA7be/ZbbotxdRMZDb5+Dpejv4SBDG/MOftkkDhD1IebWnHwWGlAheQB9oShwdg1mU8/la9qz8hFd3YkmLHznCyCMH+dxmmmQHib2Mw7ewYVAa0X/oZXN/p4cct4WGP5FtTLsNgE8CU7gWKlriO7fJhTCvD3HnjWq0WOrTseQiKGdUcN/119978bDSXfAXzlsKx3lrHngIHHed1lSWLWaP+RyGFHVKKGw5kBPPIUFAq3QubH7PqXL8KQ9JUrdN6TvxCfg8VNCPIdsUGCxBz+6XXXbT0BsFzbSTfoOPtVGqY95j2CdgvD1Y=", "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": "\n 94b91c8d-bb07-4c47-3969-08d82e18fa49", "X-MS-Exchange-CrossTenant-originalarrivaltime": "22 Jul 2020 08:26:48.3922 (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": "\n MjBgqhdIbZY2kHfuHpRlun8N6ch3Yh6qX+ADMIB78YiDBg9WttPNBR6UqbtW5Z09rg0DXxDOCMrJn7komEV8UyJHc5vxpXfRek5D3EU9wEw=", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BY5PR11MB3943", "X-OriginatorOrg": "intel.com", "Subject": "Re: [dpdk-dev] [PATCH v4] 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 <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116477, "web_url": "https://patches.dpdk.org/comment/116477/", "msgid": "<CY4PR1101MB231015070338C942BE9013D5F8790@CY4PR1101MB2310.namprd11.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/CY4PR1101MB231015070338C942BE9013D5F8790@CY4PR1101MB2310.namprd11.prod.outlook.com", "date": "2020-07-22T08:30:41", "subject": "Re: [dpdk-dev] [PATCH v4] lib/table: fix cache alignment issue", "submitter": { "id": 1363, "url": "https://patches.dpdk.org/api/people/1363/?format=api", "name": "Xu, Ting", "email": "ting.xu@intel.com" }, "content": "Hi, Cristian,\n\n> -----Original Message-----\n> From: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>\n> Sent: Wednesday, July 22, 2020 4:27 PM\n> To: Xu, Ting <ting.xu@intel.com>; dev@dpdk.org\n> Cc: stable@dpdk.org\n> Subject: RE: [PATCH v4] lib/table: fix cache alignment issue\n> \n> \n> \n> > +#ifdef RTE_ARCH_64\n> > struct rte_bucket_4_32 {\n> > \t/* Cache line 0 */\n> > \tuint64_t signature[4 + 1];\n> > @@ -46,6 +47,22 @@ struct rte_bucket_4_32 {\n> > \t/* Cache line 3 */\n> > \tuint8_t data[0];\n> > };\n> > +#else\n> > +struct rte_bucket_4_32 {\n> > +\t/* Cache line 0 */\n> > +\tuint64_t signature[4 + 1];\n> > +\tuint64_t lru_list;\n> > +\tstruct rte_bucket_4_32 *next;\n> > +\tuint32_t pad;\n> > +\tuint64_t next_valid;\n> > +\n> > +\t/* Cache lines 1 and 2 */\n> > +\tuint64_t key[4][4];\n> > +\n> > +\t/* Cache line 3 */\n> > +\tuint8_t data[0];\n> > +};\n> > +#endif\n> >\n> \n> Hi Ting,\n> \n> Yes, it looks good, but as mentioned previously please do the same on the\n> other files in the same folder and add the changes to your patch, as we need\n> to keep all these files in sync:\n> \n> rte_table_hash_key8.c, struct rte_bucket_4_8 rte_table_hash_key32.c, struct\n> rte_bucket_4_32\n> \n\nI have did the changes to 8 and 32 bytes in this patch.\n\n> Thanks,\n> Cristian", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 09BF1A0526;\n\tWed, 22 Jul 2020 10:30:49 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id AE8BF1BFD1;\n\tWed, 22 Jul 2020 10:30:47 +0200 (CEST)", "from mga09.intel.com (mga09.intel.com [134.134.136.24])\n by dpdk.org (Postfix) with ESMTP id 8B82B2B86;\n Wed, 22 Jul 2020 10:30:45 +0200 (CEST)", "from fmsmga002.fm.intel.com ([10.253.24.26])\n by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 22 Jul 2020 01:30:43 -0700", "from fmsmsx105.amr.corp.intel.com ([10.18.124.203])\n by fmsmga002.fm.intel.com with ESMTP; 22 Jul 2020 01:30:43 -0700", "from FMSEDG001.ED.cps.intel.com (10.1.192.133) by\n FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Wed, 22 Jul 2020 01:30:43 -0700", "from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.177)\n by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id\n 14.3.439.0; Wed, 22 Jul 2020 01:30:42 -0700", "from CY4PR1101MB2310.namprd11.prod.outlook.com\n (2603:10b6:910:1b::16) by CY4PR11MB2023.namprd11.prod.outlook.com\n (2603:10b6:903:30::11) with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.24; Wed, 22 Jul\n 2020 08:30:41 +0000", "from CY4PR1101MB2310.namprd11.prod.outlook.com\n ([fe80::2497:a5ff:5152:7782]) by CY4PR1101MB2310.namprd11.prod.outlook.com\n ([fe80::2497:a5ff:5152:7782%10]) with mapi id 15.20.3216.021; Wed, 22 Jul\n 2020 08:30:41 +0000" ], "IronPort-SDR": [ "\n oTFxI8yEayfk5ZZlZYBh3DC4QZLOt/Yu9AG2OJQOrpD79HH2aqb2jjF8fFpFLpAZG/cbBm8WAk\n /C7H49WqVdlg==", "\n bVOYb/Jcp7Z/TZ6vIVJZn9/PgA3e0PFUousioWXC3fqFpWHpH1Ez9myjp/T6BuQHaHCspqykfb\n nnedChSCAc6Q==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9689\"; a=\"151616755\"", "E=Sophos;i=\"5.75,381,1589266800\"; d=\"scan'208\";a=\"151616755\"", "E=Sophos;i=\"5.75,381,1589266800\"; d=\"scan'208\";a=\"320201119\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=JMpeVCcEt2WP4zKUhgWlyhhALSH59X6Eczljlj3CFKaQpzzVJAByVs8VS7KgTS1nY3CnvHfWHOi/nV5B6qn7fBpYa8UrmcGPA4kZay7pFiz2vHo78e5atWTBEmNVu9TvVY2GwhVc55ofBnTskvgtJxLWT34fCQTLK4dAgPB/tMuJkguaIVKzhBneDFM6u+1mooEC3yepBMtkYK365qNKbdANtFnls1lXYKnQN/UaZ32gCtBgO+wcONz8z3jdppdtLSO5SdfdKF8q1madYHBvOoJtOoqxg9kYBruNwdnkpa9fBB/tOiZQZK3cXBvchKgMZZQSxOmmrx/fSdFFoLDixA==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=UVMyUKpnmArsa9f/M3btqXBq+LFPh1WcamS+HPpW2ak=;\n b=VE5Q4AKw5aPXPAh7fHQ5QDagPzrDNPDBqPBOYi7gGbe9SJijBD1xnOFTEhQwGvSVnoKQU7iLqTBHkwcwiZNPboQmOjWeVy031qX6tBBZF7JKZMFpZgy1Z/yYH5CAvBR6jo5gl+X+WqvCyhYLTubEhEpgFrRdLXAHWJjg5oIJSCBYSXp2PGqhS6vLD0jyS6umTyINy2oTtr0YaZAlBepXZuq/g8uDkmR5n8M2I9iBbtFcdbDQBYer5T/Cd9w5TtlJZrElUmtgkL0HOjLMqiPS4EeD2d6vSVP+syDMO4e7wf3uHwK7GblbapgxShkqMSPTGtjxY4403qoEIW38c3Vn+w==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;\n s=selector2-intel-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=UVMyUKpnmArsa9f/M3btqXBq+LFPh1WcamS+HPpW2ak=;\n b=krIqSYZZ0H7b4RuRBu1W54QyhkPZ1U46RbZyYRCYf4a3PrW7rCr5EE+/S/DYBvj0/9VTUR//Wz0rpeQ3UQ97FgzMHUu4Jo/Nu8N2M79MzPS+dWfSG3FEeOqXTbtk/pYySGaus9EKeLi698gs9kvn0iHe9WYIuDqN/TBhzLAFYCk=", "From": "\"Xu, Ting\" <ting.xu@intel.com>", "To": "\"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>, \"dev@dpdk.org\"\n <dev@dpdk.org>", "CC": "\"stable@dpdk.org\" <stable@dpdk.org>", "Thread-Topic": "[PATCH v4] lib/table: fix cache alignment issue", "Thread-Index": "AQHWX82iNlqzroybpk6bRvdW1k5beqkTRBMAgAAAweA=", "Date": "Wed, 22 Jul 2020 08:30:41 +0000", "Message-ID": "\n <CY4PR1101MB231015070338C942BE9013D5F8790@CY4PR1101MB2310.namprd11.prod.outlook.com>", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <BYAPR11MB2935565CF64827508D474F16EB790@BYAPR11MB2935.namprd11.prod.outlook.com>", "In-Reply-To": "\n <BYAPR11MB2935565CF64827508D474F16EB790@BYAPR11MB2935.namprd11.prod.outlook.com>", "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)\n 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": "1aa4c6e6-df7b-42ee-5f74-08d82e198536", "x-ms-traffictypediagnostic": "CY4PR11MB2023:", "x-ms-exchange-transport-forked": "True", "x-microsoft-antispam-prvs": "\n <CY4PR11MB20236D540F9E760AD2B77C6FF8790@CY4PR11MB2023.namprd11.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:8882;", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam": "BCL:0;", "x-microsoft-antispam-message-info": "\n /7O5zfFHGKUWYheSgYbPxtFC4uzLNMyqRw5HW1KgWFQC4ayG8c1sPP0mLwssjJeL3mmmNILdMlpXXplaj62qTNh7xM7KVyWKa+AJFIIhGKnDsTdPqacCTF/G3GtTz6+UJRcwaBzcZaZjsISJRIa1y+oneRTqkkcYLPK36PMSE4zVN8weK2NXW+aKpu+bMbuLZLIG/ZC4SK/jGpFI4v6qmhe0cImYWKBJx/Wrq+j/1S66Wsl9flS0KUz42PG3J3jvdw7zsbyxwQYCDztlFq46Lhl2/2AlpXdsmog3LnKx7JwC7dJ26+yGIwvUnmMuZ7hr", "x-forefront-antispam-report": "CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:CY4PR1101MB2310.namprd11.prod.outlook.com; PTR:;\n CAT:NONE;\n SFTY:;\n SFS:(4636009)(376002)(136003)(396003)(366004)(39860400002)(346002)(71200400001)(52536014)(8936002)(9686003)(5660300002)(478600001)(66946007)(66556008)(64756008)(2906002)(66446008)(110136005)(186003)(66476007)(55016002)(76116006)(83380400001)(33656002)(86362001)(316002)(26005)(53546011)(6506007)(450100002)(4326008)(7696005)(8676002);\n DIR:OUT; SFP:1102;", "x-ms-exchange-antispam-messagedata": "\n 0JihdrBcOu6t4PHjdWwC1VGGCnWnh6/tFfKhorHNLNvrzRonVCpgGH9t1IMzYenlqxAxRL2mxmd2SRnglQ95tZWffBtNlYphQ+hVr7ie0yzzkB8/DzBstTmNGX7ReguBMGydnTkgBxreJLsMJMCGyBZclcYa3eMocNRDwc2KFRWgaC6eGmCqJrXvRb4KSWePM6kGW52CBwgC6wwnrneQlEYpRhgR/Ty+TlgMZZFyFvRkBI4nPYt5t/M1jh6yqyKnyHHffCABNpSU1YjWkBZMV3CAww3wZk2bucItGqxNhSMt2p8xCfhOkkIGlCF9zNOIHDItyEaryDhKSfSOvoGf+GmhaVIG2DkTk9IDxEokfgYquKrBWZb4Ws/G8whTyI4A1GJI4YBo1tNNJkLQY8TyGVEB9MS0h/K1j1gMAhhvLSNkEQsKIPBa8+Nbw41dNSi/FUtBcw1IHlTISIE94WV4Bt1X1q3VTamvXYfUixOSVyxiKZaem/GSrTprzr+6Wefp", "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": "\n CY4PR1101MB2310.namprd11.prod.outlook.com", "X-MS-Exchange-CrossTenant-Network-Message-Id": "\n 1aa4c6e6-df7b-42ee-5f74-08d82e198536", "X-MS-Exchange-CrossTenant-originalarrivaltime": "22 Jul 2020 08:30:41.5658 (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": "\n bj1TErEfPwlOthzmH46iB4rp8JExeMYlF64kncw+Bnrmr3Ez93PRf6QGQ7kVog8UbeG+JfX8U+EzCEvEQZFGzw==", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "CY4PR11MB2023", "X-OriginatorOrg": "intel.com", "Subject": "Re: [dpdk-dev] [PATCH v4] 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 <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116479, "web_url": "https://patches.dpdk.org/comment/116479/", "msgid": "<BYAPR11MB293580093EB11C87837FAFE1EB790@BYAPR11MB2935.namprd11.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR11MB293580093EB11C87837FAFE1EB790@BYAPR11MB2935.namprd11.prod.outlook.com", "date": "2020-07-22T08:48:58", "subject": "Re: [dpdk-dev] [PATCH v4] lib/table: fix cache alignment issue", "submitter": { "id": 19, "url": "https://patches.dpdk.org/api/people/19/?format=api", "name": "Cristian Dumitrescu", "email": "cristian.dumitrescu@intel.com" }, "content": "> -----Original Message-----\n> From: Xu, Ting <ting.xu@intel.com>\n> Sent: Wednesday, July 22, 2020 3:16 AM\n> To: dev@dpdk.org\n> Cc: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Xu, Ting\n> <ting.xu@intel.com>; stable@dpdk.org\n> Subject: [PATCH v4] lib/table: fix cache alignment issue\n> \n> When create softnic hash table with 16 keys, it failed on 32-bit\n> environment, because the pointer field in structure rte_bucket_4_16\n> is only 32 bits. Add a padding field in 32-bit environment to keep\n> the structure to a multiple of 64 bytes. Apply this to 8-byte and\n> 32-byte key hash function as well.\n> \n> Fixes: 8aa327214c (\"table: hash\")\n> Cc: stable@dpdk.org\n> \n> Signed-off-by: Ting Xu <ting.xu@intel.com>\n> \n> ---\n> v3->v4: Change design based on comment\n> v2->v3: Rebase\n> v1->v2: Correct patch time\n> ---\n\nAcked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 497F6A0526;\n\tWed, 22 Jul 2020 10:49:07 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 866811BFEB;\n\tWed, 22 Jul 2020 10:49:05 +0200 (CEST)", "from mga04.intel.com (mga04.intel.com [192.55.52.120])\n by dpdk.org (Postfix) with ESMTP id AF7832C6E;\n Wed, 22 Jul 2020 10:49:03 +0200 (CEST)", "from fmsmga006.fm.intel.com ([10.253.24.20])\n by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 22 Jul 2020 01:49:02 -0700", "from fmsmsx603.amr.corp.intel.com ([10.18.126.83])\n by fmsmga006.fm.intel.com with ESMTP; 22 Jul 2020 01:49:02 -0700", "from fmsmsx610.amr.corp.intel.com (10.18.126.90) by\n fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.1713.5; Wed, 22 Jul 2020 01:49:02 -0700", "from FMSEDG002.ED.cps.intel.com (10.1.192.134) by\n fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5\n via Frontend Transport; Wed, 22 Jul 2020 01:49:02 -0700", "from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169)\n by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id\n 14.3.439.0; Wed, 22 Jul 2020 01:49:00 -0700", "from BYAPR11MB2935.namprd11.prod.outlook.com (2603:10b6:a03:82::24)\n by BYAPR11MB3240.namprd11.prod.outlook.com (2603:10b6:a03:18::19)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Wed, 22 Jul\n 2020 08:48:59 +0000", "from BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061]) by BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061%3]) with mapi id 15.20.3195.026; Wed, 22 Jul 2020\n 08:48:59 +0000" ], "IronPort-SDR": [ "\n 6Ss2ezq7oPvAfMDNN1uQ6UCtL/OP4+LK8vbbCvJLtz+6CWzwxHh4CCy7K7p9v+AXTH4Ay9Vp6L\n OvRym+HBSiPA==", "\n Iccy/VSJDxUjdp9r5eRsBq7Jw/wNdZZp2dQdvqufduwTdpuE7DpEbvJJoQ1qR+1/x726UUAEdc\n MCamNHcbzEZQ==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9689\"; a=\"147789818\"", "E=Sophos;i=\"5.75,381,1589266800\"; d=\"scan'208\";a=\"147789818\"", "E=Sophos;i=\"5.75,381,1589266800\"; d=\"scan'208\";a=\"487921758\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=P+gPZxKuds/8JQq/wSEUbXAQpQ5deWncHdJu2+QESbteLI32PLdF2du/rU8CkIp8nuyy5/m2OES/Nxv23+GQB/28D6LiSni4PJEORmzMmv/hJ/szvaeTVgJGlB/un4Kp2lrj9Hi9yWKtIuqmCZPWA5hioU/7CdqPi4vnDohoF15ZRxDIX+2ZveiHcxdURFYQSDVONJDAiDNN8OLKwO5gxn7OCfzUQu2mC0XU7tAn4nLtDijM995z13p1V6cDERTx5Ha5xptfEyef0izIXWDOs+6Dp2pSLOEmiQVeU5C12q/8w1EGUeSqJozjyKiIFzjNmZIKNawURgous1w9/Yljvw==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=f50+PTLSDxASz7q95MCDSJK4gkukVUt6ILAL08V1wjc=;\n b=nfu9W4uumeDiytrUUThNGpY9s/pTBc0Tly0Rdt3vf2fhv7KFIMJUigONUviHpgs6S7BJRjbEdHjVN7QgGy8bKaVqQVQ7w02pbr1V2mdBN7II/x8R3SMCI7V+ubXkLPAx1X1hXQ+F/o0u/afcudqNyUFEbNGywbqa0LQ1cS2po2AR0zG5mHvS4vHltFmnG0Ks2l8dvg9O5RrElhFwHYMtz0Mcci12Sf9qqGEQ4jQ7DE1gv7ePo8wHAF0kz0OhfHUwcu5Eqn5ybJdnAFecZzGwkPsrh7yDamdBUWPkIOUGk41Apy/GTHUc4icP4eJEdgR1RwhFL6uzGy6B5GchjRUK/A==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;\n s=selector2-intel-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=f50+PTLSDxASz7q95MCDSJK4gkukVUt6ILAL08V1wjc=;\n b=C/QMtcf5ZJ8sTgkfYmsLy3zZWDm8Hd3ms1q+rVmGAyKlkzza3F8+gjp0KOIJSpEgoVY3v7DxAT+hWg9dctuJpgg459oCSY9C6L9x+QcvzIqA0we9pt2F16/uH4ZcfVMOALcx4YeoydMPIPlf4OcEyelZy0ZxQHjW8FrSuj2aAW4=", "From": "\"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>", "To": "\"Xu, Ting\" <ting.xu@intel.com>, \"dev@dpdk.org\" <dev@dpdk.org>", "CC": "\"stable@dpdk.org\" <stable@dpdk.org>", "Thread-Topic": "[PATCH v4] lib/table: fix cache alignment issue", "Thread-Index": "AQHWX82i+KTf+DtoXESWs1iJ7M+JEakTShgw", "Date": "Wed, 22 Jul 2020 08:48:58 +0000", "Message-ID": "\n <BYAPR11MB293580093EB11C87837FAFE1EB790@BYAPR11MB2935.namprd11.prod.outlook.com>", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>", "In-Reply-To": "<20200722021628.17194-1-ting.xu@intel.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "dlp-version": "11.5.1.3", "dlp-reaction": "no-action", "dlp-product": "dlpe-windows", "authentication-results": "intel.com; dkim=none (message not signed)\n 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": "a4339709-b68e-4d2a-0e66-08d82e1c134d", "x-ms-traffictypediagnostic": "BYAPR11MB3240:", "x-ms-exchange-transport-forked": "True", "x-microsoft-antispam-prvs": "\n <BYAPR11MB3240B2C0840B6F5D995B5912EB790@BYAPR11MB3240.namprd11.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:3383;", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam": "BCL:0;", "x-microsoft-antispam-message-info": "\n BIjMSd27z76VwePQGHovvmr7ngtA/QsZ+T+vBStUVVqvUjMhbRfsr/4Le8SFvRW001iPTsOJwefI3ZZPkoGuz6fBwK63kiaaSSUP6r7BGcU617c/dqNYytWSTQz6UcFBdzT8ciV755DxsZpM/IoFui6mFxp9w81vZ4TtI9lVYx6nRyAW9xaydB14qaovBAlZlju9eVrcdZF3OgWmcEOZTMRjPcNNCi2YdEGzLof/c8ZQbibzLAL3h6QxXOWpqnlA7Xygo/OtyMQvJQ95W5pE4fUmelORFlgsu4y92x9Mtlojh7vSIG+4uFeP6CRRHW89MNH5j6KE9mE51Lc74KNoVg==", "x-forefront-antispam-report": "CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BYAPR11MB2935.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFTY:;\n SFS:(4636009)(39860400002)(396003)(366004)(376002)(346002)(136003)(26005)(33656002)(316002)(110136005)(71200400001)(8936002)(2906002)(86362001)(4744005)(5660300002)(4326008)(450100002)(52536014)(66446008)(7696005)(66556008)(478600001)(8676002)(55016002)(9686003)(186003)(76116006)(66946007)(66476007)(6506007)(53546011)(83380400001)(64756008);\n DIR:OUT; SFP:1102;", "x-ms-exchange-antispam-messagedata": "\n 7E0pVtjm0ppCZvmtHa4bSfvmLNRme0pqtGN1wrnCJxDmUfu3IEltuEujk10bWMFxDcABZhvuBoOJlb4MRJsSxuiLPQA8n176Jk8PnsNiIAB07FU+TKDDz6GNc5nBvlIhKsngrz6QY+iexJZiohbbsE5q4LYhOBRyVVfXisetG8yJDyL1BLbtfAs4JetF4FKJsoSiUTRQfRCGv++rjnN1nHEEouzmcojZtfq486ItfYh+qDeKnHSgzJUMbhywrLEcN32rWAY5rDzCnntWLqWWjrQu6D2gb6EI0NzJRLxx/yshrNm9KOcctkDB1HizZp3EkMqxlUbx6pQ3y3jFULZqANAD/tCD6sj56HwWUGIFRgaYESk4XxD1x5f1uBh8OmyRz9mFAoAUEnsYFqHSVBkmL6RP7kTz9hetUgVOz+0MPU0CrTSrbGHAW2gPbzC40ADkXXjodqRVyS/Jac0LjybDf8T7y8/Gm6iJq9yTRzNj2QM=", "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": "\n a4339709-b68e-4d2a-0e66-08d82e1c134d", "X-MS-Exchange-CrossTenant-originalarrivaltime": "22 Jul 2020 08:48:58.7486 (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": "\n BCXHsESh1JMyJ/ZpmY/VQGt2eRl4gM0oJLgcIPoSGykNrIBiExzu5WaG0K8tvFXwvFVbu+dHgMBpdjxJWYHh0O1yASP92645LdgvwCdMHLo=", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR11MB3240", "X-OriginatorOrg": "intel.com", "Subject": "Re: [dpdk-dev] [PATCH v4] 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 <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116480, "web_url": "https://patches.dpdk.org/comment/116480/", "msgid": "<BYAPR11MB29353625C9B16EABF2713D2CEB790@BYAPR11MB2935.namprd11.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR11MB29353625C9B16EABF2713D2CEB790@BYAPR11MB2935.namprd11.prod.outlook.com", "date": "2020-07-22T08:49:53", "subject": "Re: [dpdk-dev] [PATCH v4] lib/table: fix cache alignment issue", "submitter": { "id": 19, "url": "https://patches.dpdk.org/api/people/19/?format=api", "name": "Cristian Dumitrescu", "email": "cristian.dumitrescu@intel.com" }, "content": "> -----Original Message-----\n> From: Xu, Ting <ting.xu@intel.com>\n> Sent: Wednesday, July 22, 2020 9:31 AM\n> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; dev@dpdk.org\n> Cc: stable@dpdk.org\n> Subject: RE: [PATCH v4] lib/table: fix cache alignment issue\n> \n> Hi, Cristian,\n> \n> > -----Original Message-----\n> > From: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>\n> > Sent: Wednesday, July 22, 2020 4:27 PM\n> > To: Xu, Ting <ting.xu@intel.com>; dev@dpdk.org\n> > Cc: stable@dpdk.org\n> > Subject: RE: [PATCH v4] lib/table: fix cache alignment issue\n> >\n> >\n> >\n> > > +#ifdef RTE_ARCH_64\n> > > struct rte_bucket_4_32 {\n> > > \t/* Cache line 0 */\n> > > \tuint64_t signature[4 + 1];\n> > > @@ -46,6 +47,22 @@ struct rte_bucket_4_32 {\n> > > \t/* Cache line 3 */\n> > > \tuint8_t data[0];\n> > > };\n> > > +#else\n> > > +struct rte_bucket_4_32 {\n> > > +\t/* Cache line 0 */\n> > > +\tuint64_t signature[4 + 1];\n> > > +\tuint64_t lru_list;\n> > > +\tstruct rte_bucket_4_32 *next;\n> > > +\tuint32_t pad;\n> > > +\tuint64_t next_valid;\n> > > +\n> > > +\t/* Cache lines 1 and 2 */\n> > > +\tuint64_t key[4][4];\n> > > +\n> > > +\t/* Cache line 3 */\n> > > +\tuint8_t data[0];\n> > > +};\n> > > +#endif\n> > >\n> >\n> > Hi Ting,\n> >\n> > Yes, it looks good, but as mentioned previously please do the same on the\n> > other files in the same folder and add the changes to your patch, as we\n> need\n> > to keep all these files in sync:\n> >\n> > rte_table_hash_key8.c, struct rte_bucket_4_8 rte_table_hash_key32.c,\n> struct\n> > rte_bucket_4_32\n> >\n> \n> I have did the changes to 8 and 32 bytes in this patch.\n> \n> > Thanks,\n> > Cristian\n\nUpss, sorry, somehow I missed it. I just acked this patch. Thanks, Ting!\n\nRegards,\nCristian", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 6849FA0526;\n\tWed, 22 Jul 2020 10:49:59 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 4783B1BFEC;\n\tWed, 22 Jul 2020 10:49:59 +0200 (CEST)", "from mga11.intel.com (mga11.intel.com [192.55.52.93])\n by dpdk.org (Postfix) with ESMTP id 91EC32C6E;\n Wed, 22 Jul 2020 10:49:56 +0200 (CEST)", "from fmsmga005.fm.intel.com ([10.253.24.32])\n by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 22 Jul 2020 01:49:55 -0700", "from orsmsx104.amr.corp.intel.com ([10.22.225.131])\n by fmsmga005.fm.intel.com with ESMTP; 22 Jul 2020 01:49:55 -0700", "from ORSEDG002.ED.cps.intel.com (10.7.248.5) by\n ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Wed, 22 Jul 2020 01:49:55 -0700", "from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.168)\n by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Wed, 22 Jul 2020 01:49:55 -0700", "from BYAPR11MB2935.namprd11.prod.outlook.com (2603:10b6:a03:82::24)\n by BYAPR11MB3240.namprd11.prod.outlook.com (2603:10b6:a03:18::19)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Wed, 22 Jul\n 2020 08:49:53 +0000", "from BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061]) by BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061%3]) with mapi id 15.20.3195.026; Wed, 22 Jul 2020\n 08:49:53 +0000" ], "IronPort-SDR": [ "\n UtRfdNOl/E6g1lAnlM5CwKP4QjpvN8/VBnu1KQjlJx4b9ZvY+HJ9GcF4PTZsDBzoMX1LCPOifU\n rxJl00gcC75g==", "\n TvoZhHXdVTIQUexBr4pztr0TQL6gGQShL8O4nX486rwoJH6v6ZGZjPfAIzRCcl6hvclSPVd9hw\n ED3cQ8YvJ6Ew==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9689\"; a=\"148227834\"", "E=Sophos;i=\"5.75,381,1589266800\"; d=\"scan'208\";a=\"148227834\"", "E=Sophos;i=\"5.75,381,1589266800\"; d=\"scan'208\";a=\"488389655\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=JtjRw370/SdpYn7ixttmKtoqzWX+VKEUU5Tex9fUxHDp9Q5ELZpm7M1/ntNkP7jsjwvLu73mhRTtDM0B6OWy0Vu/zH15LnmogrA2du0AZk3guZd5tK9sJhYJpSKPIEcwLIEjn8EdT4DBJpvNHOOWFlbVUgqGzVFJoYuC7VOGC+lZ4QyMh63VQTkxp6qFpwws4t4AErvK3VionsDKM51q5cvV6gqa00gr7Ms2wsfFnGVfR1H5QJk2qk6X2RLFA8u8Uk6vgWd3xbSfL609OJ5HhgUrbWQ0SWgOH6GGkKRMc2LEqH689eFO/oa8b5WFuHJ8ajKevnJuifxQ7km53Q/gTw==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=BBoAZEK1Yp9jsFK7Z9MOmXjj8CuU1HPc0PTd1p7q32s=;\n b=CdwSAnEQhzvxDWzCYm2HVmRw2XL+IVezNyhe0YPwfNJpgUrHDLA+xyvc/Xmkps8VahvYaKGIbGfx892jVMfRe/hgC2sFlWb8mpsRlbpTcOrhjri8NE1LKYXp0vFuT78SxhUnQaSIZ0+PsOSTLOAV1IGl3DCY7DbOT8iBILEhO6UlB/k7J+rSJZr0w+ujvyh0yIehfg+OF50jlFAkkR8hl4eS7YaIN10YCyYNZbk4uE57CZKZyQoPht+vTZ0cgQLTED45s+1mS8v//aaTfDvumPLlyIXsKmR+8nfEnKNtqBQuSoh7R3qLgDnigG8paLCRIy0j44RzxvHKZi/ooBt0Rw==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;\n s=selector2-intel-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=BBoAZEK1Yp9jsFK7Z9MOmXjj8CuU1HPc0PTd1p7q32s=;\n b=FprkdHR+NYOHB+10Xv4+IXniOrjKL2A3tvHO/FREQqkc3+ypyyGhBGmsZhbnFa2Vwu3+kG/jDGQ/+6N5cbVTili0KKIMnI3pnE1/9Ezs0yOiizi3ik86tMwXwQgfXpWnlGV73AR6yfD15roA+cMqFhNd4h35QEpWZo2y2tvd01Y=", "From": "\"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>", "To": "\"Xu, Ting\" <ting.xu@intel.com>, \"dev@dpdk.org\" <dev@dpdk.org>", "CC": "\"stable@dpdk.org\" <stable@dpdk.org>", "Thread-Topic": "[PATCH v4] lib/table: fix cache alignment issue", "Thread-Index": "AQHWX82i+KTf+DtoXESWs1iJ7M+JEakTQuIAgAACR4CAAAUjsA==", "Date": "Wed, 22 Jul 2020 08:49:53 +0000", "Message-ID": "\n <BYAPR11MB29353625C9B16EABF2713D2CEB790@BYAPR11MB2935.namprd11.prod.outlook.com>", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <BYAPR11MB2935565CF64827508D474F16EB790@BYAPR11MB2935.namprd11.prod.outlook.com>\n <CY4PR1101MB231015070338C942BE9013D5F8790@CY4PR1101MB2310.namprd11.prod.outlook.com>", "In-Reply-To": "\n <CY4PR1101MB231015070338C942BE9013D5F8790@CY4PR1101MB2310.namprd11.prod.outlook.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "dlp-version": "11.5.1.3", "dlp-reaction": "no-action", "dlp-product": "dlpe-windows", "authentication-results": "intel.com; dkim=none (message not signed)\n 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": "f7c6deb6-1400-41db-f2c0-08d82e1c33d8", "x-ms-traffictypediagnostic": "BYAPR11MB3240:", "x-ms-exchange-transport-forked": "True", "x-microsoft-antispam-prvs": "\n <BYAPR11MB3240629DB6389DE2543BAADFEB790@BYAPR11MB3240.namprd11.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:6790;", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam": "BCL:0;", "x-microsoft-antispam-message-info": "\n VFLSWJhQzy+lChHAXsLAn6CRYQ+7+4cgi5ZPuNlHOhurI53uWC0Z/Zs939+XwbMkrqQafQe+tgBibZctW8dd0eiJx4s1vc9Pp2Q3tLUHTZbFFMLJD6Nipo4Q8e6ugpctMg0qOlwRE52WI0ANxAXr2JBR2OtO94f/Rh2P6FLpMs5lamba2maCCeyTYzw++pbR7p28bBzJ4CL0QI9gw8R6p64tQm5cdbuOUFa8/I1bgOrRvrQgenegibSfvX93LxZXd1ABSOqQ5WjIVmnEUGl1KnqPlHu8zj96UrlQMliDzvCKC4oV0SQNfjyVhxbD5WE9", "x-forefront-antispam-report": "CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BYAPR11MB2935.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFTY:;\n SFS:(4636009)(39860400002)(396003)(366004)(376002)(346002)(136003)(26005)(33656002)(316002)(110136005)(71200400001)(8936002)(2906002)(86362001)(5660300002)(4326008)(450100002)(52536014)(66446008)(7696005)(66556008)(478600001)(8676002)(55016002)(9686003)(186003)(76116006)(66946007)(66476007)(6506007)(53546011)(83380400001)(64756008);\n DIR:OUT; SFP:1102;", "x-ms-exchange-antispam-messagedata": "\n rR7RiQcRsulJgbG1u6kWKQWnH+64JBYaGt6nhif5712SAQySbwM1xW1uHlymseQ+0PJ302bEBG6F7NaMCgomb7roWW/tosWk2xVAel0o6o80ann/8GqQQB79Sfpv8Amn9QwoPxS0pu8cBVvY+B7R3XvWnUlrDga2rYv79PTmkBY0LYYLiQdn9hQ4peAH/3/OVwa4hMFmYgz09yRM6KZFpGhSQ95HsBPmCOgeKNSAuEroW7EpydgSLEpG1mCBG4pSKJ1tWUfc/27CnlCdsAsQiHiFw4d92irnJZvAvw9+LR+CZmqbRiIoMwMSJ3NwedOA8GEXZIR6886IHlXmKFFwCTef5Xyq3nBqErn4c0Ug7oSiMLWScW/jgRwaYxVhV20+wa925nNYYnNZ1+Bb0pedRfzEqn11QO8BFx66gSqDaLkNW6ADLkRJ+/m2e7qd9bs1PnscR3qw1zG8cKVqU5kCWvwA37jV3FUgR9YPG4Pn95M=", "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": "\n f7c6deb6-1400-41db-f2c0-08d82e1c33d8", "X-MS-Exchange-CrossTenant-originalarrivaltime": "22 Jul 2020 08:49:53.4904 (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": "\n lk6jG/HpKyCf2UKRCe6PAg+FRXQxSWC3J1I2JKGff2GhKCB1XTpk2cXdYwLZFpjsrzXVs+V85E0LQom9uSpZd9YjPyJbk35nEBnF1V2tqRI=", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR11MB3240", "X-OriginatorOrg": "intel.com", "Subject": "Re: [dpdk-dev] [PATCH v4] 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 <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116856, "web_url": "https://patches.dpdk.org/comment/116856/", "msgid": "<CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>", "list_archive_url": "https://inbox.dpdk.org/dev/CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com", "date": "2020-07-29T12:01:25", "subject": "Re: [dpdk-dev] [PATCH v4] lib/table: fix cache alignment issue", "submitter": { "id": 1173, "url": "https://patches.dpdk.org/api/people/1173/?format=api", "name": "David Marchand", "email": "david.marchand@redhat.com" }, "content": "On Wed, Jul 22, 2020 at 4:13 AM Ting Xu <ting.xu@intel.com> wrote:\n>\n> When create softnic hash table with 16 keys, it failed on 32-bit\n> environment, because the pointer field in structure rte_bucket_4_16\n> is only 32 bits. Add a padding field in 32-bit environment to keep\n> the structure to a multiple of 64 bytes. Apply this to 8-byte and\n> 32-byte key hash function as well.\n\nPlease correct me if I am wrong, but it simply means this part of the\ntable library never worked for 32-bit.\nIt seems more adding 32-bit support rather than a fix and then I\nwonder if it has its place in rc3.\n\n\n\nNow, looking at the details:\n\nFor 64-bit on my x86, we have:\n\nstruct rte_bucket_4_8 {\n uint64_t signature; /* 0 8 */\n uint64_t lru_list; /* 8 8 */\n struct rte_bucket_4_8 * next; /* 16 8 */\n uint64_t next_valid; /* 24 8 */\n uint64_t key[4]; /* 32 32 */\n /* --- cacheline 1 boundary (64 bytes) --- */\n uint8_t data[]; /* 64 0 */\n\n /* size: 64, cachelines: 1, members: 6 */\n};\n\n\nFor 32-bit, we have:\n\nstruct rte_bucket_4_8 {\n uint64_t signature; /* 0 8 */\n uint64_t lru_list; /* 8 8 */\n struct rte_bucket_4_8 * next; /* 16 4 */\n uint64_t next_valid; /* 20 8 */\n uint64_t key[4]; /* 28 32 */\n uint8_t data[]; /* 60 0 */\n\n /* size: 60, cachelines: 1, members: 6 */\n /* last cacheline: 60 bytes */\n} __attribute__((__packed__));\n\n^^ it is interesting that a packed attribute ends up here.\nI saw no such attribute in the library code.\nCompiler black magic at work I guess...\n\n\n>\n> Fixes: 8aa327214c (\"table: hash\")\n> Cc: stable@dpdk.org\n>\n> Signed-off-by: Ting Xu <ting.xu@intel.com>\n>\n> ---\n> v3->v4: Change design based on comment\n> v2->v3: Rebase\n> v1->v2: Correct patch time\n> ---\n> lib/librte_table/rte_table_hash_key16.c | 17 +++++++++++++++++\n> lib/librte_table/rte_table_hash_key32.c | 17 +++++++++++++++++\n> lib/librte_table/rte_table_hash_key8.c | 16 ++++++++++++++++\n> 3 files changed, 50 insertions(+)\n>\n> diff --git a/lib/librte_table/rte_table_hash_key16.c b/lib/librte_table/rte_table_hash_key16.c\n> index 2cca1c924..c4384b114 100644\n> --- a/lib/librte_table/rte_table_hash_key16.c\n> +++ b/lib/librte_table/rte_table_hash_key16.c\n> @@ -33,6 +33,7 @@\n>\n> #endif\n>\n> +#ifdef RTE_ARCH_64\n> struct rte_bucket_4_16 {\n> /* Cache line 0 */\n> uint64_t signature[4 + 1];\n> @@ -46,6 +47,22 @@ struct rte_bucket_4_16 {\n> /* Cache line 2 */\n> uint8_t data[0];\n> };\n> +#else\n> +struct rte_bucket_4_16 {\n> + /* Cache line 0 */\n> + uint64_t signature[4 + 1];\n> + uint64_t lru_list;\n> + struct rte_bucket_4_16 *next;\n> + uint32_t pad;\n> + uint64_t next_valid;\n> +\n> + /* Cache line 1 */\n> + uint64_t key[4][2];\n> +\n> + /* Cache line 2 */\n> + uint8_t data[0];\n> +};\n> +#endif\n\nThe change could simply be:\n\n@@ -38,6 +38,9 @@ struct rte_bucket_4_16 {\n uint64_t signature[4 + 1];\n uint64_t lru_list;\n struct rte_bucket_4_16 *next;\n+#ifndef RTE_ARCH_64\n+ uint32_t pad;\n+#endif\n uint64_t next_valid;\n\n /* Cache line 1 */\n\nIt avoids duplicating the whole structure definition (we could miss\nupdating one side of the #ifdef later).\nIdem for the other \"8\" and \"32\" structures.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 1C94FA052B;\n\tWed, 29 Jul 2020 14:01:43 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id DE16D37B7;\n\tWed, 29 Jul 2020 14:01:41 +0200 (CEST)", "from us-smtp-delivery-74.mimecast.com\n (us-smtp-delivery-74.mimecast.com [63.128.21.74])\n by dpdk.org (Postfix) with ESMTP id 3194110A3\n for <dev@dpdk.org>; Wed, 29 Jul 2020 14:01:40 +0200 (CEST)", "from mail-vk1-f197.google.com (mail-vk1-f197.google.com\n [209.85.221.197]) (Using TLS) by relay.mimecast.com with ESMTP id\n us-mta-428-u_QmIPaQOdGN8iulyEEbLw-1; Wed, 29 Jul 2020 08:01:38 -0400", "by mail-vk1-f197.google.com with SMTP id v125so3784700vkg.9\n for <dev@dpdk.org>; Wed, 29 Jul 2020 05:01:37 -0700 (PDT)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1596024099;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=0YnJE4NCOywxh+DDxKj8SiVH1TYiCtyyNf5MwyubIfo=;\n b=Mb6IancmwK/2Bm7Ke/0p2/beBfKX/BfyT50H5ZJaYCU8HWLYAvGvdF4TINmKQvsqBCpyJG\n 9guj748V/ClS3ZdZ1PJhLnjpQZjuNxVxqb8O1BTFkwCnPpPml3kr4mxYXDFXkNKVyzBc2t\n PpaO06kuOw3uu6HF7DPRUjmyzCtE/Ho=", "X-MC-Unique": "u_QmIPaQOdGN8iulyEEbLw-1", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20161025;\n h=x-gm-message-state:mime-version:references:in-reply-to:from:date\n :message-id:subject:to:cc;\n bh=0YnJE4NCOywxh+DDxKj8SiVH1TYiCtyyNf5MwyubIfo=;\n b=bXvsCwiHN03FYsuF3VkqIfJtFzBnptC27wEUKlCRXY4DHTLFB4om4fwq2tOsFP6eWl\n aT577dvBsraBg/gDZfn7FbZT+ouG1R5UoMMVbqg6ugX+cYoAdNqwT6t+MoSo3ceaNyxV\n DeYxxt6QIGl8AQb4SDaUYj03TBt3qkjQx7zuPwJ56TuhkTesk5QZJtLxMMuiblTUFZtV\n 0aQKI7+Hl3o0tXztS2x4HhDumdgE3zX06hBEc28D173Ybt2jnbUCV1W2Ea0tkudpGX+J\n GIGoqK5xVCj4GSX9bHzcrBWu32sJ/KLXhOr6Lmidx1U7AYT46rWYBXZ9uI1QNNclnE/I\n v78Q==", "X-Gm-Message-State": "AOAM531I+bOajSe67JymW9uts7zZE4tfMBS/1vhaRvScrT0JmjDEkGWM\n Ll2wESxNdjmgV1nuRQ2YmuvXIkGEnZ2KJq8lqhD5lQ7KfNbgjbUBX20Mim3qesYRQfJxA4Ajwsx\n 1ttuxxKxT36GAHjmmJgs=", "X-Received": [ "by 2002:a9f:2b8d:: with SMTP id\n y13mr23075685uai.126.1596024097024;\n Wed, 29 Jul 2020 05:01:37 -0700 (PDT)", "by 2002:a9f:2b8d:: with SMTP id\n y13mr23075579uai.126.1596024096108;\n Wed, 29 Jul 2020 05:01:36 -0700 (PDT)" ], "X-Google-Smtp-Source": "\n ABdhPJxu6SWvRyQl5Ii78jTOk6Az9XGKl3T7h3C53KVFHa8Mryff5AGJbvZIl1lXxvIVVKE7T9vzoXC1rdK01MB8aCs=", "MIME-Version": "1.0", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>", "In-Reply-To": "<20200722021628.17194-1-ting.xu@intel.com>", "From": "David Marchand <david.marchand@redhat.com>", "Date": "Wed, 29 Jul 2020 14:01:25 +0200", "Message-ID": "\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>", "To": "Ting Xu <ting.xu@intel.com>,\n Cristian Dumitrescu <cristian.dumitrescu@intel.com>", "Cc": "dev <dev@dpdk.org>, dpdk stable <stable@dpdk.org>", "X-Mimecast-Spam-Score": "0", "X-Mimecast-Originator": "redhat.com", "Content-Type": "text/plain; charset=\"UTF-8\"", "Subject": "Re: [dpdk-dev] [PATCH v4] 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 <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116860, "web_url": "https://patches.dpdk.org/comment/116860/", "msgid": "<BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com", "date": "2020-07-29T13:13:57", "subject": "Re: [dpdk-dev] [PATCH v4] lib/table: fix cache alignment issue", "submitter": { "id": 19, "url": "https://patches.dpdk.org/api/people/19/?format=api", "name": "Cristian Dumitrescu", "email": "cristian.dumitrescu@intel.com" }, "content": "> -----Original Message-----\n> From: David Marchand <david.marchand@redhat.com>\n> Sent: Wednesday, July 29, 2020 1:01 PM\n> To: Xu, Ting <ting.xu@intel.com>; Dumitrescu, Cristian\n> <cristian.dumitrescu@intel.com>\n> Cc: dev <dev@dpdk.org>; dpdk stable <stable@dpdk.org>\n> Subject: Re: [dpdk-dev] [PATCH v4] lib/table: fix cache alignment issue\n> \n> On Wed, Jul 22, 2020 at 4:13 AM Ting Xu <ting.xu@intel.com> wrote:\n> >\n> > When create softnic hash table with 16 keys, it failed on 32-bit\n> > environment, because the pointer field in structure rte_bucket_4_16\n> > is only 32 bits. Add a padding field in 32-bit environment to keep\n> > the structure to a multiple of 64 bytes. Apply this to 8-byte and\n> > 32-byte key hash function as well.\n> \n> Please correct me if I am wrong, but it simply means this part of the\n> table library never worked for 32-bit.\n> It seems more adding 32-bit support rather than a fix and then I\n> wonder if it has its place in rc3.\n> \n\nFunctionally. the code works, but performance is affected.\n\nThe only thing that prevents the code from working is the check in the table create function that checks the size of the above structure is 64 bytes, which caught this issue.\n\n> \n> \n> Now, looking at the details:\n> \n> For 64-bit on my x86, we have:\n> \n> struct rte_bucket_4_8 {\n> uint64_t signature; /* 0 8 */\n> uint64_t lru_list; /* 8 8 */\n> struct rte_bucket_4_8 * next; /* 16 8 */\n> uint64_t next_valid; /* 24 8 */\n> uint64_t key[4]; /* 32 32 */\n> /* --- cacheline 1 boundary (64 bytes) --- */\n> uint8_t data[]; /* 64 0 */\n> \n> /* size: 64, cachelines: 1, members: 6 */\n> };\n> \n> \n> For 32-bit, we have:\n> \n> struct rte_bucket_4_8 {\n> uint64_t signature; /* 0 8 */\n> uint64_t lru_list; /* 8 8 */\n> struct rte_bucket_4_8 * next; /* 16 4 */\n> uint64_t next_valid; /* 20 8 */\n> uint64_t key[4]; /* 28 32 */\n> uint8_t data[]; /* 60 0 */\n> \n> /* size: 60, cachelines: 1, members: 6 */\n> /* last cacheline: 60 bytes */\n> } __attribute__((__packed__));\n> \n> ^^ it is interesting that a packed attribute ends up here.\n> I saw no such attribute in the library code.\n> Compiler black magic at work I guess...\n> \n\nWhere do you see the packet attribute? I don't see it in the code.\n\nA packet attribute would explain this issue, i.e. why did the compiler decide not to insert an expected padfing of 4 bytes right after the \"next\" field, that would allow the field \"next_valid\" to be aligned to its natural boundary of 8 bytes.\n\n> \n> >\n> > Fixes: 8aa327214c (\"table: hash\")\n> > Cc: stable@dpdk.org\n> >\n> > Signed-off-by: Ting Xu <ting.xu@intel.com>\n> >\n> > ---\n> > v3->v4: Change design based on comment\n> > v2->v3: Rebase\n> > v1->v2: Correct patch time\n> > ---\n> > lib/librte_table/rte_table_hash_key16.c | 17 +++++++++++++++++\n> > lib/librte_table/rte_table_hash_key32.c | 17 +++++++++++++++++\n> > lib/librte_table/rte_table_hash_key8.c | 16 ++++++++++++++++\n> > 3 files changed, 50 insertions(+)\n> >\n> > diff --git a/lib/librte_table/rte_table_hash_key16.c\n> b/lib/librte_table/rte_table_hash_key16.c\n> > index 2cca1c924..c4384b114 100644\n> > --- a/lib/librte_table/rte_table_hash_key16.c\n> > +++ b/lib/librte_table/rte_table_hash_key16.c\n> > @@ -33,6 +33,7 @@\n> >\n> > #endif\n> >\n> > +#ifdef RTE_ARCH_64\n> > struct rte_bucket_4_16 {\n> > /* Cache line 0 */\n> > uint64_t signature[4 + 1];\n> > @@ -46,6 +47,22 @@ struct rte_bucket_4_16 {\n> > /* Cache line 2 */\n> > uint8_t data[0];\n> > };\n> > +#else\n> > +struct rte_bucket_4_16 {\n> > + /* Cache line 0 */\n> > + uint64_t signature[4 + 1];\n> > + uint64_t lru_list;\n> > + struct rte_bucket_4_16 *next;\n> > + uint32_t pad;\n> > + uint64_t next_valid;\n> > +\n> > + /* Cache line 1 */\n> > + uint64_t key[4][2];\n> > +\n> > + /* Cache line 2 */\n> > + uint8_t data[0];\n> > +};\n> > +#endif\n> \n> The change could simply be:\n> \n> @@ -38,6 +38,9 @@ struct rte_bucket_4_16 {\n> uint64_t signature[4 + 1];\n> uint64_t lru_list;\n> struct rte_bucket_4_16 *next;\n> +#ifndef RTE_ARCH_64\n> + uint32_t pad;\n> +#endif\n> uint64_t next_valid;\n> \n> /* Cache line 1 */\n> \n> It avoids duplicating the whole structure definition (we could miss\n> updating one side of the #ifdef later).\n> Idem for the other \"8\" and \"32\" structures.\n> \n> \n> --\n> David Marchand", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 1BFAAA052B;\n\tWed, 29 Jul 2020 15:14:06 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 018C81BFF4;\n\tWed, 29 Jul 2020 15:14:06 +0200 (CEST)", "from mga04.intel.com (mga04.intel.com [192.55.52.120])\n by dpdk.org (Postfix) with ESMTP id 6CF2623D;\n Wed, 29 Jul 2020 15:14:03 +0200 (CEST)", "from fmsmga005.fm.intel.com ([10.253.24.32])\n by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 29 Jul 2020 06:14:02 -0700", "from orsmsx604.amr.corp.intel.com ([10.22.229.17])\n by fmsmga005.fm.intel.com with ESMTP; 29 Jul 2020 06:14:02 -0700", "from orsmsx607.amr.corp.intel.com (10.22.229.20) by\n ORSMSX604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.1713.5; Wed, 29 Jul 2020 06:14:01 -0700", "from ORSEDG002.ED.cps.intel.com (10.7.248.5) by\n orsmsx607.amr.corp.intel.com (10.22.229.20) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5\n via Frontend Transport; Wed, 29 Jul 2020 06:14:01 -0700", "from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.49) by\n edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server\n (TLS) id 14.3.439.0; Wed, 29 Jul 2020 06:13:59 -0700", "from BYAPR11MB2935.namprd11.prod.outlook.com (2603:10b6:a03:82::24)\n by BY5PR11MB4039.namprd11.prod.outlook.com (2603:10b6:a03:18b::20)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.26; Wed, 29 Jul\n 2020 13:13:57 +0000", "from BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061]) by BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061%3]) with mapi id 15.20.3216.034; Wed, 29 Jul 2020\n 13:13:57 +0000" ], "IronPort-SDR": [ "\n dO/BCPVDFTSLcMEFItVhHcn+S2IbpM2lCspZ8DmW/pbL4tpdtVNV9nAwHLo1dG6mol3oYtUMaK\n lmpCO9PRVcdQ==", "\n W2WVmDvx0LVx6CTYWNWRXqcJTofMoHOCnSkP4yknCIicLTQmEi+cxijVmxV+fvvouODAwJySSW\n c9/OgrP03nzw==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9696\"; a=\"148866537\"", "E=Sophos;i=\"5.75,410,1589266800\"; d=\"scan'208\";a=\"148866537\"", "E=Sophos;i=\"5.75,410,1589266800\"; d=\"scan'208\";a=\"490749776\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=ifmI7qdycQtIqPUFY6HHevIQBuFszTn/0Yz0OJ+EPLEWx9hrEylBpeMjhdxHuBR6jjACuAuvhDWOK8ZkqR8xsj5uVkAwDQV1Vp9OFZi8Ze66ye4ZzfQ0MtI31g7ZHgvgHV+6wERgD8mVoSX9dSPTgkX9Z5w3q/RcgJ4YlTIThPlkQNpaZvNfNiFBb92y/q0Sk5C/O42lLk+dkfF9F6Oq824KvKwfhs1w3Jz/TGXvsdHeWF5vo3iTcpFCJ/HYrVTkkqXn4Pn2kxnjBiJ9A1ZgZdA8dShWtpyRkgqAdbwfe4MRXKyRwQ5BpkbwFobGXkr5Cum3G06dwlcYKPddqmfnww==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=svRRtUqyAMaSpUoLr3NOytV4JK2hj2REaSlGUwgjYMw=;\n b=Hc9qHN4iWnukt92JYRDBdp4zIc4s37R1Ot5hu2kudENLK6dkqLaQ8sM6Bd1AJsg/9DrQ9PcwER6aKIapORx0tPPr6BbE2HbPcoKndgGNvX5xN4rOrFwJc7l7aodI+qXt4HCvs2So8XNz6UKPqFa13J4IVbgYlxC+92DZQlhFtTyclxm+YUuzcDWA5Fcb+xGfr30hSlnXv8QnWgsAOoDwW45EW5qEK9Udj9506o2mIoneRdRmxZLiqXyfmYEU55sNhmQG77lq3eCJZMeP6hCoPPQ/VJ9KN+aMf0C5BP270W0r23H9cUuhU60BvpWGMJHkibQ94yeQ+xShuTvaV4iuzA==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;\n s=selector2-intel-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=svRRtUqyAMaSpUoLr3NOytV4JK2hj2REaSlGUwgjYMw=;\n b=oGUTAizhld+O1UyzzFERUyg9otHzyNTQbsiHMytt5Y4oIteczGN8vYrV2ZVbEnK/7OdbJm/s18FJFJSbTGfCI1Z6iSwRHTb6GNWhHDmnWJoN8SNCgjaZMXkaboA3xRSF3776dZ+sruXtlpVa0qjFn1rbeo1CvA3jdzx/XhXIt+s=", "From": "\"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>", "To": "David Marchand <david.marchand@redhat.com>, \"Xu, Ting\" <ting.xu@intel.com>", "CC": "dev <dev@dpdk.org>, dpdk stable <stable@dpdk.org>", "Thread-Topic": "[dpdk-dev] [PATCH v4] lib/table: fix cache alignment issue", "Thread-Index": "AQHWX82i+KTf+DtoXESWs1iJ7M+JEakegFyAgAAShhA=", "Date": "Wed, 29 Jul 2020 13:13:57 +0000", "Message-ID": "\n <BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>", "In-Reply-To": "\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "dlp-version": "11.5.1.3", "dlp-reaction": "no-action", "dlp-product": "dlpe-windows", "authentication-results": "redhat.com; dkim=none (message not signed)\n header.d=none;redhat.com; dmarc=none action=none header.from=intel.com;", "x-originating-ip": "[109.76.64.157]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "b19d9eea-1590-435b-ab72-08d833c14089", "x-ms-traffictypediagnostic": "BY5PR11MB4039:", "x-ms-exchange-transport-forked": "True", "x-microsoft-antispam-prvs": "\n <BY5PR11MB4039C60308F46072D1197F48EB700@BY5PR11MB4039.namprd11.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:9508;", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam": "BCL:0;", "x-microsoft-antispam-message-info": "\n F5rWMx+Wl/gt3PzcSZMD4pnXt04LviXRMqkjZdQj3KzkHpz0JrzP+eG6jQEHwOu/nLO1Cy5HzRibQ5uV+90GLiIfffw3C9/PpGMiFLrCAloNJmyUZudy30d9BYrxkeaYbinqI6pM5GQrc86QpwYpUp3M06u+bWmSbTIxKRC0s4JQb2I33yv4Q0sagSQ4rOEN78SRgi1MoLXrh1gmR3jtwT1wvOYSJZVU1l6WaxOzuoDtmIXklQ/RBwVdB50atn3f4mEwvZ2tI3H4GvK+r4PialWR6GjwRzo96ZEfvjCzgtEG1Vg23Q0ib+JEC+bMhFXRDVAblr6tW3Ds6PPPMjX4Nw==", "x-forefront-antispam-report": "CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BYAPR11MB2935.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFTY:;\n SFS:(4636009)(136003)(396003)(376002)(39860400002)(366004)(346002)(66556008)(71200400001)(83380400001)(55016002)(66476007)(76116006)(8936002)(2906002)(66946007)(4326008)(9686003)(8676002)(66446008)(64756008)(7696005)(316002)(86362001)(33656002)(52536014)(53546011)(6506007)(186003)(6636002)(5660300002)(478600001)(54906003)(110136005)(26005);\n DIR:OUT; SFP:1102;", "x-ms-exchange-antispam-messagedata": "\n YWV0FNrsSGpLKI3CAoNSuvB4HoUqy7Z49ZAZIX7yUvBsjlDonkuTfdf8cCnZUvQb/AJeqX44xH0uPXjla17imbNTBUPc1kXzlJe2Zymhw/+E2BCv2rsL5cmjMj4T+DspJvLpsOgQnsONWG0t1+7WxuaMn4JxFLUWuW36csxV1O6GXKnDPZwokTN2kQ31wlIom9GIHyftB/3hCHOU5mge4PiMVFLG7rM+/e/Xop6XLpwCWoWGCkFusmQWwFXjNwyNDZRgyh7o0ZteKRjGgeQv2gRee6/4HgtP8xGQTwkJ2e8RzI9B68FFzrWI2IGcBR4CJMbED8716BEsFqm0a0gNHvUAdzlraWhIZg3skp28ioamsAgJN9y0zx5hm2z1PLJBgLBueOKh5a7XsMZz8dYZVtIcxRq+116HbupxK6wjw5mg2bFkde20HgJUIIao1XXn9FqdlHGiATeI0rQr2qHnovt7kMYTS0/lITyCiSbrgao=", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "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": "\n b19d9eea-1590-435b-ab72-08d833c14089", "X-MS-Exchange-CrossTenant-originalarrivaltime": "29 Jul 2020 13:13:57.5155 (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": "\n jMb1EUrWy0nJQoi1k7dKf5sXZ56cKVCYAh0vUeGBkG7VBPy/YLM9uV6JB367GqBtaeoY2VvWQ/CXw7jfSX5xANcxDhi7csqigi8MkQbKO3A=", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BY5PR11MB4039", "X-OriginatorOrg": "intel.com", "Subject": "Re: [dpdk-dev] [PATCH v4] 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 <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116865, "web_url": "https://patches.dpdk.org/comment/116865/", "msgid": "<CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>", "list_archive_url": "https://inbox.dpdk.org/dev/CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com", "date": "2020-07-29T13:28:24", "subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "submitter": { "id": 1173, "url": "https://patches.dpdk.org/api/people/1173/?format=api", "name": "David Marchand", "email": "david.marchand@redhat.com" }, "content": "On Wed, Jul 29, 2020 at 3:14 PM Dumitrescu, Cristian\n<cristian.dumitrescu@intel.com> wrote:\n> > Please correct me if I am wrong, but it simply means this part of the\n> > table library never worked for 32-bit.\n> > It seems more adding 32-bit support rather than a fix and then I\n> > wonder if it has its place in rc3.\n> >\n>\n> Functionally. the code works, but performance is affected.\n>\n> The only thing that prevents the code from working is the check in the table create function that checks the size of the above structure is 64 bytes, which caught this issue.\n\nYes, and that's my point.\nIt was not working.\nIt was not tested.\n\n\nThis patch asks for backport in stable branches, I will let Kevin and\nLuca comment.\n\n\n>\n> >\n> >\n> > Now, looking at the details:\n> >\n> > For 64-bit on my x86, we have:\n> >\n> > struct rte_bucket_4_8 {\n> > uint64_t signature; /* 0 8 */\n> > uint64_t lru_list; /* 8 8 */\n> > struct rte_bucket_4_8 * next; /* 16 8 */\n> > uint64_t next_valid; /* 24 8 */\n> > uint64_t key[4]; /* 32 32 */\n> > /* --- cacheline 1 boundary (64 bytes) --- */\n> > uint8_t data[]; /* 64 0 */\n> >\n> > /* size: 64, cachelines: 1, members: 6 */\n> > };\n> >\n> >\n> > For 32-bit, we have:\n> >\n> > struct rte_bucket_4_8 {\n> > uint64_t signature; /* 0 8 */\n> > uint64_t lru_list; /* 8 8 */\n> > struct rte_bucket_4_8 * next; /* 16 4 */\n> > uint64_t next_valid; /* 20 8 */\n> > uint64_t key[4]; /* 28 32 */\n> > uint8_t data[]; /* 60 0 */\n> >\n> > /* size: 60, cachelines: 1, members: 6 */\n> > /* last cacheline: 60 bytes */\n> > } __attribute__((__packed__));\n> >\n> > ^^ it is interesting that a packed attribute ends up here.\n> > I saw no such attribute in the library code.\n> > Compiler black magic at work I guess...\n> >\n>\n> Where do you see the packet attribute? I don't see it in the code.\n\nThat's pahole reporting this.\nMaybe the tool extrapolates this attribute based on the next_valid\nfield placement... I don't know.\n\n> A packet attribute would explain this issue, i.e. why did the compiler decide not to insert an expected padfing of 4 bytes right after the \"next\" field, that would allow the field \"next_valid\" to be aligned to its natural boundary of 8 bytes.\n\nOr a 64-bit field on 32-bit has a special alignment that I am not aware of.\n\n\n>\n> >\n> > >\n> > > Fixes: 8aa327214c (\"table: hash\")\n> > > Cc: stable@dpdk.org\n> > >\n> > > Signed-off-by: Ting Xu <ting.xu@intel.com>\n> > >\n> > > ---\n> > > v3->v4: Change design based on comment\n> > > v2->v3: Rebase\n> > > v1->v2: Correct patch time\n> > > ---\n> > > lib/librte_table/rte_table_hash_key16.c | 17 +++++++++++++++++\n> > > lib/librte_table/rte_table_hash_key32.c | 17 +++++++++++++++++\n> > > lib/librte_table/rte_table_hash_key8.c | 16 ++++++++++++++++\n> > > 3 files changed, 50 insertions(+)\n> > >\n> > > diff --git a/lib/librte_table/rte_table_hash_key16.c\n> > b/lib/librte_table/rte_table_hash_key16.c\n> > > index 2cca1c924..c4384b114 100644\n> > > --- a/lib/librte_table/rte_table_hash_key16.c\n> > > +++ b/lib/librte_table/rte_table_hash_key16.c\n> > > @@ -33,6 +33,7 @@\n> > >\n> > > #endif\n> > >\n> > > +#ifdef RTE_ARCH_64\n> > > struct rte_bucket_4_16 {\n> > > /* Cache line 0 */\n> > > uint64_t signature[4 + 1];\n> > > @@ -46,6 +47,22 @@ struct rte_bucket_4_16 {\n> > > /* Cache line 2 */\n> > > uint8_t data[0];\n> > > };\n> > > +#else\n> > > +struct rte_bucket_4_16 {\n> > > + /* Cache line 0 */\n> > > + uint64_t signature[4 + 1];\n> > > + uint64_t lru_list;\n> > > + struct rte_bucket_4_16 *next;\n> > > + uint32_t pad;\n> > > + uint64_t next_valid;\n> > > +\n> > > + /* Cache line 1 */\n> > > + uint64_t key[4][2];\n> > > +\n> > > + /* Cache line 2 */\n> > > + uint8_t data[0];\n> > > +};\n> > > +#endif\n> >\n> > The change could simply be:\n> >\n> > @@ -38,6 +38,9 @@ struct rte_bucket_4_16 {\n> > uint64_t signature[4 + 1];\n> > uint64_t lru_list;\n> > struct rte_bucket_4_16 *next;\n> > +#ifndef RTE_ARCH_64\n> > + uint32_t pad;\n> > +#endif\n> > uint64_t next_valid;\n> >\n> > /* Cache line 1 */\n> >\n> > It avoids duplicating the whole structure definition (we could miss\n> > updating one side of the #ifdef later).\n> > Idem for the other \"8\" and \"32\" structures.\n\n\nWhat about this comment?", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 245F7A052B;\n\tWed, 29 Jul 2020 15:28:40 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 0327C10A3;\n\tWed, 29 Jul 2020 15:28:40 +0200 (CEST)", "from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com\n [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id 9F833F04\n for <dev@dpdk.org>; Wed, 29 Jul 2020 15:28:38 +0200 (CEST)", "from mail-ua1-f69.google.com (mail-ua1-f69.google.com\n [209.85.222.69]) (Using TLS) by relay.mimecast.com with ESMTP id\n us-mta-470-_rvh4UksOT2SyHGPQbiX6Q-1; Wed, 29 Jul 2020 09:28:36 -0400", "by mail-ua1-f69.google.com with SMTP id n4so7215115uaq.17\n for <dev@dpdk.org>; Wed, 29 Jul 2020 06:28:36 -0700 (PDT)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1596029318;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=j8q/Imi3gxRbZ362wbHWZCmLgGx7fzzyweYSz+gOEC4=;\n b=evLH2Ddku4NO/JKz29Htz7JaJ20xabJYe3Ycu4l4bJdKux7VjdFwJ/otHAAMrf/SZNWdan\n K4guo8Ea9duyepKvYwC2u52xaaPDLt1LYP1L0SWbHQ0RYwX8ojkNPL96imqoO33fOCRxBh\n E3YIX2Ap5K4aL1ynwuQyy97oQexjvx4=", "X-MC-Unique": "_rvh4UksOT2SyHGPQbiX6Q-1", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20161025;\n h=x-gm-message-state:mime-version:references:in-reply-to:from:date\n :message-id:subject:to:cc;\n bh=j8q/Imi3gxRbZ362wbHWZCmLgGx7fzzyweYSz+gOEC4=;\n b=ExAUGOBWwYjeAi/9NG1JDEcn46FLR241q2qdhwNVV4P5GggZFoK6+r/QNfhpC4SH1N\n poHyf/BXR2ULoZ1mV4D1gzvAfkUIRlRiPZkvxombkDIjD7QyLk604BMw4sL3L9HY6GyC\n c0UAIwZvZeVEUdNFt3oUmoiP/wwyV1edUfFgVH6vGXbHYY1Ey52BIxfVM42eSMW3LRIh\n 6Y5lljG63fjOomApX7MArbVH6vf2UoEhNPMRrPzE77McVPGBk4BpYrPYfraBgscPGlWv\n zQvC8gwZukFso2lKdXkjKkmCPh+PAEUyAikIgOc60YdKsoWSjhULVPZosrbRDczNpmYl\n d8kg==", "X-Gm-Message-State": "AOAM532K9/BtlNdHHe/Oyohj4r6Wy5zgTqFgVj55Eh6xovvTxn2NecUL\n D2yii2u5R5lRUStpbtVfEh9nWPWYml0+QB9kkIeasKldyZyaAOk8dT5K8zcW0huEdovE2BHFSnM\n ViFmWuiIY2fGZKgcfqfY=", "X-Received": [ "by 2002:a1f:acc2:: with SMTP id\n v185mr22963037vke.18.1596029315690;\n Wed, 29 Jul 2020 06:28:35 -0700 (PDT)", "by 2002:a1f:acc2:: with SMTP id\n v185mr22963006vke.18.1596029315286;\n Wed, 29 Jul 2020 06:28:35 -0700 (PDT)" ], "X-Google-Smtp-Source": "\n ABdhPJwKVVxZoWunW4Q1Rr3fKhggiPcC+gMardVFAa5LxK4K9zrHrWmxLiBegxEZMbxSf/DJ2vf+suQFBUKclAhe044=", "MIME-Version": "1.0", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>\n <BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "In-Reply-To": "\n <BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "From": "David Marchand <david.marchand@redhat.com>", "Date": "Wed, 29 Jul 2020 15:28:24 +0200", "Message-ID": "\n <CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>", "To": "\"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>", "Cc": "\"Xu, Ting\" <ting.xu@intel.com>, dev <dev@dpdk.org>,\n dpdk stable <stable@dpdk.org>,\n Kevin Traynor <ktraynor@redhat.com>, Luca Boccassi <bluca@debian.org>", "X-Mimecast-Spam-Score": "0", "X-Mimecast-Originator": "redhat.com", "Content-Type": "text/plain; charset=\"UTF-8\"", "Subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116868, "web_url": "https://patches.dpdk.org/comment/116868/", "msgid": "<BYAPR11MB2935CA1D2C9010F40D955B69EB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR11MB2935CA1D2C9010F40D955B69EB700@BYAPR11MB2935.namprd11.prod.outlook.com", "date": "2020-07-29T13:54:03", "subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "submitter": { "id": 19, "url": "https://patches.dpdk.org/api/people/19/?format=api", "name": "Cristian Dumitrescu", "email": "cristian.dumitrescu@intel.com" }, "content": "> -----Original Message-----\n> From: David Marchand <david.marchand@redhat.com>\n> Sent: Wednesday, July 29, 2020 2:28 PM\n> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>\n> Cc: Xu, Ting <ting.xu@intel.com>; dev <dev@dpdk.org>; dpdk stable\n> <stable@dpdk.org>; Kevin Traynor <ktraynor@redhat.com>; Luca Boccassi\n> <bluca@debian.org>\n> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache\n> alignment issue\n> \n> On Wed, Jul 29, 2020 at 3:14 PM Dumitrescu, Cristian\n> <cristian.dumitrescu@intel.com> wrote:\n> > > Please correct me if I am wrong, but it simply means this part of the\n> > > table library never worked for 32-bit.\n> > > It seems more adding 32-bit support rather than a fix and then I\n> > > wonder if it has its place in rc3.\n> > >\n> >\n> > Functionally. the code works, but performance is affected.\n> >\n> > The only thing that prevents the code from working is the check in the\n> table create function that checks the size of the above structure is 64 bytes,\n> which caught this issue.\n> \n> Yes, and that's my point.\n> It was not working.\n> It was not tested.\n> \n> \n\nNot sure when this code was last tested on 32-bit systems, I'll let the validation folks comment on this, but I cannot rule out a change in compiler behavior either.\n\nThis is a low complexity and low impact change, hence low risk IMO.\n\n> This patch asks for backport in stable branches, I will let Kevin and\n> Luca comment.\n> \n> \n> >\n> > >\n> > >\n> > > Now, looking at the details:\n> > >\n> > > For 64-bit on my x86, we have:\n> > >\n> > > struct rte_bucket_4_8 {\n> > > uint64_t signature; /* 0 8 */\n> > > uint64_t lru_list; /* 8 8 */\n> > > struct rte_bucket_4_8 * next; /* 16 8 */\n> > > uint64_t next_valid; /* 24 8 */\n> > > uint64_t key[4]; /* 32 32 */\n> > > /* --- cacheline 1 boundary (64 bytes) --- */\n> > > uint8_t data[]; /* 64 0 */\n> > >\n> > > /* size: 64, cachelines: 1, members: 6 */\n> > > };\n> > >\n> > >\n> > > For 32-bit, we have:\n> > >\n> > > struct rte_bucket_4_8 {\n> > > uint64_t signature; /* 0 8 */\n> > > uint64_t lru_list; /* 8 8 */\n> > > struct rte_bucket_4_8 * next; /* 16 4 */\n> > > uint64_t next_valid; /* 20 8 */\n> > > uint64_t key[4]; /* 28 32 */\n> > > uint8_t data[]; /* 60 0 */\n> > >\n> > > /* size: 60, cachelines: 1, members: 6 */\n> > > /* last cacheline: 60 bytes */\n> > > } __attribute__((__packed__));\n> > >\n> > > ^^ it is interesting that a packed attribute ends up here.\n> > > I saw no such attribute in the library code.\n> > > Compiler black magic at work I guess...\n> > >\n> >\n> > Where do you see the packet attribute? I don't see it in the code.\n> \n> That's pahole reporting this.\n> Maybe the tool extrapolates this attribute based on the next_valid\n> field placement... I don't know.\n> \n> > A packet attribute would explain this issue, i.e. why did the compiler decide\n> not to insert an expected padfing of 4 bytes right after the \"next\" field, that\n> would allow the field \"next_valid\" to be aligned to its natural boundary of 8\n> bytes.\n> \n> Or a 64-bit field on 32-bit has a special alignment that I am not aware of.\n> \n> \n> >\n> > >\n> > > >\n> > > > Fixes: 8aa327214c (\"table: hash\")\n> > > > Cc: stable@dpdk.org\n> > > >\n> > > > Signed-off-by: Ting Xu <ting.xu@intel.com>\n> > > >\n> > > > ---\n> > > > v3->v4: Change design based on comment\n> > > > v2->v3: Rebase\n> > > > v1->v2: Correct patch time\n> > > > ---\n> > > > lib/librte_table/rte_table_hash_key16.c | 17 +++++++++++++++++\n> > > > lib/librte_table/rte_table_hash_key32.c | 17 +++++++++++++++++\n> > > > lib/librte_table/rte_table_hash_key8.c | 16 ++++++++++++++++\n> > > > 3 files changed, 50 insertions(+)\n> > > >\n> > > > diff --git a/lib/librte_table/rte_table_hash_key16.c\n> > > b/lib/librte_table/rte_table_hash_key16.c\n> > > > index 2cca1c924..c4384b114 100644\n> > > > --- a/lib/librte_table/rte_table_hash_key16.c\n> > > > +++ b/lib/librte_table/rte_table_hash_key16.c\n> > > > @@ -33,6 +33,7 @@\n> > > >\n> > > > #endif\n> > > >\n> > > > +#ifdef RTE_ARCH_64\n> > > > struct rte_bucket_4_16 {\n> > > > /* Cache line 0 */\n> > > > uint64_t signature[4 + 1];\n> > > > @@ -46,6 +47,22 @@ struct rte_bucket_4_16 {\n> > > > /* Cache line 2 */\n> > > > uint8_t data[0];\n> > > > };\n> > > > +#else\n> > > > +struct rte_bucket_4_16 {\n> > > > + /* Cache line 0 */\n> > > > + uint64_t signature[4 + 1];\n> > > > + uint64_t lru_list;\n> > > > + struct rte_bucket_4_16 *next;\n> > > > + uint32_t pad;\n> > > > + uint64_t next_valid;\n> > > > +\n> > > > + /* Cache line 1 */\n> > > > + uint64_t key[4][2];\n> > > > +\n> > > > + /* Cache line 2 */\n> > > > + uint8_t data[0];\n> > > > +};\n> > > > +#endif\n> > >\n> > > The change could simply be:\n> > >\n> > > @@ -38,6 +38,9 @@ struct rte_bucket_4_16 {\n> > > uint64_t signature[4 + 1];\n> > > uint64_t lru_list;\n> > > struct rte_bucket_4_16 *next;\n> > > +#ifndef RTE_ARCH_64\n> > > + uint32_t pad;\n> > > +#endif\n> > > uint64_t next_valid;\n> > >\n> > > /* Cache line 1 */\n> > >\n> > > It avoids duplicating the whole structure definition (we could miss\n> > > updating one side of the #ifdef later).\n> > > Idem for the other \"8\" and \"32\" structures.\n> \n> \n> What about this comment?\n> \n> \n> --\n> David Marchand", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id E5296A052B;\n\tWed, 29 Jul 2020 15:54:11 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 31A78F04;\n\tWed, 29 Jul 2020 15:54:10 +0200 (CEST)", "from mga07.intel.com (mga07.intel.com [134.134.136.100])\n by dpdk.org (Postfix) with ESMTP id AF84FA69;\n Wed, 29 Jul 2020 15:54:07 +0200 (CEST)", "from fmsmga005.fm.intel.com ([10.253.24.32])\n by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 29 Jul 2020 06:54:06 -0700", "from orsmsx103.amr.corp.intel.com ([10.22.225.130])\n by fmsmga005.fm.intel.com with ESMTP; 29 Jul 2020 06:54:05 -0700", "from orsmsx162.amr.corp.intel.com (10.22.240.85) by\n ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Wed, 29 Jul 2020 06:54:05 -0700", "from ORSEDG002.ED.cps.intel.com (10.7.248.5) by\n ORSMSX162.amr.corp.intel.com (10.22.240.85) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Wed, 29 Jul 2020 06:54:05 -0700", "from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.174)\n by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Wed, 29 Jul 2020 06:54:05 -0700", "from BYAPR11MB2935.namprd11.prod.outlook.com (2603:10b6:a03:82::24)\n by BY5PR11MB4120.namprd11.prod.outlook.com (2603:10b6:a03:18f::28)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Wed, 29 Jul\n 2020 13:54:04 +0000", "from BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061]) by BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061%3]) with mapi id 15.20.3216.034; Wed, 29 Jul 2020\n 13:54:04 +0000" ], "IronPort-SDR": [ "\n K6ZFANE49wIHwicC3dQbYt8HTi8webHm7a6vWnAvhgvCLzbUecjCgoLTR9mqWuCO7uTeayIH+V\n 4wDWufu1GX4w==", "\n YtUE/4hKuw3xChzR2BCOsGwAFHWtyhg01BFfQYcuLglyiftXN3rP2OPyhNOTxfVQIhlrhHugtm\n 9BuushUokSvg==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9696\"; a=\"215910446\"", "E=Sophos;i=\"5.75,410,1589266800\"; d=\"scan'208\";a=\"215910446\"", "E=Sophos;i=\"5.75,410,1589266800\"; d=\"scan'208\";a=\"490759155\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=D+4OpF4vN5z/eIa6Wl85ewYtV7LMMhTaa+L7iPGeccJIRQdmmCtJPfNdoGIy5eeJt4IOsv6esMUOaN/zfz7yfkJtqIXN4TpOyVSjLKhaNSxm9GJ1qAFB/xVI/EZuwZofVkE1GJYLvoX0TtIGKsgISxbfhKDVt0TdoeCYNqvloTPn7vicLMgo9ju9o//r3AxTCv5Pako4MJp8K4tBdBt8bBIF9Iexjps+FbPBPkqJidQteu80Eul5G8jY/82Y3lsgxv7gSSJe5E4Tg5me/AeF4jcpOJ/6tkowazwHhxhbgXziVSrMYtLrNibh+XScBXMkwwCGBjXdi9N7AuTBB8psrw==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=EzCaXX7tcd99ZfAHITmWCylZ+sz9UuZT/itXeuTFc/M=;\n b=ECNNgC+HOjPeR5uAZD4xSS0OcddInVXrwW7T+yqeR92/dmhb2hZqsM2p59+Zw9ahGhJzsHv7oRsDPjqPucvCJwlPzYGQ8/e229/T50pIUrdx4OAwZDvU777HzgsbnNONwQqDIhYAtJLi619QPYMHew0EfSWaWfg/vQ6m59Dmq3JS9ZHK0EHqn+5KTQyKOiAD4CDset7qfEvTKXW2VihZYnki4RDGaAhFpPvsX8LvH8sn2AQh9VsL8utZJRTghbkYUrvWV1tWVi/Qn+51/WVqq30C7i3TjziLssqqkexxJrnyWwFR+7q06yb7ZrVEnTcejqdcocc/ja+fqFEbf56b4w==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;\n s=selector2-intel-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=EzCaXX7tcd99ZfAHITmWCylZ+sz9UuZT/itXeuTFc/M=;\n b=hqEw2AzfIILfZvrIfKEZdUIl4/5pqk6Lj271h3m5vDBoQIyH8ItkgNQUGmxzIxytNvyb8035chL76/i3GKpw2kmSGeIE0klO1yrJLgbNRUr/F5jQ88+N8RUEHy4mkQ5yQFMn7QtZtCozmSLDt0YJGwuXg7u9kKk8fryUCyttVX4=", "From": "\"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>", "To": "David Marchand <david.marchand@redhat.com>", "CC": "\"Xu, Ting\" <ting.xu@intel.com>, dev <dev@dpdk.org>, dpdk stable\n <stable@dpdk.org>, Kevin Traynor <ktraynor@redhat.com>, Luca Boccassi\n <bluca@debian.org>", "Thread-Topic": "[dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache\n alignment issue", "Thread-Index": "AQHWX82i+KTf+DtoXESWs1iJ7M+JEakegFyAgAAShhCAAAXHAIAABh2A", "Date": "Wed, 29 Jul 2020 13:54:03 +0000", "Message-ID": "\n <BYAPR11MB2935CA1D2C9010F40D955B69EB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>\n <BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>\n <CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>", "In-Reply-To": "\n <CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "dlp-version": "11.5.1.3", "dlp-reaction": "no-action", "dlp-product": "dlpe-windows", "authentication-results": "redhat.com; dkim=none (message not signed)\n header.d=none;redhat.com; dmarc=none action=none header.from=intel.com;", "x-originating-ip": "[109.76.64.157]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "827209d0-7f67-46b4-d68e-08d833c6dad6", "x-ms-traffictypediagnostic": "BY5PR11MB4120:", "x-ms-exchange-transport-forked": "True", "x-microsoft-antispam-prvs": "\n <BY5PR11MB412010D08C8E52E9B43228F2EB700@BY5PR11MB4120.namprd11.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:10000;", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam": "BCL:0;", "x-microsoft-antispam-message-info": "\n 0VzBsiNeeP9Qr0HLobPHwcHDEarVCWhC5Ofl5IIEZNnXiDmoUVL8RmiIiRqVE2vtm5GYsMW74DqG9LDyJkMBok37yndZw7ySEK3xwsHUGpAyflXM13hrFgjHJpOwYe0qkrssP9A3yHBwJEDwv2hITOzX/CmcWCwhF2Dm0WXQRBevfD/62alJhqdVPNIw4Ml6SWBhLawrxRntCaAgnEJNL5j2T8tv+NGL0wNP9fRDRGYTq/fqlxuUxq5vB+g2OMR45KGkzWF1XbNh+3+v6YDT/LxhW7Nce9EpO3wQbUrAnOqb2szfslY1GIAgy2oMv5JuyqaMQQ5qxzDRiy13npo+VA==", "x-forefront-antispam-report": "CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BYAPR11MB2935.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFTY:;\n SFS:(4636009)(396003)(366004)(39860400002)(136003)(346002)(376002)(9686003)(2906002)(33656002)(316002)(5660300002)(83380400001)(55016002)(52536014)(54906003)(478600001)(86362001)(4326008)(71200400001)(66946007)(76116006)(66476007)(66556008)(64756008)(66446008)(8676002)(8936002)(6916009)(186003)(26005)(53546011)(6506007)(7696005);\n DIR:OUT; SFP:1102;", "x-ms-exchange-antispam-messagedata": "\n W6NtcVjq8j/v+QlgECNDBeXsj15UhtDChwVhfxcc9rLo9yKqKJsCuRl/exyP1YKwKKXz0MMcmHQzO03KUIT7gDY5Gkr8ol6gZMu3y7gT1fjRbQwj/DWtsH/lculaWFy5DwGQg4sW1GGLevV6W9O51X8rglZTuh9FvsywG7DCzjCfF3KVuIJL80ees6ym58+jkLDGCNZFDxOVnhBcHsjymC3BFEMT7mx0K2V3ETjHVOb6R7JdLtGiUBbzCX8QubjUWGkO5XahJgZ6MpKRtw0VA4Ge++k1MbPPJShThLWliqu6ekHJV66oEY7VdJmMq/rJVO4gvkUdHzNE5JnNWAR1DW+b8T6UnWksExvQY3V1iFG5RMdZRX2beH1mxCQGVj2NhEP6ifrrVXnmeP703x+jAYfbiPkpRLGYW5bvCUyQQcKTkaW7qWrCoQCVSc3c/+CvaT23pS4aivs+3MKK97Q1Pmge6CcodkolixTmiYRYt+6iyUqPucLBW1mQ4ZOkgF/8gwpkO9aURmd3ZirbkOjqdVlUTIUiwNVWBw6GU3ZQintlIN6dGFsDLUAtxRutqOB9NT7qVhLhlzVZEBc41WTpz31stWPip3Ltlw7vUCJhtCB5wJERq+txuuWWklBedvBPgkQM732SYtkky0jePpu5kw==", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "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": "\n 827209d0-7f67-46b4-d68e-08d833c6dad6", "X-MS-Exchange-CrossTenant-originalarrivaltime": "29 Jul 2020 13:54:03.8410 (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": "\n bJOr0giOrjOhGUg0WZNw8MZtGS4a0DRcEU7VgogClA5xIeZNp6a81NIWKcE9+OHsim+8Ze1YRaITPibYNqQeTfC1IdK3RBBXaxcH06HqFOk=", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BY5PR11MB4120", "X-OriginatorOrg": "intel.com", "Subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116870, "web_url": "https://patches.dpdk.org/comment/116870/", "msgid": "<CAJFAV8ybYZuokpo3FXBHCD8mdj4OUL2aMGBrHPjVsmKv8HL9vA@mail.gmail.com>", "list_archive_url": "https://inbox.dpdk.org/dev/CAJFAV8ybYZuokpo3FXBHCD8mdj4OUL2aMGBrHPjVsmKv8HL9vA@mail.gmail.com", "date": "2020-07-29T13:59:35", "subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "submitter": { "id": 1173, "url": "https://patches.dpdk.org/api/people/1173/?format=api", "name": "David Marchand", "email": "david.marchand@redhat.com" }, "content": "On Wed, Jul 29, 2020 at 3:54 PM Dumitrescu, Cristian\n<cristian.dumitrescu@intel.com> wrote:\n> > -----Original Message-----\n> > From: David Marchand <david.marchand@redhat.com>\n> > Sent: Wednesday, July 29, 2020 2:28 PM\n> > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>\n> > Cc: Xu, Ting <ting.xu@intel.com>; dev <dev@dpdk.org>; dpdk stable\n> > <stable@dpdk.org>; Kevin Traynor <ktraynor@redhat.com>; Luca Boccassi\n> > <bluca@debian.org>\n> > Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache\n> > alignment issue\n> >\n> > On Wed, Jul 29, 2020 at 3:14 PM Dumitrescu, Cristian\n> > <cristian.dumitrescu@intel.com> wrote:\n> > > > Please correct me if I am wrong, but it simply means this part of the\n> > > > table library never worked for 32-bit.\n> > > > It seems more adding 32-bit support rather than a fix and then I\n> > > > wonder if it has its place in rc3.\n> > > >\n> > >\n> > > Functionally. the code works, but performance is affected.\n> > >\n> > > The only thing that prevents the code from working is the check in the\n> > table create function that checks the size of the above structure is 64 bytes,\n> > which caught this issue.\n> >\n> > Yes, and that's my point.\n> > It was not working.\n> > It was not tested.\n> >\n> >\n>\n> Not sure when this code was last tested on 32-bit systems, I'll let the validation folks comment on this, but I cannot rule out a change in compiler behavior either.\n>\n> This is a low complexity and low impact change, hence low risk IMO.\n\nRisk is to be evaluated when there is a need.\nI got pinged on this, like it was the end of the times.\n\nThen I find something that is not worth looking at, hence I am a bit irritated.\n\nAnd please, for the 2nd time, can you look at my comment below?\n\n\n> > > > > diff --git a/lib/librte_table/rte_table_hash_key16.c\n> > > > b/lib/librte_table/rte_table_hash_key16.c\n> > > > > index 2cca1c924..c4384b114 100644\n> > > > > --- a/lib/librte_table/rte_table_hash_key16.c\n> > > > > +++ b/lib/librte_table/rte_table_hash_key16.c\n> > > > > @@ -33,6 +33,7 @@\n> > > > >\n> > > > > #endif\n> > > > >\n> > > > > +#ifdef RTE_ARCH_64\n> > > > > struct rte_bucket_4_16 {\n> > > > > /* Cache line 0 */\n> > > > > uint64_t signature[4 + 1];\n> > > > > @@ -46,6 +47,22 @@ struct rte_bucket_4_16 {\n> > > > > /* Cache line 2 */\n> > > > > uint8_t data[0];\n> > > > > };\n> > > > > +#else\n> > > > > +struct rte_bucket_4_16 {\n> > > > > + /* Cache line 0 */\n> > > > > + uint64_t signature[4 + 1];\n> > > > > + uint64_t lru_list;\n> > > > > + struct rte_bucket_4_16 *next;\n> > > > > + uint32_t pad;\n> > > > > + uint64_t next_valid;\n> > > > > +\n> > > > > + /* Cache line 1 */\n> > > > > + uint64_t key[4][2];\n> > > > > +\n> > > > > + /* Cache line 2 */\n> > > > > + uint8_t data[0];\n> > > > > +};\n> > > > > +#endif\n> > > >\n> > > > The change could simply be:\n> > > >\n> > > > @@ -38,6 +38,9 @@ struct rte_bucket_4_16 {\n> > > > uint64_t signature[4 + 1];\n> > > > uint64_t lru_list;\n> > > > struct rte_bucket_4_16 *next;\n> > > > +#ifndef RTE_ARCH_64\n> > > > + uint32_t pad;\n> > > > +#endif\n> > > > uint64_t next_valid;\n> > > >\n> > > > /* Cache line 1 */\n> > > >\n> > > > It avoids duplicating the whole structure definition (we could miss\n> > > > updating one side of the #ifdef later).\n> > > > Idem for the other \"8\" and \"32\" structures.\n> >\n> >\n> > What about this comment?\n\nWhat about this comment?", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 9B45FA052B;\n\tWed, 29 Jul 2020 15:59:53 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 732121BFD6;\n\tWed, 29 Jul 2020 15:59:53 +0200 (CEST)", "from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com\n [205.139.110.120]) by dpdk.org (Postfix) with ESMTP id 247014C98\n for <dev@dpdk.org>; Wed, 29 Jul 2020 15:59:52 +0200 (CEST)", "from mail-vk1-f200.google.com (mail-vk1-f200.google.com\n [209.85.221.200]) (Using TLS) by relay.mimecast.com with ESMTP id\n us-mta-156-CGTzSCHNM4SZHMhMyYQlBw-1; Wed, 29 Jul 2020 09:59:47 -0400", "by mail-vk1-f200.google.com with SMTP id k185so1351476vke.10\n for <dev@dpdk.org>; Wed, 29 Jul 2020 06:59:47 -0700 (PDT)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1596031191;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=9ZpKHXRVOT/bTMYTY4RDXvzpJ9qTr+FwqJjUPLrxB7o=;\n b=cx3ujjcb/XLdWm1PWqwaGQvZeWxO2r76q0sf72Q+qf5xdRkL57MiBmwgUoIKQvLLWApJtY\n DnkN7y0sjZML5V2RxljiQniMqxHzNdiTeFPty5RO9xPUHjphsIBfv5hOEKdfF0twBL86m/\n FiICRx/gzQTlMyY7jDwa3P7P5EnFLTU=", "X-MC-Unique": "CGTzSCHNM4SZHMhMyYQlBw-1", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20161025;\n h=x-gm-message-state:mime-version:references:in-reply-to:from:date\n :message-id:subject:to:cc;\n bh=9ZpKHXRVOT/bTMYTY4RDXvzpJ9qTr+FwqJjUPLrxB7o=;\n b=tk/bQG4FPFX7QcboERE93IJYEsKmmsQIlelSRIhx6OLc5tNadEh6JdOOiyEsU130Tw\n 9Uyc73bEtoHqNnZHbxihU92H0NGg3ZtIgiispHwTxXMkh4azafovZ4FcYm7havhhr1Sr\n yfBFAYZhUaWp10CEVnRvkocrrCZ5HtLXt18U7tm977igdN3q+VkDAPNTnL0ZbpgfzR9d\n iPTiApl8B3mhaaOf8mUvM2ioa5JaXN8dhSweuJlclEbeNEYaIheFI5bkjjZbF53U7jxH\n kLqEG6chNEbSNrD2dzuxiBkytzYgHxGsOTqqucmP/2XV/2y9lQB7uv0Dy7czJZ+Rq/wp\n ZI9w==", "X-Gm-Message-State": "AOAM53112FdvrGOdADj3V/cnj+XOKr6wFKch5sW4rgCNdPSEaR8+NSI0\n q19XwTzKu2V56aL34+A2g4CDvVzY/HVvtCcVRNGyShFOSRgDJcSx4fkUJcZi+XGWw/EMNe1KIFf\n L4dvWNnd5FCAlthKuvYY=", "X-Received": [ "by 2002:a9f:2b8d:: with SMTP id\n y13mr23560620uai.126.1596031187121;\n Wed, 29 Jul 2020 06:59:47 -0700 (PDT)", "by 2002:a9f:2b8d:: with SMTP id\n y13mr23560601uai.126.1596031186840;\n Wed, 29 Jul 2020 06:59:46 -0700 (PDT)" ], "X-Google-Smtp-Source": "\n ABdhPJwUg4MHYEqZnU9Hg5S8kNTw0fFj1urcqRDAmRixXQMSQ+C5cQLqRKNquz8xSpxiFGYXk3hxNUjkfpI+KK1lod0=", "MIME-Version": "1.0", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>\n <BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>\n <CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>\n <BYAPR11MB2935CA1D2C9010F40D955B69EB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "In-Reply-To": "\n <BYAPR11MB2935CA1D2C9010F40D955B69EB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "From": "David Marchand <david.marchand@redhat.com>", "Date": "Wed, 29 Jul 2020 15:59:35 +0200", "Message-ID": "\n <CAJFAV8ybYZuokpo3FXBHCD8mdj4OUL2aMGBrHPjVsmKv8HL9vA@mail.gmail.com>", "To": "\"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>", "Cc": "\"Xu, Ting\" <ting.xu@intel.com>, dev <dev@dpdk.org>,\n dpdk stable <stable@dpdk.org>,\n Kevin Traynor <ktraynor@redhat.com>, Luca Boccassi <bluca@debian.org>", "X-Mimecast-Spam-Score": "0", "X-Mimecast-Originator": "redhat.com", "Content-Type": "text/plain; charset=\"UTF-8\"", "Subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116883, "web_url": "https://patches.dpdk.org/comment/116883/", "msgid": "<BYAPR11MB293542E4B50F98B59075F8ABEB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/BYAPR11MB293542E4B50F98B59075F8ABEB700@BYAPR11MB2935.namprd11.prod.outlook.com", "date": "2020-07-29T14:53:10", "subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "submitter": { "id": 19, "url": "https://patches.dpdk.org/api/people/19/?format=api", "name": "Cristian Dumitrescu", "email": "cristian.dumitrescu@intel.com" }, "content": "> -----Original Message-----\n> From: David Marchand <david.marchand@redhat.com>\n> Sent: Wednesday, July 29, 2020 3:00 PM\n> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>\n> Cc: Xu, Ting <ting.xu@intel.com>; dev <dev@dpdk.org>; dpdk stable\n> <stable@dpdk.org>; Kevin Traynor <ktraynor@redhat.com>; Luca Boccassi\n> <bluca@debian.org>\n> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache\n> alignment issue\n> \n> On Wed, Jul 29, 2020 at 3:54 PM Dumitrescu, Cristian\n> <cristian.dumitrescu@intel.com> wrote:\n> > > -----Original Message-----\n> > > From: David Marchand <david.marchand@redhat.com>\n> > > Sent: Wednesday, July 29, 2020 2:28 PM\n> > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>\n> > > Cc: Xu, Ting <ting.xu@intel.com>; dev <dev@dpdk.org>; dpdk stable\n> > > <stable@dpdk.org>; Kevin Traynor <ktraynor@redhat.com>; Luca\n> Boccassi\n> > > <bluca@debian.org>\n> > > Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache\n> > > alignment issue\n> > >\n> > > On Wed, Jul 29, 2020 at 3:14 PM Dumitrescu, Cristian\n> > > <cristian.dumitrescu@intel.com> wrote:\n> > > > > Please correct me if I am wrong, but it simply means this part of the\n> > > > > table library never worked for 32-bit.\n> > > > > It seems more adding 32-bit support rather than a fix and then I\n> > > > > wonder if it has its place in rc3.\n> > > > >\n> > > >\n> > > > Functionally. the code works, but performance is affected.\n> > > >\n> > > > The only thing that prevents the code from working is the check in the\n> > > table create function that checks the size of the above structure is 64\n> bytes,\n> > > which caught this issue.\n> > >\n> > > Yes, and that's my point.\n> > > It was not working.\n> > > It was not tested.\n> > >\n> > >\n> >\n> > Not sure when this code was last tested on 32-bit systems, I'll let the\n> validation folks comment on this, but I cannot rule out a change in compiler\n> behavior either.\n> >\n> > This is a low complexity and low impact change, hence low risk IMO.\n> \n> Risk is to be evaluated when there is a need.\n> I got pinged on this, like it was the end of the times.\n> \n> Then I find something that is not worth looking at, hence I am a bit irritated.\n> \n\nI got pinged as well, and I also had to allocate time on this patch. It probably means it is important for somebody.\n\n> And please, for the 2nd time, can you look at my comment below?\n> \nSorry, I missed it first.\n\n> \n> > > > > > diff --git a/lib/librte_table/rte_table_hash_key16.c\n> > > > > b/lib/librte_table/rte_table_hash_key16.c\n> > > > > > index 2cca1c924..c4384b114 100644\n> > > > > > --- a/lib/librte_table/rte_table_hash_key16.c\n> > > > > > +++ b/lib/librte_table/rte_table_hash_key16.c\n> > > > > > @@ -33,6 +33,7 @@\n> > > > > >\n> > > > > > #endif\n> > > > > >\n> > > > > > +#ifdef RTE_ARCH_64\n> > > > > > struct rte_bucket_4_16 {\n> > > > > > /* Cache line 0 */\n> > > > > > uint64_t signature[4 + 1];\n> > > > > > @@ -46,6 +47,22 @@ struct rte_bucket_4_16 {\n> > > > > > /* Cache line 2 */\n> > > > > > uint8_t data[0];\n> > > > > > };\n> > > > > > +#else\n> > > > > > +struct rte_bucket_4_16 {\n> > > > > > + /* Cache line 0 */\n> > > > > > + uint64_t signature[4 + 1];\n> > > > > > + uint64_t lru_list;\n> > > > > > + struct rte_bucket_4_16 *next;\n> > > > > > + uint32_t pad;\n> > > > > > + uint64_t next_valid;\n> > > > > > +\n> > > > > > + /* Cache line 1 */\n> > > > > > + uint64_t key[4][2];\n> > > > > > +\n> > > > > > + /* Cache line 2 */\n> > > > > > + uint8_t data[0];\n> > > > > > +};\n> > > > > > +#endif\n> > > > >\n> > > > > The change could simply be:\n> > > > >\n> > > > > @@ -38,6 +38,9 @@ struct rte_bucket_4_16 {\n> > > > > uint64_t signature[4 + 1];\n> > > > > uint64_t lru_list;\n> > > > > struct rte_bucket_4_16 *next;\n> > > > > +#ifndef RTE_ARCH_64\n> > > > > + uint32_t pad;\n> > > > > +#endif\n> > > > > uint64_t next_valid;\n> > > > >\n> > > > > /* Cache line 1 */\n> > > > >\n> > > > > It avoids duplicating the whole structure definition (we could miss\n> > > > > updating one side of the #ifdef later).\n> > > > > Idem for the other \"8\" and \"32\" structures.\n> > >\n> > >\n> > > What about this comment?\n> \n> What about this comment?\n> \n\nYou might suspect I also thought about this option. My preference is for the option in the patch for the reasons that IMO it is easier to read and understand the reason for the difference, even though the code is slightly larger. It also leaves the 64-bit code untouched, so it is easier to remove when we finally decide at some point to drop the 32-bit support.\n\nBut I can live with the option you describe as well. Thanks for the input.\n\nFor me, it would be great if somebody on this list could indicate why the 4-byte padding was not inserted by the compiler automatically, and hence the need for this fix.\n\n> \n> --\n> David Marchand", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id E3ABCA052B;\n\tWed, 29 Jul 2020 16:53:18 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id AACC61023;\n\tWed, 29 Jul 2020 16:53:17 +0200 (CEST)", "from mga01.intel.com (mga01.intel.com [192.55.52.88])\n by dpdk.org (Postfix) with ESMTP id 26C04A69;\n Wed, 29 Jul 2020 16:53:15 +0200 (CEST)", "from orsmga007.jf.intel.com ([10.7.209.58])\n by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 29 Jul 2020 07:53:14 -0700", "from orsmsx107.amr.corp.intel.com ([10.22.240.5])\n by orsmga007.jf.intel.com with ESMTP; 29 Jul 2020 07:53:14 -0700", "from ORSEDG002.ED.cps.intel.com (10.7.248.5) by\n ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Wed, 29 Jul 2020 07:53:14 -0700", "from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.174)\n by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Wed, 29 Jul 2020 07:53:14 -0700", "from BYAPR11MB2935.namprd11.prod.outlook.com (2603:10b6:a03:82::24)\n by BYAPR11MB2583.namprd11.prod.outlook.com (2603:10b6:a02:c6::16)\n with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Wed, 29 Jul\n 2020 14:53:11 +0000", "from BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061]) by BYAPR11MB2935.namprd11.prod.outlook.com\n ([fe80::d514:54b4:8e58:2061%3]) with mapi id 15.20.3216.034; Wed, 29 Jul 2020\n 14:53:11 +0000" ], "IronPort-SDR": [ "\n rojUm4D+UT0Y+x1wvk8i/elVSDS2nIqFTkznGciOF/X8TPlAu/1I9vkCFYn/bif39fkq3mCzAx\n GF/QZSYTt6Uw==", "\n 6LdRg2kf9WGwlrj6muUeCrZI8R1tKuX+yBUPaHL6Rmle1cKFVFE0u9KS8P+xv/bHFqQVDuQBkj\n V3gdc31pGBng==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9696\"; a=\"169545574\"", "E=Sophos;i=\"5.75,410,1589266800\"; d=\"scan'208\";a=\"169545574\"", "E=Sophos;i=\"5.75,410,1589266800\"; d=\"scan'208\";a=\"330424327\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=J9uEcprzLdF96vBqTKDijuQ/0RCbouENF2SA1u5gjzWHU4oB70VXOyrBjKfPtknOu484/Z/WbDEe6CMzs6mrojQGt7XwwKFT6DWM6/mhI5P8daZYRLACGcesBVJjC1L1BVm72AZpIU9t/0WoAMdY0gBpaR8cdPozDjm7pygHvlgD0p43tCH7yDYRsK15DDjtNkTQmveKYU63CbleIwnTk+opWw6NE4q6fK1r5cn783S4G0w7WuZ0ULh79ldhcCH09CbmLJGcN3paZIdzh34KI+frdvpL6nigBTrAJDGAxmscNbseL+i/CJzdYocIxyZbxIJ9V0XRxgKSCrJkAUzofw==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=TQBhj0x+i5LhS1t798qAQukQSdbFEPshOZjyyLno784=;\n b=JeGfNZfpTBtzQzf1xOEIDm/LLywkzeEmB5K5etDHoE0Wnyt3n0aYaZrOZYdj24Dp38I5UL1F5EhN94upHup97LbTm70o8Qp359MbJpWZKVK3NPeK4sY0Jt6anzy410uX7tqWdf2L4BPmDrfx6FgKM6ZF+a3r8fKWFGecq/4xIVN3bpTtX8+wUsbjCiq+6SPPIKJ1dtmTdy1s1dnM/vDXmz6/lYDzRh0cMihSbZ8k2HgIsQ9cakOxn5Jeqb3buaqOUD1Dbm21jZvbz95dQxbLxv0xCPNVbPtG5qImpvpt0cy3LbhWRnSLTz1Pi7rCYelgI9IY6C2CgKIkJa3aC/W0Jg==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;\n s=selector2-intel-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=TQBhj0x+i5LhS1t798qAQukQSdbFEPshOZjyyLno784=;\n b=ch8J5rLbeFZ/SwCcPfZcyp8Muf8cemRSJbljTTf8aM63i+A/SyE/0Oky1zDnX8F9jFRJXt7gxReRw98Ic6iRMfj0cGKpfBIteU08dysbkHESy8naEcw52qKO7K+LkTH3W3KaEu5rvOU8lNActdvQvlY4WpdSvldlh6YXV1vQbNs=", "From": "\"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>", "To": "David Marchand <david.marchand@redhat.com>", "CC": "\"Xu, Ting\" <ting.xu@intel.com>, dev <dev@dpdk.org>, dpdk stable\n <stable@dpdk.org>, Kevin Traynor <ktraynor@redhat.com>, Luca Boccassi\n <bluca@debian.org>", "Thread-Topic": "[dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache\n alignment issue", "Thread-Index": "\n AQHWX82i+KTf+DtoXESWs1iJ7M+JEakegFyAgAAShhCAAAXHAIAABh2AgAACmYCAAAUMIA==", "Date": "Wed, 29 Jul 2020 14:53:10 +0000", "Message-ID": "\n <BYAPR11MB293542E4B50F98B59075F8ABEB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>\n <BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>\n <CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>\n <BYAPR11MB2935CA1D2C9010F40D955B69EB700@BYAPR11MB2935.namprd11.prod.outlook.com>\n <CAJFAV8ybYZuokpo3FXBHCD8mdj4OUL2aMGBrHPjVsmKv8HL9vA@mail.gmail.com>", "In-Reply-To": "\n <CAJFAV8ybYZuokpo3FXBHCD8mdj4OUL2aMGBrHPjVsmKv8HL9vA@mail.gmail.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "dlp-version": "11.5.1.3", "dlp-reaction": "no-action", "dlp-product": "dlpe-windows", "authentication-results": "redhat.com; dkim=none (message not signed)\n header.d=none;redhat.com; dmarc=none action=none header.from=intel.com;", "x-originating-ip": "[109.76.64.157]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "12773866-1e2c-496a-24b2-08d833cf1d11", "x-ms-traffictypediagnostic": "BYAPR11MB2583:", "x-ms-exchange-transport-forked": "True", "x-microsoft-antispam-prvs": "\n <BYAPR11MB258303C270BCCBB5A6E0310FEB700@BYAPR11MB2583.namprd11.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:10000;", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam": "BCL:0;", "x-microsoft-antispam-message-info": "\n 3tXjSW3Xhcde8HqDH5AB4WcFpeNxo8jUPJbKcUqKrIVuJGp1MaonmAYpPWGvxFQpZblnYSfIKysMbzBfxPx7VelS8m+boG23SD+RdA9q7ppkbt+9KQePUcllnawBeWuFiRL7GHZGIk3QHT7wuVU60VgU9F30/g5TMwTTaF2SLpKEtTRGlOJp7SAPCptbKOexpUMIiCQenWhgRByq7nDLrhqYfbqn/DinZtGQhBKKfQGNZzmFY5cdA1Wbss100IvU+VJinlNJmRs1r1yCuTNML/diABVleFt3BiOuLPUw3sBg6xIZ1i/RnAXU5/0bN51z2VhK2eEhOOA4g1yGGaVfFw==", "x-forefront-antispam-report": "CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:BYAPR11MB2935.namprd11.prod.outlook.com; PTR:; CAT:NONE;\n SFTY:;\n SFS:(4636009)(39860400002)(346002)(376002)(136003)(366004)(396003)(316002)(54906003)(6916009)(8936002)(9686003)(52536014)(8676002)(55016002)(2906002)(86362001)(7696005)(5660300002)(66556008)(76116006)(66476007)(66946007)(66446008)(64756008)(4326008)(83380400001)(6506007)(478600001)(71200400001)(33656002)(186003)(53546011)(26005);\n DIR:OUT; SFP:1102;", "x-ms-exchange-antispam-messagedata": "\n xGbYcbMKjLunIlZHDhgNXBVkY9hfdr992WUNW7Pcyqyn27lYqABNSXrRGI/RPbGKXIBmBIHMz464T76WyWgcjhh/WrrjXVyVTu8cfQ8VZaFA/29RbCF88iE+SgSa2F/9iDRaZpuF9B2aW+BeQVmbxGp8f2GBwJVmXoK0MabR9XPcmbK0kB4qX4eIUoXuUIfPQjQrtgM23W98QaNCi+AUFgGCmbAWa/FNTdTmNAGchwp1YWjmJvQRjUHy7pk5ZamBYde60YYrefwO/XkoWtQ90JGoAnug31MRteylNWUs/O2DKhw0CHvtnbq3XSj+HJTNWE4WjQcuBr8J+wWXGfHGO9o7brPJrYWm7dOkQDrRUaPB4BJFNdRFprswDfpVIV3Pgxkes+uOjaRoYCv0TeXW9q+YXmpKwy832t7rTCpjQLNTn0nySmq+2cl17qv8RyjL/Rwu2WZx3rXMchJ/Dcreg0Vmaa8eL4QQCHMkN7v6w54=", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "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": "\n 12773866-1e2c-496a-24b2-08d833cf1d11", "X-MS-Exchange-CrossTenant-originalarrivaltime": "29 Jul 2020 14:53:10.9506 (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": "\n Jv5NpCvdaVPjdrfbU74x2ieg2hyvE2kErqvY3ksEusRJfyLHyLKO7St5NOKbv5w6I+lBfh97jjX2PRnOrTtYsy239Q5xfWnW6v1Z5p67TXg=", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "BYAPR11MB2583", "X-OriginatorOrg": "intel.com", "Subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116918, "web_url": "https://patches.dpdk.org/comment/116918/", "msgid": "<CY4PR1101MB2310ACC3491D123779DC3E96F8710@CY4PR1101MB2310.namprd11.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/CY4PR1101MB2310ACC3491D123779DC3E96F8710@CY4PR1101MB2310.namprd11.prod.outlook.com", "date": "2020-07-30T06:57:44", "subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "submitter": { "id": 1363, "url": "https://patches.dpdk.org/api/people/1363/?format=api", "name": "Xu, Ting", "email": "ting.xu@intel.com" }, "content": "Hi, all,\n\n> -----Original Message-----\n> From: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>\n> Sent: Wednesday, July 29, 2020 10:53 PM\n> To: David Marchand <david.marchand@redhat.com>\n> Cc: Xu, Ting <ting.xu@intel.com>; dev <dev@dpdk.org>; dpdk stable\n> <stable@dpdk.org>; Kevin Traynor <ktraynor@redhat.com>; Luca Boccassi\n> <bluca@debian.org>\n> Subject: RE: [dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache alignment\n> issue\n> \n> \n> \n> > -----Original Message-----\n> > From: David Marchand <david.marchand@redhat.com>\n> > Sent: Wednesday, July 29, 2020 3:00 PM\n> > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>\n> > Cc: Xu, Ting <ting.xu@intel.com>; dev <dev@dpdk.org>; dpdk stable\n> > <stable@dpdk.org>; Kevin Traynor <ktraynor@redhat.com>; Luca Boccassi\n> > <bluca@debian.org>\n> > Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache\n> > alignment issue\n> >\n> > On Wed, Jul 29, 2020 at 3:54 PM Dumitrescu, Cristian\n> > <cristian.dumitrescu@intel.com> wrote:\n> > > > -----Original Message-----\n> > > > From: David Marchand <david.marchand@redhat.com>\n> > > > Sent: Wednesday, July 29, 2020 2:28 PM\n> > > > To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>\n> > > > Cc: Xu, Ting <ting.xu@intel.com>; dev <dev@dpdk.org>; dpdk stable\n> > > > <stable@dpdk.org>; Kevin Traynor <ktraynor@redhat.com>; Luca\n> > Boccassi\n> > > > <bluca@debian.org>\n> > > > Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix\n> > > > cache alignment issue\n> > > >\n> > > > On Wed, Jul 29, 2020 at 3:14 PM Dumitrescu, Cristian\n> > > > <cristian.dumitrescu@intel.com> wrote:\n> > > > > > Please correct me if I am wrong, but it simply means this part\n> > > > > > of the table library never worked for 32-bit.\n> > > > > > It seems more adding 32-bit support rather than a fix and then\n> > > > > > I wonder if it has its place in rc3.\n> > > > > >\n> > > > >\n> > > > > Functionally. the code works, but performance is affected.\n> > > > >\n> > > > > The only thing that prevents the code from working is the check\n> > > > > in the\n> > > > table create function that checks the size of the above structure\n> > > > is 64\n> > bytes,\n> > > > which caught this issue.\n> > > >\n> > > > Yes, and that's my point.\n> > > > It was not working.\n> > > > It was not tested.\n> > > >\n> > > >\n> > >\n> > > Not sure when this code was last tested on 32-bit systems, I'll let\n> > > the\n> > validation folks comment on this, but I cannot rule out a change in\n> > compiler behavior either.\n> > >\n> > > This is a low complexity and low impact change, hence low risk IMO.\n> >\n> > Risk is to be evaluated when there is a need.\n> > I got pinged on this, like it was the end of the times.\n> >\n> > Then I find something that is not worth looking at, hence I am a bit irritated.\n> >\n> \n> I got pinged as well, and I also had to allocate time on this patch. It probably\n> means it is important for somebody.\n> \n> > And please, for the 2nd time, can you look at my comment below?\n> >\n> Sorry, I missed it first.\n> \n> >\n> > > > > > > diff --git a/lib/librte_table/rte_table_hash_key16.c\n> > > > > > b/lib/librte_table/rte_table_hash_key16.c\n> > > > > > > index 2cca1c924..c4384b114 100644\n> > > > > > > --- a/lib/librte_table/rte_table_hash_key16.c\n> > > > > > > +++ b/lib/librte_table/rte_table_hash_key16.c\n> > > > > > > @@ -33,6 +33,7 @@\n> > > > > > >\n> > > > > > > #endif\n> > > > > > >\n> > > > > > > +#ifdef RTE_ARCH_64\n> > > > > > > struct rte_bucket_4_16 {\n> > > > > > > /* Cache line 0 */\n> > > > > > > uint64_t signature[4 + 1]; @@ -46,6 +47,22 @@ struct\n> > > > > > > rte_bucket_4_16 {\n> > > > > > > /* Cache line 2 */\n> > > > > > > uint8_t data[0];\n> > > > > > > };\n> > > > > > > +#else\n> > > > > > > +struct rte_bucket_4_16 {\n> > > > > > > + /* Cache line 0 */\n> > > > > > > + uint64_t signature[4 + 1];\n> > > > > > > + uint64_t lru_list;\n> > > > > > > + struct rte_bucket_4_16 *next;\n> > > > > > > + uint32_t pad;\n> > > > > > > + uint64_t next_valid;\n> > > > > > > +\n> > > > > > > + /* Cache line 1 */\n> > > > > > > + uint64_t key[4][2];\n> > > > > > > +\n> > > > > > > + /* Cache line 2 */\n> > > > > > > + uint8_t data[0];\n> > > > > > > +};\n> > > > > > > +#endif\n> > > > > >\n> > > > > > The change could simply be:\n> > > > > >\n> > > > > > @@ -38,6 +38,9 @@ struct rte_bucket_4_16 {\n> > > > > > uint64_t signature[4 + 1];\n> > > > > > uint64_t lru_list;\n> > > > > > struct rte_bucket_4_16 *next;\n> > > > > > +#ifndef RTE_ARCH_64\n> > > > > > + uint32_t pad;\n> > > > > > +#endif\n> > > > > > uint64_t next_valid;\n> > > > > >\n> > > > > > /* Cache line 1 */\n> > > > > >\n> > > > > > It avoids duplicating the whole structure definition (we could\n> > > > > > miss updating one side of the #ifdef later).\n> > > > > > Idem for the other \"8\" and \"32\" structures.\n> > > >\n> > > >\n> > > > What about this comment?\n> >\n> > What about this comment?\n> >\n> \n> You might suspect I also thought about this option. My preference is for the\n> option in the patch for the reasons that IMO it is easier to read and\n> understand the reason for the difference, even though the code is slightly\n> larger. It also leaves the 64-bit code untouched, so it is easier to remove when\n> we finally decide at some point to drop the 32-bit support.\n> \n> But I can live with the option you describe as well. Thanks for the input.\n> \n> For me, it would be great if somebody on this list could indicate why the 4-\n> byte padding was not inserted by the compiler automatically, and hence the\n> need for this fix.\n> \n\nThanks for your help and additional works on this patch.\nThe validation team tested this case in a 32-bit environment, besides, there are a series of similar tests in 32-bit environment as well. There might be some practical needs for this.\nTherefore, before we decide to drop 32-bit support formally, I think such modification is OK, if we cannot fix the compiler issue directly.\n\nShall I update the patch as David suggested to make it simpler?\n\n> >\n> > --\n> > David Marchand", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 495B7A052B;\n\tThu, 30 Jul 2020 08:57:54 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 045B81023;\n\tThu, 30 Jul 2020 08:57:53 +0200 (CEST)", "from mga09.intel.com (mga09.intel.com [134.134.136.24])\n by dpdk.org (Postfix) with ESMTP id 1BDB2A69;\n Thu, 30 Jul 2020 08:57:49 +0200 (CEST)", "from fmsmga006.fm.intel.com ([10.253.24.20])\n by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 29 Jul 2020 23:57:48 -0700", "from orsmsx601.amr.corp.intel.com ([10.22.229.14])\n by fmsmga006.fm.intel.com with ESMTP; 29 Jul 2020 23:57:48 -0700", "from orsmsx604.amr.corp.intel.com (10.22.229.17) by\n ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.1713.5; Wed, 29 Jul 2020 23:57:48 -0700", "from ORSEDG002.ED.cps.intel.com (10.7.248.5) by\n orsmsx604.amr.corp.intel.com (10.22.229.17) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5\n via Frontend Transport; Wed, 29 Jul 2020 23:57:48 -0700", "from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.104)\n by edgegateway.intel.com (134.134.137.101) with Microsoft SMTP Server (TLS)\n id 14.3.439.0; Wed, 29 Jul 2020 23:57:45 -0700", "from CY4PR1101MB2310.namprd11.prod.outlook.com\n (2603:10b6:910:1b::16) by CY4PR11MB1432.namprd11.prod.outlook.com\n (2603:10b6:910:5::22) with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.18; Thu, 30 Jul\n 2020 06:57:44 +0000", "from CY4PR1101MB2310.namprd11.prod.outlook.com\n ([fe80::2497:a5ff:5152:7782]) by CY4PR1101MB2310.namprd11.prod.outlook.com\n ([fe80::2497:a5ff:5152:7782%10]) with mapi id 15.20.3239.019; Thu, 30 Jul\n 2020 06:57:44 +0000" ], "IronPort-SDR": [ "\n 16Q3pBS83AXQMAt54zXVOcOisO6zzIU0fmZR8H6wVlIMJY6r/J956RcWnoMB5tM1JSyyzjytQ2\n kfxbUqNUU6Kg==", "\n SutmnWFd5iHTYNHhPqU6ULFOkqrpvHvHu+hbus8pooKpkfFACX1MrHC8EALAst+MFnmuO9b+RL\n TuVu3QcH5nAw==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9697\"; a=\"152776778\"", "E=Sophos;i=\"5.75,413,1589266800\"; d=\"scan'208\";a=\"152776778\"", "E=Sophos;i=\"5.75,413,1589266800\"; d=\"scan'208\";a=\"490559398\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=KDGh3ZjzKqckH7RPFYZa6Df3Ntk8CT/eClLYOufxA66CIwDjOL8LZdix0MyAlB2LqW16kFNNtWufyrQLZuZIY4mOzoVT/Lgfu5Q8RXN/HzvcMh7pBvJSBN6kFscRml7oQ+YTw226Yp+dwcgpL/xTtYwKz2dKJcYXLIihNeL8Zs4GB0Kjqh3uii75CJzFwlamkwNOnssiHozXwAOrIO5kIDnxk8rmEXQTPbRm3jZ+JZ4A+ASfouEhjpK4uRzRxzQuli1oGfukBAJFdLfMCSPl2CYs6PrkgfLPlEOMd050a0eIYfwaY3oSvlH4kVnn4RM1nEpmnmC5XbFeMF9fW4CTfg==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=FGt91b0u/uwOrp/njcc4MY9KUVewQO3kKYLE8KKSc5Q=;\n b=cxhQVEFCkd+P3sedQBtr3+dwJSERMVm1bImDJbf+Wbb0aNNHHvCan4wheaPiyWOFkuFxR5q576SSjS57AGK4Bn5eI96Kgs7YJgQ0zdu8c0yN4EqZd5bsuwG7MusDO76eEdrpCrjT7RZtIXq59DuSBUliNnpwtgstvtNTV3exFDZLHBDpz7XH4KvPJObP3QND0kdk/VxxgKLBWxb6kAcR4X9d4nkmG3Yx1RAfklgFMJArmW5PeJ6lijh5gp6C+G2pK90Ml43vXO4Nv6m4LXaTZAFKd422HRKs6RCuybUg2KRHYaS0sPXkGegeIcHM/tzWPXdgG/KaG/UK4/BQVhmWEA==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;\n s=selector2-intel-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=FGt91b0u/uwOrp/njcc4MY9KUVewQO3kKYLE8KKSc5Q=;\n b=QhsmmA71evQkWvCcwLiYgPOLbzatbxSJ1BjtT0HLeNbSUBBWi3YB+dA9MFs7ntwI30+KOFJ3Sz2M/Lj/KOqp4GCA/IwZD3WNaQiE1MH+mGK3f0C1R5C2ftuAE0i7ZYqG3OO5xeGqJqiprc9iaDoNAXgZ7RfLmLTLOGE3HzYzXwU=", "From": "\"Xu, Ting\" <ting.xu@intel.com>", "To": "\"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>, David Marchand\n <david.marchand@redhat.com>", "CC": "dev <dev@dpdk.org>, dpdk stable <stable@dpdk.org>, Kevin Traynor\n <ktraynor@redhat.com>, Luca Boccassi <bluca@debian.org>", "Thread-Topic": "[dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache\n alignment issue", "Thread-Index": "\n AQHWX82iNlqzroybpk6bRvdW1k5beqkegFyAgAAUQ4CAAAQKAIAAByuAgAABi4CAAA75AIABCWxg", "Date": "Thu, 30 Jul 2020 06:57:44 +0000", "Message-ID": "\n <CY4PR1101MB2310ACC3491D123779DC3E96F8710@CY4PR1101MB2310.namprd11.prod.outlook.com>", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>\n <BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>\n <CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>\n <BYAPR11MB2935CA1D2C9010F40D955B69EB700@BYAPR11MB2935.namprd11.prod.outlook.com>\n <CAJFAV8ybYZuokpo3FXBHCD8mdj4OUL2aMGBrHPjVsmKv8HL9vA@mail.gmail.com>\n <BYAPR11MB293542E4B50F98B59075F8ABEB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "In-Reply-To": "\n <BYAPR11MB293542E4B50F98B59075F8ABEB700@BYAPR11MB2935.namprd11.prod.outlook.com>", "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)\n header.d=none;intel.com; dmarc=none action=none header.from=intel.com;", "x-originating-ip": "[192.198.147.211]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "b6c2346e-41f9-4efd-fb30-08d83455dc36", "x-ms-traffictypediagnostic": "CY4PR11MB1432:", "x-ms-exchange-transport-forked": "True", "x-microsoft-antispam-prvs": "\n <CY4PR11MB1432980B7815832EEBE2AB3BF8710@CY4PR11MB1432.namprd11.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:10000;", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam": "BCL:0;", "x-microsoft-antispam-message-info": "\n Ylx5yHwkn0sj6qApDS2ocx/D0UuTt8hUn0ER1vHzPfne3djVyPYf3gafo/bKnyV/LXXxirpLHphGJW41aVMsY3gKNrSMlg+20c3x6Sl5xV7xh7CkI3aYB/isavBbuPLYmAitATfsnm43OIJ+CmgzY3z+Y/E7HpodkaHnalf33thYx2lwJ3cyZe59acUhg/LofmtMGeIxt3oLPQLjNnTSMYQR+fnFTh3qv90cEWVLXrkKFRnI5WLDs/pIki4qz5QEz/37vUSWziyiHdyHZusk0iuXvI9kWxJgRLxYABPITSVNIMK1wHjN6RoZ4UkvFO5Bam8kscbscSNX11gXuNhYkw==", "x-forefront-antispam-report": "CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:CY4PR1101MB2310.namprd11.prod.outlook.com; PTR:;\n CAT:NONE;\n SFTY:;\n SFS:(4636009)(136003)(39860400002)(346002)(396003)(366004)(376002)(66446008)(76116006)(86362001)(64756008)(66556008)(66476007)(33656002)(66946007)(186003)(54906003)(110136005)(478600001)(2906002)(26005)(71200400001)(316002)(55016002)(9686003)(53546011)(83380400001)(6506007)(52536014)(7696005)(5660300002)(8676002)(4326008)(8936002);\n DIR:OUT; SFP:1102;", "x-ms-exchange-antispam-messagedata": "\n Rk1vpgKG2fz2OlsEYvMx8ihgVrg8qooIcLxr62bChviBzuO9GKSZI7z16bwDM6eU4W66ZfMfZkcwpYLG4P+lkt7ib3v/5CDZRQMII3ISzvalPN5WhLYFlCk3JbrYv6ibTwl6qF9e6Ahy5TOBQOpH0fr8h093hY1tMFJ8Kr5SbSFmkLvyCM3WtR4glKaRn5494g4slxgEG9fbY+KrG8F62sECmB9nqxVzxDvn00de8TgvScHaoZExuSXC42SyM4b8csleuknTYphIpX4MusDkJO0m+m9meAC/Rx+MS7aCDKHmn0G5ZkH3jEIXyh51KVqi8goDwEbLFBpmEx7FupD/nH2/au89bohljG7aoZoamo1gTOYJ3ZW6Ru2aItntrdNDPmODsa3Ap83MSuaao+jd0cbjyEnFFeck0I3xIwIC/2wMvRJsQuIb8Wdv84IkAzx5UGSLxM2OKXAhpDL/SuFfC1RZ/vFZZpeqkH28qUxlMeHcihO9OAtvEJg42MFU4modrfN8Bpm4MDVxIEsKufXCSy+hzndEK6XwdtjZ3VAqSOC1N2Vu7fUQlyTxmuTfg5nNROwy5qIwgbKevPDtsU/ee7HIYpTEJuFBpreUudELPS7uf7uMOyeWQmlz4fTPLd1OGuUE5ENDCf7g9VRQI5l2SQ==", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "MIME-Version": "1.0", "X-MS-Exchange-CrossTenant-AuthAs": "Internal", "X-MS-Exchange-CrossTenant-AuthSource": "\n CY4PR1101MB2310.namprd11.prod.outlook.com", "X-MS-Exchange-CrossTenant-Network-Message-Id": "\n b6c2346e-41f9-4efd-fb30-08d83455dc36", "X-MS-Exchange-CrossTenant-originalarrivaltime": "30 Jul 2020 06:57:44.3201 (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": "\n 0kbMV8qdMwODXte0BYnQMQ7wOhOriieBiL2756W227jFvRwiRYkfcdzyYT/SNgOFQilkJINee5chHWGZ/qMkpw==", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "CY4PR11MB1432", "X-OriginatorOrg": "intel.com", "Subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 116930, "web_url": "https://patches.dpdk.org/comment/116930/", "msgid": "<9347f349-9334-5ffa-81c3-5f79253278af@redhat.com>", "list_archive_url": "https://inbox.dpdk.org/dev/9347f349-9334-5ffa-81c3-5f79253278af@redhat.com", "date": "2020-07-30T10:35:17", "subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "submitter": { "id": 598, "url": "https://patches.dpdk.org/api/people/598/?format=api", "name": "Kevin Traynor", "email": "ktraynor@redhat.com" }, "content": "On 29/07/2020 14:28, David Marchand wrote:\n> On Wed, Jul 29, 2020 at 3:14 PM Dumitrescu, Cristian\n> <cristian.dumitrescu@intel.com> wrote:\n>>> Please correct me if I am wrong, but it simply means this part of the\n>>> table library never worked for 32-bit.\n>>> It seems more adding 32-bit support rather than a fix and then I\n>>> wonder if it has its place in rc3.\n>>>\n>>\n>> Functionally. the code works, but performance is affected.\n>>\n>> The only thing that prevents the code from working is the check in the table create function that checks the size of the above structure is 64 bytes, which caught this issue.\n> \n> Yes, and that's my point.\n> It was not working.\n> It was not tested.\n> \n> \n> This patch asks for backport in stable branches, I will let Kevin and\n> Luca comment.\n> \n\nIt should be in master first, but then it's a fix so I think it can go\nto stable if requested and supported by the table maintainer in the\nevent of any (future) regressions.\n\n> \n>>\n>>>\n>>>\n>>> Now, looking at the details:\n>>>\n>>> For 64-bit on my x86, we have:\n>>>\n>>> struct rte_bucket_4_8 {\n>>> uint64_t signature; /* 0 8 */\n>>> uint64_t lru_list; /* 8 8 */\n>>> struct rte_bucket_4_8 * next; /* 16 8 */\n>>> uint64_t next_valid; /* 24 8 */\n>>> uint64_t key[4]; /* 32 32 */\n>>> /* --- cacheline 1 boundary (64 bytes) --- */\n>>> uint8_t data[]; /* 64 0 */\n>>>\n>>> /* size: 64, cachelines: 1, members: 6 */\n>>> };\n>>>\n>>>\n>>> For 32-bit, we have:\n>>>\n>>> struct rte_bucket_4_8 {\n>>> uint64_t signature; /* 0 8 */\n>>> uint64_t lru_list; /* 8 8 */\n>>> struct rte_bucket_4_8 * next; /* 16 4 */\n>>> uint64_t next_valid; /* 20 8 */\n>>> uint64_t key[4]; /* 28 32 */\n>>> uint8_t data[]; /* 60 0 */\n>>>\n>>> /* size: 60, cachelines: 1, members: 6 */\n>>> /* last cacheline: 60 bytes */\n>>> } __attribute__((__packed__));\n>>>\n>>> ^^ it is interesting that a packed attribute ends up here.\n>>> I saw no such attribute in the library code.\n>>> Compiler black magic at work I guess...\n>>>\n>>\n>> Where do you see the packet attribute? I don't see it in the code.\n> \n> That's pahole reporting this.\n> Maybe the tool extrapolates this attribute based on the next_valid\n> field placement... I don't know.\n> \n>> A packet attribute would explain this issue, i.e. why did the compiler decide not to insert an expected padfing of 4 bytes right after the \"next\" field, that would allow the field \"next_valid\" to be aligned to its natural boundary of 8 bytes.\n> \n> Or a 64-bit field on 32-bit has a special alignment that I am not aware of.\n> \n> \n>>\n>>>\n>>>>\n>>>> Fixes: 8aa327214c (\"table: hash\")\n>>>> Cc: stable@dpdk.org\n>>>>\n>>>> Signed-off-by: Ting Xu <ting.xu@intel.com>\n>>>>\n>>>> ---\n>>>> v3->v4: Change design based on comment\n>>>> v2->v3: Rebase\n>>>> v1->v2: Correct patch time\n>>>> ---\n>>>> lib/librte_table/rte_table_hash_key16.c | 17 +++++++++++++++++\n>>>> lib/librte_table/rte_table_hash_key32.c | 17 +++++++++++++++++\n>>>> lib/librte_table/rte_table_hash_key8.c | 16 ++++++++++++++++\n>>>> 3 files changed, 50 insertions(+)\n>>>>\n>>>> diff --git a/lib/librte_table/rte_table_hash_key16.c\n>>> b/lib/librte_table/rte_table_hash_key16.c\n>>>> index 2cca1c924..c4384b114 100644\n>>>> --- a/lib/librte_table/rte_table_hash_key16.c\n>>>> +++ b/lib/librte_table/rte_table_hash_key16.c\n>>>> @@ -33,6 +33,7 @@\n>>>>\n>>>> #endif\n>>>>\n>>>> +#ifdef RTE_ARCH_64\n>>>> struct rte_bucket_4_16 {\n>>>> /* Cache line 0 */\n>>>> uint64_t signature[4 + 1];\n>>>> @@ -46,6 +47,22 @@ struct rte_bucket_4_16 {\n>>>> /* Cache line 2 */\n>>>> uint8_t data[0];\n>>>> };\n>>>> +#else\n>>>> +struct rte_bucket_4_16 {\n>>>> + /* Cache line 0 */\n>>>> + uint64_t signature[4 + 1];\n>>>> + uint64_t lru_list;\n>>>> + struct rte_bucket_4_16 *next;\n>>>> + uint32_t pad;\n>>>> + uint64_t next_valid;\n>>>> +\n>>>> + /* Cache line 1 */\n>>>> + uint64_t key[4][2];\n>>>> +\n>>>> + /* Cache line 2 */\n>>>> + uint8_t data[0];\n>>>> +};\n>>>> +#endif\n>>>\n>>> The change could simply be:\n>>>\n>>> @@ -38,6 +38,9 @@ struct rte_bucket_4_16 {\n>>> uint64_t signature[4 + 1];\n>>> uint64_t lru_list;\n>>> struct rte_bucket_4_16 *next;\n>>> +#ifndef RTE_ARCH_64\n>>> + uint32_t pad;\n>>> +#endif\n>>> uint64_t next_valid;\n>>>\n>>> /* Cache line 1 */\n>>>\n>>> It avoids duplicating the whole structure definition (we could miss\n>>> updating one side of the #ifdef later).\n>>> Idem for the other \"8\" and \"32\" structures.\n> \n> \n> What about this comment?\n> \n>", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 580A8A0518;\n\tThu, 30 Jul 2020 12:35:28 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 374651C023;\n\tThu, 30 Jul 2020 12:35:28 +0200 (CEST)", "from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com\n [207.211.31.81]) by dpdk.org (Postfix) with ESMTP id 1EBE711A2\n for <dev@dpdk.org>; Thu, 30 Jul 2020 12:35:26 +0200 (CEST)", "from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com\n [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id\n us-mta-405-8pb5GnpxM8WonYLpc7RtYQ-1; Thu, 30 Jul 2020 06:35:25 -0400", "from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com\n [10.5.11.23])\n (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n (No client certificate requested)\n by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B7E16800597;\n Thu, 30 Jul 2020 10:35:23 +0000 (UTC)", "from [10.33.36.208] (unknown [10.33.36.208])\n by smtp.corp.redhat.com (Postfix) with ESMTP id 39BBC19D7B;\n Thu, 30 Jul 2020 10:35:18 +0000 (UTC)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1596105326;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=eoP8RgAkYupPEK+NC4NTu/Pe01k3O7mVxH+plylS9WE=;\n b=i4XcPSxKnxS+lF6/4voWG6h6FzTEjj1PDYvnjtCL05P9HvVUyBoFT4RGBs76QOMu3eE4kt\n jpBmnlulSsA19f4OWVO7sKGPIqFnV80XyvkKnaLjzUcCex9LCqvhPCdsHvmbrdwKpx7MKT\n eBzoVORJcOU+XEIoCWfMQSm8Nq5CAh8=", "X-MC-Unique": "8pb5GnpxM8WonYLpc7RtYQ-1", "To": "David Marchand <david.marchand@redhat.com>,\n \"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>", "Cc": "\"Xu, Ting\" <ting.xu@intel.com>, dev <dev@dpdk.org>,\n dpdk stable <stable@dpdk.org>, Luca Boccassi <bluca@debian.org>", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>\n <BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>\n <CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>", "From": "Kevin Traynor <ktraynor@redhat.com>", "X-Pep-Version": "2.0", "Message-ID": "<9347f349-9334-5ffa-81c3-5f79253278af@redhat.com>", "Date": "Thu, 30 Jul 2020 11:35:17 +0100", "User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101\n Thunderbird/68.10.0", "MIME-Version": "1.0", "In-Reply-To": "\n <CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>", "Content-Language": "en-US", "X-Scanned-By": "MIMEDefang 2.84 on 10.5.11.23", "X-Mimecast-Spam-Score": "0", "X-Mimecast-Originator": "redhat.com", "Content-Type": "text/plain; charset=utf-8", "Content-Transfer-Encoding": "quoted-printable", "X-Content-Filtered-By": "Mailman/MimeDel 2.1.15", "Subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 118317, "web_url": "https://patches.dpdk.org/comment/118317/", "msgid": "<CY4PR1101MB2310036B0AAA6EE2D020C4DBF8260@CY4PR1101MB2310.namprd11.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/CY4PR1101MB2310036B0AAA6EE2D020C4DBF8260@CY4PR1101MB2310.namprd11.prod.outlook.com", "date": "2020-09-09T06:18:52", "subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "submitter": { "id": 1363, "url": "https://patches.dpdk.org/api/people/1363/?format=api", "name": "Xu, Ting", "email": "ting.xu@intel.com" }, "content": "Hi, All\n\nSorry to bother you again. Since the next release is coming, and this patch is deferred for some time, I'd like to know that shall we continue to merge it?\n\nWhat is the key issue that blocks us? Thanks!\n\nBest Regards,\nXu Ting\n\n> -----Original Message-----\n> From: Kevin Traynor <ktraynor@redhat.com>\n> Sent: Thursday, July 30, 2020 6:35 PM\n> To: David Marchand <david.marchand@redhat.com>; Dumitrescu, Cristian\n> <cristian.dumitrescu@intel.com>\n> Cc: Xu, Ting <ting.xu@intel.com>; dev <dev@dpdk.org>; dpdk stable\n> <stable@dpdk.org>; Luca Boccassi <bluca@debian.org>\n> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache alignment\n> issue\n> \n> \n> \n> On 29/07/2020 14:28, David Marchand wrote:\n> > On Wed, Jul 29, 2020 at 3:14 PM Dumitrescu, Cristian\n> > <cristian.dumitrescu@intel.com> wrote:\n> >>> Please correct me if I am wrong, but it simply means this part of\n> >>> the table library never worked for 32-bit.\n> >>> It seems more adding 32-bit support rather than a fix and then I\n> >>> wonder if it has its place in rc3.\n> >>>\n> >>\n> >> Functionally. the code works, but performance is affected.\n> >>\n> >> The only thing that prevents the code from working is the check in the\n> table create function that checks the size of the above structure is 64 bytes,\n> which caught this issue.\n> >\n> > Yes, and that's my point.\n> > It was not working.\n> > It was not tested.\n> >\n> >\n> > This patch asks for backport in stable branches, I will let Kevin and\n> > Luca comment.\n> >\n> \n> It should be in master first, but then it's a fix so I think it can go to stable if\n> requested and supported by the table maintainer in the event of any (future)\n> regressions.\n> \n> >\n> >>\n> >>>\n> >>>\n> >>> Now, looking at the details:\n> >>>\n> >>> For 64-bit on my x86, we have:\n> >>>\n> >>> struct rte_bucket_4_8 {\n> >>> uint64_t signature; /* 0 8 */\n> >>> uint64_t lru_list; /* 8 8 */\n> >>> struct rte_bucket_4_8 * next; /* 16 8 */\n> >>> uint64_t next_valid; /* 24 8 */\n> >>> uint64_t key[4]; /* 32 32 */\n> >>> /* --- cacheline 1 boundary (64 bytes) --- */\n> >>> uint8_t data[]; /* 64 0 */\n> >>>\n> >>> /* size: 64, cachelines: 1, members: 6 */ };\n> >>>\n> >>>\n> >>> For 32-bit, we have:\n> >>>\n> >>> struct rte_bucket_4_8 {\n> >>> uint64_t signature; /* 0 8 */\n> >>> uint64_t lru_list; /* 8 8 */\n> >>> struct rte_bucket_4_8 * next; /* 16 4 */\n> >>> uint64_t next_valid; /* 20 8 */\n> >>> uint64_t key[4]; /* 28 32 */\n> >>> uint8_t data[]; /* 60 0 */\n> >>>\n> >>> /* size: 60, cachelines: 1, members: 6 */\n> >>> /* last cacheline: 60 bytes */\n> >>> } __attribute__((__packed__));\n> >>>\n> >>> ^^ it is interesting that a packed attribute ends up here.\n> >>> I saw no such attribute in the library code.\n> >>> Compiler black magic at work I guess...\n> >>>\n> >>\n> >> Where do you see the packet attribute? I don't see it in the code.\n> >\n> > That's pahole reporting this.\n> > Maybe the tool extrapolates this attribute based on the next_valid\n> > field placement... I don't know.\n> >\n> >> A packet attribute would explain this issue, i.e. why did the compiler\n> decide not to insert an expected padfing of 4 bytes right after the \"next\" field,\n> that would allow the field \"next_valid\" to be aligned to its natural boundary\n> of 8 bytes.\n> >\n> > Or a 64-bit field on 32-bit has a special alignment that I am not aware of.\n> >\n> >\n> >>\n> >>>\n> >>>>\n> >>>> Fixes: 8aa327214c (\"table: hash\")\n> >>>> Cc: stable@dpdk.org\n> >>>>\n> >>>> Signed-off-by: Ting Xu <ting.xu@intel.com>\n> >>>>\n> >>>> ---\n> >>>> v3->v4: Change design based on comment\n> >>>> v2->v3: Rebase\n> >>>> v1->v2: Correct patch time\n> >>>> ---\n> >>>> lib/librte_table/rte_table_hash_key16.c | 17 +++++++++++++++++\n> >>>> lib/librte_table/rte_table_hash_key32.c | 17 +++++++++++++++++\n> >>>> lib/librte_table/rte_table_hash_key8.c | 16 ++++++++++++++++\n> >>>> 3 files changed, 50 insertions(+)\n> >>>>\n> >>>> diff --git a/lib/librte_table/rte_table_hash_key16.c\n> >>> b/lib/librte_table/rte_table_hash_key16.c\n> >>>> index 2cca1c924..c4384b114 100644\n> >>>> --- a/lib/librte_table/rte_table_hash_key16.c\n> >>>> +++ b/lib/librte_table/rte_table_hash_key16.c\n> >>>> @@ -33,6 +33,7 @@\n> >>>>\n> >>>> #endif\n> >>>>\n> >>>> +#ifdef RTE_ARCH_64\n> >>>> struct rte_bucket_4_16 {\n> >>>> /* Cache line 0 */\n> >>>> uint64_t signature[4 + 1];\n> >>>> @@ -46,6 +47,22 @@ struct rte_bucket_4_16 {\n> >>>> /* Cache line 2 */\n> >>>> uint8_t data[0];\n> >>>> };\n> >>>> +#else\n> >>>> +struct rte_bucket_4_16 {\n> >>>> + /* Cache line 0 */\n> >>>> + uint64_t signature[4 + 1];\n> >>>> + uint64_t lru_list;\n> >>>> + struct rte_bucket_4_16 *next;\n> >>>> + uint32_t pad;\n> >>>> + uint64_t next_valid;\n> >>>> +\n> >>>> + /* Cache line 1 */\n> >>>> + uint64_t key[4][2];\n> >>>> +\n> >>>> + /* Cache line 2 */\n> >>>> + uint8_t data[0];\n> >>>> +};\n> >>>> +#endif\n> >>>\n> >>> The change could simply be:\n> >>>\n> >>> @@ -38,6 +38,9 @@ struct rte_bucket_4_16 {\n> >>> uint64_t signature[4 + 1];\n> >>> uint64_t lru_list;\n> >>> struct rte_bucket_4_16 *next;\n> >>> +#ifndef RTE_ARCH_64\n> >>> + uint32_t pad;\n> >>> +#endif\n> >>> uint64_t next_valid;\n> >>>\n> >>> /* Cache line 1 */\n> >>>\n> >>> It avoids duplicating the whole structure definition (we could miss\n> >>> updating one side of the #ifdef later).\n> >>> Idem for the other \"8\" and \"32\" structures.\n> >\n> >\n> > What about this comment?\n> >\n> >", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 1F615A04B1;\n\tWed, 9 Sep 2020 08:19:00 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 3EEC11C0BC;\n\tWed, 9 Sep 2020 08:18:59 +0200 (CEST)", "from mga07.intel.com (mga07.intel.com [134.134.136.100])\n by dpdk.org (Postfix) with ESMTP id 1F9371C0BC;\n Wed, 9 Sep 2020 08:18:56 +0200 (CEST)", "from fmsmga007.fm.intel.com ([10.253.24.52])\n by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 08 Sep 2020 23:18:55 -0700", "from orsmsx601.amr.corp.intel.com ([10.22.229.14])\n by fmsmga007.fm.intel.com with ESMTP; 08 Sep 2020 23:18:55 -0700", "from orsmsx601.amr.corp.intel.com (10.22.229.14) by\n ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.1713.5; Tue, 8 Sep 2020 23:18:54 -0700", "from ORSEDG601.ED.cps.intel.com (10.7.248.6) by\n orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5\n via Frontend Transport; Tue, 8 Sep 2020 23:18:54 -0700", "from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.169)\n by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.1.1713.5; Tue, 8 Sep 2020 23:18:53 -0700", "from CY4PR1101MB2310.namprd11.prod.outlook.com\n (2603:10b6:910:1b::16) by CY4PR1101MB2087.namprd11.prod.outlook.com\n (2603:10b6:910:25::20) with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.16; Wed, 9 Sep\n 2020 06:18:52 +0000", "from CY4PR1101MB2310.namprd11.prod.outlook.com\n ([fe80::64a7:149e:a731:4f3d]) by CY4PR1101MB2310.namprd11.prod.outlook.com\n ([fe80::64a7:149e:a731:4f3d%12]) with mapi id 15.20.3348.019; Wed, 9 Sep 2020\n 06:18:52 +0000" ], "IronPort-SDR": [ "\n 8iPWoP3BNNjoBRyZbilV7D56xfwyQ40W7Anl5aW5E3qqRxVsQuTlsCZB1B4mYQGYSPJZEVkMCa\n TZ6RW4MV0Amw==", "\n X8DPM7ljddfo7TJDKhXPr+vLwXVsv4T5C22KDpyZjEYkt952LcsmDMvcmq8/M6ZM9NGz+HcIXf\n J04AUrHz+DTw==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9738\"; a=\"222482276\"", "E=Sophos;i=\"5.76,408,1592895600\"; d=\"scan'208\";a=\"222482276\"", "E=Sophos;i=\"5.76,408,1592895600\"; d=\"scan'208\";a=\"284767434\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=VWMBmr34DwZ95Iv30FHTazRC2WyeRpt2S7izf+2WNRFjJ1DcMEbyeTAZDXWb05Yi8+9LSrjHhjQlRHL9JdPcZrEJxR/mDXJa5+4AEIL7qRDSjJW1YrQGO9Ct5meXDr+HWw5FATmGih72ep9odecAS/NUsDe5V8W2insgmC1fvq8BnvGT6Hm2h/lKuhKDmkxcG/TxtRJ2k6PPTRxUKG2rwj0MD1X1qxaN0rQXK16FL7yZXzD/ynU+fxo3xkxsGry9gWO022lCYxJ2692ncmOTdd6zjnuDa44v7858s615+W57RkGNpyl+r8cqUgaFo/JuQgAwNcFMJPkWuTG3Es0H2w==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=bopbEwxDi9PuIbP+gjpJrGU6+fb540iplHWyVpPV9ao=;\n b=k4gnuGzZoP8GinTOoJvlQbg/fpyCiwAhOEXrFNZnb5g1OFvy7FePjVNQdvvPxl+hhixokpAP7FLNtXNGvJuDeaR4wULwqyNO8ftUuDoRwJdo4xF/8Jk8EIT9wGG1kznGRzF7bnBpZoYHAIXNmPup22r74LdN+J1psj1IRZMSHO77YItj+wwk7kyyvpFk65uvSdr4NSikgbHtw5QkPez3UNvTDb7pyA+Lv2Pw0R3l9hKBoM6rFhVPx8trmUTFss77OCmTW3ug4bF/lhdBGw7VUplBPWyS4NFzj3CuXKEEAhOaMDu5Hu5sudwDtOqNWnI9n+F8bazh8lxAOlmkqXyTXA==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;\n s=selector2-intel-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=bopbEwxDi9PuIbP+gjpJrGU6+fb540iplHWyVpPV9ao=;\n b=jmIkccRVJ6NWNYUPH+i9atrMRbrSgUzcRafuijyZaDU2Mj0P/LAuXrNHBuo8sO0ymmb8jk8Eygh4uhJDUDPZTDOuWt/cDiLzdCSGjuLLA+Nvw/QCReYgg+VJTE2XnQCqReYwz36bevgE5EeYm6cAMQE1QLI3o7iwroCDDaNVem4=", "From": "\"Xu, Ting\" <ting.xu@intel.com>", "To": "Kevin Traynor <ktraynor@redhat.com>, David Marchand\n <david.marchand@redhat.com>, \"Dumitrescu, Cristian\"\n <cristian.dumitrescu@intel.com>", "CC": "dev <dev@dpdk.org>, dpdk stable <stable@dpdk.org>, Luca Boccassi\n <bluca@debian.org>", "Thread-Topic": "[dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache\n alignment issue", "Thread-Index": "AQHWX82iNlqzroybpk6bRvdW1k5beqkegFyAgAAUQ4CAAAQKAIABYfeAgEAmyGA=", "Date": "Wed, 9 Sep 2020 06:18:52 +0000", "Message-ID": "\n <CY4PR1101MB2310036B0AAA6EE2D020C4DBF8260@CY4PR1101MB2310.namprd11.prod.outlook.com>", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>\n <BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>\n <CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>\n <9347f349-9334-5ffa-81c3-5f79253278af@redhat.com>", "In-Reply-To": "<9347f349-9334-5ffa-81c3-5f79253278af@redhat.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "dlp-version": "11.5.1.3", "dlp-product": "dlpe-windows", "dlp-reaction": "no-action", "authentication-results": "redhat.com; dkim=none (message not signed)\n header.d=none;redhat.com; dmarc=none action=none header.from=intel.com;", "x-originating-ip": "[192.55.46.36]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "35032ecd-a447-463f-7f0d-08d854883924", "x-ms-traffictypediagnostic": "CY4PR1101MB2087:", "x-ms-exchange-transport-forked": "True", "x-microsoft-antispam-prvs": "\n <CY4PR1101MB2087F888732258FD93C8526EF8260@CY4PR1101MB2087.namprd11.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:10000;", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam": "BCL:0;", "x-microsoft-antispam-message-info": "\n 4mfa/lU5O8pIPb90XZFpfYtN2xXJ2EJaRn9OH7sC4o2LXurb7SN9fIEKWZ88UdlJtEogzQlEihxP2SyrzfznwKnEDcOlPjA0dU2ii8bqHdIbyKniLAIb59NaGdzMcLsxonzCOlTP6R6dJ/nYJrR2vbc9kpsQ1k8vYRmlpeTzkg1rgHov6H5lYa9Jv/mIX9gqTgnp5fnc2pZo4Us3f6CG91Cw+41/8P8HVrcJuPM5nQlqT1o3LY0ORdXXoJV7mWqD1pHEEUOCETiWpWsTaOAG0+CiwDwv+qUif7ndYptfFtnnk9sfrdWzavRe3W9f4HMUN2a3aTvNeBwkdeDW3uclng==", "x-forefront-antispam-report": "CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:CY4PR1101MB2310.namprd11.prod.outlook.com; PTR:;\n CAT:NONE;\n SFS:(4636009)(136003)(366004)(396003)(39860400002)(376002)(346002)(8936002)(4326008)(26005)(55016002)(5660300002)(186003)(66446008)(71200400001)(66476007)(86362001)(7696005)(53546011)(66946007)(6506007)(9686003)(76116006)(66556008)(64756008)(54906003)(83380400001)(8676002)(110136005)(52536014)(2906002)(33656002)(316002)(6636002)(478600001);\n DIR:OUT; SFP:1102;", "x-ms-exchange-antispam-messagedata": "\n gBB8JJllFT8TW8CZxmvhQMh1WjwQUD/r0+JQ5BLv6lIVQw8CACniNs+semtX2ftNIWP+DpI/FFpRuXX3uQzbBUa4uUIZwdvhVL9LG9S/p2qeq+yyESUJvtCfIkGL+8OK0vF20YOnvvrYZfyeNip5hM80Ma+JDrKYZ0+F+PtP/h1WgukYsjx2aJO4xxnyE89WYD8EEUIKIOL4P4VQojR+dgAbvlXSijlZ7sBn8OKjQifuE4zWp6HFC7Z1ZyhcTSRoZybF6wInz6VzLs3Z8Z58kSHbKJCiAUAjKEOVbt/4jHszNfB37/jvwUq3p80gSI1lF6Xii40jNt0YRLiSsBqjfgAbKwCkYyWnbme/Q0QpN9mvPmTiUcZG/qiJuucTMkWqcXxPYBgP7qtBQJJeoACRHcdFsuLSOwZyMgJjSgg0bryrRXBS4cydTPU0CvPe5ROfLHbTYHhXQL2oYMtRtPuISG63XTCkC78PwlDWqwBU0K3IJdmMRPSPLDm/yl7sEwE5L/59DdZELQb4Nrt6Za5aXqNaWBMREE+iLBItQEl76qD6pNMCWD5iDTxt+3gP7vkoN1zTmd783i6bWV81BGsuHy0JMLoJjS1UauQEEOuPcAjQxXfvObZtom1EpYwlreuK3gqDBakGQg/womfn6mQZHw==", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "MIME-Version": "1.0", "X-MS-Exchange-CrossTenant-AuthAs": "Internal", "X-MS-Exchange-CrossTenant-AuthSource": "\n CY4PR1101MB2310.namprd11.prod.outlook.com", "X-MS-Exchange-CrossTenant-Network-Message-Id": "\n 35032ecd-a447-463f-7f0d-08d854883924", "X-MS-Exchange-CrossTenant-originalarrivaltime": "09 Sep 2020 06:18:52.2814 (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": "\n 0bTp05oUbWXEc/G3FUAQL3QHxm4jbeNmp9QjcMRe3e5YVysWQzJEYJO5B+ObeBM+5wpZVjpgktsACqVuaWTfAw==", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "CY4PR1101MB2087", "X-OriginatorOrg": "intel.com", "Subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 118697, "web_url": "https://patches.dpdk.org/comment/118697/", "msgid": "<CAJFAV8wc-qAoCa2qDwBoFdCesd_mnpZkQFQdDjF9BXq7Tdz8zQ@mail.gmail.com>", "list_archive_url": "https://inbox.dpdk.org/dev/CAJFAV8wc-qAoCa2qDwBoFdCesd_mnpZkQFQdDjF9BXq7Tdz8zQ@mail.gmail.com", "date": "2020-09-15T08:03:11", "subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "submitter": { "id": 1173, "url": "https://patches.dpdk.org/api/people/1173/?format=api", "name": "David Marchand", "email": "david.marchand@redhat.com" }, "content": "On Wed, Sep 9, 2020 at 8:19 AM Xu, Ting <ting.xu@intel.com> wrote:\n> Sorry to bother you again. Since the next release is coming, and this patch is deferred for some time, I'd like to know that shall we continue to merge it?\n>\n> What is the key issue that blocks us? Thanks!\n\nAfaics, Kevin email did not get a reply, so I understand this as an\nimplicit ack from the table maintainers.\nI will take this patch as is (i.e. with the request for backport) in rc1.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id B7858A04C7;\n\tTue, 15 Sep 2020 10:03:29 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 56D271BFC4;\n\tTue, 15 Sep 2020 10:03:29 +0200 (CEST)", "from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [216.205.24.124])\n by dpdk.org (Postfix) with ESMTP id 4E3CC1BF83\n for <dev@dpdk.org>; Tue, 15 Sep 2020 10:03:27 +0200 (CEST)", "from mail-vs1-f70.google.com (mail-vs1-f70.google.com\n [209.85.217.70]) (Using TLS) by relay.mimecast.com with ESMTP id\n us-mta-281-Q9V86Fv9M-KClh11pEng1A-1; Tue, 15 Sep 2020 04:03:23 -0400", "by mail-vs1-f70.google.com with SMTP id y129so905363vsy.22\n for <dev@dpdk.org>; Tue, 15 Sep 2020 01:03:23 -0700 (PDT)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1600157006;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=g2TdLg7XnTH+hZUmMmOu1qFdXhlHV4bQCJg0KYS7BSQ=;\n b=AtYoXSrBUMn6t979UsG16/N5Xfj20FVGlMZkm4Tu0uMt0mmUqps1im1UBxgOa3x48bxFV1\n Lvu4JWaI1WV/5t8X617LKXStiALhea2iNbJi4IAgNZUxEgsiS/LzJb0c3OKbUiZ/4+RUcj\n mJ38RDPuIcwyQHOr6km4OVPsCn3GCjM=", "X-MC-Unique": "Q9V86Fv9M-KClh11pEng1A-1", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20161025;\n h=x-gm-message-state:mime-version:references:in-reply-to:from:date\n :message-id:subject:to:cc;\n bh=g2TdLg7XnTH+hZUmMmOu1qFdXhlHV4bQCJg0KYS7BSQ=;\n b=gQ/4VU7TA215s0+/yVULF/KR/gFIc7yHdE7fggpFTMuZzy87/IR6c24L/FIZUSgI/F\n Z/K+p39B3JSF9ckmjGhDg4uZThikh8NKChPisdwE8now1em4jSyKK3d5XiFlMuK4FNgv\n CUd6JavZksliyzUuvN/sEC0OhogSDyghQppB7L7IOVILarYHJRnIGEUKiDetRsPL6IjR\n j00h/l+ou4ezVWWAjo6puD2O1cU4v3WlqCzJmVDglpICbPgHlu8lNIVNqmoV0mrX1G2L\n 8lUpb1+7ADYUpZLfg94wXhYqhsFsfEjWW4/g1PAJoSWSG8vYSzkbNjRRzQdhZrK/W97/\n 2GoQ==", "X-Gm-Message-State": "AOAM533SjeUr18fvVotCkFwlTflFQ2yxLMqbJUbds4F02/Ls0T4Xs0ph\n Zne+KUzn2xMdd6JFDiFLiMtI/zWp1f6M68coef8pI2jg3H57z4YhxNoALesv+emOEXJqG6eF8zA\n KQ495kcYevk+F5irgu9s=", "X-Received": [ "by 2002:a67:e190:: with SMTP id e16mr10163516vsl.5.1600157002831;\n Tue, 15 Sep 2020 01:03:22 -0700 (PDT)", "by 2002:a67:e190:: with SMTP id e16mr10163507vsl.5.1600157002639;\n Tue, 15 Sep 2020 01:03:22 -0700 (PDT)" ], "X-Google-Smtp-Source": "\n ABdhPJw//IP7ubDgGDnKC0Ud6uLWKZh3o4Js8GPXqjremakZZ6L/LOmhekumaijP0/FNp6TmoK00PHPi6HfGet3hBUU=", "MIME-Version": "1.0", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>\n <BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>\n <CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>\n <9347f349-9334-5ffa-81c3-5f79253278af@redhat.com>\n <CY4PR1101MB2310036B0AAA6EE2D020C4DBF8260@CY4PR1101MB2310.namprd11.prod.outlook.com>", "In-Reply-To": "\n <CY4PR1101MB2310036B0AAA6EE2D020C4DBF8260@CY4PR1101MB2310.namprd11.prod.outlook.com>", "From": "David Marchand <david.marchand@redhat.com>", "Date": "Tue, 15 Sep 2020 10:03:11 +0200", "Message-ID": "\n <CAJFAV8wc-qAoCa2qDwBoFdCesd_mnpZkQFQdDjF9BXq7Tdz8zQ@mail.gmail.com>", "To": "\"Xu, Ting\" <ting.xu@intel.com>", "Cc": "Kevin Traynor <ktraynor@redhat.com>,\n \"Dumitrescu, Cristian\" <cristian.dumitrescu@intel.com>, dev <dev@dpdk.org>,\n dpdk stable <stable@dpdk.org>, Luca Boccassi <bluca@debian.org>", "Authentication-Results": "relay.mimecast.com;\n auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com", "X-Mimecast-Spam-Score": "0.001", "X-Mimecast-Originator": "redhat.com", "Content-Type": "text/plain; charset=\"UTF-8\"", "Subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 121400, "web_url": "https://patches.dpdk.org/comment/121400/", "msgid": "<CY4PR1101MB23103022B62856E414FF86B9F8050@CY4PR1101MB2310.namprd11.prod.outlook.com>", "list_archive_url": "https://inbox.dpdk.org/dev/CY4PR1101MB23103022B62856E414FF86B9F8050@CY4PR1101MB2310.namprd11.prod.outlook.com", "date": "2020-10-14T08:26:31", "subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "submitter": { "id": 1363, "url": "https://patches.dpdk.org/api/people/1363/?format=api", "name": "Xu, Ting", "email": "ting.xu@intel.com" }, "content": "> -----Original Message-----\n> From: David Marchand <david.marchand@redhat.com>\n> Sent: Tuesday, September 15, 2020 4:03 PM\n> To: Xu, Ting <ting.xu@intel.com>\n> Cc: Kevin Traynor <ktraynor@redhat.com>; Dumitrescu, Cristian\n> <cristian.dumitrescu@intel.com>; dev <dev@dpdk.org>; dpdk stable\n> <stable@dpdk.org>; Luca Boccassi <bluca@debian.org>\n> Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache alignment\n> issue\n> \n> On Wed, Sep 9, 2020 at 8:19 AM Xu, Ting <ting.xu@intel.com> wrote:\n> > Sorry to bother you again. Since the next release is coming, and this patch is\n> deferred for some time, I'd like to know that shall we continue to merge it?\n> >\n> > What is the key issue that blocks us? Thanks!\n> \n> Afaics, Kevin email did not get a reply, so I understand this as an implicit ack\n> from the table maintainers.\n> I will take this patch as is (i.e. with the request for backport) in rc1.\n> \n\nKindly remind RC1 is coming soon. If there is no additional comments, could this be merged?\n\n> \n> --\n> David Marchand", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id CC4B4A04B7;\n\tWed, 14 Oct 2020 10:26:50 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id 497981DCBC;\n\tWed, 14 Oct 2020 10:26:38 +0200 (CEST)", "from mga03.intel.com (mga03.intel.com [134.134.136.65])\n by dpdk.org (Postfix) with ESMTP id C62041DCB8;\n Wed, 14 Oct 2020 10:26:34 +0200 (CEST)", "from orsmga007.jf.intel.com ([10.7.209.58])\n by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 14 Oct 2020 01:26:34 -0700", "from fmsmsx606.amr.corp.intel.com ([10.18.126.86])\n by orsmga007.jf.intel.com with ESMTP; 14 Oct 2020 01:26:33 -0700", "from fmsmsx603.amr.corp.intel.com (10.18.126.83) by\n fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id\n 15.1.1713.5; Wed, 14 Oct 2020 01:26:33 -0700", "from fmsedg602.ED.cps.intel.com (10.1.192.136) by\n fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5\n via Frontend Transport; Wed, 14 Oct 2020 01:26:33 -0700", "from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.174)\n by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server\n (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id\n 15.1.1713.5; Wed, 14 Oct 2020 01:26:32 -0700", "from CY4PR1101MB2310.namprd11.prod.outlook.com\n (2603:10b6:910:1b::16) by CY4PR11MB1573.namprd11.prod.outlook.com\n (2603:10b6:910:c::19) with Microsoft SMTP Server (version=TLS1_2,\n cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.28; Wed, 14 Oct\n 2020 08:26:31 +0000", "from CY4PR1101MB2310.namprd11.prod.outlook.com\n ([fe80::69cb:1c26:c52c:c2a6]) by CY4PR1101MB2310.namprd11.prod.outlook.com\n ([fe80::69cb:1c26:c52c:c2a6%3]) with mapi id 15.20.3477.020; Wed, 14 Oct 2020\n 08:26:31 +0000" ], "IronPort-SDR": [ "\n 3DBSr+NNQv0IQqH4HQmSEqCs/39jNMFKCz4AOt4GHuE2ALJrjssVvARt9tGmifOmX2rtQ2VpFS\n KzmNTHsqrJuQ==", "\n h62+PLPN+8prv8qYnaPK2ywRhlS5t4j3ZwBYBi//Z5fxnbUE0sD0VKYkqQfUCiwRGB51td5TwQ\n prEizARESoYw==" ], "X-IronPort-AV": [ "E=McAfee;i=\"6000,8403,9773\"; a=\"166123439\"", "E=Sophos;i=\"5.77,374,1596524400\"; d=\"scan'208\";a=\"166123439\"", "E=Sophos;i=\"5.77,374,1596524400\"; d=\"scan'208\";a=\"357309582\"" ], "X-Amp-Result": "SKIPPED(no attachment in message)", "X-Amp-File-Uploaded": "False", "X-ExtLoop1": "1", "ARC-Seal": "i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;\n b=kdWYrv2EF8aJCqBbETbp/Rpq50zucF0LrI7pDPYmhjpQsI10WhAulOmM65WvtylHqNi/D7MruDg96XKjJX7/vu84c0Azi57uXkItNEKAlP+dNMToEwhKyndmTdrwvzI4xOahBtMD4sGDsjKRMAL6V1GF74LagvSu2WkFw7ppWladYh5BS1Lwxd32JdAFrS9ng0EYRKRYl+ckR6GhsO/n6KEU0pg4cHwwkRzSA2WxokrWy7HGH/b/+I89dP0ZVBGoOAjeY4wO36MwEaesAKHOZwcQae9cgD2MFY4WashwwaTA6cg41EL8f4so6+jDd+3oFpBVXGxRnNlRr27j3grBcA==", "ARC-Message-Signature": "i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;\n s=arcselector9901;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=R770g3SkXEMFp0HxMFeCUYIFfBXFfuqv5rT9i0diDxw=;\n b=nTf5I8cJiianCQKKYfGQcfXXPkEfpPiNDk0XaNr9mXwQasT/IPvUxf9LgwJez7fozWUkiOqKSM+Bxf/Q/CHYHywrhYPP/WbF95UR9P2u+Lm/N8dJu47lY2xwIhuu3gDcT1k+F7vdM2xH1nzxb9X7dUjRBXKpKiKc0BKGNzHItC3PbuWtg5czHWsfLNsvIfriiHqIoaeSmkxL+XOLAnAT4MvBHG11/R9Vibdoujekdc3t8NWF+2xhnOZSSTOWe6yU5G512UksEvYEg6SEOg0kjWncbEG6d2iOuwnBS57bzV15GyunjvPvkZqZMt2XQk0JpaPWHPNpb3bKClL+oKxbkg==", "ARC-Authentication-Results": "i=1; mx.microsoft.com 1; spf=pass\n smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com;\n dkim=pass header.d=intel.com; arc=none", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com;\n s=selector2-intel-onmicrosoft-com;\n h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;\n bh=R770g3SkXEMFp0HxMFeCUYIFfBXFfuqv5rT9i0diDxw=;\n b=weVS8zYn1XcsdaoxCgQAWW57/LRpiWH8Z8mRhfxkOOiyf/lGLfP4MHMXbkmpa0VoVtMVqbcvAKldggGN8EADCqXeYeNnaKIUCdSni0kvO0kgxUXjOzsjFtzPM0b8G96zxU/OOeDhILDz0VWga/F5lqsML/T3aKeaaBW2uaAHy4Y=", "From": "\"Xu, Ting\" <ting.xu@intel.com>", "To": "David Marchand <david.marchand@redhat.com>", "CC": "Kevin Traynor <ktraynor@redhat.com>, \"Dumitrescu, Cristian\"\n <cristian.dumitrescu@intel.com>, dev <dev@dpdk.org>, dpdk stable\n <stable@dpdk.org>, Luca Boccassi <bluca@debian.org>", "Thread-Topic": "[dpdk-stable] [dpdk-dev] [PATCH v4] lib/table: fix cache\n alignment issue", "Thread-Index": "\n AQHWX82iNlqzroybpk6bRvdW1k5beqkegFyAgAAUQ4CAAAQKAIABYfeAgEAmyGCACYxLgIAtmZ3Q", "Date": "Wed, 14 Oct 2020 08:26:31 +0000", "Message-ID": "\n <CY4PR1101MB23103022B62856E414FF86B9F8050@CY4PR1101MB2310.namprd11.prod.outlook.com>", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>\n <CAJFAV8zZRQEjVGp07NzuraHuA9YWWK_6VZZ5hN69w2GQuFeTeQ@mail.gmail.com>\n <BYAPR11MB29352D566CB43BB6D5752361EB700@BYAPR11MB2935.namprd11.prod.outlook.com>\n <CAJFAV8wbNnQ_wfAJv8K-Awzi+WHb57hzJCT77LQEQAdyEBBLiA@mail.gmail.com>\n <9347f349-9334-5ffa-81c3-5f79253278af@redhat.com>\n <CY4PR1101MB2310036B0AAA6EE2D020C4DBF8260@CY4PR1101MB2310.namprd11.prod.outlook.com>\n <CAJFAV8wc-qAoCa2qDwBoFdCesd_mnpZkQFQdDjF9BXq7Tdz8zQ@mail.gmail.com>", "In-Reply-To": "\n <CAJFAV8wc-qAoCa2qDwBoFdCesd_mnpZkQFQdDjF9BXq7Tdz8zQ@mail.gmail.com>", "Accept-Language": "en-US", "Content-Language": "en-US", "X-MS-Has-Attach": "", "X-MS-TNEF-Correlator": "", "dlp-version": "11.5.1.3", "dlp-product": "dlpe-windows", "dlp-reaction": "no-action", "authentication-results": "redhat.com; dkim=none (message not signed)\n header.d=none;redhat.com; dmarc=none action=none header.from=intel.com;", "x-originating-ip": "[192.198.147.210]", "x-ms-publictraffictype": "Email", "x-ms-office365-filtering-correlation-id": "97fb3276-494a-45fa-4410-08d8701adae9", "x-ms-traffictypediagnostic": "CY4PR11MB1573:", "x-ms-exchange-transport-forked": "True", "x-microsoft-antispam-prvs": "\n <CY4PR11MB157325B7580B8B9184EFE102F8050@CY4PR11MB1573.namprd11.prod.outlook.com>", "x-ms-oob-tlc-oobclassifiers": "OLM:8882;", "x-ms-exchange-senderadcheck": "1", "x-microsoft-antispam": "BCL:0;", "x-microsoft-antispam-message-info": "\n CbJPh9xTcYXCpUBkNfrn3sJR4oiYRkfWW3777cGz5vjYSySWI9IUnWpWwwWyCclLaZWT9zk9wY3XX/MRMEJEaTj1WWmQesSyhD+4i8ARHG42sq0hJihxxTnI7/Q54ny9hCqVSNVxeD+sBjTMlH4+ZKKqJICoQe9mxr6iEcKVshw+iP0D1wtfkiu1pIE+WOZogLbrZ3kReo8kFJYSKGZoyQDSJxwon+XQN4WFGmgmnn7Tejc2T4ASlb1KUpkJocKs2PSlEPQ3D8juRzHlGVGm6Bi02sFQ16yqUPIohcv5wZGhGXZt+DzE4FVNMdku6ljfZwVRG66gqYghU8UgUtkqXA==", "x-forefront-antispam-report": "CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;\n IPV:NLI; SFV:NSPM; H:CY4PR1101MB2310.namprd11.prod.outlook.com; PTR:;\n CAT:NONE;\n SFS:(4636009)(396003)(39860400002)(376002)(346002)(366004)(136003)(478600001)(83380400001)(55016002)(71200400001)(9686003)(33656002)(7696005)(86362001)(54906003)(5660300002)(316002)(6506007)(2906002)(53546011)(8676002)(4326008)(186003)(26005)(4744005)(66446008)(6916009)(8936002)(66556008)(64756008)(66476007)(76116006)(66946007)(52536014);\n DIR:OUT; SFP:1102;", "x-ms-exchange-antispam-messagedata": "\n sYWSM/gQOdg9qHD6pAA743vsbgqOfUKn9WAEqYWMkRChXO92hfOR+FQ5qwxuNRz2be4tmiq5b9OOHNvzZViedaOKNDa5m4eu2Vdsr27W3YwE2GHWbaDycNmkyoUCpLdhbi2Tju+KKsSt9esBWvYg5yVEuQ/kO4iK01anXE22/SEjyIKZ2MSKhcJ6sjQlxFT7Vw+DVk/5wBpnjshbwqU8c1/dEoJEEUYEIstOA+vxZP8CwrjSaJL/6h1tuqLoYVxK53Uj0IASrn9DurhsD26JKZhxpwzhKLDr2BPRYb6VUCxhEksQY6IHGcjYqYnbX4HG43HCmclxXnE0v25jttwzyLtcrV+x8CEAV+hpMkbJTbeHsdjAiwaUmEOXqPsGGIEkUgKYkak7HyV0tT3gE1UXY2xubWPaTkwhHrN14OJfKf5gpVbChm6BBPkMbSHIsz96kr3W9tI3awAcungdFzMHSwAQXlfszJojJ8g+9PQHoYqnMHOJwXU6ldqRdxAGcgac/A9kQsnPGOIeU4myFrGYnD7gu2BZG4UM6DFIPhOMdcfVof9WvrLPHAE071XC4c9N29W0YM1qCwRvtBPg+nB+FDm2MQIITX+La9yGYfIpeixQBaDtwNLFqKaBS9yKHPIQkUmHwvVCd6X+rTmyi8aTcg==", "Content-Type": "text/plain; charset=\"utf-8\"", "Content-Transfer-Encoding": "base64", "MIME-Version": "1.0", "X-MS-Exchange-CrossTenant-AuthAs": "Internal", "X-MS-Exchange-CrossTenant-AuthSource": "\n CY4PR1101MB2310.namprd11.prod.outlook.com", "X-MS-Exchange-CrossTenant-Network-Message-Id": "\n 97fb3276-494a-45fa-4410-08d8701adae9", "X-MS-Exchange-CrossTenant-originalarrivaltime": "14 Oct 2020 08:26:31.5476 (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": "\n GM/f8LrGz7cVGB2ayzvsDZhls8LhkIIBJt3jeotWx7hpOnfF4B6rahRJTgMKKzMcaqhQyTPApY0ThOJzU22o9Q==", "X-MS-Exchange-Transport-CrossTenantHeadersStamped": "CY4PR11MB1573", "X-OriginatorOrg": "intel.com", "Subject": "Re: [dpdk-dev] [dpdk-stable] [PATCH v4] lib/table: fix cache\n alignment issue", "X-BeenThere": "dev@dpdk.org", "X-Mailman-Version": "2.1.15", "Precedence": "list", "List-Id": "DPDK patches and discussions <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null }, { "id": 121494, "web_url": "https://patches.dpdk.org/comment/121494/", "msgid": "<CAJFAV8xo0mjeZA_-WfLF7aMO=F7Jtx3qWpuy=ypUmSJ66KgwOg@mail.gmail.com>", "list_archive_url": "https://inbox.dpdk.org/dev/CAJFAV8xo0mjeZA_-WfLF7aMO=F7Jtx3qWpuy=ypUmSJ66KgwOg@mail.gmail.com", "date": "2020-10-14T13:53:21", "subject": "Re: [dpdk-dev] [PATCH v4] lib/table: fix cache alignment issue", "submitter": { "id": 1173, "url": "https://patches.dpdk.org/api/people/1173/?format=api", "name": "David Marchand", "email": "david.marchand@redhat.com" }, "content": "On Wed, Jul 22, 2020 at 4:13 AM Ting Xu <ting.xu@intel.com> wrote:\n>\n> When create softnic hash table with 16 keys, it failed on 32-bit\n> environment, because the pointer field in structure rte_bucket_4_16\n> is only 32 bits. Add a padding field in 32-bit environment to keep\n> the structure to a multiple of 64 bytes. Apply this to 8-byte and\n> 32-byte key hash function as well.\n>\n> Fixes: 8aa327214c (\"table: hash\")\n> Cc: stable@dpdk.org\n>\n> Signed-off-by: Ting Xu <ting.xu@intel.com>\nAcked-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>\n\nApplied, thanks.", "headers": { "Return-Path": "<dev-bounces@dpdk.org>", "X-Original-To": "patchwork@inbox.dpdk.org", "Delivered-To": "patchwork@inbox.dpdk.org", "Received": [ "from dpdk.org (dpdk.org [92.243.14.124])\n\tby inbox.dpdk.org (Postfix) with ESMTP id 6493BA04B7;\n\tWed, 14 Oct 2020 15:53:39 +0200 (CEST)", "from [92.243.14.124] (localhost [127.0.0.1])\n\tby dpdk.org (Postfix) with ESMTP id E4BB11DE37;\n\tWed, 14 Oct 2020 15:53:37 +0200 (CEST)", "from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [216.205.24.124])\n by dpdk.org (Postfix) with ESMTP id 5244D1DE35\n for <dev@dpdk.org>; Wed, 14 Oct 2020 15:53:36 +0200 (CEST)", "from mail-vk1-f199.google.com (mail-vk1-f199.google.com\n [209.85.221.199]) (Using TLS) by relay.mimecast.com with ESMTP id\n us-mta-289-CWwuHLXBPxqUBql5nZCOqg-1; Wed, 14 Oct 2020 09:53:33 -0400", "by mail-vk1-f199.google.com with SMTP id i9so722991vki.15\n for <dev@dpdk.org>; Wed, 14 Oct 2020 06:53:33 -0700 (PDT)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1602683614;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n in-reply-to:in-reply-to:references:references;\n bh=RcxyVCK2JIu7Td67RCK4kqzJu02c5MPfgdSAnqwUIcw=;\n b=NViy5Ik0CV4P0NbPjxVnTULtI9PUeM/Y95tgxguIV/Wgxztibad6zqcaAtWBRLym1MbpJE\n 3HRuCkvsMdWJg3XCSYlF783rkzb9Cx5dpOAx7OWHZivYft/cUANs8zb1Zg979FI2dl+gQe\n 5LS5JjEII9sfEqg0J5IDgoSOF+0mHCs=", "X-MC-Unique": "CWwuHLXBPxqUBql5nZCOqg-1", "X-Google-DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20161025;\n h=x-gm-message-state:mime-version:references:in-reply-to:from:date\n :message-id:subject:to:cc;\n bh=RcxyVCK2JIu7Td67RCK4kqzJu02c5MPfgdSAnqwUIcw=;\n b=I3FGaKcGGp7cH3DvE1cJ5kAnCormasCbgY//7DUnIEw1La/NTVK2LeeHUbb7hXwuk7\n lZNlPfaJK6SnDelg4UaNZ+3Wj/aC83KJW14KVFauxEF2SY6j+/+42TGWm3ssN5VK1W6v\n HGq88oLtfghSClSkkD/DmH0HUH+hJrD6TlR9qXsc1AjSkQ/wACxWyr8NCNSPuh0G4QYN\n mq6vS+9haDVPc7QLllZpVl//X7D/SHKCoO5mOd/GKgTY+C1QZvm/UvgEARZ05+40jJ6R\n dtp4aOf9mbbiOoBbiIOKH4IkwZunTqRAOhf9d9qCh06Ext/1TzpKc2yqPsn2m0OL951/\n cy4g==", "X-Gm-Message-State": "AOAM532HEx9Lwtj+FC5x2u4WvWNjtDnH5lRpqQQLhQBhEiZI2rFtVeqU\n Wqx+LYAfch7e5YxENacOjDHdo6tt9Bxac267LcbjxSxZ0ECw8rKB6hDrnUwfnAHxPfPnJmWOPzn\n lfv9UBQpS4HdwIXfGJas=", "X-Received": [ "by 2002:ab0:5926:: with SMTP id n35mr2769136uad.126.1602683612819;\n Wed, 14 Oct 2020 06:53:32 -0700 (PDT)", "by 2002:ab0:5926:: with SMTP id n35mr2769126uad.126.1602683612566;\n Wed, 14 Oct 2020 06:53:32 -0700 (PDT)" ], "X-Google-Smtp-Source": "\n ABdhPJyCQFJ+b8AK7BcAnaqXioBzpgHZnqC+hLLEb9XZOUuuh/tH4xfqoC7i43ROzZBX1p+f1fHGYitpqOtEDneddmQ=", "MIME-Version": "1.0", "References": "<20200616162705.83575-1-ting.xu@intel.com>\n <20200722021628.17194-1-ting.xu@intel.com>", "In-Reply-To": "<20200722021628.17194-1-ting.xu@intel.com>", "From": "David Marchand <david.marchand@redhat.com>", "Date": "Wed, 14 Oct 2020 15:53:21 +0200", "Message-ID": "\n <CAJFAV8xo0mjeZA_-WfLF7aMO=F7Jtx3qWpuy=ypUmSJ66KgwOg@mail.gmail.com>", "To": "Ting Xu <ting.xu@intel.com>", "Cc": "dev <dev@dpdk.org>, Cristian Dumitrescu <cristian.dumitrescu@intel.com>,\n dpdk stable <stable@dpdk.org>, Kevin Traynor <ktraynor@redhat.com>", "Authentication-Results": "relay.mimecast.com;\n auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com", "X-Mimecast-Spam-Score": "0", "X-Mimecast-Originator": "redhat.com", "Content-Type": "text/plain; charset=\"UTF-8\"", "Subject": "Re: [dpdk-dev] [PATCH v4] 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 <dev.dpdk.org>", "List-Unsubscribe": "<https://mails.dpdk.org/options/dev>,\n <mailto:dev-request@dpdk.org?subject=unsubscribe>", "List-Archive": "<http://mails.dpdk.org/archives/dev/>", "List-Post": "<mailto:dev@dpdk.org>", "List-Help": "<mailto:dev-request@dpdk.org?subject=help>", "List-Subscribe": "<https://mails.dpdk.org/listinfo/dev>,\n <mailto:dev-request@dpdk.org?subject=subscribe>", "Errors-To": "dev-bounces@dpdk.org", "Sender": "\"dev\" <dev-bounces@dpdk.org>" }, "addressed": null } ]