From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 989868DA8 for ; Fri, 11 Sep 2015 19:15:22 +0200 (CEST) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 11 Sep 2015 10:15:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,512,1437462000"; d="scan'208";a="643079953" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga003.jf.intel.com with ESMTP; 11 Sep 2015 10:15:21 -0700 Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 11 Sep 2015 10:15:20 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by ORSMSX158.amr.corp.intel.com (10.22.240.20) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 11 Sep 2015 10:15:20 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.247]) by fmsmsx111.amr.corp.intel.com ([169.254.12.103]) with mapi id 14.03.0224.002; Fri, 11 Sep 2015 10:15:20 -0700 From: "Wiles, Keith" To: Don Provan , Thomas Monjalon Thread-Topic: [dpdk-dev] rte_eal_init() alternative? Thread-Index: AdDlfPBIBcvmYGE5S+iOMZ1NcwR9ugAPJFUAAAB5coAACrsHAAABgE2AAAR5wAD//7sDgIAJfosAgARWXgA= Date: Fri, 11 Sep 2015 17:15:20 +0000 Message-ID: References: <44e664970fef4bff942eaee5c7eaca67@bilemail1.empirix.com> <20150902120039.69e3809c@urahara> <1964148.0REVA6fuqc@xps13> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.85.101] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6767B67ADCE76F4DA5C8B64D628238DF@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] rte_eal_init() alternative? 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, 11 Sep 2015 17:15:23 -0000 On 9/8/15, 1:01 PM, "Don Provan" wrote: >From: Wiles, Keith: >>That stated I am not a big fan of huge structures being passed into >>a init routine as that structure would need to be versioned and it will >>grow/change. Plus he did not really want to deal in strings, so the >>structure would be binary values and strings as required. > >A typical library has an init routine which establishes defaults, and >then the application adjusts parameters through targeted set routines >before starting to use the library operationally. In the argc/argv >wrapper, the parsing code would call one of those individual routines >when it parses the corresponding command line flag. > >The idea that there has to be one massive init routine which is >passed every possible configuration parameter is more of the same >monolithic thinking that DPDK needs to shake. I am not sure DPDK has a lot of monolithic parts, so I do not fully understand your statement, if you mean we should carefully add this support in the correct way then I agree. Some items may need to be passed into the first routine and other items can be set via the setter routines. The problem is the current routine does it all at once and it will need go be broken down to do as you say with setter routines. Passing in a few options or a small structure can still work, but we should not try to create a huge structure. Today we have one API rte_eal_init() and breaking this up into 20 routines is going to be a problem IMO, we need to strike a balance of some type that does not use argc/argv or we add new APIs. > >-don provan >dprovan@bivio.net > =8B=20 Regards, ++Keith Intel Corporation