From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by dpdk.org (Postfix) with ESMTP id 8CE11333 for ; Tue, 23 Sep 2014 14:33:11 +0200 (CEST) Received: by mail-yk0-f170.google.com with SMTP id 19so1754481ykq.15 for ; Tue, 23 Sep 2014 05:39:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1JbJacWL0xJw2eOIwDN8hjJfYwG9krga/6GsXplZh/k=; b=TkQlrILDQzVGwBggr7f/K6zkkpBByWVcaqkNGj3V/0CIJRp4F5CPpsZZEq6jGRYDza hP9JijogJQ2twGQiw6ZAes3J2KGnn4kmEr0NrsZMK+A4G47kQ8/I2HRtypW2jF1kKrv/ LEWeOATkWXQLOp4yZW5ACyxfG5I/8lNSclnXq12cd05IHutqslVVDR3IJ4KVEA0ZT4FT pPDAEgbeecDPb1fJonzG14eyr71Q6dS6rYlwFvFV1AkDgpXinG4upkFYvd9gi4OTin+6 Izc6hVnjlZNzXKzxLFGsBXOIFqJpNRddY6yN7MyYmE00q5KG1EhuTl3enfujd43WPbsE SZoQ== X-Gm-Message-State: ALoCoQkZKliIaX1zEoL6ScVaB8szT2jAm/P6EABzRjC/ZpEVvvMpwoUUzeFojaUE55IHiPlCyX9q MIME-Version: 1.0 X-Received: by 10.236.41.100 with SMTP id g64mr17661652yhb.60.1411475959064; Tue, 23 Sep 2014 05:39:19 -0700 (PDT) Received: by 10.170.84.10 with HTTP; Tue, 23 Sep 2014 05:39:18 -0700 (PDT) In-Reply-To: <54213D13.4040605@bisdn.de> References: <54213D13.4040605@bisdn.de> Date: Tue, 23 Sep 2014 07:39:18 -0500 Message-ID: From: Jay Rolette To: Marc Sune Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "" , "dev-team@bisdn.de" Subject: Re: [dpdk-dev] KNI and memzones X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 12:33:12 -0000 *> 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?* KNI is a non-trivial part of the product I'm in the process of building. I'd appreciate someone "in the know" addressing this one please. Are there specific roadmap plans relative to KNI that we need to be aware of? Regards, Jay On Tue, Sep 23, 2014 at 4:27 AM, Marc Sune wrote: > 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? >