Re: [PATCH 07/10] eal: add core list input format

["Venkatesan, Venky" <venky.venkatesan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

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,
>>
>> 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-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
>>>>>
>>>>> 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 ",")?
>>
> Burn!
Burn ^ 2 ;)