[dpdk-dev] possible kni bug and proposed fix

[Ferruh Yigit]

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 at intel.com
> <mailto:ferruh.yigit at 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