[dpdk-dev] [PATCH 07/10] eal: add core list input format

[Neil Horman]

On Mon, Nov 24, 2014 at 01:37:03PM +0000, Burakov, Anatoly wrote:
> > > > > 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!
> 
> I would still prefer a long option (we already have a coremask parameter, so another one is kind-of non-essential and IMO shouldn't belong in a scarce resource of one-letter parameters), but if everyone else agrees, the "burn" option is much more preferable to me than complicating syntax of an already existing parameter.
> 
If we can't support two syntaxes with a single option (which still seems
reasonable to me, but I digress), then I would support the additional long
option.  Short options are not only scarse on their own, but they also have to
potentially comingle with options parsed by an application building on the DPDK.
At least with a long option the chances of a conflict are lessened.
Neil

> Thanks,
> Anatoly
>