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

Mcnamara, John john.mcnamara at intel.com
Thu Dec 3 17:32:42 CET 2015



> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Friday, November 20, 2015 4:29 PM
> To: Mcnamara, John; Nelio Laranjeiro; dev at dpdk.org
> Cc: thomas.monjalon at 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 at 6wind.com]
> >> Sent: Monday, November 9, 2015 4:48 PM
> >> To: dev at dpdk.org
> >> Cc: olivier.matz at 6wind.com; thomas.monjalon at 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 at 6wind.com>
> >
> > Acked-by: John McNamara <john.mcnamara at 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.
-- 




More information about the dev mailing list