From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivano Cerrato <8002onavi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Subject: KNI Out of memory Date: Wed, 27 Aug 2014 10:40:48 +0200 Message-ID: <53FD9990.4050709@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit To: "dev-VfR2kkLFssw@public.gmane.org" Return-path: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hello, I wrote a code that creates some KNI interfaces, destroys them when some management events occur, and creates new interfaces when other management events happen. What happens is that I create a number of interfaces using "kni_alloc", I destroy ALL of them through "kni_release" and, when I try to create a new one I get the message "KNI out of memory" during the execution of the "kni_alloc". The number of interfaces that I can create/destroy before getting the error depends on the size of the mempool that I specify during the creation of the interfaces themselves. Then, to me it seems that the memory is not properly released when a KNI interface is destroyed. Before invoking "kni_release", I drain all the remaining mbufs in the tx queues. While checking the sources of DPDK, I have seen that indeed this trace only appears when there there are no mbufs available in the mempool. Am I missing something here? Is there any other call necessary to properly release a KNI interface? Just before/after the creation and release of an interface, I print the values obtained by invoking "rte_mempool_count" and "rte_mempool_free_count" on the mempool used for the KNI. What I get is the following: the value obtained with "rte_mempool_count" tends to decrease, while the value get with "rte_mempool_free_count" tends to increase. What is the exact semantic of "rte_mempool_count" and "rte_mempool_free_count"? From the doxygen documentation, it seems that the behaviour should be the opposite. Best regards, Ivano