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 30A27A0527; Mon, 9 Nov 2020 09:27:47 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 804355916; Mon, 9 Nov 2020 09:27:45 +0100 (CET) Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by dpdk.org (Postfix) with ESMTP id 1D8195913 for ; Mon, 9 Nov 2020 09:27:44 +0100 (CET) Received: by mail-il1-f193.google.com with SMTP id y9so409444ilb.0 for ; Mon, 09 Nov 2020 00:27:44 -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=T8YSSB7Sn/HzTcMg889Hv9MUd+Tctn56eKJyFXn2idM=; b=DFa/SjdXVVlGBot5tNcJBwdIEX2eYxlFtti2tdJetiwvVlf3GdByvDpOjhfsow/fNF C6R0gbrUYJsktafattvKMfzNC2JUFO/joE3+BgO+boRk9q1aeUwgRDUm7MfdwAbrLo+S uT0rBZLjcfPQwJzKF1cEhc2Cpyvh+8lJ85MEGbiyXtxtz4HsA9/AUBMBYbNkbwFp0LqP ClNnUSZvkG0ayhrC8qIqYlXOdkIz1wEG7qSzg7cvzYnfaq4XzuVSVbggecvOP+inyyaE dXvZFIBAoKXHZOhU5DJKzBqhoS9TpG6H1EXCz9BmJYsOHYm9YAJcP+E/T9y8miDvojIC NV0g== 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=T8YSSB7Sn/HzTcMg889Hv9MUd+Tctn56eKJyFXn2idM=; b=YQtergvmze691H6nMoxGIkhc/S19fxWBlB4tEwyt1rvDdr42ZW10Cm7r7hODEWSGBK afKQYhebeGAV0P1BSe/OwrTI9ZK/eZ2QoaaYhQUG2hmroj4Xiz0SNltA9Ad70D2Godef 80uH7TqIYzifDs222Eq9gZdMzunLHMyErMD3hS3wcJoVvM1XLB3pu55mdIt/jsx9vXuS v/lEdV5umIht9bN81dhgp+LL84osZ6k5wews03wy2OcB/tDcZ6My3Bpdm10SiP5u16tF 6R0GN8AVvHYW/wdonnyApBJ+qZnNbJjWsObPohOIWLvhsAPuW/LQ2VtqCuaxEPIXGpWw zv2g== X-Gm-Message-State: AOAM532Bk1zOjtJ+uHo+lv/viJvLMyhbg7EFuysWrCheWsDAHs/CUT5g I0RMnZU6IggKCPnZKPpjbTlYKs07C8jdgEsc40c= X-Google-Smtp-Source: ABdhPJztzCqphxz/PZuQ/QYztksezB12eOJkMy/nq6SLzMcFsd5cUpjdCkLGI9dDgvIrJSR2KhRhA2vFZCNH67qAnzg= X-Received: by 2002:a92:c984:: with SMTP id y4mr5409087iln.130.1604910462356; Mon, 09 Nov 2020 00:27:42 -0800 (PST) MIME-Version: 1.0 References: <20201107155306.463148-1-thomas@monjalon.net> <6088267.6fNGb03Fmp@thomas> <7853350.9sPKUjbg19@thomas> In-Reply-To: <7853350.9sPKUjbg19@thomas> From: Jerin Jacob Date: Mon, 9 Nov 2020 13:57:26 +0530 Message-ID: To: Thomas Monjalon Cc: 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 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. > > > - Also it will be effecting exiting vector routines > > > > I request to reconsider the tech board decision. > > >