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 CA509A04B7; Tue, 13 Oct 2020 13:27:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2E2471DAAF; Tue, 13 Oct 2020 13:27:42 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id CBE481DAAD for ; Tue, 13 Oct 2020 13:27:39 +0200 (CEST) IronPort-SDR: DCWxsMLxOC052QMeC/vS6PMfXvmsirGDy+aEYXi5jOgffxJKZy8vM+5mMBKdG42/jIcN+AnOCl vbyxHzsO5UVg== X-IronPort-AV: E=McAfee;i="6000,8403,9772"; a="183368716" X-IronPort-AV: E=Sophos;i="5.77,370,1596524400"; d="scan'208";a="183368716" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Oct 2020 04:27:34 -0700 IronPort-SDR: 0mzbkxvqMSnOQmr4XIm/VIn3pHJbE99iQKg4zethUNfHN8byQ1pND3Vew72UFaCb7t+nHui+di bVRItF7y1b2A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,370,1596524400"; d="scan'208";a="299575506" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by fmsmga008.fm.intel.com with ESMTP; 13 Oct 2020 04:27:34 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 13 Oct 2020 04:27:34 -0700 Received: from fmsmsx603.amr.corp.intel.com (10.18.126.83) 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; Tue, 13 Oct 2020 04:27:34 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 13 Oct 2020 04:27:33 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.169) 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; Tue, 13 Oct 2020 04:27:32 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iG5CYskcrUv988toevljV/SZV4h0AlmBlzjZqDu4kzhEnhCuGH9sMSleLotQi2hqn6x32AN842lC0J4JfbzKCJ38/bHaOVyvb4iQoSuBRIKdG+zb91k90S6orgQ5HlFvyotLIQLhCLR4fS85imYUcLljX3UXQCTHAOlQUbjClLEdAGQGpzK3fjrYKupf4kUYu/snTq7uiUFF/EF9nOnLUORkneUmD2ld4OdW+Yc5ePooIgImFXYvwG3hlKLVhPXlPe8pYGRbd4jChZUVW8g0K48eBRoiHbKPYaIz3maA/AmWBaCBHkowd4a0cOjds7JTnuqvtSeQeyd9KnXtk5Hkjg== 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=4mLzouO5xlJd77kgOoP5+MBS9FvdUnUwIhBITqVZxqs=; b=bQzlLsogTtLw3uiSzleFZD2JCGGGjzmQCpS34TUH/cG8HbWPJSbMH9Oq5+s5sLbR2f9jgRibVFDpJYEL/yqfZsIXhNclstexUe0Dob5e0iC13L+ZNpYypb/2mdVGNRicRjdWLVH51Z1zueVCGOX7xOH8IKj6ytScrN18W81evueH6AbLAHFxjAfJiwIOO/QsT49LhtqQ04a6Ml4La+urpWeS7Acg+egjv2PmQ+OSnEzSYA0fiAoaFtgr4uIiCGp2vtHspztsA4EJvkWzg1t8+WXNOQ1mDkJ5V7YTxjwufsrnFtqEEr6QJpYIvuPQNdPesGxfvk+o1NzzV9cN9+tYuA== 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=4mLzouO5xlJd77kgOoP5+MBS9FvdUnUwIhBITqVZxqs=; b=wQTbsqL6hXXQzIFManwbDqimXlIwCH+xVtoslxSMhV062dKvtTI1o6DQ85DoGPWaKOCArwonbq8+hwMdRhGpO6UwQJu1iS1q1qbcU68b7cs6nPJJt6ZpHAWDrDHaukPwrCrwSQ1FyQ1DGF6iKLEA8QWZ+8y2XbtEmMkcX0wRmsM= 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.3455.29; Tue, 13 Oct 2020 11:27:29 +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; Tue, 13 Oct 2020 11:27:29 +0000 From: "Power, Ciara" To: "Ananyev, Konstantin" , 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: AQHWnYMAz4Y1p0fTy0SWh8+VP6BnFamVazrQ Date: Tue, 13 Oct 2020 11:27:29 +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: 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: 5df19eac-6d59-4c93-e245-08d86f6af835 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: iYfhWI57Mztbbsm0BJ2IioRJizOS+InppfBXtrFo2h9/XL5747UODJxbEtNfGpmkOSUtoPksRiqBwTRUREtHBJxXGtYkXsDzNJwETIndkfOZn9N5ePfRPQq9oFFaK3YpuvyVBefr0FkekNMORclpW0Y6JS4+yLsEYUjFk2INrxEikjWB4y8wPTMLsSnd4ZI3ofz/NLFDRtPQopAGk7FHiuK43siVfWyDQb3mjrJP2XL7AuBHxHB0rlqNq6KnDu7S87mDOX567E5KLj7B1DAKpR2Ap/xECqZHLmiR8Djzh2bOeozF7HauYDyAoKWp+Z6NKTNAaHHZOlM5ruOz4hLgGQ== 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)(396003)(366004)(346002)(39860400002)(136003)(66556008)(76116006)(66946007)(66446008)(64756008)(52536014)(66476007)(5660300002)(26005)(186003)(4326008)(86362001)(6506007)(54906003)(110136005)(478600001)(55016002)(7696005)(316002)(8936002)(71200400001)(83380400001)(9686003)(2906002)(107886003)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: VCxhsSpRY7nev+TK7zKIUnB8LH1P+jgddMYyldkgXgRdtGCbW0rYxrOQusTgUB3WZ9xH3scqTSJBIi6oeH0oL5u2eVPlyUb/KvyvjNk/iNWcbdo+62Q4DeV9jkOwtq08VH7rl+fosarFSbJXqo6B6KhiiZezz/bDAp4LQHL9Qzlg3np/UAY/Dbbxa9QQ0jiwHhYi3w/FouR+NVq6my723EUGHXnoE1gxWtiKd/vI4QnFSFjpXerfjkfaw+iFUO6X11+qAwlEK5hQE0UwFGf7wM0KOES9rU9qMT4H6ckcn0RZqK8feAlOoQ8q7BIWH1AZXmuhw4xO5MvCZMHVxzIRl2wy2vbkm97A033/Q1bp/4n6X82zmQWlYAObV2Fz8r6cCLvoOyEFlRYj7ydGTU6pq20K5/GGcZORyCmvXcTJsoQ7inaFBCoB9CuqPidMnefXHXFolvsw9ejS61VtSZRu9BTozq3eRQIKbZTuJ2fCnHFiITt4mmt6bxW1bzElSEPmLylmMMai1B+97zpMvHEcedUfQdW9mLMYFozHjx0MECWWYUBWxcqyMZRJPPPiy/zgTmEWx/jMhhc0TJOKL3Pu64OSrR3WfRgYVLFKGo03FFu00RywUQepMJ7Zts2CCXs8yBOjhJ5T0oGw5vGfJLQXjA== 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: 5df19eac-6d59-4c93-e245-08d86f6af835 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2020 11:27:29.2633 (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: LOODpxVAxNFsFPMzxQZvXkmPfXSloCJY5ccGbhM/Ku6l3kAQes3nZvg/1c3ldmmNtIA+H7pmS06GNdC7bSiojA== 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 Konstantin, >-----Original Message----- >From: Ananyev, Konstantin >Sent: Thursday 8 October 2020 15:55 >To: Olivier Matz ; 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 > >> > >> > > 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 cho= sen. >> > >> > >> > >> > [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 c= all 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 SIMD 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. >> >> 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 >> would have to be registered to notify SIMD bitwidth changes... but I >> don't think it is worth to do it. Instead, it can be documented that >> rte_set_max_simd_bitwidth() has to be called early, before >> rte_eal_init(). > >Actually I also thought about callback approach. >It does complicate things a bit for sure, but on a positive side - it allo= ws to >solve RTE_INIT() code-path selection problem in a generic way, plus it mea= ns >zero changes in the data-path. >So probably worth to consider it. > I am not sure adding callbacks to allow for runtime changes to max SIMD bit= width is worth it. I have sent a new version of my patchset which currently does not have this= suggested rework to use callbacks. Thanks, Ciara