From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Gaëtan Rivet
Sent: Tuesday, June 20, 2017 11:19 AM
To: Thomas Monjalon <redacted>
Cc: Richardson, Bruce <redacted>; De Lara Guarch, Pablo
[off-list ref]; dev@dpdk.org; Wu, Jingjing [off-list ref]
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:

quoted

20/06/2017 11:22, Bruce Richardson:

quoted

On Mon, Jun 19, 2017 at 11:12:53PM +0200, Thomas Monjalon wrote:

quoted

15/06/2017 14:05, De Lara Guarch, Pablo:

quoted

quoted

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 <redacted>
---

--- 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..

quoted

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

quoted

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