<snip> > You're right that in most cases it would come from the stop output, > but the output from that stop command has one other thing as well that > I would consider valuable which is statistics of packets handled by > ports specifically for the duration of the packet forwarding you are > stopping. It is also true that sending other testpmd commands while > verbose output is being sent will change what is collected, so I > didn't want to tie the method specifically to the stop command since > if you did a start command then checked port statistics for example, > it would consume all of the verbose output up until the command to > check port statistics. > > For the reason stated above I think it actually might make sense to > make it so that every testpmd method (including ones that currently > return dataclasses) return their original, unmodified collected output > from the testpmd shell as well. Things like port stats can return both > in a tuple potentially. This way if there is asynchronous output like > there is with verbose output other commands don't completely remove > it.
I agree! I think giving each testpmd method its own output would add more consistency. An idea I had floating around that kind of relates to your suggestion above was introducing some instance variables that could enable the testpmd shell object to be smart enough to automatically scan, and keep a record of, any verbose output that comes out across any command run. The TestPMDShell class could track whether verbose mode is on or not, and if True, run additional logic to scan for verbose output and add it to a data structure for access every time a command is run. Then users, from the perspective of writing a test suite, could do something like 'output in testpmd.verbose_output', where verbose_output is an instance data structure of the TestPMDShell. This might be overcomplicated to implement, but it was an idea I had that might make using verbose mode more streamlined. What are your thoughts?
