From: Ferruh Yigit <ferruh.yigit@intel.com>
To: ALeX Wang <ee07b291@gmail.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] possible kni bug and proposed fix
Date: Mon, 16 May 2016 12:20:31 +0100 [thread overview]
Message-ID: <5739ACFF.4000506@intel.com> (raw)
In-Reply-To: <CANmyKO6rKKCpZCD5aSTcSWBRKktX5Yrf+MF1Q4JUfa=mf2jkTQ@mail.gmail.com>
On 5/15/2016 5:48 AM, ALeX Wang wrote:
> Hi,
>
> When using the kni module to test my application inside
> debian (virtualbox) VM (kernel version 4.4), I get the
>
> "KNI: Out of memory"
>
> from syslog every time I `tcpreply` packets through
> the kni interface.
>
> After checking source code, I saw that when I call
> 'rte_kni_rx_burst()', no matter how many packets
> are actually retrieved, we always call 'kni_allocate_mbufs()'
> and try allocate 'MAX_MBUF_BURST_NUM' more
> mbufs... I fix the issue via using this patch below,
>
> Could you confirm if this is an actual bug?
>
Hi Alex,
I don't think this is a bug.
kni_allocate_mbufs() will allocate MAX_MBUF_BURST_NUM mbufs as you
mentioned. And will fill alloc_q with these mubfs _until it gets full_.
And if the alloc_q is full and there are remaining mbufs, they will be
freed. So for some cases this isn't the most optimized way, but there is
no defect.
Since you are getting "KNI: Out of memory", somewhere else can be
missing freeing mbufs.
mbufs freeing done in rte_kni_tx_burst(), I can guess two cases that can
cause problem:
a) not calling rte_kni_tx_burst() frequent, so that all free mbufs consumed.
b) calling rte_kni_tx_burst() with number of mbufs bigger than
MAX_MBUF_BURST_NUM, because this function frees at most
MAX_MBUF_BURST_NUM of mbufs, but if you are calling calling
rte_kni_tx_burst() with bigger numbers, this will cause mbufs to stuck
in free_q
Regards,
ferruh
next prev parent reply other threads:[~2016-05-16 11:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-15 4:48 ALeX Wang
2016-05-16 11:20 ` Ferruh Yigit [this message]
2016-05-16 15:31 ` ALeX Wang
2016-05-17 10:07 ` Ferruh Yigit
2016-05-17 17:09 ` ALeX Wang
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=5739ACFF.4000506@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=ee07b291@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).