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 C2CC8A053D; Fri, 17 Jul 2020 18:43:39 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A324F1BED5; Fri, 17 Jul 2020 18:43:39 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 4183E1BED2 for ; Fri, 17 Jul 2020 18:43:37 +0200 (CEST) IronPort-SDR: oNcBrNcVkP2C6tdaTGvbvPhaq3GQrMZUBfAIWu2zZlmEBi3ArCIKkL+c5B+K0wHj9b0i23to00 ZoCg6kZbWfzg== X-IronPort-AV: E=McAfee;i="6000,8403,9685"; a="167767508" X-IronPort-AV: E=Sophos;i="5.75,362,1589266800"; d="scan'208";a="167767508" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jul 2020 09:43:35 -0700 IronPort-SDR: VVG6pfW3X9vV5MRugB6l9aFAAn0eW7//k5ms3XqfiDPj4a7HEH3KnlRTMQezQF0Gr955MTGSOp r1IfgtdL50vA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,362,1589266800"; d="scan'208";a="460902583" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga005.jf.intel.com with ESMTP; 17 Jul 2020 09:43:34 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.245]) by IRSMSX101.ger.corp.intel.com ([169.254.1.120]) with mapi id 14.03.0439.000; Fri, 17 Jul 2020 17:43:33 +0100 From: "Richardson, Bruce" To: Thomas Monjalon , "Medvedkin, Vladimir" CC: "Kinsella, Ray" , Stephen Hemminger , "dev@dpdk.org" , "david.marchand@redhat.com" , "jerinj@marvell.com" , "Ananyev, Konstantin" , "Mcnamara, John" , "O'Driscoll, Tim" Thread-Topic: [dpdk-dev] [PATCH v6 0/8] fib: implement AVX512 vector lookup Thread-Index: AQHWWQZe7S89x9sPNkSEhdkCoUEN6qkGBH2AgACaSgCAAHdIAIABQSyAgAANYoCAABd2gIAACD6AgAAEaoCAA3bNUA== Date: Fri, 17 Jul 2020 16:43:32 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B0976C3CD1@IRSMSX103.ger.corp.intel.com> References: <4060360.4fru8zSAKM@thomas> <27499155.uCKWoEMfP3@thomas> In-Reply-To: <27499155.uCKWoEMfP3@thomas> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v6 0/8] fib: implement AVX512 vector lookup 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" > -----Original Message----- > From: Thomas Monjalon > Sent: Wednesday, July 15, 2020 1:45 PM > To: Medvedkin, Vladimir > Cc: Kinsella, Ray ; Stephen Hemminger > ; dev@dpdk.org; david.marchand@redhat.com; > jerinj@marvell.com; Ananyev, Konstantin ; > Richardson, Bruce ; Mcnamara, John > ; O'Driscoll, Tim > Subject: Re: [dpdk-dev] [PATCH v6 0/8] fib: implement AVX512 vector looku= p >=20 > 15/07/2020 14:29, Medvedkin, Vladimir: > > On 15/07/2020 12:59, Thomas Monjalon wrote: > > > 15/07/2020 12:35, Medvedkin, Vladimir: > > >> On 15/07/2020 10:47, Thomas Monjalon wrote: > > >>> 14/07/2020 16:38, Stephen Hemminger: > > >>>> "Kinsella, Ray" wrote: > > >>>>> On 13/07/2020 23:19, Stephen Hemminger wrote: > > >>>>>> Did anyone else see the recent AVX512 discussion from Linus: > > >>>>>> "I hope AVX512 dies a painful death, and that Intel starts > fixing real problems > > >>>>>> instead of trying to create magic instructions to then > create benchmarks that they can look good on. > > >>>>> > > >>>>> Yup - I saw this one. > > >>>>> Sweeping statements like these are good to provoke debate, the > truth is generally more nuanced. > > >>>>> If you continue to read the post, Linus appears to be mostly > questioning microprocessor design decisions. > > >>>>> > > >>>>> That is an interesting discussion, however the reality is that th= e > technology does exists and may be beneficial for Packet Processing. > > >>>>> > > >>>>> I would suggest, we continue to apply the same logic governing > adoption of any technology by DPDK. > > >>>>> When the technology is present and a clear benefit is shown, we > use it with caution. > > >>>>> > > >>>>> In the case of Vladimir's patch, the user has to explicitly > > >>>>> switch on the AVX512 lookup with RTE_FIB_DIR24_8_VECTOR_AVX512. > > >>>> > > >>>> Using what is available makes sense in DPDK. > > >>> > > >>> Why does it require explicit enabling in application? > > >>> AVX512 is not reliable enough to be automatically used when > available? > > >> > > >> It is reliable enough. User have to explicitly trigger to avx512 > > >> lookup because using avx512 instructions can reduce the frequency > > >> of your cores. The user knows their environment better. So the > > >> scalar version is used so as not to affect the frequency. > > > > > > So the user must know which micro-optimization is better for a code > > > they don't know. Reminder: an user is not a developper. > > > I understand we have no better solution though. > > > Can we improve the user experience with some recommendations, numbers= , > etc? > > > > > > > In case where a user is a developer (dpdk users are mostly devs, > > aren't > > they?) who uses the fib library in their app may decide to switch to > > avx512 lookup using rte_fib_set_lookup_fn() when they know that their > > code is already using avx512 (ifdef, startup check, etc). > > In other case an app developer, for example, could provide to user > > command line option or some interactive command to switch lookup > function. > > I'd recommend to run testfib app with various "-v" options to evaluate > > lookup performance on a target system to make a decision. >=20 > I think this is the difference between a library for hackers, and a > product for end-users. > We are not building a product, but we can make a step in that direction b= y > documenting some knowledge. > I don't know exactly what it means in this case, so I'll let others > suggest some doc improvements (if anyone cares). >=20 We have got a patchset in the works to try and make AVX-512 use simpler for= 20.11, by providing both developer APIs and end-user cmdline flags to control this centrally for DPDK, rather than having each library provide its own magic h= ooks to optionally enable this support. As part of that set, we'll see about wha= t doc updates need to be made also - again covering both developer and end-ap= p user. Hopefully we can get that set out soon to get early feedback and reach a go= od conclusion. /Bruce