From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Venkatesan, Venky" Subject: Re: [PATCH 07/10] eal: add core list input format Date: Mon, 24 Nov 2014 06:52:08 -0800 Message-ID: <54734618.1020905@intel.com> References: <1416692622-28886-1-git-send-email-thomas.monjalon@6wind.com> <20141123013517.GA3982@localhost.localdomain> <20141124112819.GA11552@bricha3-MOBL3> <4662010.O9okd8Allt@xps13> <20141124132821.GA11116@bricha3-MOBL3> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit To: dev-VfR2kkLFssw@public.gmane.org Return-path: In-Reply-To: <20141124132821.GA11116@bricha3-MOBL3> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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 ;)