First take at p4tc automated tests #5011
Conversation
|
The installation might be missing I recommend adding a TC-specific section here: https://github.com/p4lang/p4c/blob/main/tools/ci-build.sh#L170 |
Thank you, will do |
vbnogueira
force-pushed
the
automated_p4tc_tests
branch
14 times, most recently
from
12ebfd2 to
e5ba246
Compare
vbnogueira
force-pushed
the
automated_p4tc_tests
branch
3 times, most recently
from
80d0655 to
c915f8e
Compare
vbnogueira
force-pushed
the
automated_p4tc_tests
branch
2 times, most recently
from
148cd65 to
8b06b32
Compare
| @@ -26,7 +26,7 @@ sudo dnf install -y -q \ | |||
| boost-test \ | |||
| boost-thread \ | |||
| ccache \ | |||
| clang \ | |||
| clang-15 \ | |||
There was a problem hiding this comment.
Any reason why clang-15 is required?
There was a problem hiding this comment.
It's because ubuntu and fedora's clang versions are too old and generated eBPF code that was rejected by the eBPF verifier. clang-15 was the oldest version that worked with the kernel version we are using for the tests
There was a problem hiding this comment.
Does the TC back end check the clang version? It should either throw an error or disable itself if clang-15 is not available.
There was a problem hiding this comment.
I pushed a change for this yesterday, which checks whether we have at least clang-15 (anything above that should also work for the current p4tc kernel). However the tests are failing because they are not being able to clone p4c. Can you try to run them again? I don't think I have permission to do so.
vbnogueira
force-pushed
the
automated_p4tc_tests
branch
from
8b06b32 to
14f48b6
Compare
First take at implementing the automated testing code for tc backend. In a nutshell, what it's doing is expanding on the already existing run-tc-test.py script. The expansion consists of: - Compiling the generated C files to eBPF bytecode - Extracting a P4TC kernel image from github - Compiling P4TC's version of iproute2 - Spawning a VM using virtme to boot the P4TC kernel - Executing the template script generated by the compiler - Loading the generated eBPF parser and control blocks binaries using a TC P4 filter - Parsing an STF in the samples directory detailing what packets to send/expect and what runtime rules to load - Loading any specified runtime rules - Sending the packets using scapy - Verifying that the sent packets (and eventual received packets from the p4tc pipeline) and correct according to the STF file The commands are sent to the VM using ssh through a bridge that connects the host to the VM After the test is finished both the bridge and the VM are destroyed We also added an example (arp_responder) to exercise the testing framework Signed-off-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Victor Nogueira <victor@mojatatu.com>
vbnogueira
force-pushed
the
automated_p4tc_tests
branch
from
14f48b6 to
ac4b956
Compare
|
The code looks okay from my side, I just have final reservations on the CI process. The installation of the VM etc adds significant overhead to our CI. Maybe we should make this a separate workflow that is optional and only runs on code that touches p4tc parts or PRs tagged with p4tc. Let me think about how to introduce this. |
First take at implementing the automated testing code for tc backend. In a nutshell, what it's doing is expanding on the already existing run-tc-test.py script. The expansion consists of:
Compiling the generated C files to eBPF bytecode
Extracting a P4TC kernel image from github
Compiling P4TC's version of iproute2
Spawning a VM using virtme to boot the P4TC kernel
Executing the template script generated by the compiler
Loading the generated eBPF parser and control blocks binaries using a TC P4 filter
Loading the runtime rules specified in the samples directory (*.rules)
Parsing an STF in the samples directory detailing what packets to send/expect
Sending the packets using scapy
Verifying that the sent packets (and eventual received packets from the p4tc pipeline) and correct according to the STF file
Opening it as a draft PR because we still need to see how this works with github actions
Locally it's doing fine, however we never know
I created a separate directory for the tests that involve STFs testdata/p4tc_samples_stf/ to make it cleaner
However that might've been overkill, I can undo that if reviewers think it's best