Re: [dpdk-dev] [PATCH 2/3] app/testpmd: support creation of no IOVA contig mempools

[Shahaf Shuler <shahafs@mellanox.com>]

Tuesday, April 2, 2019 6:16 PM, Burakov, Anatoly:
> Subject: Re: [dpdk-dev] [PATCH 2/3] app/testpmd: support creation of no
> IOVA contig mempools
> 
> On 02-Apr-19 8:02 AM, Shahaf Shuler wrote:
> > Monday, April 1, 2019 4:50 PM, Burakov, Anatoly:
> >> Subject: Re: [dpdk-dev] [PATCH 2/3] app/testpmd: support creation of
> >> no IOVA contig mempools
> >>
> >> On 01-Apr-19 11:34 AM, Shahaf Shuler wrote:
> >>> providing a command line parameter to set the mempool flags
> accordingly.
> >>> This mode is relevant only when creating an empty mempool and then
> >>> populating with memory.
> >>>
> >>> Signed-off-by: Shahaf Shuler <shahafs@mellanox.com>
> >>> ---
> >>>    app/test-pmd/parameters.c             | 5 +++++
> >>>    app/test-pmd/testpmd.c                | 3 ++-
> >>>    app/test-pmd/testpmd.h                | 2 ++
> >>>    doc/guides/testpmd_app_ug/run_app.rst | 5 +++++
> >>>    4 files changed, 14 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
> >>> index 7b6b60905d..ce0056b0bd 100644
> >>> --- a/app/test-pmd/parameters.c
> >>> +++ b/app/test-pmd/parameters.c
> >>> @@ -202,6 +202,8 @@ usage(char* progname)
> >>>    	printf("  --noisy-lkup-num-writes=N: do N random writes per
> >> packet\n");
> >>>    	printf("  --noisy-lkup-num-reads=N: do N random reads per
> >> packet\n");
> >>>    	printf("  --noisy-lkup-num-writes=N: do N random reads and
> >>> writes per packet\n");
> >>> +	printf("  --no-iova-contig: mempool memory can be IOVA non
> >> contiguous. "
> >>> +	       "valid only with --mp-alloc=anon\n");
> >>
> >> Maybe rather than spelling this out in the help message, it would be
> >> better to enforce it at option parse time,
> >
> > No problem, I can add.
> >
> >> and document it in the user guide?
> >
> > I think I did documents it. what is missing?
> 
> Nothing, as it seems :) The user guide is fine. I just don't think we should
> explicitly reference other parameters in the help message, as it makes it
> harder to track down any changes/usages that may be needed.

I think when people run testpmd and want to reason on the use of some parameter they use the help message and not the user guide (it is more straight forward).
Also - usually when changes are done one do grep for the field name it change, so it will catch also the parameter in the help message. Moreover, we have maintainers for this app to make sure nothing is missed. 

So I suggest to keep it. I don't think it will that of a burden and will simplify the user experience. 


> 
> >
> >
> >
> >>
> >> --
> >> Thanks,
> >> Anatoly
> 
> 
> --
> Thanks,
> Anatoly