| Age | Commit message (Collapse) | Author |
|---|
|
The test suite served as a demonstration of the Scapy traffic generator
implementation. Now that we have a test suite that uses DPDK code (via
testpmd), there is no reason to keep the test suite, as there's no
expectation it'll be actually used in any setup.
Signed-off-by: Juraj Linkeš <[email protected]>
Signed-off-by: Paul Szczepanek <[email protected]>
Reviewed-by: Luca Vizzarro <[email protected]>
Reviewed-by: Patrick Robb <[email protected]>
|
|
This change brings in pydantic in place of warlock. Pydantic offers
a built-in model validation system in the classes, which allows for
a more resilient and simpler code. As a consequence of this change:
- most validation is now built-in
- further validation is added to verify:
- cross referencing of node names and ports
- test suite and test cases names
- dictionaries representing the config schema are removed
- the config schema is no longer used and therefore dropped
- the TrafficGeneratorType enum has been changed from inheriting
StrEnum to the native str and Enum. This change was necessary to
enable the discriminator for object unions
- the structure of the classes has been slightly changed to perfectly
match the structure of the configuration files
- the test suite argument catches the ValidationError that
TestSuiteConfig can now raise
- the DPDK location has been wrapped under another configuration
mapping `dpdk_location`
- the DPDK locations are now structured and enforced by classes,
further simplifying the validation and handling thanks to
pattern matching
Bugzilla ID: 1508
Signed-off-by: Luca Vizzarro <[email protected]>
Reviewed-by: Paul Szczepanek <[email protected]>
Reviewed-by: Nicholas Pratte <[email protected]>
Reviewed-by: Patrick Robb <[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]>
|
|
We currently assume there are two links between the SUT and TG nodes,
but that's too strict, even for some of the already existing test cases.
Add support for topologies with less than two links.
For topologies with no links, dummy ports are used. The expectation is
that test suites or cases that don't require any links won't be using
methods that use ports. Any test suites or cases requiring links will be
skipped in topologies with no links, but this feature is not implemented
in this commit.
Signed-off-by: Juraj Linkeš <[email protected]>
Reviewed-by: Jeremy Spewock <[email protected]>
Reviewed-by: Dean Marx <[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]>
|
|
Make it so that interactive shells accept an implementation of `Params`
for app arguments. Convert EalParameters to use `Params` instead.
String command line parameters can still be supplied by using the
`Params.from_str()` method.
Signed-off-by: Luca Vizzarro <[email protected]>
Reviewed-by: Paul Szczepanek <[email protected]>
Reviewed-by: Juraj Linkeš <[email protected]>
Reviewed-by: Jeremy Spewock <[email protected]>
Reviewed-by: Nicholas Pratte <[email protected]>
|
|
The major part is the removal of _set_up_test_run() and
_tear_down_test_run() of Node in lieu of using super() in the
superclasses, which simplifies the code while achieving the same thing.
The minor changes are the move of virtual devices and build target
setup/teardown into SutNode from Node since both are DPDK-related which
are only going to run on the SutNode.
Signed-off-by: Juraj Linkeš <[email protected]>
Reviewed-by: Luca Vizzarro <[email protected]>
Reviewed-by: Jeremy Spewock <[email protected]>
|
|
The configuration containing the combination of:
1. what testbed to use,
2. which tests to run,
3. and what build targets to test
is called an execution. This is confusing since we're using the exact
same term to describe other things and execution does not really capture
that well the three items listed above.
A new term is thus needed to describe the configuration. Test run is
much less confusing and better captures what the configuration contains.
Signed-off-by: Juraj Linkeš <[email protected]>
Reviewed-by: Jeremy Spewock <[email protected]>
Reviewed-by: Luca Vizzarro <[email protected]>
|
|
The term 'amount' is used for uncountable nouns. Since total hugepages
is a discrete value (i.e. countable), the declaration of the 'amount'
key value pair should be changes to a different term in both the config
and the rest of the code.
Bugzilla ID: 1370
Signed-off-by: Nicholas Pratte <[email protected]>
Reviewed-by: Jeremy Spewock <[email protected]>
Reviewed-by: Juraj Linkeš <[email protected]>
Reviewed-by: Luca Vizzarro <[email protected]>
|
|
The previous implementation configures and allocates hugepage sizes
based on a system default. This can lead to two problems: overallocation of
hugepages (which may crash the remote host), and configuration of hugepage
sizes that are not recommended during runtime. This new implementation
allows only 2MB hugepage allocation during runtime; any other unique
hugepage size must be configured by the end-user for initializing DTS.
If the amount of 2MB hugepages requested exceeds the amount of 2MB
hugepages already configured on the system, then the system will remount
hugepages to cover the difference. If the amount of hugepages requested is
either less than or equal to the amount already configured on the system,
then nothing is done.
Bugzilla ID: 1370
Signed-off-by: Nicholas Pratte <[email protected]>
Reviewed-by: Jeremy Spewock <[email protected]>
Reviewed-by: Juraj Linkeš <[email protected]>
Reviewed-by: Luca Vizzarro <[email protected]>
|
|
Remove unused parts of the code and add useful features:
1. Add DTS execution stages such as execution and test suite to better
identify where in the DTS lifecycle we are when investigating logs,
2. Logging to separate files in specific stages, which is mainly useful
for having test suite logs in additional separate files.
3. Remove the dependence on the settings module which enhances the
usefulness of the logger module, as it can now be imported in more
modules.
The execution stages and the files to log to are the same for all DTS
loggers. To achieve this, we have one DTS root logger which should be
used for handling stage switching and all other loggers are children of
this DTS root logger. The DTS root logger is the one where we change the
behavior of all loggers (the stage and which files to log to) and the
child loggers just log messages under a different name.
Signed-off-by: Juraj Linkeš <[email protected]>
Reviewed-by: Jeremy Spewock <[email protected]>
|
|
Format according to the Google format and PEP257, with slight
deviations.
Signed-off-by: Juraj Linkeš <[email protected]>
|
|
The standard Python tool for generating API documentation, Sphinx,
imports modules one-by-one when generating the documentation. This
requires code changes:
* properly guarding argument parsing in the if __name__ == '__main__'
block,
* the logger used by DTS runner underwent the same treatment so that it
doesn't create log files outside of a DTS run,
* however, DTS uses the arguments to construct an object holding global
variables. The defaults for the global variables needed to be moved
from argument parsing elsewhere,
* importing the remote_session module from framework resulted in
circular imports because of one module trying to import another
module. This is fixed by reorganizing the code,
* some code reorganization was done because the resulting structure
makes more sense, improving documentation clarity.
The are some other changes which are documentation related:
* added missing type annotation so they appear in the generated docs,
* reordered arguments in some methods,
* removed superfluous arguments and attributes,
* change private functions/methods/attributes to private and vice-versa.
The above all appear in the generated documentation and the with them,
the documentation is improved.
Signed-off-by: Juraj Linkeš <[email protected]>
|
|
Reformat to 100 from the previous 88 to unify with C recommendations.
The C recommendation is the maximum with the ideal being 80.
The Python tools are not suitable for this flexibility.
We require all patches with DTS code to be validated with the
devtools/dts-check-format.sh script, part of which is the black
formatting tool. We've set up black to format all of the codebase and
the reformat is needed so that future submitters are not affected.
Signed-off-by: Juraj Linkeš <[email protected]>
Acked-by: Jeremy Spewock <[email protected]>
|
|
The test cases showcases the scapy traffic generator code.
Signed-off-by: Juraj Linkeš <[email protected]>
Acked-by: Jeremy Spewock <[email protected]>
|
|
There are traffic abstractions for all traffic generators and for
traffic generators that can capture (not just count) packets.
There also related abstractions, such as TGNode where the traffic
generators reside and some related code.
Signed-off-by: Juraj Linkeš <[email protected]>
|
|
Adds a new test suite for running smoke tests that verify general
configuration aspects of the system under test. If any of these tests
fail, the DTS execution terminates as part of a "fail-fast" model.
Signed-off-by: Jeremy Spewock <[email protected]>
Reviewed-by: Juraj Linkeš <[email protected]>
|
|
Setup hugepages on nodes. This is useful not only on SUT nodes, but
also on TG nodes which use TGs that utilize hugepages.
The setup is opt-in, i.e. users need to supply hugepage configuration to
instruct DTS to configure them. It not configured, hugepage
configuration will be skipped. This is helpful if users don't want DTS
to tamper with hugepages on their system.
Signed-off-by: Juraj Linkeš <[email protected]>
Tested-by: Bruce Richardson <[email protected]>
Tested-by: Chenyu Huang <[email protected]>
Tested-by: Patrick Robb <[email protected]>
|
|
Add methods for setting up and shutting down DPDK apps and for
constructing EAL parameters.
Signed-off-by: Juraj Linkeš <[email protected]>
Tested-by: Bruce Richardson <[email protected]>
Tested-by: Chenyu Huang <[email protected]>
Tested-by: Patrick Robb <[email protected]>
|
|
Add the ability to build DPDK and apps on the SUT, using a configured
target.
Signed-off-by: Juraj Linkeš <[email protected]>
Tested-by: Bruce Richardson <[email protected]>
Tested-by: Chenyu Huang <[email protected]>
Tested-by: Patrick Robb <[email protected]>
|
|
The abstraction model in DTS is as follows:
Node, defining and implementing methods common to and the base of SUT
(system under test) Node and TG (traffic generator) Node.
Remote Session, defining and implementing methods common to any remote
session implementation, such as SSH Session.
OSSession, defining and implementing methods common to any operating
system/distribution, such as Linux.
OSSession uses a derived Remote Session and Node in turn uses a derived
OSSession. This split delegates OS-specific and connection-specific code
to specialized classes designed to handle the differences.
The base classes implement the methods or parts of methods that are
common to all implementations and defines abstract methods that must be
implemented by derived classes.
Part of the abstractions is the DTS test execution skeleton:
execution setup, build setup and then test execution.
Signed-off-by: Juraj Linkeš <[email protected]>
Tested-by: Bruce Richardson <[email protected]>
Tested-by: Chenyu Huang <[email protected]>
Tested-by: Patrick Robb <[email protected]>
|
|
The base class implements basic node management methods - connect and
execute commands.
Signed-off-by: Owen Hilyard <[email protected]>
Signed-off-by: Juraj Linkeš <[email protected]>
|
