> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gaëtan Rivet > Sent: Tuesday, June 20, 2017 11:19 AM > To: Thomas Monjalon <tho...@monjalon.net> > Cc: Richardson, Bruce <bruce.richard...@intel.com>; De Lara Guarch, Pablo > <pablo.de.lara.gua...@intel.com>; dev@dpdk.org; Wu, Jingjing > <jingjing...@intel.com> > Subject: Re: [dpdk-dev] [PATCH v3] app/testpmd: add parameter to start > forwarding TX first > > On Tue, Jun 20, 2017 at 11:58:54AM +0200, Thomas Monjalon wrote: > > 20/06/2017 11:22, Bruce Richardson: > > > On Mon, Jun 19, 2017 at 11:12:53PM +0200, Thomas Monjalon wrote: > > > > 15/06/2017 14:05, De Lara Guarch, Pablo: > > > > > > Add parameter to start forwarding sending first > > > > > > a burst of packets, which is useful when testing > > > > > > a loopback connection. > > > > > > > > > > > > This was already implemented as an internal command, > > > > > > but adding it as a parameter is interesting, as it > > > > > > allows the user to test a loopback connection without > > > > > > entering in the internal command line. > > > > > > > > > > > > Signed-off-by: Pablo de Lara <pablo.de.lara.gua...@intel.com> > > > > > > --- > > > > > > --- a/doc/guides/testpmd_app_ug/run_app.rst > > > > > > +++ b/doc/guides/testpmd_app_ug/run_app.rst > > > > > > @@ -188,6 +188,14 @@ The commandline options are: > > > > > > > > > > > > Start forwarding on initialization. > > > > > > > > > > > > +* ``--tx-first`` > > > > > > + > > > > > > + Start forwarding, after sending a burst of packets first. > > > > > > + > > > > > > +.. Note:: > > > > > > + > > > > > > + This flag should be only used in non-interactive mode. > > > > > > > > I don't really understand the benefit of this option. > > > > Why is it better than > > > > echo start tx_first | testpmd -i > > > > ? > > > > > > The one big difference I see is normal vs abnormal termination. With the > > > echo command you suggest, the only way to terminate testpmd is to kill > > > it via signal. With the extra cmdline option, it will cleanly exit via > > > enter as with non-interactive mode right now. Not a huge difference, but > > > I think having the extra argument to enable tx-first is useful. > > Side note, one can: > > (trap 'echo quit' SIGUSR1; echo 'start'; while true; do sleep 1; done) > |testpmd -i & > > and issue a SIGUSR1 to the subshell to cleanly quit testpmd. > Or: > > (trap 'echo show port stats all' SIGUSR1; \ > trap 'echo quit' SIGUSR2; \ > echo 'start'; \ > while true; do :; done) |\ > testpmd -i & > > It's a little contrived, but it does the job and is easy enough to put > in scripts. > > For automated testing, what I did was open a pipe to testpmd to issue > commands from wherever, allowing to keep testpmd running in the > background and dispatch commands when needed from other terminals. No > need to issue signals at all then.
In an expert-user automated testing environment this is a solution yes.. > > I do not see a big difference between "enter" and "ctrl+c". > > > > I think it is more flexible to pipe commands instead of options. > > We could combine the proposed options --tx-first and -T into this command: > > ( echo 'start tx_first' ; while true ; do echo 'show port stats all' ; > > sleep 1 ; done ) | > testpmd -i > > > > It is even possible to add more actions in the loop, so it is less > > limited than the -T options. > > > > It is a matter of deciding whether we prefer to implement more restricted > > options or leverage the shell to freely program non-interactive testpmd. Lets keep in mind the beginner users, who probably don't have a traffic generator machine, perhaps just 2 ports and a loopback cable. IMO running ./testpmd -- --tx-first is the easiest way to learn to run traffic using testpmd, instead of various shell tricks to work-around a missing CLI flag? A +1 from me to add --tx-first to the CLI, -Harry
