From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 9ECD942871;
	Thu, 30 Mar 2023 17:05:36 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 26972410D3;
	Thu, 30 Mar 2023 17:05:36 +0200 (CEST)
Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com
 [209.85.214.182])
 by mails.dpdk.org (Postfix) with ESMTP id 268A840E25
 for <dev@dpdk.org>; Thu, 30 Mar 2023 17:05:35 +0200 (CEST)
Received: by mail-pl1-f182.google.com with SMTP id u10so18335718plz.7
 for <dev@dpdk.org>; Thu, 30 Mar 2023 08:05:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20210112.gappssmtp.com; s=20210112; t=1680188734;
 h=content-transfer-encoding:mime-version:references:in-reply-to
 :message-id:subject:cc:to:from:date:from:to:cc:subject:date
 :message-id:reply-to;
 bh=ut+MaHwzg0YQZwbOaBughEmDOsgYwbISz/0nwZAQvgI=;
 b=vM0eSsFWzYY7DOfXjwHflp1ahuQMnxSwqzwPwECM14irH+BP+EMrDZ/tIyDUSWueKk
 pjDzmvzBppqGLyvA3UcXXuafuK9TnLOw5rEJtJbTZuph07hzCDsnA4laNerjJfbnO3ky
 U93oRtCuef7isO5vGj29Dyb7/YXMY787fJXM2YWQnrf74Ni/CknN2aSa7oKmXW+iVlxi
 m3bd72ZOv1bhR4qmSW2KtOYziLiU29LIJqi5nlcRoDYZ2dmor303NVcve7pVdeytidpL
 Lf06pSCqS/LvLP6mi2cDOtnXYIcWFj720DYooCE+YnGATxCSqEc0KMGSFYEjTEWYnL8e
 SHVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112; t=1680188734;
 h=content-transfer-encoding:mime-version:references:in-reply-to
 :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=ut+MaHwzg0YQZwbOaBughEmDOsgYwbISz/0nwZAQvgI=;
 b=DPdrJr96PVdeVesKYxKuR3BewyhGXT2+iy8MyryUI8mrQfepTag4qbq2GgxcKnipdS
 pYjilGCIU56008PcCNGDCJWR75ArtkA0u9XF73FdgEDqPx6lxRovjlLxyb8ftvGdvJ2d
 bQG2B/bscooqkV2b6IACptkbEm0NU2woStW58jhtK4Qmr8GM2vbe1PPRuPVqH1FYGJQf
 bN6+bH0u/e4jXfjDZwHq0x67FgDdWwp8m6ECl1E3ifYYwYeMZGKu/p3PPTDtkBsQjTls
 3CQ6/aBov1KOJHd3NvX849Sb1ZR1aqT7dAUqcLaS5V1sPVFVhMH/DxCC8v311eOXjdsQ
 +aCQ==
X-Gm-Message-State: AO0yUKXYY0qcZ1HNYrapGl7qcWdfVE2Jegr2W+omLKyLFv+qriuYFYwr
 wbT29Se4/PK/TSy8yLhxGYwaqg==
X-Google-Smtp-Source: AK7set8ewHN+o1Vr+/bIjjeT7VD9YA4No2auZer9qdjuGKtTsR2tOd/9sXRECkFmr35wbgS/DMOITQ==
X-Received: by 2002:a05:6a20:2d83:b0:d9:7e82:6cf1 with SMTP id
 bf3-20020a056a202d8300b000d97e826cf1mr18790256pzb.48.1680188734054; 
 Thu, 30 Mar 2023 08:05:34 -0700 (PDT)
Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218])
 by smtp.gmail.com with ESMTPSA id
 15-20020aa7910f000000b0062c0cfbb264sm11370607pfh.93.2023.03.30.08.04.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 30 Mar 2023 08:05:11 -0700 (PDT)
Date: Thu, 30 Mar 2023 08:04:48 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Feifei Wang <feifei.wang2@arm.com>
Cc: dev@dpdk.org, konstantin.v.ananyev@yandex.ru, mb@smartsharesystems.com,
 nd@arm.com
Subject: Re: [PATCH v5 0/3] Recycle buffers from Tx to Rx
Message-ID: <20230330080448.5a73a5d3@hermes.local>
In-Reply-To: <20230330062939.1206267-1-feifei.wang2@arm.com>
References: <20211224164613.32569-1-feifei.wang2@arm.com>
 <20230330062939.1206267-1-feifei.wang2@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Thu, 30 Mar 2023 14:29:36 +0800
Feifei Wang <feifei.wang2@arm.com> wrote:

> Currently, the transmit side frees the buffers into the lcore cache and
> the receive side allocates buffers from the lcore cache. The transmit
> side typically frees 32 buffers resulting in 32*8=256B of stores to
> lcore cache. The receive side allocates 32 buffers and stores them in
> the receive side software ring, resulting in 32*8=256B of stores and
> 256B of load from the lcore cache.
> 
> This patch proposes a mechanism to avoid freeing to/allocating from
> the lcore cache. i.e. the receive side will free the buffers from
> transmit side directly into its software ring. This will avoid the 256B
> of loads and stores introduced by the lcore cache. It also frees up the
> cache lines used by the lcore cache. And we can call this mode as buffer
> recycle mode.


My naive reading of this is that lcore cache update is slow on ARM
so you are introducing yet another cache. Perhaps a better solution
would be to figure out/optimize the lcore cache to work better.

Adding another layer of abstraction is not going to help everyone
and the implementation you chose requires modifications to drivers
to get it to work.

In current form, this is not acceptable.