From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id C246C7FCA for ; Fri, 10 Oct 2014 09:28:18 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 10 Oct 2014 00:35:42 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,690,1406617200"; d="scan'208";a="612328604" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by fmsmga002.fm.intel.com with ESMTP; 10 Oct 2014 00:35:42 -0700 Received: from fmsmsx116.amr.corp.intel.com (10.18.116.20) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 10 Oct 2014 00:35:41 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by fmsmsx116.amr.corp.intel.com (10.18.116.20) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 10 Oct 2014 00:35:42 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.230]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.204]) with mapi id 14.03.0195.001; Fri, 10 Oct 2014 15:35:40 +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//+RKwD//jwMwIADGW2A//9t3AA= Date: Fri, 10 Oct 2014 07:35:39 +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> <54366044.8020507@bisdn.de> <54377EB7.6080300@bisdn.de> In-Reply-To: <54377EB7.6080300@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: Fri, 10 Oct 2014 07:28:19 -0000 Hi Marc > -----Original Message----- > From: Marc Sune [mailto:marc.sune@bisdn.de] > Sent: Friday, October 10, 2014 2:38 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 > On 10/10/14 07:25, Zhang, Helin wrote: > > Hi Marc > > > > More comments added. > > > >> [snip] > >>>>>> 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. > >>>> 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 out to be better. > >>> How about add a new compile config item in config files? I still > >>> think we should avoid adding more interfaces if possible. :) > >> In my original answer to your comment here cited starting by "I don't > >> think the approach of pre-allocating on the first rte_kni_alloc()..." > >> I explain why I think this is not a good idea. > > I understood your concern. It is not bad of adding a config item in > > config files (config/config_linux), as it already has a lot of compile = time > configurations in them. > > For a specific platform, the maximum number of KNI interfaces should > > be fixed, and no need to be changed frequently. > rte_kni_init() should be staying. Actually the asymmetry of the API nowad= ays > (no rte_kni_init, because fd is created during first alloc but an rte_kni= _close) > looks weird to me. Just an aside question, not related to this patch, why= was > the KNI fd not closed in the last rte_kni_release to be consistent? Initially there was no rte_kni_close() which was later added for supporting= XEN specifically. If KNI needs an init function, it might need to be put in rte_eal_init() li= ke other modules do. > > > >> A config.g #define approach would be highly dependent on hugepages > >> memory size and the usage the applications wants to do with KNI > >> interfaces. Specially due to the former, I don't think it is a good > >> idea. DPDK doesn't force any user to edit manually the config.h > >> AFAIK, unless you want to do some performance optimizations or debug. > >> And I think it is a good approach and I would like to keep it and not > >> break it with this patch > > No need to edit config.h, just modify config/config_linux or config/con= fig_bsd. > This is what I meant, all the config_*.h > >> Any parameter that depends on DPDK applications so far, so really out > >> of the scope of DPDK itself (like the size of the pool parameter is), > >> is handled via an API call. So I see rte_kni_init() as the natural > >> way to do so, specially by the fact that rte_kni_close() API call alre= ady exists. > > I agree that your solution is good, I am just thinking if we can make > > less changes for API level. >=20 > I can understand the reluctance for adding new API calls, but, let me dou= ble > check, as I am not sure you understood my point: >=20 > If we set it in the config_*.h, and we set MAX_NUM_OF_KNI to a value > whatever, 8, 16... 128..., it is quite possible that a lot of users of DP= DK that will > use the KNI (only those) get run-time errors since the memzones cannot be > pre-allocated (out of memory). Memzones are preallocated at rte_kni_init(= ) (or > at first alloc, as per what you are suggesting). Moreover, the user would= have > to go and change (e.g. > reduce) the MAX_NUM_OF_KNI in the config_*.h and recompile DPDK. I don't > think that's what we want. Actually the end user doesn't know the mapping between hugepage memory size and the maximum number of KNI. Right? Giving 1G memory, end user doesn't kn= ow how many KNI interfaces it can support. So the maximum number of KNI interf= aces still needs to be tuned. I think the default number can be tuned to a reasonable small to support mo= st of cases, e.g. 4 or 8. And I don't think that number needs to be changed at ru= ntime. >=20 > Marc Regards, Helin