From: Stephen Hemminger <stephen@networkplumber.org>
To: Yasin CANER <yasin.caner@ulakhaberlesme.com.tr>
Cc: "users@dpdk.org" <users@dpdk.org>
Subject: Re: DPDK 22.11 - How to fix memory leak for KNI - How to debug
Date: Thu, 4 May 2023 09:14:50 -0700 [thread overview]
Message-ID: <20230504091450.4520f2c6@hermes.local> (raw)
In-Reply-To: <AM9P189MB155428CC0218E33AADF29B8CB96D9@AM9P189MB1554.EURP189.PROD.OUTLOOK.COM>
On Thu, 4 May 2023 13:00:32 +0000
Yasin CANER <yasin.caner@ulakhaberlesme.com.tr> wrote:
> In default-testing kni application works as below
>
>
> 1. Call rte_kni_rx_burst function to get messages
> 2. Then push to other KNI interface via rte_kni_tx_burst. There is no memory-leak because kni_free_mbufs is called and freed unused allocations.
>
> On the other hand, in my scenario
>
>
> 1. Call rte_kni_rx_burst func to get messages, burst_size is 32 but 1 packet is received from Kernel
> 2. Then try to free all messages via rte_pktmbuf_free
> 3. Freed 1 unit and 31 unit is not freed. memory leak
>
> Other scenario,
>
>
> 1. Call rte_kni_rx_burst func to get messages, burst_size is 32 but 1 packet is received from Kernel
> 2. Push to ethernet_device via rte_eth_tx_burst
> 3. There is not any free operation by rte_eth_tx_burst
> 4. Try to free via rte_pktmbuf_free
> 5. 1 unit is freed 31 unit is left in memory. Still memory leak
It looks like you are confused about the lifetime of mbufs, and the "ownership" of the mbuf.
When you do kni_rx_burst, one mbuf is full of data and returned. The other 31 slots are not used.
Only the first mbuf is valid.
When mbuf is passed to another DPDK device driver for transmit. The mbuf is then owned by the
device. This mbuf can not be freed until the device has completed DMA and is transmitting it.
Also, many devices defer freeing transmit mbuf's as an optimization. There is some limited control
over the transmit freeing via tx_free_thresh. See the DPDK programmers guide for more info:
https://doc.dpdk.org/guides/prog_guide/poll_mode_drv.html
next prev parent reply other threads:[~2023-05-04 16:14 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-04 7:32 Yasin CANER
2023-05-04 13:00 ` Yasin CANER
2023-05-04 16:14 ` Stephen Hemminger [this message]
2023-05-08 6:01 Yasin CANER
2023-05-08 16:18 ` Stephen Hemminger
2023-05-09 11:13 ` Yasin CANER
2023-05-11 14:14 ` Yasin CANER
2023-05-17 17:53 ` Ferruh Yigit
2023-05-18 8:14 ` Yasin CANER
2023-05-18 14:56 ` Ferruh Yigit
2023-05-19 17:47 ` Yasin CANER
2023-05-19 18:43 ` Ferruh Yigit
2023-05-29 6:33 ` Yasin CANER
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230504091450.4520f2c6@hermes.local \
--to=stephen@networkplumber.org \
--cc=users@dpdk.org \
--cc=yasin.caner@ulakhaberlesme.com.tr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).