On 29/05/2024 21:40, Jeremy Spewock wrote:
This is a good thought. I was sort of falling back on the current
assumption that we can only support 2 ports per server in test suites,
but there is nothing that ensures these ports are the first and second
in trestpmd. I think it is probably safer to just modify the MTU of
all ports that testpmd knows of since we just blindly pick the ingress
and egress ports we want to use. I didn't want to at first since the
ideal would be that we have minimal side effects in testing suites so
we wouldn't want to just change the MTU of all ports, but if there
comes a time when this matters in the future (the only one I could
really think of is implementing parallel testing) then we can just
limit what ports are in the scope of testpmd.
Well, I had originally proposed to add test-specific port filters, so
that a test can say what it wants (and the shells/testpmd could
integrate some test awareness). I think it was said that we want to
introduce test configuration that could deal with this.
With my shell interaction patch this could work nicely too, so instead
of doing:
TestPmdShell(self.sut_node)
We could implement a Protocol in the TestSuite to ensure that
self.sut_node is always present for type checking, and pass self:
TestPmdShell(self)
Similary the core, port filters etc could also be part of the class per
type checking. And the underlying shell could just deal with the
boilerplate code.
This would also spare us from having to manually write lengthy filters
in the test suite code.
Per-test-case configurations could also be initialised easily at the
class-level through a @test decorator as proposed in Juraj's RFC. This
could potentially be done at class initialisation while leaving the
current API untouched, although it won't work well with other decorators
such as @requires.
Just food for thought.
