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 8DFC3A057C for ; Fri, 27 Mar 2020 09:13:17 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 80FED1BFD9; Fri, 27 Mar 2020 09:13:17 +0100 (CET) Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) by dpdk.org (Postfix) with ESMTP id 753521C028 for ; Fri, 27 Mar 2020 09:13:16 +0100 (CET) Received: by mail-wm1-f68.google.com with SMTP id z18so10496286wmk.2 for ; Fri, 27 Mar 2020 01:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=0xwjWwYh0jEuUOd3twTClWXe91K64G3KkdJJsnbla1o=; b=N42kuGv+us4FEEbW1/f+2u18MQWUdaTw4DiSUvFJFhE1B39JVk7OCOmAw2tYEqnYS3 FYL/S67heHJJpSvoHtTEgm0Ds2a7mfzaMpQ275bzKC7rRt/oOjwm6xDa2B3dZpjilVlR ZkNzLiPGrZl4HZSfMI8k+4IJuz8f+DnCmBWUgcCXXDQX8b6BB8FnoG0IN8WMDYnl6FrN vrPDKy75biF+tJ9QX1hMNM3bujcZuunqenFhrRrd2sWboTZRQ9EIRtLtNQFFaHv0kAW+ AQBLgjbgc1hHEKfMXEdIkCOKMNBf8sCcKrQ/FZUAbEEqV5TUpql7+s6Xq6vJrnpg5XL0 BWBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=0xwjWwYh0jEuUOd3twTClWXe91K64G3KkdJJsnbla1o=; b=WtUuGUjHkWr2hklwLUbctsldYF8EPLfuMAnOq+NRUGRmyKEEMGHPQMzEV4ppIpsvYe euz7eKBClmik/X6Of8OuwMBhbz8WeiqE1Y8YXCIALvaZv4n1AnFA5JuzLBukSwThLyvb jzCls7cHcTDYWqgwuV0oryyf9zOoTsdt0X+tSIPmHE72wHnPrhBOJEOx7c0HkkFIiCZx DmXBVNRhmcOHOxSNd76C+2FdaZnw/K88DX3pTGrigP585Ts6NGBM/vRRT+N1WVyVTxaO amFzGO1k+gINmQ2waQ/nrEOXX34mJy6o//RU9f9SWbTFlgti4DyDTHNN3dDqmz1kZ+9e t9Wg== X-Gm-Message-State: ANhLgQ1bVLa8vAMtS4HaAHWHe6OGrNb6DfQkDQiUWahhDkFKlZoLHkmC JWdEaIQeNrnFEOeCNM3ZY9ysqg== X-Google-Smtp-Source: ADFU+vujvkt04jCac1vcTM5onEJ2Lmza/WVKx+EQNzq2ZMcFOY6R5TyX3KrpJ+XwKcdYTUQH4h7s9g== X-Received: by 2002:a1c:5604:: with SMTP id k4mr3933477wmb.57.1585296796167; Fri, 27 Mar 2020 01:13:16 -0700 (PDT) Received: from 6wind.com (2a01cb0c0005a600345636f7e65ed1a0.ipv6.abo.wanadoo.fr. [2a01:cb0c:5:a600:3456:36f7:e65e:d1a0]) by smtp.gmail.com with ESMTPSA id f1sm7187744wrv.37.2020.03.27.01.13.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Mar 2020 01:13:15 -0700 (PDT) Date: Fri, 27 Mar 2020 09:13:14 +0100 From: Olivier Matz To: Alexander Kozyrev Cc: dev@dpdk.org, viacheslavo@mellanox.com, matan@mellanox.com, thomas@monjalon.net, stable@dpdk.org Message-ID: <20200327081314.GD6327@platinum> References: <1584383500-27482-1-git-send-email-akozyrev@mellanox.com> <1584719715-17818-1-git-send-email-akozyrev@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1584719715-17818-1-git-send-email-akozyrev@mellanox.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-stable] [PATCH v2] mbuf: optimize memory loads during mbuf freeing X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi, On Fri, Mar 20, 2020 at 03:55:15PM +0000, Alexander Kozyrev wrote: > Introduction of pinned external buffers doubled memory loads in the > rte_pktmbuf_prefree_seg() function. Analysis of the generated assembly > code shows unnecessary load of the pool field of the rte_mbuf structure. > Here is the snippet of the assembly for "if (!RTE_MBUF_DIRECT(m))": > Before the change the code was: > movq 0x18(%rbx), %rax // load the ol_flags field > test %r13, %rax // check if ol_flags equals to 0x60...0 > jz 0x9a8718 // jump out to "if (m->next != NULL)" > After the change the code became: > movq 0x18(%rbx), %rax // load ol_flags > test %r14, %rax // check if ol_flags equals to 0x60...0 > jnz 0x9bea38 // jump in to "if (!RTE_MBUF_HAS_EXTBUF(m)" > movq 0x48(%rbx), %rax // load the pool field > jmp 0x9bea78 // jump out to "if (m->next != NULL)" > Look like this absolutely unneeded memory load of the pool field is an > optimization for the external buffer case in GCC (4.8.5), since Clang > generates the same assembly for both before and after the change versions. > Plus, GCC favors the external buffer case over the simple case. > This assembly code layout causes the performance degradation because the > rte_pktmbuf_prefree_seg() function is a part of a very hot path. > Workaround this compilation issue by moving the check for pinned buffer > apart from the check for external buffer and restore the initial code > flow that favors the direct mbuf case over the external one. > > Fixes: 6ef1107ad4c6 ("mbuf: detach mbuf with pinned external buffer") > Cc: stable@dpdk.org > > Signed-off-by: Alexander Kozyrev > Acked-by: Viacheslav Ovsiienko Acked-by: Olivier Matz Thanks!