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.