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 3120BA0545; Wed, 15 Jul 2020 14:29:28 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F2F0D1BEBF; Wed, 15 Jul 2020 14:29:27 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 6583C1B3BB for ; Wed, 15 Jul 2020 14:29:25 +0200 (CEST) IronPort-SDR: Bi8DDBxSTY9kxzevUdbGS/8s1seS+jtteauK+cUVuki7ZnDVdXmePxTSke6J1FVnqd6qFZEBm4 0vOrdMiVAuEQ== X-IronPort-AV: E=McAfee;i="6000,8403,9682"; a="137260915" X-IronPort-AV: E=Sophos;i="5.75,355,1589266800"; d="scan'208";a="137260915" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jul 2020 05:29:24 -0700 IronPort-SDR: LsmXQ0/H8Dnf93qLqLQWJ1AJdeH2kw/oxYKXdwdRku0UzgNbYuKRHziIeOq/ihK4mZmsKAecMz NjS+o+IboWmw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,355,1589266800"; d="scan'208";a="299873741" Received: from vmedvedk-mobl.ger.corp.intel.com (HELO [10.213.250.89]) ([10.213.250.89]) by orsmga002.jf.intel.com with ESMTP; 15 Jul 2020 05:29:22 -0700 To: Thomas Monjalon Cc: "Kinsella, Ray" , Stephen Hemminger , dev@dpdk.org, david.marchand@redhat.com, jerinj@marvell.com, konstantin.ananyev@intel.com, bruce.richardson@intel.com References: <1758703.2oNzlfH3Ak@thomas> <07b5fd0a-25b7-3bb3-f268-458b2266c93e@intel.com> <4060360.4fru8zSAKM@thomas> From: "Medvedkin, Vladimir" Message-ID: Date: Wed, 15 Jul 2020 13:29:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <4060360.4fru8zSAKM@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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" 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 the 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. > -- Regards, Vladimir