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 DAF31A0583 for ; Thu, 19 Mar 2020 10:30:29 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D09E92B9E; Thu, 19 Mar 2020 10:30:29 +0100 (CET) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id F14E72B9E for ; Thu, 19 Mar 2020 10:30:27 +0100 (CET) Received: by mail-wr1-f66.google.com with SMTP id s1so1828625wrv.5 for ; Thu, 19 Mar 2020 02:30:27 -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=CiBdQcueCZByPFgRZ3HBlHH/4ZpyKKvNjIfQzrwLaf0=; b=YAbtUx/KN/ogVVoaqb8yBx2c+Mv+1stlbKYggxoIPUfPATX1FZkQ3jtYcqMdDKLc/n aK26TIGA2vc48ylDQWM3YRtuXPUivtvvf92MXKb6aKaPew8hCOkDCtR5MdyFOBsMCIPN ABzpMl115KKZZ+MRFobQxFgeTXnqfgzSd7Zx6PYVKKmd31oHBydEzjbQ8bSMProJhQXw 1wLDKXdS7NPLZ+0XZakxD/TncJWPBtG3NBFDrriPpOsve6LGmUg1qxCuwYdl+c6nXBMB LuboXgU00H+yKGfEa2Pa1CiKI1LuPFrLrpoVt0tBmDWgItmKtWE8GtL/WYAvXRwf7A/z IQWQ== 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=CiBdQcueCZByPFgRZ3HBlHH/4ZpyKKvNjIfQzrwLaf0=; b=cWSvwZ3LVsWWMMG2l5z6tvOT4A3XKD5gMVVhdFalM0tQJ5U88zcIvWkUzkNCjNqTUR HqvW0z9yaIv/19SlGnCf1ighKUOYuBG0AA7M51L4NMYn+mMf8XRykuD4QjXuqkodHVel 5ZceD5/hD9cHvIgeOPKmwrKsXhtJ/HNiicxq6oh0Ok1pm9YHMaMgwuNdSNVm1A4G9Yys Zu6q+CHItkUz2QSDP4fvHAPfOwWZ55dzteezKh/yPeORuFWjfRyDJJd8Nkcj2OFm7JNq cIcB7xTI2EZ7qezgESpHo8Ey5LF5UtgtoWmGJGmhQNblxMygWFQEGx5bzXBFaqNyBnf+ JbmQ== X-Gm-Message-State: ANhLgQ2Y9wfNzPwUlcIrqGT1h3ynHHTtjzARU7bjtwE2ZdutSsUjFdn5 8tgiwjTpVqV7e0OUBUoY8KTMng== X-Google-Smtp-Source: ADFU+vsXmVsICN5tvn35Q5IdrG9hZwvS5Tf3rbsZ9WWfl2BP+TuLu35Bi1FP953Gi3cxHAXzq00uOA== X-Received: by 2002:a5d:6287:: with SMTP id k7mr2825673wru.195.1584610227624; Thu, 19 Mar 2020 02:30:27 -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 b15sm2495201wru.70.2020.03.19.02.30.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Mar 2020 02:30:26 -0700 (PDT) Date: Thu, 19 Mar 2020 10:30:25 +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: <20200319093025.GT17125@platinum> References: <1584383500-27482-1-git-send-email-akozyrev@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1584383500-27482-1-git-send-email-akozyrev@mellanox.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-stable] [PATCH] 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 Mon, Mar 16, 2020 at 06:31:40PM +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 becomed: > 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 chenge versions. > Plus, GCC favors the extrnal 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 > --- > lib/librte_mbuf/rte_mbuf.h | 14 ++++++-------- > 1 file changed, 6 insertions(+), 8 deletions(-) > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > index 34679e0..ab9d3f5 100644 > --- a/lib/librte_mbuf/rte_mbuf.h > +++ b/lib/librte_mbuf/rte_mbuf.h > @@ -1335,10 +1335,9 @@ static inline int __rte_pktmbuf_pinned_extbuf_decref(struct rte_mbuf *m) > if (likely(rte_mbuf_refcnt_read(m) == 1)) { > > if (!RTE_MBUF_DIRECT(m)) { > - if (!RTE_MBUF_HAS_EXTBUF(m) || > - !RTE_MBUF_HAS_PINNED_EXTBUF(m)) > - rte_pktmbuf_detach(m); > - else if (__rte_pktmbuf_pinned_extbuf_decref(m)) > + rte_pktmbuf_detach(m); > + if (RTE_MBUF_HAS_PINNED_EXTBUF(m) && > + __rte_pktmbuf_pinned_extbuf_decref(m)) > return NULL; > } > [...] Reading the previous code again, it was correct but not easy to understand, especially the: if (!RTE_MBUF_HAS_EXTBUF(m) || !RTE_MBUF_HAS_PINNED_EXTBUF(m)) Knowing we already checked it is not a direct mbuf, it is equivalent to: if (!RTE_MBUF_HAS_PINNED_EXTBUF(m)) I think the objective was to avoid an access to the pool flags if not necessary. Completely removing the test as you did is also functionally OK, because rte_pktmbuf_detach() also does the check, and the code is even clearer. I wonder however if doing this wouldn't avoid an access to the pool flags for mbufs which have the IND_ATTACHED flags: if (!RTE_MBUF_DIRECT(m)) { rte_pktmbuf_detach(m); if (RTE_MBUF_HAS_EXTBUF(m) && RTE_MBUF_HAS_PINNED_EXTBUF(m) && __rte_pktmbuf_pinned_extbuf_decref(m)) return NULL; } What do you think? Nit: if you wish to send a v2, there are few english fixes that could be done (becomed, chenge, extrnal) Thanks