[dpdk-dev] possible kni bug and proposed fix

Ferruh Yigit ferruh.yigit at intel.com
Mon May 16 13:20:31 CEST 2016


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




More information about the dev mailing list