From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 06175567E for ; Thu, 3 Dec 2015 17:32:47 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP; 03 Dec 2015 08:32:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,378,1444719600"; d="scan'208";a="6949234" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by fmsmga004.fm.intel.com with ESMTP; 03 Dec 2015 08:32:45 -0800 Received: from irsmsx112.ger.corp.intel.com (10.108.20.5) by IRSMSX154.ger.corp.intel.com (163.33.192.96) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 3 Dec 2015 16:32:44 +0000 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.13]) by irsmsx112.ger.corp.intel.com ([169.254.1.8]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 16:32:44 +0000 From: "Mcnamara, John" To: Olivier MATZ , Nelio Laranjeiro , "dev@dpdk.org" Thread-Topic: [PATCH 1/2] doc: announce ABI change for cmdline buffer size Thread-Index: AQHRGw6e57TwS2JqF02KpbH4eoIXcp6VhFwQgA+mkYCAFGv5QA== Date: Thu, 3 Dec 2015 16:32:42 +0000 Message-ID: References: <1447087700-20921-1-git-send-email-nelio.laranjeiro@6wind.com> <564F4A3B.5080204@6wind.com> In-Reply-To: <564F4A3B.5080204@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size 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: Thu, 03 Dec 2015 16:32:48 -0000 > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Friday, November 20, 2015 4:29 PM > To: Mcnamara, John; Nelio Laranjeiro; dev@dpdk.org > Cc: thomas.monjalon@6wind.com; Lu, Wenzhuo > Subject: Re: [PATCH 1/2] doc: announce ABI change for cmdline buffer size >=20 > Hi N=E9lio, >=20 > On 11/10/2015 06:29 PM, Mcnamara, John wrote: > > > > > >> -----Original Message----- > >> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com] > >> Sent: Monday, November 9, 2015 4:48 PM > >> To: dev@dpdk.org > >> Cc: olivier.matz@6wind.com; thomas.monjalon@6wind.com; Mcnamara, > >> John; Lu, Wenzhuo > >> Subject: [PATCH 1/2] doc: announce ABI change for cmdline buffer size > >> > >> Current buffer size are not enough for a few testpmd commands. > >> > >> Signed-off-by: Nelio Laranjeiro > > > > Acked-by: John McNamara > > >=20 > While I'm not fundamentally opposed to change the buffer size, I'm > wondering if the impacted commands shouldn't be reworked to have smaller > lines. 256 is already a quite big value for a line: >=20 > 0123456789012345678901234567890123456789012345678901234567890123456789012= 3 > 4567890123456789012345678901234567890123456789012345678901234567890123456= 7 > 8901234567890123456789012345678901234567890123456789012345678901234567890= 1 > 2345678901234567890123456789012345 >=20 > For instance, we could change some commands to use contexts. > Dummy example with reta config: >=20 > testpmd> port config 0 rss reta > testpmd-reta-config-0> add hash1 queue1 > testpmd-reta-config-0> add hash2 queue2 > testpmd-reta-config-0> del hash1 queue1 > testpmd-reta-config-0> show > testpmd-reta-config-0> commit > testpmd> >=20 > What do you think? Hi, I think it is a good idea but my concern is that it won't get done unless s= omeone commits to doing it. And if they do it will be a non-trivial change since the commandline/runtim= e parsing in testpmd is a little crufty and it isn't set up to do this kind= of sub-command parsing. Also, we will still have to maintain backward compatibility (for users and = testers) with the existing single line versions of the commands. So, I'd like to make sure that this change isn't blocked on the assumption = that it will be fixed with a more elegant solution if that solution is unli= kely to happen. However, I do think that we should avoid bolting on every increasing option= s to existing testpmd commands and should instead create new commands where= it makes sense. John. --=20