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 C01BDA0546; Wed, 15 Jul 2020 14:45:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DB49E1BEB2; Wed, 15 Jul 2020 14:45:16 +0200 (CEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by dpdk.org (Postfix) with ESMTP id F2ADF1BDAE for ; Wed, 15 Jul 2020 14:45:14 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 33439C11; Wed, 15 Jul 2020 08:45:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 15 Jul 2020 08:45:13 -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= xgbuF0xOSk3I/u5Ee2YhpEEN1ArHvTI7gv7onAKK1FM=; b=BYBpxX9ZxdN7jVJY zM4zDUug/6+lmN/OUwVYNPCVvLsJY/ixroNNm/NJxOh7CHNcgkO+Zf+d4IU1wtin QoyE5nJiCoChdwYFWOSLV1tLTLR2sq1kmDb+Ie9AS47zPFMZ5f5QsRvFzAKsaEUz 5fYbyCl8bfM64Vh1bDQ+s2sPWcUX4iHr6PtdqONFVUHa3J9sSYTRMFA60iFEZVwx JhIqhmOdT/MiQ7E4PdJQQ/9XxMs1Qd1ggFKErxp3Ab5+0XLwkIYegaZXL+1RqAhv mEOq6wELjKFYsM6wpc6wIpKrXKVj9nCDcEUVgLbuoofoS/0aNN/zgLj94azGTIX0 jm8F+Q== 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=xgbuF0xOSk3I/u5Ee2YhpEEN1ArHvTI7gv7onAKK1 FM=; b=XT6eciZ/81Ph81Xy6kaoBBHOEI+TWVSNtFC59h05Jop+BbS40jETF/M1E 0KbRaCO7x/QLo5n+qVuMy+9h/0Qcyh9BHWa2OuXOP21+X9bM2BxsED1Q9wBP3IjT g6Wq6fp4wuq4WJbC3q4hWtZh4qmxfGu2qm4heXfn1joK3s/XskWzt4VvYdXvtgje XhCO6Yd4lOesQLIy47eeX8lTRS7yuU8DGO0lPP6WBe+9rlh0jwmz7PZTdDcUgX8n sLpwkDfE/dH5HmYkDti5bzB/gkV4F3P4alFd0n3ZJh005FaM6G68VYsE7zhDU2/t PxZ342sBEO9MvYXtNDa4HbQvlhj5Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedvgdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 04AA53060067; Wed, 15 Jul 2020 08:45:10 -0400 (EDT) From: Thomas Monjalon To: "Medvedkin, Vladimir" Cc: "Kinsella, Ray" , Stephen Hemminger , dev@dpdk.org, david.marchand@redhat.com, jerinj@marvell.com, konstantin.ananyev@intel.com, bruce.richardson@intel.com, john.mcnamara@intel.com, tim.odriscoll@intel.com Date: Wed, 15 Jul 2020 14:45:09 +0200 Message-ID: <27499155.uCKWoEMfP3@thomas> In-Reply-To: References: <4060360.4fru8zSAKM@thomas> 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" 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).