[PATCH] app/testpmd: show output of commands read from file

[PATCH] app/testpmd: show output of commands read from file

[Bruce Richardson]

Testpmd supports the "--cmdline-file" parameter to read a set of initial
commands from a file. However, the only indication that this has been
done successfully on startup is a single-line message, no output from
the commands is seen.

To improve usability here, we can use cmdline_new rather than
cmdline_file_new and have the output from the various commands sent to
stdout, allowing the user to see better what is happening.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 app/test-pmd/cmdline.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b7759e38a8..2a449b6b2f 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6,6 +6,7 @@
 #include <ctype.h>
 #include <stdarg.h>
 #include <errno.h>
+#include <fcntl.h>
 #include <stdio.h>
 #include <stdint.h>
 #include <stdlib.h>
@@ -13431,7 +13432,18 @@ cmdline_read_from_file(const char *filename)
 {
 	struct cmdline *cl;
 
-	cl = cmdline_file_new(main_ctx, "testpmd> ", filename);
+	/* cmdline_file_new does not produce any output which is not ideal here.
+	 * Much better to show output of the commands, so we open filename directly
+	 * and then pass that to cmdline_new with stdout as the output path.
+	 */
+	int fd = open(filename, O_RDONLY);
+	if (fd < 0) {
+		fprintf(stderr, "Failed to open file %s: %s\n",
+			filename, strerror(errno));
+		return;
+	}
+
+	cl = cmdline_new(main_ctx, "testpmd> ", fd, 1);
 	if (cl == NULL) {
 		fprintf(stderr,
 			"Failed to create file based cmdline context: %s\n",
-- 
2.43.0

[PATCH v2] app/testpmd: show output of commands read from file

[Bruce Richardson]

Testpmd supports the "--cmdline-file" parameter to read a set of initial
commands from a file. However, the only indication that this has been
done successfully on startup is a single-line message, no output from
the commands is seen.

To improve usability here, we can use cmdline_new rather than
cmdline_file_new and have the output from the various commands sent to
stdout, allowing the user to see better what is happening.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>

---
v2: use STDOUT_FILENO in place of hard-coded "1"
---
 app/test-pmd/cmdline.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b7759e38a8..52e64430d9 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -6,6 +6,7 @@
 #include <ctype.h>
 #include <stdarg.h>
 #include <errno.h>
+#include <fcntl.h>
 #include <stdio.h>
 #include <stdint.h>
 #include <stdlib.h>
@@ -13431,7 +13432,18 @@ cmdline_read_from_file(const char *filename)
 {
 	struct cmdline *cl;
 
-	cl = cmdline_file_new(main_ctx, "testpmd> ", filename);
+	/* cmdline_file_new does not produce any output which is not ideal here.
+	 * Much better to show output of the commands, so we open filename directly
+	 * and then pass that to cmdline_new with stdout as the output path.
+	 */
+	int fd = open(filename, O_RDONLY);
+	if (fd < 0) {
+		fprintf(stderr, "Failed to open file %s: %s\n",
+			filename, strerror(errno));
+		return;
+	}
+
+	cl = cmdline_new(main_ctx, "testpmd> ", fd, STDOUT_FILENO);
 	if (cl == NULL) {
 		fprintf(stderr,
 			"Failed to create file based cmdline context: %s\n",
-- 
2.43.0

Re: [PATCH v2] app/testpmd: show output of commands read from file

[Ferruh Yigit]

On 8/22/2024 11:41 AM, Bruce Richardson wrote:
> Testpmd supports the "--cmdline-file" parameter to read a set of initial
> commands from a file. However, the only indication that this has been
> done successfully on startup is a single-line message, no output from
> the commands is seen.
> 

For user I think it makes sense to see the command [1], only concern is
if someone parsing testpmd output may be impacted on this, although I
expect it should be trivial to update the relevant parsing.

[1]
Btw, I can still see the command output, I assume because command does
the printf itself, for example for 'show port summary 0' command:
- before patch:
...
Number of available ports: 2
Port MAC Address       Name         Driver         Status   Link
0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
...

- after patch
...
testpmd> show port summary 0
Number of available ports: 2
Port MAC Address       Name         Driver         Status   Link
0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
...

Only difference above is, after patch the command itself also printed.


> To improve usability here, we can use cmdline_new rather than
> cmdline_file_new and have the output from the various commands sent to
> stdout, allowing the user to see better what is happening.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> 
> ---
> v2: use STDOUT_FILENO in place of hard-coded "1"
> ---
>  app/test-pmd/cmdline.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> index b7759e38a8..52e64430d9 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -6,6 +6,7 @@
>  #include <ctype.h>
>  #include <stdarg.h>
>  #include <errno.h>
> +#include <fcntl.h>
>  #include <stdio.h>
>  #include <stdint.h>
>  #include <stdlib.h>
> @@ -13431,7 +13432,18 @@ cmdline_read_from_file(const char *filename)
>  {
>  	struct cmdline *cl;
>  
> -	cl = cmdline_file_new(main_ctx, "testpmd> ", filename);
> +	/* cmdline_file_new does not produce any output which is not ideal here.
> +	 * Much better to show output of the commands, so we open filename directly
> +	 * and then pass that to cmdline_new with stdout as the output path.
> +	 */
> +	int fd = open(filename, O_RDONLY);
> +	if (fd < 0) {
> +		fprintf(stderr, "Failed to open file %s: %s\n",
> +			filename, strerror(errno));
> +		return;
> +	}
> +
> +	cl = cmdline_new(main_ctx, "testpmd> ", fd, STDOUT_FILENO);
>

Above is almost save as 'cmdline_file_new()' function with only
difference that it uses '-1' for 's_out'.

If this usecase may be required by others, do you think does it have a
value to pass 's_out' to 'cmdline_file_new()' or have a new version of
API that accepts 's_out' as parameter?

btw, I recognized that 'cmdline' library doesn't have doxygen
documentation, which is a gap to address. Next time when someone asks
for entry level task, we can point this one.

Re: [PATCH v2] app/testpmd: show output of commands read from file

[Bruce Richardson]

On Thu, Aug 22, 2024 at 05:53:27PM +0100, Ferruh Yigit wrote:
> On 8/22/2024 11:41 AM, Bruce Richardson wrote:
> > Testpmd supports the "--cmdline-file" parameter to read a set of initial
> > commands from a file. However, the only indication that this has been
> > done successfully on startup is a single-line message, no output from
> > the commands is seen.
> > 
> 
> For user I think it makes sense to see the command [1], only concern is
> if someone parsing testpmd output may be impacted on this, although I
> expect it should be trivial to update the relevant parsing.
> 
> [1]
> Btw, I can still see the command output, I assume because command does
> the printf itself, for example for 'show port summary 0' command:
> - before patch:
> ...
> Number of available ports: 2
> Port MAC Address       Name         Driver         Status   Link
> 0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
> ...
> 
> - after patch
> ...
> testpmd> show port summary 0
> Number of available ports: 2
> Port MAC Address       Name         Driver         Status   Link
> 0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
> ...
> 
> Only difference above is, after patch the command itself also printed.
> 
> 

That's because the function uses printf itself, which is actually wrong.
Any output from a cmdline function should use the "cmdline_printf" call
which outputs to the proper cmdline filehandle.

> > To improve usability here, we can use cmdline_new rather than
> > cmdline_file_new and have the output from the various commands sent to
> > stdout, allowing the user to see better what is happening.
> > 
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > 
> > ---
> > v2: use STDOUT_FILENO in place of hard-coded "1"
> > ---
> >  app/test-pmd/cmdline.c | 14 +++++++++++++-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > index b7759e38a8..52e64430d9 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -6,6 +6,7 @@
> >  #include <ctype.h>
> >  #include <stdarg.h>
> >  #include <errno.h>
> > +#include <fcntl.h>
> >  #include <stdio.h>
> >  #include <stdint.h>
> >  #include <stdlib.h>
> > @@ -13431,7 +13432,18 @@ cmdline_read_from_file(const char *filename)
> >  {
> >  	struct cmdline *cl;
> >  
> > -	cl = cmdline_file_new(main_ctx, "testpmd> ", filename);
> > +	/* cmdline_file_new does not produce any output which is not ideal here.
> > +	 * Much better to show output of the commands, so we open filename directly
> > +	 * and then pass that to cmdline_new with stdout as the output path.
> > +	 */
> > +	int fd = open(filename, O_RDONLY);
> > +	if (fd < 0) {
> > +		fprintf(stderr, "Failed to open file %s: %s\n",
> > +			filename, strerror(errno));
> > +		return;
> > +	}
> > +
> > +	cl = cmdline_new(main_ctx, "testpmd> ", fd, STDOUT_FILENO);
> >
> 
> Above is almost save as 'cmdline_file_new()' function with only
> difference that it uses '-1' for 's_out'.
> 
> If this usecase may be required by others, do you think does it have a
> value to pass 's_out' to 'cmdline_file_new()' or have a new version of
> API that accepts 's_out' as parameter?
> 

Yes, I thought about this, and actually started implementing a new API for
cmdline library to that. However, I decided that, given the complexity
here, that it's not really necessary - especially as there is no clear way
to do things. The options are:

* extend cmdline_file_new to have a flag to echo to stdout (which would be
  the very common case here).
* extend cmdline_file_new to take a file handle - this is more flexible,
  but slightly less usable.
* add a new cmdline_file_<something>_new function to echo to stdout.
* add a new cmdline_file_<something>_new function to write to a filehandle.

I don't like breaking the cmdline API (and ABI), so I didn't want to do
either #1 or #2, which would be the cleanest solutions. For #3 and #4,
naming is hard, and deciding between them is even harder. Given the choice,
I prefer #3, as I can't see #4 being very common and we always have
cmdline_new as a fallback anyway.

Overall, though, I threw away that work, because it didn't seem worth it,
for the sake of having the user to do an extra "open" call.

> btw, I recognized that 'cmdline' library doesn't have doxygen
> documentation, which is a gap to address. Next time when someone asks
> for entry level task, we can point this one.
> 

Yep, good idea.

/Bruce

Re: [PATCH v2] app/testpmd: show output of commands read from file

[Bruce Richardson]

On Thu, Aug 22, 2024 at 06:14:55PM +0100, Bruce Richardson wrote:
> On Thu, Aug 22, 2024 at 05:53:27PM +0100, Ferruh Yigit wrote:
> > On 8/22/2024 11:41 AM, Bruce Richardson wrote:
> > > Testpmd supports the "--cmdline-file" parameter to read a set of initial
> > > commands from a file. However, the only indication that this has been
> > > done successfully on startup is a single-line message, no output from
> > > the commands is seen.
> > > 
> > 
> > For user I think it makes sense to see the command [1], only concern is
> > if someone parsing testpmd output may be impacted on this, although I
> > expect it should be trivial to update the relevant parsing.
> > 
> > [1]
> > Btw, I can still see the command output, I assume because command does
> > the printf itself, for example for 'show port summary 0' command:
> > - before patch:
> > ...
> > Number of available ports: 2
> > Port MAC Address       Name         Driver         Status   Link
> > 0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
> > ...
> > 
> > - after patch
> > ...
> > testpmd> show port summary 0
> > Number of available ports: 2
> > Port MAC Address       Name         Driver         Status   Link
> > 0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
> > ...
> > 
> > Only difference above is, after patch the command itself also printed.
> > 
> > 
> 
> That's because the function uses printf itself, which is actually wrong.
> Any output from a cmdline function should use the "cmdline_printf" call
> which outputs to the proper cmdline filehandle.
> 
> > > To improve usability here, we can use cmdline_new rather than
> > > cmdline_file_new and have the output from the various commands sent to
> > > stdout, allowing the user to see better what is happening.
> > > 
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > 
> > > ---
> > > v2: use STDOUT_FILENO in place of hard-coded "1"
> > > ---
> > >  app/test-pmd/cmdline.c | 14 +++++++++++++-
> > >  1 file changed, 13 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> > > index b7759e38a8..52e64430d9 100644
> > > --- a/app/test-pmd/cmdline.c
> > > +++ b/app/test-pmd/cmdline.c
> > > @@ -6,6 +6,7 @@
> > >  #include <ctype.h>
> > >  #include <stdarg.h>
> > >  #include <errno.h>
> > > +#include <fcntl.h>
> > >  #include <stdio.h>
> > >  #include <stdint.h>
> > >  #include <stdlib.h>
> > > @@ -13431,7 +13432,18 @@ cmdline_read_from_file(const char *filename)
> > >  {
> > >  	struct cmdline *cl;
> > >  
> > > -	cl = cmdline_file_new(main_ctx, "testpmd> ", filename);
> > > +	/* cmdline_file_new does not produce any output which is not ideal here.
> > > +	 * Much better to show output of the commands, so we open filename directly
> > > +	 * and then pass that to cmdline_new with stdout as the output path.
> > > +	 */
> > > +	int fd = open(filename, O_RDONLY);
> > > +	if (fd < 0) {
> > > +		fprintf(stderr, "Failed to open file %s: %s\n",
> > > +			filename, strerror(errno));
> > > +		return;
> > > +	}
> > > +
> > > +	cl = cmdline_new(main_ctx, "testpmd> ", fd, STDOUT_FILENO);
> > >
> > 
> > Above is almost save as 'cmdline_file_new()' function with only
> > difference that it uses '-1' for 's_out'.
> > 
> > If this usecase may be required by others, do you think does it have a
> > value to pass 's_out' to 'cmdline_file_new()' or have a new version of
> > API that accepts 's_out' as parameter?
> > 
> 
> Yes, I thought about this, and actually started implementing a new API for
> cmdline library to that. However, I decided that, given the complexity
> here, that it's not really necessary - especially as there is no clear way
> to do things. The options are:
> 
> * extend cmdline_file_new to have a flag to echo to stdout (which would be
>   the very common case here).
> * extend cmdline_file_new to take a file handle - this is more flexible,
>   but slightly less usable.
> * add a new cmdline_file_<something>_new function to echo to stdout.
> * add a new cmdline_file_<something>_new function to write to a filehandle.
> 
> I don't like breaking the cmdline API (and ABI), so I didn't want to do
> either #1 or #2, which would be the cleanest solutions. For #3 and #4,
> naming is hard, and deciding between them is even harder. Given the choice,
> I prefer #3, as I can't see #4 being very common and we always have
> cmdline_new as a fallback anyway.
> 
> Overall, though, I threw away that work, because it didn't seem worth it,
> for the sake of having the user to do an extra "open" call.
> 

And also to add:
If there is clear consensus on what the correct option for this case is,
I'm happy enough to go back and extend the cmdline library as agreed.
:-)

Re: [PATCH v2] app/testpmd: show output of commands read from file

[Ferruh Yigit]

On 8/22/2024 6:18 PM, Bruce Richardson wrote:
> On Thu, Aug 22, 2024 at 06:14:55PM +0100, Bruce Richardson wrote:
>> On Thu, Aug 22, 2024 at 05:53:27PM +0100, Ferruh Yigit wrote:
>>> On 8/22/2024 11:41 AM, Bruce Richardson wrote:
>>>> Testpmd supports the "--cmdline-file" parameter to read a set of initial
>>>> commands from a file. However, the only indication that this has been
>>>> done successfully on startup is a single-line message, no output from
>>>> the commands is seen.
>>>>
>>>
>>> For user I think it makes sense to see the command [1], only concern is
>>> if someone parsing testpmd output may be impacted on this, although I
>>> expect it should be trivial to update the relevant parsing.
>>>
>>> [1]
>>> Btw, I can still see the command output, I assume because command does
>>> the printf itself, for example for 'show port summary 0' command:
>>> - before patch:
>>> ...
>>> Number of available ports: 2
>>> Port MAC Address       Name         Driver         Status   Link
>>> 0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
>>> ...
>>>
>>> - after patch
>>> ...
>>> testpmd> show port summary 0
>>> Number of available ports: 2
>>> Port MAC Address       Name         Driver         Status   Link
>>> 0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
>>> ...
>>>
>>> Only difference above is, after patch the command itself also printed.
>>>
>>>
>>
>> That's because the function uses printf itself, which is actually wrong.
>> Any output from a cmdline function should use the "cmdline_printf" call
>> which outputs to the proper cmdline filehandle.
>>

Got it.
But in existing testpmd code, only a handful cmdline functions use the
'cmdline_printf' and most of them are in the same help function.
At this stage I think no need to update them. There is already some
confusion on testpmd logging between printf & TESTPMD_LOG().

>>>> To improve usability here, we can use cmdline_new rather than
>>>> cmdline_file_new and have the output from the various commands sent to
>>>> stdout, allowing the user to see better what is happening.
>>>>
>>>> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>>>>
>>>> ---
>>>> v2: use STDOUT_FILENO in place of hard-coded "1"
>>>> ---
>>>>  app/test-pmd/cmdline.c | 14 +++++++++++++-
>>>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
>>>> index b7759e38a8..52e64430d9 100644
>>>> --- a/app/test-pmd/cmdline.c
>>>> +++ b/app/test-pmd/cmdline.c
>>>> @@ -6,6 +6,7 @@
>>>>  #include <ctype.h>
>>>>  #include <stdarg.h>
>>>>  #include <errno.h>
>>>> +#include <fcntl.h>
>>>>  #include <stdio.h>
>>>>  #include <stdint.h>
>>>>  #include <stdlib.h>
>>>> @@ -13431,7 +13432,18 @@ cmdline_read_from_file(const char *filename)
>>>>  {
>>>>  	struct cmdline *cl;
>>>>  
>>>> -	cl = cmdline_file_new(main_ctx, "testpmd> ", filename);
>>>> +	/* cmdline_file_new does not produce any output which is not ideal here.
>>>> +	 * Much better to show output of the commands, so we open filename directly
>>>> +	 * and then pass that to cmdline_new with stdout as the output path.
>>>> +	 */
>>>> +	int fd = open(filename, O_RDONLY);
>>>> +	if (fd < 0) {
>>>> +		fprintf(stderr, "Failed to open file %s: %s\n",
>>>> +			filename, strerror(errno));
>>>> +		return;
>>>> +	}
>>>> +
>>>> +	cl = cmdline_new(main_ctx, "testpmd> ", fd, STDOUT_FILENO);
>>>>
>>>
>>> Above is almost save as 'cmdline_file_new()' function with only
>>> difference that it uses '-1' for 's_out'.
>>>
>>> If this usecase may be required by others, do you think does it have a
>>> value to pass 's_out' to 'cmdline_file_new()' or have a new version of
>>> API that accepts 's_out' as parameter?
>>>
>>
>> Yes, I thought about this, and actually started implementing a new API for
>> cmdline library to that. However, I decided that, given the complexity
>> here, that it's not really necessary - especially as there is no clear way
>> to do things. The options are:
>>
>> * extend cmdline_file_new to have a flag to echo to stdout (which would be
>>   the very common case here).
>> * extend cmdline_file_new to take a file handle - this is more flexible,
>>   but slightly less usable.
>> * add a new cmdline_file_<something>_new function to echo to stdout.
>> * add a new cmdline_file_<something>_new function to write to a filehandle.
>>
>> I don't like breaking the cmdline API (and ABI), so I didn't want to do
>> either #1 or #2, which would be the cleanest solutions. For #3 and #4,
>> naming is hard, and deciding between them is even harder. Given the choice,
>> I prefer #3, as I can't see #4 being very common and we always have
>> cmdline_new as a fallback anyway.
>>
>> Overall, though, I threw away that work, because it didn't seem worth it,
>> for the sake of having the user to do an extra "open" call.
>>
> 

I vote to option #1, but agree that it may not worth breaking API and ABI.

Is 'cmdline_file_new_v2()' too bad a name, perhaps better to go with
testpmd implementation, as you did in this patch.

> And also to add:
> If there is clear consensus on what the correct option for this case is,
> I'm happy enough to go back and extend the cmdline library as agreed.
> :-)

Re: [PATCH v2] app/testpmd: show output of commands read from file

[Bruce Richardson]

On Thu, Aug 22, 2024 at 10:09:09PM +0100, Ferruh Yigit wrote:
> On 8/22/2024 6:18 PM, Bruce Richardson wrote:
> > On Thu, Aug 22, 2024 at 06:14:55PM +0100, Bruce Richardson wrote:
> >> On Thu, Aug 22, 2024 at 05:53:27PM +0100, Ferruh Yigit wrote:
> >>> On 8/22/2024 11:41 AM, Bruce Richardson wrote:
> >>>> Testpmd supports the "--cmdline-file" parameter to read a set of initial
> >>>> commands from a file. However, the only indication that this has been
> >>>> done successfully on startup is a single-line message, no output from
> >>>> the commands is seen.
> >>>>
> >>>
> >>> For user I think it makes sense to see the command [1], only concern is
> >>> if someone parsing testpmd output may be impacted on this, although I
> >>> expect it should be trivial to update the relevant parsing.
> >>>
> >>> [1]
> >>> Btw, I can still see the command output, I assume because command does
> >>> the printf itself, for example for 'show port summary 0' command:
> >>> - before patch:
> >>> ...
> >>> Number of available ports: 2
> >>> Port MAC Address       Name         Driver         Status   Link
> >>> 0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
> >>> ...
> >>>
> >>> - after patch
> >>> ...
> >>> testpmd> show port summary 0
> >>> Number of available ports: 2
> >>> Port MAC Address       Name         Driver         Status   Link
> >>> 0    xx:xx:xx:xx:xx:xx xxxx:xx:xx.x aaaaaaaa       up       xxx Gbps
> >>> ...
> >>>
> >>> Only difference above is, after patch the command itself also printed.
> >>>
> >>>
> >>
> >> That's because the function uses printf itself, which is actually wrong.
> >> Any output from a cmdline function should use the "cmdline_printf" call
> >> which outputs to the proper cmdline filehandle.
> >>
> 
> Got it.
> But in existing testpmd code, only a handful cmdline functions use the
> 'cmdline_printf' and most of them are in the same help function.
> At this stage I think no need to update them. There is already some
> confusion on testpmd logging between printf & TESTPMD_LOG().
> 

Agree. No point in updating the existing functions to use cmdline_printf vs
printf.

One other point related to echoing commands, there are also testpmd
commands that produce no output - the commands for configuring rte_tm,
being examples right now - and having those echoed to screen when read from
a file is the only way to know what is actually happening.

> >>>> To improve usability here, we can use cmdline_new rather than
> >>>> cmdline_file_new and have the output from the various commands sent to
> >>>> stdout, allowing the user to see better what is happening.
> >>>>
> >>>> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> >>>>
> >>>> ---
> >>>> v2: use STDOUT_FILENO in place of hard-coded "1"
> >>>> ---
> >>>>  app/test-pmd/cmdline.c | 14 +++++++++++++-
> >>>>  1 file changed, 13 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
> >>>> index b7759e38a8..52e64430d9 100644
> >>>> --- a/app/test-pmd/cmdline.c
> >>>> +++ b/app/test-pmd/cmdline.c
> >>>> @@ -6,6 +6,7 @@
> >>>>  #include <ctype.h>
> >>>>  #include <stdarg.h>
> >>>>  #include <errno.h>
> >>>> +#include <fcntl.h>
> >>>>  #include <stdio.h>
> >>>>  #include <stdint.h>
> >>>>  #include <stdlib.h>
> >>>> @@ -13431,7 +13432,18 @@ cmdline_read_from_file(const char *filename)
> >>>>  {
> >>>>  	struct cmdline *cl;
> >>>>  
> >>>> -	cl = cmdline_file_new(main_ctx, "testpmd> ", filename);
> >>>> +	/* cmdline_file_new does not produce any output which is not ideal here.
> >>>> +	 * Much better to show output of the commands, so we open filename directly
> >>>> +	 * and then pass that to cmdline_new with stdout as the output path.
> >>>> +	 */
> >>>> +	int fd = open(filename, O_RDONLY);
> >>>> +	if (fd < 0) {
> >>>> +		fprintf(stderr, "Failed to open file %s: %s\n",
> >>>> +			filename, strerror(errno));
> >>>> +		return;
> >>>> +	}
> >>>> +
> >>>> +	cl = cmdline_new(main_ctx, "testpmd> ", fd, STDOUT_FILENO);
> >>>>
> >>>
> >>> Above is almost save as 'cmdline_file_new()' function with only
> >>> difference that it uses '-1' for 's_out'.
> >>>
> >>> If this usecase may be required by others, do you think does it have a
> >>> value to pass 's_out' to 'cmdline_file_new()' or have a new version of
> >>> API that accepts 's_out' as parameter?
> >>>
> >>
> >> Yes, I thought about this, and actually started implementing a new API for
> >> cmdline library to that. However, I decided that, given the complexity
> >> here, that it's not really necessary - especially as there is no clear way
> >> to do things. The options are:
> >>
> >> * extend cmdline_file_new to have a flag to echo to stdout (which would be
> >>   the very common case here).
> >> * extend cmdline_file_new to take a file handle - this is more flexible,
> >>   but slightly less usable.
> >> * add a new cmdline_file_<something>_new function to echo to stdout.
> >> * add a new cmdline_file_<something>_new function to write to a filehandle.
> >>
> >> I don't like breaking the cmdline API (and ABI), so I didn't want to do
> >> either #1 or #2, which would be the cleanest solutions. For #3 and #4,
> >> naming is hard, and deciding between them is even harder. Given the choice,
> >> I prefer #3, as I can't see #4 being very common and we always have
> >> cmdline_new as a fallback anyway.
> >>
> >> Overall, though, I threw away that work, because it didn't seem worth it,
> >> for the sake of having the user to do an extra "open" call.
> >>
> > 
> 
> I vote to option #1, but agree that it may not worth breaking API and ABI.
> 
> Is 'cmdline_file_new_v2()' too bad a name, perhaps better to go with
> testpmd implementation, as you did in this patch.
> 

Let's see what others think. I'm fine to implement this as a cmdline lib
change or a testpmd-local change only, whatever the community prefers.

/Bruce

Re: [PATCH v2] app/testpmd: show output of commands read from file

[Ferruh Yigit]

On 8/22/2024 11:41 AM, Bruce Richardson wrote:
> Testpmd supports the "--cmdline-file" parameter to read a set of initial
> commands from a file. However, the only indication that this has been
> done successfully on startup is a single-line message, no output from
> the commands is seen.
> 
> To improve usability here, we can use cmdline_new rather than
> cmdline_file_new and have the output from the various commands sent to
> stdout, allowing the user to see better what is happening.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> 
> ---
> v2: use STDOUT_FILENO in place of hard-coded "1"
> ---
>

After discussion, I think it is OK to have the update in the testpmd
(instead of a new function in cmdline), hence;

Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

Re: [PATCH v2] app/testpmd: show output of commands read from file

[Ferruh Yigit]

On 10/4/2024 5:56 AM, Ferruh Yigit wrote:
> On 8/22/2024 11:41 AM, Bruce Richardson wrote:
>> Testpmd supports the "--cmdline-file" parameter to read a set of initial
>> commands from a file. However, the only indication that this has been
>> done successfully on startup is a single-line message, no output from
>> the commands is seen.
>>
>> To improve usability here, we can use cmdline_new rather than
>> cmdline_file_new and have the output from the various commands sent to
>> stdout, allowing the user to see better what is happening.
>>
>> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>>
>> ---
>> v2: use STDOUT_FILENO in place of hard-coded "1"
>> ---
>>
> 
> After discussion, I think it is OK to have the update in the testpmd
> (instead of a new function in cmdline), hence;
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
>

Applied to dpdk-next-net/main, thanks.

Re: [PATCH v2] app/testpmd: show output of commands read from file

[David Marchand]

Hello Bruce, Ferruh,

On Tue, Oct 8, 2024 at 3:33 AM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> On 10/4/2024 5:56 AM, Ferruh Yigit wrote:
> > On 8/22/2024 11:41 AM, Bruce Richardson wrote:
> >> Testpmd supports the "--cmdline-file" parameter to read a set of initial
> >> commands from a file. However, the only indication that this has been
> >> done successfully on startup is a single-line message, no output from
> >> the commands is seen.
> >>
> >> To improve usability here, we can use cmdline_new rather than
> >> cmdline_file_new and have the output from the various commands sent to
> >> stdout, allowing the user to see better what is happening.
> >>
> >> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> >>
> >> ---
> >> v2: use STDOUT_FILENO in place of hard-coded "1"
> >> ---
> >>
> >
> > After discussion, I think it is OK to have the update in the testpmd
> > (instead of a new function in cmdline), hence;
> >
> > Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
> Applied to dpdk-next-net/main, thanks.

This patch triggers an error in UNH for Windows builds.
Can you have a look?

https://lab.dpdk.org/results/dashboard/testruns/logs/1386705/

[756/833] Compiling C object app/dpdk-testpmd.exe.p/test-pmd_cmdline.c.obj
FAILED: app/dpdk-testpmd.exe.p/test-pmd_cmdline.c.obj
"clang" "-Iapp\dpdk-testpmd.exe.p" "-Iapp" "-I..\app" "-Iapp\test-pmd"
"-I..\app\test-pmd" "-Ilib\ethdev" "-I..\lib\ethdev" "-I." "-I.."
"-Iconfig" "-I..\config" "-Ilib\eal\include" "-I..\lib\eal\include"
"-Ilib\eal\windows\include" "-I..\lib\eal\windows\include"
"-Ilib\eal\x86\include" "-I..\lib\eal\x86\include" "-Ilib\eal\common"
"-I..\lib\eal\common" "-Ilib\eal" "-I..\lib\eal" "-Ilib\log"
"-I..\lib\log" "-Ilib\kvargs" "-I..\lib\kvargs" "-Ilib\net"
"-I..\lib\net" "-Ilib\mbuf" "-I..\lib\mbuf" "-Ilib\mempool"
"-I..\lib\mempool" "-Ilib\ring" "-I..\lib\ring" "-Ilib\metrics"
"-I..\lib\metrics" "-Ilib\telemetry" "-I..\lib\telemetry"
"-Ilib\meter" "-I..\lib\meter" "-Ilib\cmdline" "-I..\lib\cmdline"
"-Ilib\bitratestats" "-I..\lib\bitratestats" "-Ilib\gro"
"-I..\lib\gro" "-Ilib\gso" "-I..\lib\gso" "-Ilib\latencystats"
"-I..\lib\latencystats" "-Idrivers\net\i40e" "-I..\drivers\net\i40e"
"-Idrivers\net\i40e\base" "-I..\drivers\net\i40e\base"
"-Idrivers\bus\pci" "-I..\drivers\bus\pci"
"-I..\drivers\bus\pci\windows" "-Ilib\pci" "-I..\lib\pci"
"-Idrivers\bus\vdev" "-I..\drivers\bus\vdev" "-Ilib\hash"
"-I..\lib\hash" "-Ilib\rcu" "-I..\lib\rcu" "-Idrivers\net\ixgbe"
"-I..\drivers\net\ixgbe" "-Idrivers\net\ixgbe\base"
"-I..\drivers\net\ixgbe\base" "-Ilib\security" "-I..\lib\security"
"-Ilib\cryptodev" "-I..\lib\cryptodev" "-Idrivers\net\iavf"
"-I..\drivers\net\iavf" "-Idrivers\common\iavf"
"-I..\drivers\common\iavf" "-Idrivers\net\ice" "-I..\drivers\net\ice"
"-Idrivers\net\ice\base" "-I..\drivers\net\ice\base"
"-Idrivers\net\mlx5" "-I..\drivers\net\mlx5"
"-Idrivers\net/mlx5\windows" "-I..\drivers\net\mlx5\windows"
"-Idrivers\common\mlx5" "-I..\drivers\common\mlx5"
"-Idrivers\common/mlx5\windows" "-I..\drivers\common\mlx5\windows"
"-Idrivers\bus\auxiliary" "-I..\drivers\bus\auxiliary" "-IC:\Program
Files\Mellanox\MLNX_WinOF2_DevX_SDK\inc" "-Xclang"
"-fcolor-diagnostics" "-pipe" "-D_FILE_OFFSET_BITS=64" "-Wall"
"-Winvalid-pch" "-Wextra" "-Werror" "-std=c11" "-O3" "-include"
"rte_config.h" "-Wcast-qual" "-Wdeprecated" "-Wformat"
"-Wformat-nonliteral" "-Wformat-security" "-Wmissing-declarations"
"-Wmissing-prototypes" "-Wnested-externs" "-Wold-style-definition"
"-Wpointer-arith" "-Wsign-compare" "-Wstrict-prototypes" "-Wundef"
"-Wwrite-strings" "-Wno-address-of-packed-member"
"-Wno-missing-field-initializers" "-D_GNU_SOURCE"
"-D_WIN32_WINNT=0x0A00" "-D_CRT_SECURE_NO_WARNINGS" "-march=native"
"-mrtm" "-DALLOW_EXPERIMENTAL_API" "-Wno-deprecated-declarations" -MD
-MQ app/dpdk-testpmd.exe.p/test-pmd_cmdline.c.obj -MF
"app\dpdk-testpmd.exe.p\test-pmd_cmdline.c.obj.d" -o
app/dpdk-testpmd.exe.p/test-pmd_cmdline.c.obj "-c"
../app/test-pmd/cmdline.c
../app/test-pmd/cmdline.c:13692:46: error: use of undeclared
identifier 'STDOUT_FILENO'
        cl = cmdline_new(main_ctx, "testpmd> ", fd, STDOUT_FILENO);
                                                    ^
1 error generated.


-- 
David Marchand

Re: [PATCH v2] app/testpmd: show output of commands read from file

[Bruce Richardson]

On Thu, Oct 10, 2024 at 10:56:24AM +0200, David Marchand wrote:
> Hello Bruce, Ferruh,
> 
> On Tue, Oct 8, 2024 at 3:33 AM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >
> > On 10/4/2024 5:56 AM, Ferruh Yigit wrote:
> > > On 8/22/2024 11:41 AM, Bruce Richardson wrote:
> > >> Testpmd supports the "--cmdline-file" parameter to read a set of initial
> > >> commands from a file. However, the only indication that this has been
> > >> done successfully on startup is a single-line message, no output from
> > >> the commands is seen.
> > >>
> > >> To improve usability here, we can use cmdline_new rather than
> > >> cmdline_file_new and have the output from the various commands sent to
> > >> stdout, allowing the user to see better what is happening.
> > >>
> > >> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > >>
> > >> ---
> > >> v2: use STDOUT_FILENO in place of hard-coded "1"
> > >> ---
> > >>
> > >
> > > After discussion, I think it is OK to have the update in the testpmd
> > > (instead of a new function in cmdline), hence;
> > >
> > > Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > Applied to dpdk-next-net/main, thanks.
> 
> This patch triggers an error in UNH for Windows builds.
> Can you have a look?
> 
> https://lab.dpdk.org/results/dashboard/testruns/logs/1386705/
> 
Looks like I should have kept the hard-coded 1 after all! :-(

Anyway, something like this should fix the issue, I think:

diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 1fc1cce5fe..bfa0e77dce 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -68,6 +68,10 @@
 #include "cmdline_tm.h"
 #include "bpf_cmd.h"

+#ifndef STDOUT_FILENO
+#define STDOUT_FILENO _fileno(stdout)
+#endif
+
 static struct cmdline *testpmd_cl;
 static cmdline_parse_ctx_t *main_ctx;
 static TAILQ_HEAD(, testpmd_driver_commands) driver_commands_head =

However, this is a fix only for this specific testpmd instance. I see that
unistd.h is present in "lib/eal/windows/include" in DPDK, so I'm thinking
maybe we add these macros there.

WDYT?

/Bruce

Re: [PATCH] app/testpmd: show output of commands read from file

[Ferruh Yigit]

On 8/22/2024 11:36 AM, Bruce Richardson wrote:
> Testpmd supports the "--cmdline-file" parameter to read a set of initial
> commands from a file. However, the only indication that this has been
> done successfully on startup is a single-line message, no output from
> the commands is seen.
> 
> To improve usability here, we can use cmdline_new rather than
> cmdline_file_new and have the output from the various commands sent to
> stdout, allowing the user to see better what is happening.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>

After discussion, I think it is OK to have the update in the testpmd
(instead of a new function in cmdline), hence;

Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>

Re: [PATCH] app/testpmd: show output of commands read from file

[Ferruh Yigit]

On 10/4/2024 5:55 AM, Ferruh Yigit wrote:
> On 8/22/2024 11:36 AM, Bruce Richardson wrote:
>> Testpmd supports the "--cmdline-file" parameter to read a set of initial
>> commands from a file. However, the only indication that this has been
>> done successfully on startup is a single-line message, no output from
>> the commands is seen.
>>
>> To improve usability here, we can use cmdline_new rather than
>> cmdline_file_new and have the output from the various commands sent to
>> stdout, allowing the user to see better what is happening.
>>
>> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>>
> 
> After discussion, I think it is OK to have the update in the testpmd
> (instead of a new function in cmdline), hence;
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>
>

Ahh, ack was for v2, please scratch this one.