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 92128A04DE; Fri, 30 Oct 2020 17:42:12 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B1A304C9B; Fri, 30 Oct 2020 17:42:09 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id 5B9714C95 for ; Fri, 30 Oct 2020 17:42:07 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 13884B3D; Fri, 30 Oct 2020 12:42:05 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 30 Oct 2020 12:42:05 -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=fm2; bh= UdQNR7goX0uxjRvljHLaxRUCnIRUN2wB5XEESd4Eb1s=; b=Ig8wUlvxNQwE9xtH F99FUXkNelfEwIoc2WrzKWMMdDTuGJQ/xITqkr159G8AbNyV2jLJs65EZmAUujww ORjXA1VJH5Fw/IdHwUd7b7RdglgYETeMyP9qPPH52bcGCCzK1RpFxkf5znxlIVB7 uZ9ddyeXXU/fhYOTzYNf542np3UmiYNl8D9CP6z3I31ncdmAX1MEGRNHcQNk9RSJ hvJQUEDzA3zfuN8DnxOG66wjUdwWtxTA8kmLVrOQw9HcKaCV29V2vnfbBwsrhluX QaJoGXovP4l6zGRe6Pqd7B7A0ys+iIxolES4rJxaF7b0kd0lSzgY6obHvDEDPWFl +liYig== 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=fm1; bh=UdQNR7goX0uxjRvljHLaxRUCnIRUN2wB5XEESd4Eb 1s=; b=GHx326aP/b8LkIJHHzOuMOsOa50Fc37AdgxvH+aVCTtlcEOdgzmYzsvub +WlyW9MDH2O5+bqxhVM0aIAE7GlBOVhBUfM/4ZqQyZ/4+nHItNxPRvnansYROtNK OWiTA9ZVRTMccPlio1HEIe9QLPN45S5bVguXjl86NVDUdaW96Gme86r5L5sHwAIn 2JigpNiH/WCFEtCIEhSOLuDqQ8s9y1RoBuWP0TuxcOF+4omgNrQKZYecKUSOhAds DNjV3SL72Yw7Ops2gRe3Z7AUmR7engtmEiEVHyKnqVfSVBdThN3GuivHMm043M4X Zis1b6EVPnbfRlyMyQCHM5grDMeOw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleehgdekjecutefuodetggdotefrodftvf 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 5F708306467D; Fri, 30 Oct 2020 12:42:03 -0400 (EDT) From: Thomas Monjalon To: "McDaniel, Timothy" Cc: "'dev@dpdk.org'" , "Carrillo, Erik G" , "Eads, Gage" , "Van Haaren, Harry" , "'jerinj@marvell.com'" , "'david.marchand@redhat.com'" Date: Fri, 30 Oct 2020 17:42:02 +0100 Message-ID: <1765794.gbtCFdHrtP@thomas> In-Reply-To: References: <1602958879-8558-2-git-send-email-timothy.mcdaniel@intel.com> <5792010.8yoxlyRsN9@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5 00/23] Add DLB2 PMD 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" 30/10/2020 17:02, McDaniel, Timothy: > From: Thomas Monjalon > > 30/10/2020 16:35, McDaniel, Timothy: > > > From: Thomas Monjalon > > > > 30/10/2020 12:58, McDaniel, Timothy: > > > > > From: McDaniel, Timothy > > > > > > From: Thomas Monjalon > > > > > > > 30/10/2020 10:43, Timothy McDaniel: > > > > > > > > - note that the code still uses its private byte-encoded versions of > > > > > > > > umonitor/umwait, rather than the new functions in the power > > > > > > > > patch that are built on top of those intrinsics. This is intentional. > > > > > > > > > > > > > > Why? Now these intrinsics are available in the main branch. > > > > > > > We should avoid duplicating such code. > > > > > > > > > > > > > > > > > > > > > > > > > > I had asked that the low level intrinsics (UMWAIT/UMONITOR) be split > > out so > > > > > > that DLB/DLB2 could use them instead of its own private byte-encoded > > > > versions, > > > > > > but instead we have these wrappers that call the low level intrinsics. > > Those > > > > > > wrappers > > > > > > introduce additional overhead that is not required for DLB/DLB2. I have a > > > > > > meeting with Ma Liang on Monday to discuss. > > > > > > > > > > I thought the ask of DLB was to just substitute the low level > > umwait/umonitor > > > > byte > > > > > encoded instructions DLB has defined privately with similar byte-encoded > > > > instructions defined in the power > > > > > patch. The power patch does not directly expose those, which is why I did > > not > > > > update DLB/DLB2. > > > > > The power patch does have the advantage of centralizing the race > > avoidance > > > > > logic, which is a good thing for any PMD that wishes to take advantage of > > > > umwait/umonitor. > > > > > > > > So you mean the overhead is a good thing? > > > > > > > > > Sorry for the confusion. I just misunderstood what was being asked of DLB > > in > > > > regard to switching over.. That being said, > > > > > I am willing to convert DLB/DLB2 to use rte_power_monitor(...) in a future > > > > patch-set. > > > > > > > > Why not now? > > > > > > > > Indeed there is a confusion and it looks like a lot of novlang > > > > to exit from the situation. > > > > We'll wait a clear decision with facts. > > > > > > > > > > Hi Thomas, > > > > > > I have updated DLB and DLB2 to use rte_power_monitor(...), and those > > patches are > > > ready if you are willing to accept them and the 3 power patches. > > > > > > For the sake of consistency, I see the benefit of using the power patch, even if > > it is > > > slightly less efficient that the DLB-specific implementation that I currently > > have. > > > We have already encountered an empty queue, so this is no longer fast path > > for the PMD. > > > > I am really concerned that the API in EAL is not the most efficient. > > Why is that? Can we improve the EAL API? > > > > From an efficiency perspective, I only noticed 2 things. > 1) The size check and associated logic. This could be avoided if we had _8, _16, _32, _64 variants instead of 1 function that handled all possibilities, but even that may be a wash > with branch prediction > 2) The spinlock - but this observation was my mistake, and was flawed. I was looking at the rte_power_monitor_sync(...), and not rte_power_monitor(...), the latter of which does not take a spinlock. > > In summary, I am no longer concerned about efficiency and suitability for DLB/DLB2. OK, so let's go ahead with a DLB PMD using this API.