From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nk11p07mm-asmtp002.mac.com (nk11p07mm-asmtpout002.mac.com [17.158.42.247]) by dpdk.org (Postfix) with ESMTP id 24500809E for ; Mon, 24 Nov 2014 17:59:34 +0100 (CET) Received: from [172.25.40.171] (97-94-195-106.dhcp.ftwo.tx.charter.com [97.94.195.106]) by nk11p07mm-asmtp002.mac.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NFJ00MJSZOMDOB0@nk11p07mm-asmtp002.mac.com> for dev@dpdk.org; Mon, 24 Nov 2014 17:09:59 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-24_02:2014-11-24,2014-11-24,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411240134 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Roger Keith Wiles In-reply-to: <20141124170445.GA7532@hmsreliant.think-freely.org> Date: Mon, 24 Nov 2014 11:09:57 -0600 Content-transfer-encoding: quoted-printable Message-id: <77CBDAFE-F897-480B-828C-20295778DA92@icloud.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> <54734618.1020905@intel.com> <7E169FC8-CED0-4DD1-B2DA-CAAAFFBD7231@icloud.com> <20141124170445.GA7532@hmsreliant.think-freely.org> To: Neil Horman X-Mailer: Apple Mail (2.1993) 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:59:34 -0000 > On Nov 24, 2014, at 11:04 AM, Neil Horman = wrote: >=20 > 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. >>=20 > No, but what about the application authors that need to accomodate all = of the > dpdk command line options as well? The application authors are not effected. The application authors can = use any options after the =E2=80=98--=E2=80=98 as DPDK does not define = these options correct except in the example applications. > Neil >=20 >>> On Nov 24, 2014, at 8:52 AM, Venkatesan, Venky = wrote: >>>=20 >>>=20 >>> 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, >>>>>=20 >>>>> 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 >>>>>>>>=20 >>>>>>>> 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],...] >>>>>>>>=20 >>>>>>>> The letter -l can stand for lcore or list. >>>>>>>>=20 >>>>>>>> -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. >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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 ",")? >>>>>=20 >>>> Burn! >>> Burn ^ 2 ;) >>=20 >>=20