From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id E3586809D for ; Mon, 24 Nov 2014 17:54:10 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Xsx4A-0005t4-8m; Mon, 24 Nov 2014 12:04:52 -0500 Date: Mon, 24 Nov 2014 12:04:45 -0500 From: Neil Horman To: Roger Keith Wiles Message-ID: <20141124170445.GA7532@hmsreliant.think-freely.org> 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> <54734618.1020905@intel.com> <7E169FC8-CED0-4DD1-B2DA-CAAAFFBD7231@icloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E169FC8-CED0-4DD1-B2DA-CAAAFFBD7231@icloud.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 07/10] eal: add core list input format X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:54:11 -0000 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? Neil > > On Nov 24, 2014, at 8:52 AM, Venkatesan, Venky 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 > >>>>>> > >>>>>> 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 ;) > >