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 B7414A0540; Sun, 19 Jul 2020 12:04:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 202331BFBA; Sun, 19 Jul 2020 12:04:07 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 7E7401BFAD for ; Sun, 19 Jul 2020 12:04:05 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id C9C295C0121; Sun, 19 Jul 2020 06:04:03 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Sun, 19 Jul 2020 06:04:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= Auy9IiwmISKnyybUk/UiftDq+IlS0OB0x0eKoohyTJs=; b=HuruAEDoJxJWAzNK Z9Cy07f04cZjCfMXp40aB5b/q8zQZvfRIwDgNh7TZg4ILmfSfGyzxYCLXzcqFUz0 dtJKj33Jb4buYE2F2OXvsVfmqMs2nS7n2RhsA9e/5vH9NrzE1gOXFYg9MMuBKf7X 7k2Ntd4BgBAnd59aoQCq+64JTpiGxuL6QQPKJcZU7suKOz404XgUo4Y+kIhcBRDX 0cE3sp4BR5QcPq2ztIM+j3qt+tzeSAGPLExV7hhRdv8KGS+3JrOpmBCSnPEVBzkL JePVKMI1MV2igrqb1Dk/Lg4idx5xg77IBBw2b1LP0R6Cybtql5NYdzu98CDRvJvy Y89RKQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Auy9IiwmISKnyybUk/UiftDq+IlS0OB0x0eKoohyT Js=; b=eaqrKhQMDqEVDqQRIWmcnh9quc5E1v5eJT/00XKS54XnYL1eOwzkAOr4S XuFMeIp1DFn2SjVwuaLkcMyy7x9upoqJVSL4Fu0aNBJxemSeQXT8PV9J1fxUKGp7 dgNyyRcxiz9KQyIzwMYWPN9Ub8oKAMSx/6xUF0/ilpWJGntbGt97qKdMmk3IleDH clcbMYNDZiY14tGRU3aNPyWrCFpWuvmEcc/MAVee9aj/XTT+LNvkTudnJe9QheqF fOnNcR3bWAvufyhGL/gjoGl85l2h5plPfx7K1N1k+PoPZkMcszBY0gXKFKdfjJfj IOU/ywCnmXRQ+X3rwANBkQJNwvtRw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrgedugddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepleefrdeirddugeelrdduudegnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdr nhgvth X-ME-Proxy: Received: from xps.localnet (114.149.6.93.rev.sfr.net [93.6.149.114]) by mail.messagingengine.com (Postfix) with ESMTPA id DDBAF306005F; Sun, 19 Jul 2020 06:04:01 -0400 (EDT) From: Thomas Monjalon To: "Medvedkin, Vladimir" , "Richardson, Bruce" Cc: "Kinsella, Ray" , Stephen Hemminger , "dev@dpdk.org" , "david.marchand@redhat.com" , "jerinj@marvell.com" , "Ananyev, Konstantin" , "Mcnamara, John" , "O'Driscoll, Tim" Date: Sun, 19 Jul 2020 12:04:00 +0200 Message-ID: <1676131.LEHYKQzkrn@thomas> In-Reply-To: <59AF69C657FD0841A61C55336867B5B0976C3CD1@IRSMSX103.ger.corp.intel.com> References: <27499155.uCKWoEMfP3@thomas> <59AF69C657FD0841A61C55336867B5B0976C3CD1@IRSMSX103.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 17/07/2020 18:43, Richardson, Bruce: > From: Thomas Monjalon > > 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 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. > > > > 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 by > > 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). > > > > 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 hooks > to optionally enable this support. As part of that set, we'll see about what > doc updates need to be made also - again covering both developer and end-app user. > > Hopefully we can get that set out soon to get early feedback and reach a good > conclusion. We cannot merge anymore in 20.08 because we passed -rc1. I am in favor of merging this feature the day after 20.08 release.