From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3EA05A04BA; Thu, 1 Oct 2020 16:19:51 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4A0071BDDD; Thu, 1 Oct 2020 16:19:49 +0200 (CEST) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 11FAD1BD7D for ; Thu, 1 Oct 2020 16:19:46 +0200 (CEST) IronPort-SDR: etoZcuakXr9ShTnTLVCAg4W/x6E8qPH03nMEAxcswPN5aeOWhVN+FTFU9R13RujtYLOz2m/CtH so3LB8pjbWwA== X-IronPort-AV: E=McAfee;i="6000,8403,9760"; a="247476212" X-IronPort-AV: E=Sophos;i="5.77,323,1596524400"; d="scan'208";a="247476212" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Oct 2020 07:19:42 -0700 IronPort-SDR: Usnks4aeDSqX13chhXQfUl3NNkNgzzrCMH8zMkFgShY9plrY9VlovohbtxsNDFbqVZqh/h0WcB scDWBG2kVQHA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,323,1596524400"; d="scan'208";a="515505104" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by fmsmga005.fm.intel.com with ESMTP; 01 Oct 2020 07:19:41 -0700 Received: from orsmsx601.amr.corp.intel.com (10.22.229.14) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 1 Oct 2020 07:19:41 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Thu, 1 Oct 2020 07:19:41 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.171) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Thu, 1 Oct 2020 07:19:40 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EZ7dxidI/S7wIldr/WfhnQY6ONl7RCc0eyvOTc0WwREYgu1xRsP0Jjt1LVOh6eiu+usbhWPegZG5qDGVUanzx8vS4hY4BQRDpIHMdMBetYNoy/d1uWM9xMN031z97xjvVrjdNmCoF//9S1IiSY0nCkVTF758CmuJ8Bf5FPamwQyhhVP/6mGbBoI6C3rnmDIWDQWsRe+3pVdyeIupd/UwpftrxUcVyG0xNCaiKkQXRpunIyES7gLR2xLoY/sUFZWib343+cw8rLijKJDjbCAkkrGRZagZqz4MPfTc4KTkKpBPvprpzp9KTU2/1+GFZOBjRqBdgrlsGIDqrvx0HJ9R4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=akOn8EvOBaSRP+nkTRiD7+VWzxKUMuvwKPUHTitysEk=; b=JBYB3Hlzc4qeTxjDaclvP+8FFC5PH1RXvm6evLmzQTunOpDGddcUc/kfXIu0Yb2uXvneIUaL2kQzdmM+t5W3xxTwrLmCXN6MUAcm+CK0AjhJn3w8VoNxU5/wR+DhYqdVzxTT23LYft/vRQN1k3CffGbgaCZJxvVkWRWuvlQLOBx+QJzLURbqMeF/05u14SsoMMfhzVZC+gibVoo1+B+ZQmdc8yxYP/BN855jLmO1HBcoCvLEcDBOnSRBoANE1/cX3XiSmKPmLQ/fD022sXT+qna14VmfN9fky4TQOcBfPxtKC250FK85BbLNPz3YG2pyFqkAleVGovlYhtyT1cqnhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=akOn8EvOBaSRP+nkTRiD7+VWzxKUMuvwKPUHTitysEk=; b=fU/uLxaScms5ulVb8rEqRXsh7XkgITObGiwKD75dZgVZRfrGJqDz9n6MoJjzgEvhhVz3BAGZrh+ZOsqP1a3lzH8QEUL0IXuKxh/kU9B46C7G5XQPEQ/7iLowovMZ18pk62bsutB8J1xH2JyCRS2pc8VTqQyH+F6sZi7L2d0pF6M= Received: from DM6PR11MB2555.namprd11.prod.outlook.com (2603:10b6:5:c5::33) by DM6PR11MB2747.namprd11.prod.outlook.com (2603:10b6:5:c6::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.24; Thu, 1 Oct 2020 14:19:38 +0000 Received: from DM6PR11MB2555.namprd11.prod.outlook.com ([fe80::78d4:d670:95af:773d]) by DM6PR11MB2555.namprd11.prod.outlook.com ([fe80::78d4:d670:95af:773d%5]) with mapi id 15.20.3412.028; Thu, 1 Oct 2020 14:19:38 +0000 From: "Power, Ciara" To: "Coyle, David" , "Singh, Jasvinder" , "dev@dpdk.org" CC: Olivier Matz , "O'loingsigh, Mairtin" , "Ryan, Brendan" , "Richardson, Bruce" Thread-Topic: [dpdk-dev] [PATCH v3 17/18] net: add checks for max SIMD bitwidth Thread-Index: AQHWlyrPAXUR/87SBUm5DidwgUNRCKmBR3WAgAAM04CAAXhNgIAAAFtw Date: Thu, 1 Oct 2020 14:19:37 +0000 Message-ID: References: <20200807155859.63888-1-ciara.power@intel.com> <20200930130415.11211-1-ciara.power@intel.com> <20200930130415.11211-18-ciara.power@intel.com> In-Reply-To: Accept-Language: en-IE, 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: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [37.228.239.233] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7ef6952a-dbc4-4f39-139a-08d866150798 x-ms-traffictypediagnostic: DM6PR11MB2747: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pPbMkWjSX6odpOPrL9CexrCvm2DgbGuNtkaRBzcUinufm/Rvx6YpU1CQ/oJzZRllLJoqJSA95sDe9gyHFBT/gK6UJiWrQ8d2++9rmFhtWkggcQ1Bn0ah15n9VSi6pO1YR0Jb22E3NFXLfQbxPFt1q5BzaNoG/hjDB/ofDiN/0G+HiWKQeq/8TVsKPAw2yd8lkA/jKNdLMz6OqkfL04j7UroGNs9Gtj6flqvhf85pyGfwB2UH0vdUAo5tIHFC0owmL2HjCPazynlsMY0TS92gNP9XDfx7JL0zoDR0vbKN5it1ale3c3hYpScTxgZUrCZWOJhIpOC0vinBUwTGjRO41KVgmHlhEaBDEGKq7lzXIZFrMryUlq2/TTRCu6xy2bJp9kpcA51BqU0bneNnfmXAS4AVzPudui+fVU4y00w5dGNsqDXy5jYhwDDk9mQVzVlUZlPll4IDWb4L5KZOt6vslw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB2555.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(39860400002)(396003)(136003)(366004)(346002)(86362001)(186003)(316002)(33656002)(4326008)(110136005)(64756008)(478600001)(66556008)(66476007)(55016002)(66446008)(71200400001)(76116006)(54906003)(66946007)(5660300002)(7696005)(966005)(2906002)(52536014)(8936002)(83380400001)(9686003)(26005)(6506007)(107886003)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 6MK6Uuh/RbYBKg7ifbsuEHT9j2I2SIlSR+kaYJ+YH9q2xHQhPZ0uOZYDJkkwP5Q3WcAoWfsvqLawgntR2hdJjZ3Y/pwF4EEnqQ4iB9WcIwgHZszTkBYtQtRVCQysXlDXP/swDQdYLVqPfJwWPx+GWnBZuAisVpDDvY2oKX52iN0QDJSdIf9pfvXySRJT2fxGYZNMcJrmtLQx8amwLzsekPlHuRniaEG11aOqg5NgWpJtIixIDKWertet4a2S0KXfSSdSpN5kq+T95fBKT4tU7kyYou3hZREr0ZtR9PoobcjIboF6aGu072V5H7Qv5hOCQUpatICDwfZab/co4NsHDRIPHwQfzQaO6v7MYQjB1XOkFiAn9Jct59d4orYZQdFfC4Mk2vP1Pt6vV2EB4f0Yb/7b5uKz7wQWCT6Vqt1Fu66C+gzsMg861h01K3Os0fl0kMqKFuMOI/L0/MLPh0SGZ7XdUP1vv6/Tfu/X/0Gnd+qR53XJ+8l5tuI2BAV/0ogW+I9rejuk5qQ1+NJMHz/GIETMXJO+29T9X56G3mbtKOw6la0vD9LngY6epMxSrNPlAK365j1jT1MNW8Bh4dCb2CankKdzM8VwuGoaNrAY01BI7D2aDHgFrw4nLnACbNWM4Cj+9Fpi1MTM8dUZ30uTfQ== 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: DM6PR11MB2555.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7ef6952a-dbc4-4f39-139a-08d866150798 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2020 14:19:37.8889 (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: fPuNgOr2N132rPBlD7Olm5SR8POF9BDArNphicupSdQZ+WUL37KhS5GFpEItXYYRySgUjIOTBM2yNfdHYQkzkQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2747 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3 17/18] net: add checks for max SIMD bitwidth X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi David, Thanks for reviewing,=20 >-----Original Message----- >From: Coyle, David >Sent: Thursday 1 October 2020 15:17 >To: Singh, Jasvinder ; Power, Ciara >; dev@dpdk.org >Cc: Power, Ciara ; Olivier Matz >; O'loingsigh, Mairtin >; Ryan, Brendan ; >Richardson, Bruce >Subject: RE: [dpdk-dev] [PATCH v3 17/18] net: add checks for max SIMD >bitwidth > >Hi Jasvinder/Ciara > >> -----Original Message----- >> From: Singh, Jasvinder >> > >> > > From: dev On Behalf Of Ciara Power When >> > > choosing a vector path to take, an extra condition must be >> > > satisfied to ensure the max SIMD bitwidth allows for the CPU enabled >path. >> > > >> > > The vector path was initially chosen in RTE_INIT, however this is >> > > no longer suitable as we cannot check the max SIMD bitwidth at that >time. >> > > The default chosen in RTE_INIT is now scalar. For best performance >> > > and to use vector paths, apps must explicitly call the set >> > > algorithm function before using other functions from this library, >> > > as this is where vector handlers are now chosen. >> > >> > [DC] Has it been decided that it is ok to now require applications >> > to pick the CRC algorithm they want to use? >> > >> > An application which previously automatically got SSE4.2 CRC, for >> > example, will now automatically only get scalar. >> > >> > If this is ok, this should probably be called out explicitly in >> > release notes as it may not be Immediately noticeable to users that >> > they now need to select the CRC algo. >> > >> > Actually, in general, the release notes need to be updated for this >> patchset. >> >> The decision to move rte_set_alg() out of RTE_INIT was taken to avoid >> check on max_simd_bitwidth in data path for every single time when >> crc_calc() api is invoked. Based on my understanding, >> max_simd_bitwidth is set after eal init, and when used in crc_calc(), >> it might override the default crc algo set during RTE_INIT. Therefore, >> to avoid extra check on max_simd_bitwidth in data path, better option >> will be to use this static configuration one time after eal init in the = set_algo >API. > >[DC] Yes that is a good change to have made to avoid extra datapath checks= . > >Based on off-list discussion, I now also know the reason behind now >defaulting to scalar CRC in RTE_INIT. If a higher bitwidth CRC was chosen = by >RTE_INIT (e.g. >SSE4.2 CRC) but the max_simd_bitwidth was then set to RTE_NO_SIMD (64) >through the EAL parameter or call to rte_set_max_simd_bitwidth(), then >there is a mismatch if rte_net_crc_set_alg() is not then called to reconfi= gure >the CRC. Defaulting to scalar avoids this mismatch and works on all archs > >As I mentioned before, I think this needs to be called out in release note= s, as >it's an under-the-hood change which could cause app performance to drop if >app developers aren't aware of it - the API itself hasn't changed, so they= may >not read the doxygen :) > Yes that is a good point, I can add to the release notes for this to call i= t out.=20 >> >> >> > > >> > > Suggested-by: Jasvinder Singh >> > > >> > > Signed-off-by: Ciara Power >> > > >> > > --- >> > > v3: >> > > - Moved choosing vector paths out of RTE_INIT. >> > > - Moved checking max_simd_bitwidth into the set_alg function. >> > > --- >> > > lib/librte_net/rte_net_crc.c | 26 +++++++++++++++++--------- >> > > lib/librte_net/rte_net_crc.h | 3 ++- >> > > 2 files changed, 19 insertions(+), 10 deletions(-) >> > > >> > > diff --git a/lib/librte_net/rte_net_crc.c >> > > b/lib/librte_net/rte_net_crc.c index >> > > 9fd4794a9d..241eb16399 100644 >> > > --- a/lib/librte_net/rte_net_crc.c >> > > +++ b/lib/librte_net/rte_net_crc.c >> > >> > >> > >> > > @@ -145,18 +149,26 @@ rte_crc32_eth_handler(const uint8_t *data, >> > > uint32_t data_len) void rte_net_crc_set_alg(enum rte_net_crc_alg >> > > alg) { >> > > + if (max_simd_bitwidth =3D=3D 0) >> > > + max_simd_bitwidth =3D rte_get_max_simd_bitwidth(); >> > > + >> > > switch (alg) { >> > > #ifdef X86_64_SSE42_PCLMULQDQ >> > > case RTE_NET_CRC_SSE42: >> > > - handlers =3D handlers_sse42; >> > > - break; >> > > + if (max_simd_bitwidth >=3D RTE_MAX_128_SIMD) { >> > > + handlers =3D handlers_sse42; >> > > + return; >> > > + } >> > > + RTE_LOG(INFO, NET, "Max SIMD Bitwidth too low, using >> > > scalar\n"); >> > >> > [DC] Not sure if you're aware but there is another patchset which >> > adds an >> > AVX512 CRC implementation and run-time checking of cpuflags to >> > select the CRC path to use: >> > https://patchwork.dpdk.org/project/dpdk/list/?series=3D12596 >> > >> > There will be a task to merge these 2 patchsets if both are merged. >> > It looks fairly straightforward to me to merge these, but it would >> > be good if you take a look too I have looked at that patchset, I agree, I think they will be straightforwa= rd to merge together. Thanks, Ciara