From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 780337E33 for ; Thu, 9 Oct 2014 10:50:41 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP; 09 Oct 2014 01:55:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,683,1406617200"; d="scan'208";a="585903252" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga001.jf.intel.com with ESMTP; 09 Oct 2014 01:57:49 -0700 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 9 Oct 2014 01:57:47 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 9 Oct 2014 01:57:46 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.230]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.190]) with mapi id 14.03.0195.001; Thu, 9 Oct 2014 16:57:45 +0800 From: "Zhang, Helin" To: Marc Sune Thread-Topic: [dpdk-dev] [PATCH] KNI: use a memzone pool for KNI alloc/release Thread-Index: AQHP285+iUgjNWB580Cf22Ir3DYXhpwnUh3w//+O9YCAAIoo0P//gxyAgACOkED//4AWgAARAUBw Date: Thu, 9 Oct 2014 08:57:44 +0000 Message-ID: References: <1411985756-2744-1-git-send-email-marc.sune@bisdn.de> <543633B5.3020101@bisdn.de> <54363ED5.9060304@bisdn.de> <54364B1F.8030605@bisdn.de> In-Reply-To: <54364B1F.8030605@bisdn.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] KNI: use a memzone pool for KNI alloc/release 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: Thu, 09 Oct 2014 08:50:42 -0000 Hi Marc Ohh, I made a stupid proposal of adding a field per port. Sorry! I still ha= ve more comments inlined. > -----Original Message----- > From: Marc Sune [mailto:marc.sune@bisdn.de] > Sent: Thursday, October 9, 2014 4:45 PM > To: Zhang, Helin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] KNI: use a memzone pool for KNI alloc/rel= ease >=20 > Hi Helin, >=20 > Inline and snipped. Thanks for the additional comments. >=20 > On 09/10/14 10:33, Zhang, Helin wrote: > > [snip] > >>> [snip] > >>>>>> It adds a new API call, rte_kni_init(max_kni_ifaces) that shall > >>>>>> be called before any call to rte_kni_alloc() if KNI is used. > >>> To avoid the additional interface, this initialization works can be > >>> done during the first time of calling rte_kni_alloc(), please refer > >>> to how it > >> opens kni_fd ("/dev/kni"). > >>> Also I think there should be some de-initialization works should be > >>> done in > >> rte_kni_close(). > >> How is rte_kni_alloc() supposed to know the size of the pool that has > >> to be pre-allocated (max_kni_ifaces)? > > Add it into 'struct rte_kni_conf', also a default one might be needed > > if 0 is configured by the user app. >=20 > I disagree with this approach :) . struct rte_kni_conf is a per-interface > configuration struct, and the mempool is shared between all the alloc/rel= ease > of the KNI interfaces. >=20 > I don't like the approach to mix one-time-use (first alloc) parameters th= at affect > the entire KNI system into the struct rte_kni_conf. I agree with you, this approach is a bit stupid. >=20 > >> I don't think the approach of pre-allocating on the first > >> rte_kni_alloc() would work (I already discarded this approach before > >> implementing the patch), because this would imply we need a define of > >> #define MAX_KNI_IFACES during compilation time of DPDK, and the > >> pre-allocation is highly dependent on the amount of hugepages memory > >> you have and the usage of the KNI interfaces the applications wants to= do. > >> We can easily end up with DPDK users having to tweak the default > >> MAX_KNI_IFACES before compiling DPDK every time, which is definetely > >> not desirable IMHO. > > Your idea is good! My point is it possible to avoid adding new > > interface, then no changes are needed in user app. >=20 > I see the current approach the most clean and comprehensive (from the > perspective of the user of the library) approach. Do you have any other > proposal? I am open to discuss and eventually implement it if it turns ou= t to be > better. How about add a new compile config item in config files? I still think we s= hould avoid adding more interfaces if possible. :) >=20 > > > >> For rte_kni_close(), the pool is static (incl. the slot struct), and > >> the memzones cannot be unreserved, hence there is nothing AFAIU to > >> de-initialize; what do you mean specifically? > > You can see that rte_kni_close() will be called in XEN (#ifdef > > RTE_LIBRTE_XEN_DOM0), XEN support is different from standard Linux > support. >=20 > OK it is called, but what is the (extra) state that I should de-initializ= e that is > coming from this patch? I cannot see any state I've added I have to de-in= itialize > here. Just suggest you think about that. maybe nothing needs to be added there. := ) >=20 > Many thanks > Marc Thanks! Regards, Helin