| Age | Commit message (Collapse) | Author |
|
Make the "ports" attribute of EalParams as it actually is to
"allowed_ports", and add "blocked_ports".
Signed-off-by: Luca Vizzarro <[email protected]>
Reviewed-by: Paul Szczepanek <[email protected]>
Reviewed-by: Nicholas Pratte <[email protected]>
|
|
Enable the user to use either a DPDK source tree directory or a
tarball, with and without a pre-built build directory. These can be
stored on either SUT node or the DTS host. The DPDK build setup or the
pre-built binaries can be specified through the configuration file,
the command line arguments or environment variables.
Signed-off-by: Tomáš Ďurovec <[email protected]>
Signed-off-by: Luca Vizzarro <[email protected]>
|
|
The messages being logged by interactive shells currently are using the
same logger as the node they were created from. Because of this, when
sending interactive commands, the logs make no distinction between when
you are sending a command directly to the host and when you are using an
interactive shell on the host. This change adds names to interactive
shells so that they are able to use their own loggers with distinct
names.
Signed-off-by: Jeremy Spewock <[email protected]>
Reviewed-by: Juraj Linkeš <[email protected]>
Tested-by: Nicholas Pratte <[email protected]>
Reviewed-by: Nicholas Pratte <[email protected]>
Reviewed-by: Luca Vizzarro <[email protected]>
|
|
Interactive shells are managed in a way currently where they are closed
and cleaned up at the time of garbage collection. Due to there being no
guarantee of when this garbage collection happens in Python, there is no
way to consistently know when an application will be closed without
manually closing the application yourself when you are done with it.
This doesn't cause a problem in cases where you can start another
instance of the same application multiple times on a server, but this
isn't the case for primary applications in DPDK. The introduction of
primary applications, such as testpmd, adds a need for knowing previous
instances of the application have been stopped and cleaned up before
starting a new one, which the garbage collector does not provide.
To solve this problem, a new class is added which acts as a base class
for interactive shells that enforces that instances of the
application be managed using a context manager. Using a context manager
guarantees that once you leave the scope of the block where the
application is being used for any reason, the application will be closed
immediately. This avoids the possibility of the shell not being closed
due to an exception being raised or user error. The interactive shell
class then becomes shells that can be started/stopped manually or at the
time of garbage collection rather than through a context manager.
Signed-off-by: Jeremy Spewock <[email protected]>
Reviewed-by: Juraj Linkeš <[email protected]>
Reviewed-by: Patrick Robb <[email protected]>
Reviewed-by: Luca Vizzarro <[email protected]>
|
|
The way nodes and interactive shells interact makes it difficult to
develop for static type checking and hinting. The current system relies
on a top-down approach, attempting to give a generic interface to the
test developer, hiding the interaction of concrete shell classes as much
as possible. When working with strong typing this approach is not ideal,
as Python's implementation of generics is still rudimentary.
This rework reverses the tests interaction to a bottom-up approach,
allowing the test developer to call concrete shell classes directly,
and let them ingest nodes independently. While also re-enforcing type
checking and making the code easier to read.
Signed-off-by: Luca Vizzarro <[email protected]>
Reviewed-by: Paul Szczepanek <[email protected]>
Reviewed-by: Juraj Linkeš <[email protected]>
|