Re: [dpdk-dev] [PATCH 1/2] doc: announce ABI change for cmdline buffer size

["Mcnamara, John" <john.mcnamara@intel.com>]

> -----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
> 
> Hi Nélio,
> 
> 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 <nelio.laranjeiro@6wind.com>
> >
> > Acked-by: John McNamara <john.mcnamara@intel.com>
> >
> 
> 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:
> 
> 01234567890123456789012345678901234567890123456789012345678901234567890123
> 45678901234567890123456789012345678901234567890123456789012345678901234567
> 89012345678901234567890123456789012345678901234567890123456789012345678901
> 2345678901234567890123456789012345
> 
> For instance, we could change some commands to use contexts.
> Dummy example with reta config:
> 
> 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>
> 
> What do you think?

Hi,

I think it is a good idea but my concern is that it won't get done unless someone commits to doing it.

And if they do it will be a non-trivial change since the commandline/runtime 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 unlikely to happen.

However, I do think that we should avoid bolting on every increasing options to existing testpmd commands and should instead create new commands where it makes sense.

John.
--