[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 at 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