DPDK patches and discussions
 help / color / mirror / Atom feed
From: ALeX Wang <ee07b291@gmail.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] possible kni bug and proposed fix
Date: Mon, 16 May 2016 08:31:06 -0700	[thread overview]
Message-ID: <CANmyKO6LGqpODU6G=EXGseoxmtjGd9kw+3UuSHRCd=OSBVsQsg@mail.gmail.com> (raw)
In-Reply-To: <5739ACFF.4000506@intel.com>

Hi Ferruh,

Thx for pointing out the 'fill alloc_q with these mubfs _until it gets
full_.',

I saw the size of all queues are 'KNI_FIFO_COUNT_MAX (1024)'...
The corresponding memory required is more than what I specify as
'socket_mem' (since i'm using VM)...

Also, in my use case, I only `tcpreplay` through the kni interface, and
my application only do rx and then free the 'mbufs'.  So there is no tx at
all.

So, in my case, I still think this is a bug/defect, or somewhere i still
misunderstand,

P.S. The description here seems to be inverted,
http://dpdk.org/doc/api/rte__kni_8h.html#a0cdd727cdc227d005fef22c0189f3dfe
'rte_kni_rx_burst' does the 'It handles allocating the mbufs for KNI
interface alloc queue.'

Thanks,
Alex Wang,

On 16 May 2016 at 04:20, Ferruh Yigit <ferruh.yigit@intel.com> wrote:

> 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
>
>
>


-- 
Alex Wang,
Open vSwitch developer

  reply	other threads:[~2016-05-16 15:31 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
2016-05-16 15:31   ` ALeX Wang [this message]
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='CANmyKO6LGqpODU6G=EXGseoxmtjGd9kw+3UuSHRCd=OSBVsQsg@mail.gmail.com' \
    --to=ee07b291@gmail.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.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).