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 CD11EA04BA; Wed, 7 Oct 2020 13:16:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AD9651B70A; Wed, 7 Oct 2020 13:16:56 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 696B11B703 for ; Wed, 7 Oct 2020 13:16:53 +0200 (CEST) IronPort-SDR: soAmuCS2JG27QbayZLDLglBJGiCFaNACdo0wJzahNb4PWJIolI2BYnxh1GLXTOjmOVdoA8Sm4M +H4rq5B6oarw== X-IronPort-AV: E=McAfee;i="6000,8403,9766"; a="161506755" X-IronPort-AV: E=Sophos;i="5.77,346,1596524400"; d="scan'208";a="161506755" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2020 04:16:43 -0700 IronPort-SDR: 5+zWlZfv0cSBMAGt7DRUxM+2pYSJcE7KQzLBlrHUfAotaykf2ZzbLngTgmIaIpoNd8dQQX/afE 9qQgImEdN29w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,346,1596524400"; d="scan'208";a="328017754" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga002.jf.intel.com with ESMTP; 07 Oct 2020 04:16:43 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 7 Oct 2020 04:16:43 -0700 Received: from fmsmsx607.amr.corp.intel.com (10.18.126.87) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 7 Oct 2020 04:16:42 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx607.amr.corp.intel.com (10.18.126.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Wed, 7 Oct 2020 04:16:42 -0700 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.103) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Wed, 7 Oct 2020 04:16:39 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AALcZe2PWfqEOkiNyY+E8bwDT32YgaJvlMxMnGNp2JK2TddTMdcvLJHtG74xx76AKu4mbDGng2poNcck8h4+Jb+jHXgk+EIo7ITkek1JmM+e0+jLnjSwB0lG+iy3PuuNE3nuRLEp1FjWwO5l5DtVbGKzh8aumjoEQMbhT2HDs/XoHH90vXOF+POXl1eIRdTC9Hz6UB4r4piLcoB8I97F7/GYlDou75I8EXdi3jziOYcrEPbziSPNXQIXmOpl60/mTFYuUFIo1okjF0OuZCvM6ulFIXQzt7o8+O6YNm2hG8s/B571ziUdVE4KBuQhoyFzx2MwOkqdLgvgzLl0D/wUGw== 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=zuSLj6F7xI06E5RtjtZigeQ3tMTT3ImDg/RnXIcSDd8=; b=GFyIObENpJy61H/PXF4hU8Pf9MJW5evg/+MA6nlQNGTSd8Iuj0bShDibxeLCfaNh2cCDX/Z7RzhpmWGoM1U20XwbmHW1R9JygNWZQNfa1PFBW+kKiLwCHE/0lT5yHKA07UnRnaSS6fu72OO4mkpqriA0/BxkLntWfPqZPWRD6pGxL0woKnYnVy1IvK3tdBkZPQZdao7zqGn2HloKTsPncXkt9+ApbR7iz/NCC+3gfN8rdL9KOtqlWpvObbPZQBUOSuccycg/QchUqkhMR2w1q79jDVhHRxLPgcfW16kV0XaX6wALF2reg0fqF5qIQSvtxMcDUJV2RZ+ALJEwxvr72Q== 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=zuSLj6F7xI06E5RtjtZigeQ3tMTT3ImDg/RnXIcSDd8=; b=xP/M6QLA/fBVnjlU9vtGTiYDWeYSGe8WJGWOrKFJBnF9x7xyLfsEKZFJPnM0bUbvaGRC21oFFzNvs4S1LDBg3LQMxW+9ypGFoQ9Zq62xuQPQB+DVj1BY0g/BLTKO5QJu7Zd3bRd0+N3F/1yXogKnPwkzn1CDmpuY5cHMmL0rvFw= Received: from DM6PR11MB2555.namprd11.prod.outlook.com (2603:10b6:5:c5::33) by DM6PR11MB3786.namprd11.prod.outlook.com (2603:10b6:5:142::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.41; Wed, 7 Oct 2020 11:16:36 +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.3433.043; Wed, 7 Oct 2020 11:16:36 +0000 From: "Power, Ciara" To: Olivier Matz CC: "Coyle, David" , "Singh, Jasvinder" , "dev@dpdk.org" , "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/87SBUm5DidwgUNRCKmBR3WAgAAM04CAAXhNgIAAAFtwgAeT0ICAAaabIA== Date: Wed, 7 Oct 2020 11:16:36 +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> <20201006100039.GI21395@platinum> In-Reply-To: <20201006100039.GI21395@platinum> 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: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [78.18.45.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9c02993f-ee08-4c37-c4b7-08d86ab274ac x-ms-traffictypediagnostic: DM6PR11MB3786: 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: s4kOF+NY77L+bqBTXAM9bCCSuUyonEJjlAozLiLCnchwFWsdJmMZk0mh0m2g2cIsVERE3cogGz//2MZN0UUmD2qGN4bHaq7A/SrN+hkmTCSBU0p8h2BFsGQkfaRKlHnnGtG95CDfdItVUr+RPw3qS5IQAuzo15H7hScMeznF+woEWQCB7IiSy8M7KtXEhZP8sxwBCEnLG1KN2p2Iqyf7OxeOX4+SryIoxI7dOSZwuERoCVZCresV86gBUwpG4/ilwLkiLEunHzNwAw+vTEzY5djPoQD/paBxMK/dAb8JuIqxS5snwydVEzpE9HKQb31W6ttcRQDLDmp10rGokp5X2w== 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)(136003)(39860400002)(376002)(396003)(346002)(366004)(2906002)(316002)(8676002)(66946007)(52536014)(8936002)(54906003)(5660300002)(33656002)(66446008)(64756008)(66476007)(76116006)(66556008)(55016002)(26005)(7696005)(186003)(83380400001)(71200400001)(478600001)(86362001)(4326008)(9686003)(6916009)(6506007)(107886003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: NV0oxIUfFebzI5MjPJ0TWc0Oxo/4bu+IOLoHEeR8W/dAl/yxbaC8Ew7v1vZgY/mbRsgdD8OQhwEIfcCo6aq2Y20HxdtaEvsgX2Wt9RB7ijy0qMdmSaaVp6v9Cy9uOEoPleCsgu9o7JgzpiIOmAjV+sLWAL0bspTwTtZuRSysCAdg7+sBFmvNPMwqnYIwPF4tEpyahHkxg4DIcWxfiZ1LfLGdRojrIqBuQLyE7mc4MP+zsWU9kUUO8v7e9glOmMUWNJOfXLAm7y/Ih5Bbro5YajeJPoUACY8COhXmHgixv1M7gkfbM9rDfbDtDQGIz4fpd3rPYHoSDahqCDkPfkAhI8nW9cx+2LnSY9S7o9Eyl89OZhn+Iy1dLynSfa3z7Rged2U8V64KLw1aBiDJkusMif8lG1l+Z6Tr5VyYoO8pPfidcpTwpr5pWRFs9n9Qj3IYaIpC+yWeXY3f0+SehZnYWYT97iO+SOVL1iHWwG5NKmmNDRFSesTqTT4CmA3lfV1aOQo1Nhv4AvbXP0lFbfIGJCHcxoRaTXjuxmecjsKP+Wk62wEnqeJyVI7WoQRma62nObYk2CrOlA2o2FVz0yhOIQJDQjijow1Eit6CGwossbRt+l3OSVazleNwoqdgHYbmrnm1KgwKsy40PdvMSngVFw== 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: 9c02993f-ee08-4c37-c4b7-08d86ab274ac X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2020 11:16:36.5058 (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: Z2MvVhoaIyjwtlB6kX/VvujYzkuOSZRGQTIuPBnAW0xUgk12OML7X0O1Sh/Q3ZOk9WRKSbhLSMxkWoybguud3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3786 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 Olivier, =20 >-----Original Message----- >From: Olivier Matz >Sent: Tuesday 6 October 2020 11:01 >To: Power, Ciara >Cc: Coyle, David ; Singh, Jasvinder >; dev@dpdk.org; O'loingsigh, Mairtin >; Ryan, Brendan ; >Richardson, Bruce >Subject: Re: [dpdk-dev] [PATCH v3 17/18] net: add checks for max SIMD >bitwidth > >Hi, > >On Thu, Oct 01, 2020 at 02:19:37PM +0000, Power, Ciara wrote: >> Hi David, >> >> Thanks for reviewing, >> >> >-----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 reconfigure 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 >> >notes, 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 cal= l it out. > >I don't think it is a good idea to have the scalar crc by default. >To me, the fastest available CRC has to be enabled by default. > >I understand the technical reason why you did it like this however: the SI= MD >bitwidth may not be known at the time the >RTE_INIT(rte_net_crc_init) function is called. > >A simple approach to solve this issue would be to initialize the >rte_net_crc_handler pointer to a handlers_default. The first time a crc is >called, the rte_crc32_*_default_handler() function would check the >configured SIMD bitwidth, and set the handler to the correct one, to avoid= to >do the test for next time. Thanks for this suggestion, will try this for the next version, it seems it= will work quite well, thanks. >This approach still does not solve the case where the SIMD bitwidth is >modified during the life of the application. In this case, a callback woul= d have >to be registered to notify SIMD bitwidth changes... but I don't think it i= s worth >to do it. Instead, it can be documented that >rte_set_max_simd_bitwidth() has to be called early, before rte_eal_init(). > Yes, It is documented in the Doxygen comment for the rte_set_max_simd_bitwi= dth() function that it should be called early, as you mentioned. Thanks, Ciara