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

Burakov, Anatoly anatoly.burakov at intel.com
Mon Nov 24 14:37:03 CET 2014


> > > > 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.

Thanks,
Anatoly


More information about the dev mailing list