On Wed, 8 Jan 2025 10:40:43 +0800 Jie Hai <[email protected]> wrote:
> On 2024/12/31 1:55, Stephen Hemminger wrote: > > On Mon, 30 Dec 2024 14:54:03 +0800 > > Jie Hai <[email protected]> wrote: > > > >> From: Jie Hai <[email protected]> > >> To: <[email protected]>, <[email protected]>, <[email protected]>, > >> <[email protected]>, <[email protected]>, Chengwen > >> Feng <[email protected]>, "Wei Hu (Xavier)" > >> <[email protected]>, Huisong Li <[email protected]> > >> CC: <[email protected]>, <[email protected]> > >> 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 <[email protected]> > >> > >> 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: [email protected] > >> > >> Signed-off-by: Dengdui Huang <[email protected]> > >> Signed-off-by: Jie Hai <[email protected]> > > > > 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 problem. 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.
