On Fri, Aug 2, 2024 at 10:54 AM Nicholas Pratte <npra...@iol.unh.edu> wrote: > > <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?
I like the sound of this idea a lot actually since it would remove the chance of the output just completely being thrown away. In my own test suite I managed to dance around this by strategically placing my testpmd commands, but this could save people some headache in the future. I feel like this wouldn't be something overly complicated to implement either, all we would have to do is extend the send_command method in the TestpmdShell class and check a boolean for if verbose is on, extract this output. If/how to clear this list would be something to think about, but I would say that, in general, the idea of making sure we don't lose information is something that I'm all for.
