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 0A0E8A0527; Mon, 9 Nov 2020 13:01:23 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D064F5B30; Mon, 9 Nov 2020 13:01:20 +0100 (CET) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id A9C525AA6 for ; Mon, 9 Nov 2020 13:01:19 +0100 (CET) Received: by mail-io1-f65.google.com with SMTP id r9so9483955ioo.7 for ; Mon, 09 Nov 2020 04:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=92h6gclzU1olCIXXL4P/IbVLd1momsbq/GoJxiKsWs0=; b=RZ9tV/m6W7GQ2lz32odzzQXv+2rGVH0/zO8lln+l6iEAFAJC1eHWAquPYv5C8TXVmm cd1+uZyvdGnup9uCf2d23ROdUErNZU+1x9506J5t0u+DUeNvyT+W0MkdwF9UhfqUgY7f Va/FgLPhdNIn0lKjTSa0yCHGOJhgMuj+zCSOVDaBVSvhWduwygsklxO3ztR4XpIs9ofC B8CtGQAbh/d+cyKDu8hKoNZ3f+waXtmmeq9KQRIC8xXAFcqeHeZmXVse6Ihw+C7rPFcl 9HuipplYtVfIotAkAbpUZSRSjwAyWTinOaoSNF38GWCet8r3O5epM4sYAWD5uMfiSUBI BPNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=92h6gclzU1olCIXXL4P/IbVLd1momsbq/GoJxiKsWs0=; b=liD0vMU55Tu+Oy2qD5ERQVNeqrba5QNCrN3GVFivbG5JLprNFEbX4wAR09NvLO1KNQ t4gjZV8vZRNdEFjYtVXXq8lmkuOGM75JOOoqXb52A+yTt/Nlev1VmFae4XI4Zk5O9Ehq HT54XpNrIZWWifohBdyPOB8ghsO2ewpFfA/xR4FebrO7FejAv96m8DOyWJPElkg8XeFw RtAnEaunb+Ha9QSdSA/0yyR/OusQQPCoowFmTrxNJtkr/QgNDqw1U6cPbzqsmA5JZvyw AuS3PEdV9adCgNu+aUni0/UPDtbFvRlG54NhF/OktYIAsNUW5e3vbVrybwO4xiQJ/Ynz A9gQ== X-Gm-Message-State: AOAM532asq1VzpRXatf2+0IWjUnU+fj4SERLQGnNC8nNr8hqmcIYtYC0 xD3Xd+vahLg9Mfb2BYvh1bzNAe9DN+G2xZr7Z3I= X-Google-Smtp-Source: ABdhPJysmuiSHQYo9DVS1VyI4AHxvMga3Z+lBZVPXEpQ8UEEdyaSJgj+X7tVdSFaXfgTWVP+FEyzsuWtfT9zvoIn0Og= X-Received: by 2002:a05:6602:235b:: with SMTP id r27mr10032088iot.123.1604923277765; Mon, 09 Nov 2020 04:01:17 -0800 (PST) MIME-Version: 1.0 References: <20201107155306.463148-1-thomas@monjalon.net> <6088267.6fNGb03Fmp@thomas> <7853350.9sPKUjbg19@thomas> <20201109094732.GA831@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: <20201109094732.GA831@bricha3-MOBL.ger.corp.intel.com> From: Jerin Jacob Date: Mon, 9 Nov 2020 17:31:01 +0530 Message-ID: To: Bruce Richardson Cc: Thomas Monjalon , dpdk-dev , David Marchand , Ferruh Yigit , Olivier Matz , =?UTF-8?Q?Morten_Br=C3=B8rup?= , "Ananyev, Konstantin" , Andrew Rybchenko , Viacheslav Ovsiienko , Ajit Khaparde , Jerin Jacob , Hemant Agrawal , Ray Kinsella , Neil Horman , Nithin Dabilpuram , Kiran Kumar K Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 1/1] mbuf: move pool pointer in first half 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" On Mon, Nov 9, 2020 at 3:17 PM Bruce Richardson wrote: > > On Mon, Nov 09, 2020 at 01:57:26PM +0530, Jerin Jacob wrote: > > On Mon, Nov 9, 2020 at 1:34 PM Thomas Monjalon wrote: > > > > > > 09/11/2020 06:18, Jerin Jacob: > > > > On Sun, Nov 8, 2020 at 2:03 AM Thomas Monjalon wrote: > > > > > 07/11/2020 20:05, Jerin Jacob: > > > > > > On Sun, Nov 8, 2020 at 12:09 AM Thomas Monjalon wrote: > > > > > > > 07/11/2020 18:12, Jerin Jacob: > > > > > > > > On Sat, Nov 7, 2020 at 10:04 PM Thomas Monjalon wrote: > > > > > > > > > > > > > > > > > > The mempool pointer in the mbuf struct is moved > > > > > > > > > from the second to the first half. > > > > > > > > > It should increase performance on most systems having 64-byte cache line, > > > > > > > > > > > > > > > > > i.e. mbuf is split in two cache lines. > > > > > > > > > > > > > > > > But In any event, Tx needs to touch the pool to freeing back to the > > > > > > > > pool upon Tx completion. Right? > > > > > > > > Not able to understand the motivation for moving it to the first 64B cache line? > > > > > > > > The gain varies from driver to driver. For example, a Typical > > > > > > > > ARM-based NPU does not need to > > > > > > > > touch the pool in Rx and its been filled by HW. Whereas it needs to > > > > > > > > touch in Tx if the reference count is implemented. > > > > > > > > > > > > See below. > > > > > > > > > > > > > > > > > > > > > > > Due to this change, tx_offload is moved, so some vector data paths > > > > > > > > > may need to be adjusted. Note: OCTEON TX2 check is removed temporarily! > > > > > > > > > > > > > > > > It will be breaking the Tx path, Please just don't remove the static > > > > > > > > assert without adjusting the code. > > > > > > > > > > > > > > Of course not. > > > > > > > I looked at the vector Tx path of OCTEON TX2, > > > > > > > it's close to be impossible to understand :) > > > > > > > Please help! > > > > > > > > > > > > Off course. Could you check the above section any share the rationale > > > > > > for this change > > > > > > and where it helps and how much it helps? > > > > > > > > > > It has been concluded in the techboard meeting you were part of. > > > > > I don't understand why we restart this discussion again. > > > > > I won't have the energy to restart this process myself. > > > > > If you don't want to apply the techboard decision, then please > > > > > do the necessary to request another quick decision. > > > > > > > > Yes. Initially, I thought it is OK as we have 128B CL, After looking > > > > into Thomas's change, I realized > > > > it is not good for ARM64 64B catchlines based NPU as > > > > - A Typical ARM-based NPU does not need to touch the pool in Rx and > > > > its been filled by HW. Whereas it needs to > > > > touch in Tx if the reference count is implemented. > > > > > > Small note: It is not true for all Arm platforms. > > > > Yes. Generally, it is not specific to Arm platform. Any platform that > > has HW accelerated mempool. > > > > Hi Jerin, Thomas, > > For platforms without hw mempool support too, the same holds that the pool > pointer should never need to be touched on RX. However, as we discussed on > the tech board, moving the pointer may help a little some cases, and > especially less optimized drivers, and there seemed to be no downside to > it. Jerin, can you please clarify why moving the pool pointer would cause a > problem? Is it going to cause things to be slower on some systems for some > reasons? I overlooked on that part, No specific issue in moving first cache line. Hi @Thomas Monjalon Any specific reason why you removed the static assert from octeontx2. I am not able to compilation issue with that static assert. The current vector driver assumes pool and tx offload needs to 2 DWORDS apart, Which is the case before and after your change. Please remove that static assert change, No issue from my side on this patch. In general, it is too much effort to re-verify and measure performance impact with all the cases after RC2, I hope this will last mbuf change in this release. > > Regards, > /Bruce