From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <keith.wiles@icloud.com>
Received: from nk11p07mm-asmtp001.mac.com (nk11p07mm-asmtp001.mac.com
 [17.158.42.246]) by dpdk.org (Postfix) with ESMTP id 332917FED
 for <dev@dpdk.org>; Mon, 24 Nov 2014 17:01:48 +0100 (CET)
Received: from [172.25.40.171]
 (97-94-195-106.dhcp.ftwo.tx.charter.com [97.94.195.106])
 by nk11p07mm-asmtp001.mac.com
 (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014))
 with ESMTPSA id <0NFJ000NHX0X4V70@nk11p07mm-asmtp001.mac.com> for
 dev@dpdk.org; Mon, 24 Nov 2014 16:12:35 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
 engine=2.50.10432:5.13.68,1.0.28,0.0.0000
 definitions=2014-11-24_02:2014-11-24,2014-11-24,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0
 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411240132
Content-type: text/plain; charset=windows-1252
MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Roger Keith Wiles <keith.wiles@icloud.com>
In-reply-to: <54734618.1020905@intel.com>
Date: Mon, 24 Nov 2014 10:12:33 -0600
Content-transfer-encoding: quoted-printable
Message-id: <7E169FC8-CED0-4DD1-B2DA-CAAAFFBD7231@icloud.com>
References: <1416692622-28886-1-git-send-email-thomas.monjalon@6wind.com>
 <20141123013517.GA3982@localhost.localdomain>
 <20141124112819.GA11552@bricha3-MOBL3> <4662010.O9okd8Allt@xps13>
 <20141124132821.GA11116@bricha3-MOBL3> <54734618.1020905@intel.com>
To: Venky Venkatesan <venky.venkatesan@intel.com>
X-Mailer: Apple Mail (2.1993)
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 16:01:48 -0000

Burn, it is not like we are going to add a huge number of new options in =
the future and run out of letters.

> On Nov 24, 2014, at 8:52 AM, Venkatesan, Venky =
<venky.venkatesan@intel.com> wrote:
>=20
>=20
> On 11/24/2014 5:28 AM, Bruce Richardson wrote:
>> On Mon, Nov 24, 2014 at 02:19:16PM +0100, Thomas Monjalon wrote:
>>> Hi Bruce and Neil,
>>>=20
>>> 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>
>>>>>>=20
>>>>>> 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],...]
>>>>>>=20
>>>>>> The letter -l can stand for lcore or list.
>>>>>>=20
>>>>>> -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.
>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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 ",")?
>>>=20
>> Burn!
> Burn ^ 2 ;)