From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Paras Jha <dreadiscool@gmail.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] rte_eth_tx_burst improperly freeing mbufs from KNI mbuf pool
Date: Tue, 30 Apr 2019 15:59:25 +0100 [thread overview]
Message-ID: <9c7588c8-b1b8-7363-5b44-209a2bf1fa0e@intel.com> (raw)
Message-ID: <20190430145925.-gQd7x7hXeFL6jOfaOUa3cdiHZxcdJ20VTIFWMNNJcs@z> (raw)
In-Reply-To: <CAMs8r4M25oYOs=G0+jrAz+=QFj2CFisXTZJ=Pp4FhAZpUDj=2Q@mail.gmail.com>
On 4/10/2019 2:10 PM, Paras Jha wrote:
> Hi all,
>
> I've been chasing down a strange issue related to rte_kni_tx_burst.
>
> My application calls rte_kni_rx_burst, which allocates from a discrete mbuf
> pool using kni_allocate_mbufs. That traffic is immediately sent to
> rte_eth_tx_burst which does not seem to be freeing mbufs even upon
> succesful completion.
>
> My application follows the standard model of freeing mbufs only if the
> number of tx mbufs is less than the rx mbufs - however, after sending as
> many mbufs as there are in the pool, I get KNI: Out of memory soon after
> when calling rte_kni_rx_burst
>
> My concern is that if I free all mbufs allocated by the KNI during
> rte_kni_rx_burst the application seems to work as intended without memory
> leaks, even though this goes against how the actual PMDs work. Is this a
> bug, or intended behavior? The documented examples on the DPDK website seem
> to only free mbufs if it fails to send, even with the KNI example.
The behavior in the KNI sample application is correct thing to do, free only the
mbufs failed to Tx. As far as I understand you are doing same thing as the kni
sample app, so it should be OK, sample app works fine.
'rte_eth_tx_burst()' sends packets to the kernel, so it shouldn't free the
mbufs, right, userspace can't know when kernel side will be done with them.
When kernel side is done, it puts the mbufs into 'free_q' fifo,
'kni_free_mbufs()' pulls the mbuf from 'free_q' fifo and frees them.
So the mbufs sent via 'rte_eth_tx_burst()' freed asynchronously.
I hope this helps.
next prev parent reply other threads:[~2019-04-30 14:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 13:10 Paras Jha
2019-04-10 13:10 ` Paras Jha
2019-04-30 14:59 ` Ferruh Yigit [this message]
2019-04-30 14:59 ` Ferruh Yigit
2019-04-30 15:37 ` Paras Jha
2019-04-30 15:37 ` Paras Jha
2019-04-30 15:39 ` Paras Jha
2019-04-30 15:39 ` Paras Jha
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=9c7588c8-b1b8-7363-5b44-209a2bf1fa0e@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=dreadiscool@gmail.com \
/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).