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!
