> On Nov 24, 2014, at 11:04 AM, Neil Horman <nhorman at tuxdriver.com> 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 <venky.venkatesan at >>> 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 <didier.pallard at 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 ",")? >>>>> >>>> Burn! >>> Burn ^ 2 ;) >> >>
