From patchwork Wed Nov 18 12:51:20 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Zoltan Kiss X-Patchwork-Id: 56939 Delivered-To: patch@linaro.org Received: by 10.112.155.196 with SMTP id vy4csp2542010lbb; Wed, 18 Nov 2015 04:51:32 -0800 (PST) X-Received: by 10.140.166.6 with SMTP id m6mr1174208qhm.35.1447851092106; Wed, 18 Nov 2015 04:51:32 -0800 (PST) Return-Path: Received: from lists.linaro.org (lists.linaro.org. [54.225.227.206]) by mx.google.com with ESMTP id b141si2129667qka.14.2015.11.18.04.51.31; Wed, 18 Nov 2015 04:51:32 -0800 (PST) Received-SPF: pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) client-ip=54.225.227.206; Authentication-Results: mx.google.com; spf=pass (google.com: domain of lng-odp-bounces@lists.linaro.org designates 54.225.227.206 as permitted sender) smtp.mailfrom=lng-odp-bounces@lists.linaro.org; dkim=neutral (body hash did not verify) header.i=@linaro-org.20150623.gappssmtp.com Received: by lists.linaro.org (Postfix, from userid 109) id AB05F61D7E; Wed, 18 Nov 2015 12:51:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ip-10-142-244-252 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, T_DKIM_INVALID, URIBL_BLOCKED autolearn=disabled version=3.4.0 Received: from [127.0.0.1] (localhost [127.0.0.1]) by lists.linaro.org (Postfix) with ESMTP id 13AB561CFF; Wed, 18 Nov 2015 12:51:26 +0000 (UTC) X-Original-To: lng-odp@lists.linaro.org Delivered-To: lng-odp@lists.linaro.org Received: by lists.linaro.org (Postfix, from userid 109) id 3413B61D03; Wed, 18 Nov 2015 12:51:23 +0000 (UTC) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by lists.linaro.org (Postfix) with ESMTPS id C5FC961CF0 for ; Wed, 18 Nov 2015 12:51:21 +0000 (UTC) Received: by wmww144 with SMTP id w144so195719187wmw.1 for ; Wed, 18 Nov 2015 04:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=no3wmPJ8Jz3hOjoL6y/Hv3zmVBBCHQpU6OkYOZFG6Q4=; b=Ii8n104L0xGzKIAxdkmC0eoJ/gHes5h4sAI4zgvw2Kb5er0mC1vfCElP10YkTbgovp eQWiCJFi/mZye02IX1iLNPK2Hqab84tRD7R9jsjMnlqlT1Rh5pDDeKulMOivezjCyTM9 w1Lk7vAtS9qj5CPyMCB3C0l9pDJuP807PyHv4ZkmaYkNqJwGOBJ/BolLdZBv7Iu7iza5 X0aM/0c0nwsjBQeZ3flzt+67bOPYPCnWotsVGoWKwtcoedUD3jbbgAhmFweViQyzFmH/ ywknjUzYvveXzQiOYZCl3yJkwEP0g61Sp09DUBgWV9qRtUxwKLxDpJXA9O+6ZJ7WgctY P1Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=no3wmPJ8Jz3hOjoL6y/Hv3zmVBBCHQpU6OkYOZFG6Q4=; b=aBOhkgS4EO1abgUNf4z4iDk9zpoFFVWKqqJ5ptFt5q1uOvEJsz+8ssTswIZFWqTAkN 5MUwigC2G2uDXcGqC5wo3tZ192nmN5p0ZyTRXT7wR1EHUHOqfIgSzKJdlkiT2kibGlxR ILUhTR65+gVIso31dXReubakdYGmu8ad0In6i3VzLdFkYgrFIlJU62utiYabzGs/EXdH aci/xp+FVQeCrqdH8G/9/fqU4Hi0mcXHTpVprTcMERj/YIMHmQIVA4QxBxBGZxiPTajn Hg8EAP+G0cV19SVesH5275ZnAUNHSItdW8q6P3oHxW6E1dgElxBZbVFyasXNG56bgCUU 86Bg== X-Gm-Message-State: ALoCoQlXRlyK9m9g4k28f8cTyPWtOUIkujC5qVMeaNdNPKpGqZc2jFIGxk5mPMYONDO7CKuV8cVE X-Received: by 10.28.134.199 with SMTP id i190mr3832967wmd.33.1447851080946; Wed, 18 Nov 2015 04:51:20 -0800 (PST) Received: from [192.168.0.101] ([90.152.119.35]) by smtp.googlemail.com with ESMTPSA id om1sm2754164wjc.2.2015.11.18.04.51.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2015 04:51:20 -0800 (PST) To: Bill Fischofer References: <564B77F5.4060208@linaro.org> <564C59F2.5040706@linaro.org> From: Zoltan Kiss Message-ID: <564C7448.9020601@linaro.org> Date: Wed, 18 Nov 2015 12:51:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Cc: lng-odp Subject: Re: [lng-odp] odp_platform_init_t vs ODP_PLATFORM_PARAMS X-BeenThere: lng-odp@lists.linaro.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: "The OpenDataPlane \(ODP\) List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lng-odp-bounces@lists.linaro.org Sender: "lng-odp" On 18/11/15 12:05, Bill Fischofer wrote: > > > On Wed, Nov 18, 2015 at 4:58 AM, Zoltan Kiss > wrote: > > > On 17/11/15 20:46, Bill Fischofer wrote: > > I vote for B. The idea is that if the application wishes to > override it > can do so otherwise let the implementation take its defaults > from the > environment or however else it wishes to support platform-specific > > > I think your analogy fails a bit here because not passing > odp_platform_init_t doesn't mean you are using "defaults". It just > means you are using an another way to provide the configuration. > > > That "other way" by definition is a platform-specific default mechanism, > which might be an environment variable or something else entirely. The > point is either the application has an application-centric preference or > it does not. Option B handles those options simply and cleanly. I see. If you phrase it like this, it explains why we want to have two ways to do the same things, I like that. My original thought was to explicitly define ODP_PLATFORM_PARAMS, but it's better to leave it out. I would phrase option B then like this: > > > configuration options. This is in keeping with how we handle other > overridable defaults for things like log and abort functions. > Specify > NULL == accept whatever default behavior is in effect, otherwise > specify > what you want. Simpler for everyone. > > On Tue, Nov 17, 2015 at 1:05 PM, Mike Holmes > > >> > wrote: > > > > On 17 November 2015 at 13:54, Zoltan Kiss > > >> wrote: > > Hi all, > > Our odp_init_global() has a second parameter with type > odp_platform_init_t. It's supposed to convey platform > specific > init parameters, however neither linux-generic nor > linux-dpdk > uses that. In the latter we use instead the > ODP_PLATFORM_PARAMS > environment variable. It has the little advantage that > you don't > have to modify your application's code, but it limits > you to > strings. In case of ODP-OVS we store this in OVSDB and > retrieve > it from the startup script (or specify it manually if > you don't > use the startup script.) > I'm tempted to change ODP-OVS and ODP-DPDK to use > odp_platform_init_t, would be cleaner for OVS and for > any bigger > application which have a nice, full-fledged config database > solution. But that would immediately bring us a bigger > problem: > none of our unit tests or example applications supports > passing > this parameter at all. They are small applications, > implementing > a proper config management would be an overkill. I have two > options to solve this: > > Apart from keeping the odp_platform_init_t type to be > passed > odp_init_global() > > A) change our code in linux-generic for examples and > tests (>20 > places in the repo) to get the platform parameters from > ODP_PLATFORM_PARAMS env variable, and pass it down to > odp_init_global() as a string. > > B) Or just allow a platform to use both ways, document > this, and > require that if both are present, the > odp_platform_init_t passed > as parameter should take precedence. So smaller > applications > using simply configurable platforms (like ODP-DPDK) > don't have > to figure out a way to deal with this problem. > > I have a slight preference towards B), but I could be > convinced > that it's a bad idea to have 2 ways to do the same thing. > > > I like A, two ways always feels bad to me. > I like that it is explicitly passed in and you know what > you have. > Env vars can change without the difference being seen in > the code as > easily and not all OS'es have env vars. Env vars are a > great way to > do system dependent things but I think the application should > translate them into the odp_platform_init_t so that the > fudging is > the apps problem and the app knows more about the portability > compromises it is making when using platform specifics. > > > Thoughts? > > Zoltan > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > > > https://lists.linaro.org/mailman/listinfo/lng-odp > > > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org ***│ *Open source > software for > ARM SoCs > > __ > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > > > https://lists.linaro.org/mailman/listinfo/lng-odp > > > --- a/include/odp/api/init.h +++ b/include/odp/api/init.h @@ -152,6 +152,10 @@ typedef struct odp_platform_init_t { * * @see odp_term_global() * @see odp_init_local() which is required per thread before use. + * @note The underlying implementation may have an another way to get + * configuration related to platform_params (e.g. environmental variable, + * configuration file), but if the application passes it, it should always + * take precedence. */ int odp_init_global(const odp_init_t *params, const odp_platform_init_t *platform_params);