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 DF4F37FC9 for ; Mon, 24 Nov 2014 14:50:53 +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 1XsuCg-0001x2-V7; Mon, 24 Nov 2014 09:01:37 -0500 Date: Mon, 24 Nov 2014 09:01:21 -0500 From: Neil Horman To: "Burakov, Anatoly" Message-ID: <20141124140121.GB6038@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 13:50:54 -0000 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 >