From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas.monjalon@6wind.com>
Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com
 [209.85.212.175]) by dpdk.org (Postfix) with ESMTP id AB728803E
 for <dev@dpdk.org>; Mon, 24 Nov 2014 14:08:52 +0100 (CET)
Received: by mail-wi0-f175.google.com with SMTP id l15so5605353wiw.14
 for <dev@dpdk.org>; Mon, 24 Nov 2014 05:19:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:from:to:cc:subject:date:message-id:organization
 :user-agent:in-reply-to:references:mime-version
 :content-transfer-encoding:content-type;
 bh=LbDZFfUaL8fAh/M9MAsSvPtCh+g2bl0rcbGnsohW8Hg=;
 b=BZ/Ptlr4OpWpJqmmDvTbFyLb4iTD4PReJaxcbi3X7Ba+4Mu9uSASDdBa0RgLA0iSRi
 lOTdf+d6ONb/ryj6gfpzCN+lVC2u1tr9LNzdve+TkjcIPVHApZih90ZNR6rbIranEHuw
 CJeLcUq9oNOt7hQx1N/vZFMcUgMgSIZp2teRYhyGpIGRuQaDZ5MZFnuIDecvmEjcTjHH
 hDDrsttgBtBxUIVhM7iCv00s4Lk1oClGYGK3HT9cvLUgx3K1Yyx1dQul83Z3AnEjxIeA
 3Y1ui77ihaNqXWHwxdV9dUXMpGHO+iKmly+xBvPaTGEI6XIx3bifYKwnILCfwLvy8Z0R
 +FsQ==
X-Gm-Message-State: ALoCoQnaPEBZsYq+7jzXe3xEpYgULRuu7bxoDnRZFVuqBiukLeHl8GGExthJd5pebobODsXMVM5k
X-Received: by 10.194.57.43 with SMTP id f11mr24539293wjq.6.1416835180501;
 Mon, 24 Nov 2014 05:19:40 -0800 (PST)
Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136])
 by mx.google.com with ESMTPSA id n3sm12031281wiw.5.2014.11.24.05.19.39
 for <multiple recipients>
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 24 Nov 2014 05:19:39 -0800 (PST)
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Bruce Richardson <bruce.richardson@intel.com>,
 Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 24 Nov 2014 14:19:16 +0100
Message-ID: <4662010.O9okd8Allt@xps13>
Organization: 6WIND
User-Agent: KMail/4.14.2 (Linux/3.17.2-1-ARCH; KDE/4.14.2; x86_64; ; )
In-Reply-To: <20141124112819.GA11552@bricha3-MOBL3>
References: <1416692622-28886-1-git-send-email-thomas.monjalon@6wind.com>
 <20141123013517.GA3982@localhost.localdomain>
 <20141124112819.GA11552@bricha3-MOBL3>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 07/10] eal: add core list input format
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 13:08:52 -0000

Hi Bruce and Neil,

2014-11-24 11:28, Bruce Richardson:
> On Sat, Nov 22, 2014 at 08:35:17PM -0500, Neil Horman wrote:
> > On Sat, Nov 22, 2014 at 10:43:39PM +0100, Thomas Monjalon wrote:
> > > From: Didier Pallard <didier.pallard@6wind.com>
> > > 
> > > In current version, used cores can only be specified using a bitmask.
> > > It will now be possible to specify cores in 2 different ways:
> > > - Using a bitmask (-c [0x]nnn): bitmask must be in hex format
> > > - Using a list in following format: -l <c1>[-c2][,c3[-c4],...]
> > > 
> > > The letter -l can stand for lcore or list.
> > > 
> > > -l 0-7,16-23,31 being equivalent to -c 0x80FF00FF
> > 
> > Do you want to burn an option letter on that?  It seems like it might be better
> > to search the string for 0x and base the selection of bitmap of list parsing
> > based on its presence or absence.

It was the initial proposal (in April):
	http://dpdk.org/ml/archives/dev/2014-April/002173.html
And I liked keeping only 1 option;
	http://dpdk.org/ml/archives/dev/2014-May/002722.html
But Anatoly raised the compatibility problem:
	http://dpdk.org/ml/archives/dev/2014-May/002723.html
Then there was no other comment so Didier and I reworked a separate option. 

> The existing coremask parsing always assumes a hex coremask, so just looking
> for a 0x will not work. I prefer this scheme of using a new flag for this method
> of specifying the cores to use. 
> 
> If you don't want to use up a single-letter option, two alternatives:
> 1) use a long option instead.
> 2) if the -c parameter includes a "-" or a ",", treat it as a new-style option,
> otherwise treat as old. The only abiguity here would be for specifying a single
> core value 1-9 e.g. is "-c 6" a mask with two bits, or a single-core to run on.
> [0 is obviously a named core as it's an invalid mask, and A-F are obviously
> masks.] If we did want this scheme, I would suggest that we allow trailing
> commas in the list specifier, so we can force users to clear ambiguity by
> either writing "0x6" or "6," i.e. disallow ambiguous values to avoid problems.
> However, this is probably more work that it's worth to avoid using up a letter
> option.
> 
> I'd prefer any of these options to breaking backward compatibility in this case.

We need a consensus here.
Who is supporting a "burn" of an one-letter option with clear usage?
Who is supporting a "re-merge" of the 2 syntaxes with more complicated rules
(list syntax is triggered by presence of "-" or ",")? 

Please vote quickly.
Thanks
-- 
Thomas