tools/testing/selftests/tc-testing/README
Source file repositories/reference/linux-study-clean/tools/testing/selftests/tc-testing/README
File Facts
- System
- Linux kernel
- Corpus path
tools/testing/selftests/tc-testing/README- Extension
[no extension]- Size
- 7538 bytes
- Lines
- 211
- Domain
- Support Tooling And Documentation
- Bucket
- tools
- Inferred role
- Support Tooling And Documentation: tools
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
tdc - Linux Traffic Control (tc) unit testing suite
Author: Lucas Bates - lucasb@mojatatu.com
tdc is a Python script to load tc unit tests from a separate JSON file and
execute them inside a network namespace dedicated to the task.
REQUIREMENTS
------------
* Minimum Python version of 3.8.
* The kernel must have network namespace support if using nsPlugin
* The kernel must have veth support available, as a veth pair is created
prior to running the tests when using nsPlugin.
* The kernel must have the appropriate infrastructure enabled to run all tdc
unit tests. See the config file in this directory for minimum required
features. As new tests will be added, config options list will be updated.
* All tc-related features being tested must be built in or available as
modules. To check what is required in current setup run:
./tdc.py -c
Note:
In the current release, tdc run will abort due to a failure in setup or
teardown commands - which includes not being able to run a test simply
because the kernel did not support a specific feature. (This will be
handled in a future version - the current workaround is to run the tests
on specific test categories that your kernel supports)
BEFORE YOU RUN
--------------
The path to the tc executable that will be most commonly tested can be defined
in the tdc_config.py file. Find the 'TC' entry in the NAMES dictionary and
define the path.
If you need to test a different tc executable on the fly, you can do so by
using the -p option when running tdc:
./tdc.py -p /path/to/tc
RUNNING TDC
-----------
To use tdc, root privileges are required. This is because the
commands being tested must be run as root. The code that enforces
execution by root uid has been moved into a plugin (see PLUGIN
ARCHITECTURE, below).
Tests that use a network device should have nsPlugin.py listed as a
requirement for that test. nsPlugin executes all commands within a
network namespace and creates a veth pair which may be used in those test
cases. To disable execution within the namespace, pass the -N option
to tdc when starting a test run; the veth pair will still be created
by the plugin.
Running tdc without any arguments will run all tests. Refer to the section
on command line arguments for more information, or run:
./tdc.py -h
tdc will list the test names as they are being run, and print a summary in
TAP (Test Anything Protocol) format when they are done. If tests fail,
output captured from the failing test will be printed immediately following
the failed test in the TAP output.
Annotation
- Atlas domain: Support Tooling And Documentation / tools.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.