From: Ferruh Yigit <ferruh.yigit@intel.com>
To: ALeX Wang <ee07b291@gmail.com>
Cc: dev@dpdk.org
Subject: Re: possible kni bug and proposed fix
Date: Tue, 17 May 2016 11:07:27 +0100 [thread overview]
Message-ID: <573AED5F.3080105@intel.com> (raw)
In-Reply-To: <CANmyKO6LGqpODU6G=EXGseoxmtjGd9kw+3UuSHRCd=OSBVsQsg@mail.gmail.com>
On 5/16/2016 4:31 PM, ALeX Wang wrote:
> 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)...
>
If the mempool is not big enough to fill the ring, this explains the
error log. Logic is to fill the alloc_q, but if you are missing the
required mbufs, in each rte_kni_rx_burst() it will complain about memory.
But the required memory for mbufs to fill the ring is not too much. It
should be ~2Mbytes, are you sure you are missing this much memory?
> 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.'
>
You are right. That part of the description for rte_kni_rx_burst and
rte_kni_tx_burst needs to be replaced. Do you want to send a patch?
> Thanks,
> Alex Wang,
>
> On 16 May 2016 at 04:20, Ferruh Yigit <ferruh.yigit@intel.com
> <mailto: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
next prev parent reply other threads:[~2016-05-17 10:07 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-15 4:48 possible kni bug and proposed fix ALeX Wang
2016-05-16 11:20 ` Ferruh Yigit
2016-05-16 15:31 ` ALeX Wang
2016-05-17 10:07 ` Ferruh Yigit [this message]
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=573AED5F.3080105@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.