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 AF94046036;
	Thu,  9 Jan 2025 18:03:27 +0100 (CET)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 85EB240612;
	Thu,  9 Jan 2025 18:03:27 +0100 (CET)
Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com
 [209.85.216.53]) by mails.dpdk.org (Postfix) with ESMTP id 59B2740430
 for <dev@dpdk.org>; Thu,  9 Jan 2025 18:03:26 +0100 (CET)
Received: by mail-pj1-f53.google.com with SMTP id
 98e67ed59e1d1-2ee989553c1so1880572a91.3
 for <dev@dpdk.org>; Thu, 09 Jan 2025 09:03:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1736442205;
 x=1737047005; darn=dpdk.org; 
 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=0qaHirV/dAKVcqzUDjQ/dHIHJQjbaxFUxPOYWw/13t4=;
 b=rFc/ZHBDyhiXBe8Wkw+O+N4dO+EdCadtcH0sWyOVGlLhRCgcsVj4MjBpOdVTYsVMd9
 XIDvBQsWlK7Sn8A8eqhPvrVOtvwvxBkSeyOvhp4YbeFc53cIPBA1KCEgIWBb0svCT4nw
 jmyn/7i0PzSK60ce3yX48yLfkVhIbrvLnTN+cNVq7MhB+wtSLJyAcz6HuqeesYsFXrn5
 0cFhI1tSuuY3z5G4QvCId+v3lG3/S2ShQ47JTdaTtdoXV8mge51uRBvezG413xr3LVfk
 D+SXgMUc+8x5or7WZKthJtwnn8SV7rujm2qTnUTWoJpogmex7wR0IFOIDEXoCr6r2eZb
 FURQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1736442205; x=1737047005;
 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=0qaHirV/dAKVcqzUDjQ/dHIHJQjbaxFUxPOYWw/13t4=;
 b=Hly838f51h/Sp/e6uR6fZSHzSBKIkoR62PdC8UnuXVPOBZc+XtOysHKtzg71/M38wz
 pkpHomqEgp/sLLR8zceypyaCKNigoel/eZG36CeCsHaSdl13LUU0S4KTFB9iPFaxpVvU
 5SsTIX5HF+1P7CmqgCBlFAtDDyB0LUipKKWGxqQPXd4Xtfr3jUCIk5f99Yn6Msp3/DbR
 qYjDZfq8OHyMz9/ZG3xSNkcayKW5SikcQM7ZeYgIA2n69kRbABmPIW02sBeq8jJVfmWB
 FrS2ra7GHimTTlDxG7dUHsEVF161J1KFo86Kf+gGdpe6UxSSnpnOGQlm7rbOnBzce876
 WrHQ==
X-Forwarded-Encrypted: i=1;
 AJvYcCU8rdF+z8nNQCpu6H3VMqQtp+K+ruYqlNI389Za4QK5nDC5oU3jMivDUd2D740JhhcLARw=@dpdk.org
X-Gm-Message-State: AOJu0YyDYiHv877ETzRUzxXJp53tMeQg1T9sx9DO15TSJdq/ttWxZwLX
 GIkEGwg5QNLQ49xFlEP7mnb88e26/et3sZPkJjEMto9BZwCCT2JkEhSz3tlQzwY=
X-Gm-Gg: ASbGncu4p5j6vQsO608rpruqwex25vfqWLhIcxvGDHNN8d3JQh28Cice88qmQOCWDzQ
 rR9ntQJwt8EkczTuRiXxd7EwmAYw2IeFzoVyzt9WWsjxRgcDj+UeEn4OfBTZYygUviuw/IS3BkI
 vOT/nYY8PrPTTZ8q3+kwAD1OKHDwL1C4GI5SJj7FSVkyEZv9TszlyHT7RtB4O2BOgzIo36TCs/A
 vZZeIlxgstIsjRvyWk94yfWpQ/4ILqBwG+rN4SOTedBwLKBKM0BsX1xkDOGr9R9IJFxM9u5gMX7
 p5/dsz9w
X-Google-Smtp-Source: AGHT+IHK62vPH50YJHhM3RrVUW2AShO+rvoC5fMMIVNvvoLahukB803+P6aY/WTis4lQFUOs5n1AVA==
X-Received: by 2002:a17:90b:2808:b0:2ee:ab10:c187 with SMTP id
 98e67ed59e1d1-2f548f598e1mr11275042a91.18.1736442205193; 
 Thu, 09 Jan 2025 09:03:25 -0800 (PST)
Received: from pi5 (204-195-96-226.wavecable.com. [204.195.96.226])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2f559451455sm1703812a91.31.2025.01.09.09.03.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 09 Jan 2025 09:03:24 -0800 (PST)
Date: Thu, 9 Jan 2025 09:03:19 -0800
From: Stephen Hemminger <stephen@networkplumber.org>
To: huangdengdui <huangdengdui@huawei.com>
Cc: Jie Hai <haijie1@huawei.com>, <dev@dpdk.org>, <thomas@monjalon.net>,
 <ferruh.yigit@amd.com>, <david.marchand@redhat.com>,
 <andrew.rybchenko@oktetlabs.ru>, Chengwen Feng <fengchengwen@huawei.com>,
 "Wei Hu (Xavier)" <xavier.huwei@huawei.com>, Huisong Li
 <lihuisong@huawei.com>
Subject: Re: [PATCH 1/3] net/hns3: fix simple Tx path incorrect free the mbuf
Message-ID: <20250109090319.261ac377@pi5>
In-Reply-To: <51df8d40-c158-4b67-98b0-ca4517f4bd2c@huawei.com>
References: <20241230065405.18552-1-haijie1@huawei.com>
 <20241230065405.18552-2-haijie1@huawei.com>
 <20241230095530.7cb2f643@pi5>
 <29acb21d-a6d9-04bd-d528-10d1ccf3f7ce@huawei.com>
 <20250108085740.65815a35@pi5>
 <51df8d40-c158-4b67-98b0-ca4517f4bd2c@huawei.com>
X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; aarch64-unknown-linux-gnu)
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, 9 Jan 2025 15:43:12 +0800
huangdengdui <huangdengdui@huawei.com> wrote:

> On 2025/1/9 0:57, Stephen Hemminger wrote:
> > On Wed, 8 Jan 2025 10:40:43 +0800
> > Jie Hai <haijie1@huawei.com> wrote:
> >   
> >> On 2024/12/31 1:55, Stephen Hemminger wrote:  
> >>> On Mon, 30 Dec 2024 14:54:03 +0800
> >>> Jie Hai <haijie1@huawei.com> wrote:
> >>>     
> >>>> From: Jie Hai <haijie1@huawei.com>
> >>>> To: <dev@dpdk.org>, <thomas@monjalon.net>, <ferruh.yigit@amd.com>,  <david.marchand@redhat.com>, <andrew.rybchenko@oktetlabs.ru>, Chengwen Feng  <fengchengwen@huawei.com>, "Wei Hu (Xavier)" <xavier.huwei@huawei.com>,  Huisong Li <lihuisong@huawei.com>
> >>>> CC: <haijie1@huawei.com>, <huangdengdui@huawei.com>
> >>>> Subject: [PATCH 1/3] net/hns3: fix simple Tx path incorrect free the mbuf
> >>>> Date: Mon, 30 Dec 2024 14:54:03 +0800
> >>>> X-Mailer: git-send-email 2.22.0
> >>>>
> >>>> From: Dengdui Huang <huangdengdui@huawei.com>
> >>>>
> >>>> When RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE offload is not set,
> >>>> use rte_pktmbuf_free_seg() to free the mbuf.
> >>>>
> >>>> Fixes: 7ef933908f04 ("net/hns3: add simple Tx path")
> >>>> Cc: stable@dpdk.org
> >>>>
> >>>> Signed-off-by: Dengdui Huang <huangdengdui@huawei.com>
> >>>> Signed-off-by: Jie Hai <haijie1@huawei.com>    
> >>>
> >>> What about the fast free case which is using rte_mempool_put_bulk when
> >>> it should use rte_pktmbuf_free_bulk instead?
> >>>
> >>>     
> >> Hi, Stephen Hemminger,
> >>
> >> During the fast free case, the performance of using
> >> rte_mempool_put_bulk is higher than that of using
> >> rte_pktmbuf_free_bulk because other references
> >> to mbuf do not need to be considered. So it's better
> >>   to not change.
> >>
> >> Thanks,
> >> Jie Hai  
> > 
> > The problem is that having an open coded version of this buried in
> > one driver is a long term potential proble>
> > If you really think that optimizing free like this is noticeable, then
> > why not make a new function "rte_pktmuf_fast_free_bulk" and put it in the
> > regular mbuf library.
> >   
> 
> Do you mean to add the following functions to the library?
> 
> void rte_pktmbuf_fast_free_bulk(struct rte_mbuf **mbufs, unsigned int count)
> {
> 	rte_mempool_put_bulk(mbufs[0]->pool, (void **)mbufs, count);
> }

Yes something like that. Or call it rte_mbuf_raw_free_bulk to align with
what rte_mbuf_raw_free(). And maybe add some debug assertions to make sure
that mbuf is not cloned, indirect or has refcnt.

The concern is that this optimization might put an mbuf in the pool
that has different properties than the normal free path.
And that all semantics of allocation/free should be in rte_mbuf code to
allow for future optimizations.


> 
> The driver uses rte_mempool_put_bulk only when the following conditions are met:
> 1. All mbufs comes from the same mempool
> 2. All mbufs have only one reference.
> 3. All mbufs have only one segment.
> So the rte_pktmbuf_fast_free_bulk function is just a wrapper around the rte_mempool_put_bulk function.