> On Nov 24, 2014, at 11:04 AM, Neil Horman wrote:
>
> On Mon, Nov 24, 2014 at 10:12:33AM -0600, Roger Keith Wiles wrote:
>> Burn, it is not like we are going to add a huge number of new options in the
>> future and run out of letters.
>>
> No, but what about the application authors that need to accomodate all of the
> dpdk command line options as well?
The application authors are not effected. The application authors can use any
options after the ?--? as DPDK does not define these options correct except in
the example applications.
> Neil
>
>>> On Nov 24, 2014, at 8:52 AM, Venkatesan, Venky >> intel.com> wrote:
>>>
>>>
>>> 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
>>>>>>>>
>>>>>>>> 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 [-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 ;)
>>
>>
