From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9A3A2430D0; Tue, 22 Aug 2023 15:59:07 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3DC5C4021D; Tue, 22 Aug 2023 15:59:07 +0200 (CEST) Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by mails.dpdk.org (Postfix) with ESMTP id 0792240041 for ; Tue, 22 Aug 2023 15:59:05 +0200 (CEST) Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-26f4bc74131so1625477a91.1 for ; Tue, 22 Aug 2023 06:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1692712745; x=1693317545; 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=l0QNhDtwgrD4clYCX3fNpYfjqVcnL2VuQCT1Cz5mER8=; b=d7SPo5mYxjNtnm4FX8s02h0Dt6Fa8uutWl32TNcn1fVvBqX27/NXZNnwNV4GkacqeW QH2ZBtNV1ukjS9dT5EDCrEU7IeISWCsm3DMbeSpnuehxVi7UpYKBuBq5a6vAEm0E9G3p lYHCQ9nXSYFUTXdoG+G7oKsdZt6/eyDxSeVKPgX32/+RlkSVv/BEbQ27yt0b1d0+Ua+Z H4n9hjcEI7DaEsmXaJGIzrtvCGmnKpSKe7CZcRas6uFjfMkT9bHAV5ibmKdr/edDHBwQ gT4+/Zch0HcJGwSiwb0rpRbBtLB+i5OhLPM8+Y2hVmf3KOPpGZGciU1gVeFaUoYrB8Lg IKmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692712745; x=1693317545; 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=l0QNhDtwgrD4clYCX3fNpYfjqVcnL2VuQCT1Cz5mER8=; b=L5wnjx+S2G0cBoGgDmHhXI83bi6ZqGTpNL8T5fNJsUX6rK/UpCN6MLBS8rl/gO31q5 4mZcxhCNbtxfnCtzm0Af0LQ0NdrJsSZIQW5SmekMqwUXYQNMEVa4anTnQ2rwDvUhqej/ F15HDodEOWjdDSvHJk6BV/sq5TYqfzLwp1DpRWK4wIfQ3gjjxxJA6I9GJQanKDJsZscc qOM7DkAZ+Lk6K0bogBpKj9oAOJz0yvlCYqgVoBp+8HN3gXI/4yxFXQrsxSBcbp8dRw+0 N4gGcHj2CSQuJqReK6uXhUwdjLZwiXCqFJ5jMGKScbqrUazAedMfD4cvffZ3JVeT4d65 FL+Q== X-Gm-Message-State: AOJu0Yx/qUVlRWhCZmstbD4gTtgSEN/LPvYE/P0aBUvNN//TGft8O1Xg Oj55D5564/srZm+/DZPRfo169A== X-Google-Smtp-Source: AGHT+IFEv5NdlDw2/8KfZ+36sjxIK6Dh5O63ifFBPMyVxYN2/oGuAnJ6w22xUIqk6gmwnT75U3K6Eg== X-Received: by 2002:a17:90b:b11:b0:263:f521:da3e with SMTP id bf17-20020a17090b0b1100b00263f521da3emr13865382pjb.2.1692712744811; Tue, 22 Aug 2023 06:59:04 -0700 (PDT) Received: from hermes.local (204-195-127-207.wavecable.com. [204.195.127.207]) by smtp.gmail.com with ESMTPSA id y14-20020a17090a134e00b00263154aab24sm7866137pjf.57.2023.08.22.06.59.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Aug 2023 06:59:04 -0700 (PDT) Date: Tue, 22 Aug 2023 06:59:01 -0700 From: Stephen Hemminger To: Feifei Wang Cc: dev@dpdk.org, nd@arm.com Subject: Re: [PATCH v11 0/4] Recycle mbufs from Tx queue into Rx queue Message-ID: <20230822065901.0bb24be6@hermes.local> In-Reply-To: <20230822072710.1945027-1-feifei.wang2@arm.com> References: <20220420081650.2043183-1-feifei.wang2@arm.com> <20230822072710.1945027-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, 22 Aug 2023 15:27:06 +0800 Feifei Wang 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 mbufs > recycle mode. Isn't the recycle ring just another cache? Why is the lcore cache slower? Could we fix the general case there?