[dpdk-dev] KNI and memzones
Marc Sune
marc.sune at bisdn.de
Tue Sep 23 11:27:47 CEST 2014
Hi all,
So we are having some problems with KNI. In short, we have a DPDK
application that creates KNI interfaces and destroys them during its
lifecycle and connecting them to DOCKER containers. Interfaces may
eventually be even named the same (see below).
We were wondering why even calling rte_kni_release() the hugepages
memory was rapidly being exhausted, and we also realised even after
destruction, you cannot use the same name for the interface.
After close inspection of the rte_kni lib we think the core issue and is
mostly a design issue. rte_kni_alloc ends up calling
kni_memzone_reserve() that calls at the end rte_memzone_reserve() which
cannot be unreserved by rte_kni_relese() (by design of memzones). The
exhaustion is rapid due to the number of FIFOs created (6).
If this would be right, we would propose and try to provide a patch as
follows:
* Create a new rte_kni_init(unsigned int max_knis);
This would preallocate all the FIFO rings(TX, RX, ALLOC, FREE, Request
and Response)*max_knis by calling kni_memzone_reserve(), and store them
in a kni_fifo_pool. This should only be called once by DPDK applications
at bootstrapping time.
* rte_kni_allocate would just use one of the kni_fifo_pool (one =>
meaning a a set of 6 FIFOs making a single slot)
* rte_kni_release would return to the pool.
This should solve both issues. We would base the patch on 1.7.2.
Thoughts?
marc
p.s. Lately someone involved with DPDK said KNI would be deprecated in
future DPDK releases; I haven't read or listen to this before, is this
true? What would be the natural replacement then?
More information about the dev
mailing list