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 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 ; Thu, 9 Jan 2025 18:03:26 +0100 (CET) Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-2ee989553c1so1880572a91.3 for ; 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 To: huangdengdui Cc: Jie Hai , , , , , , Chengwen Feng , "Wei Hu (Xavier)" , Huisong Li 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, 9 Jan 2025 15:43:12 +0800 huangdengdui wrote: > On 2025/1/9 0:57, Stephen Hemminger wrote: > > On Wed, 8 Jan 2025 10:40:43 +0800 > > Jie Hai wrote: > > > >> On 2024/12/31 1:55, Stephen Hemminger wrote: > >>> On Mon, 30 Dec 2024 14:54:03 +0800 > >>> Jie Hai wrote: > >>> > >>>> From: Jie Hai > >>>> To: , , , , , Chengwen Feng , "Wei Hu (Xavier)" , Huisong Li > >>>> CC: , > >>>> 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 > >>>> > >>>> 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 > >>>> Signed-off-by: Jie Hai > >>> > >>> 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.