[vpp] SAIVPP unit-test harness (docker-sai-test-vpp) + devdocs - #1950
[vpp] SAIVPP unit-test harness (docker-sai-test-vpp) + devdocs#1950nicholasching wants to merge 45 commits into
Conversation
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
…test Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
…dog, --relax Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
…ature and restarting backend per group Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
…ugging Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
UT-harness portion of the L3-over-LAG forwarding fix: run_test.sh assigns the DUT-side connected IPs to each LAG (be<N>) and SVI (bvi<vlan>) so routed-to-LAG /SVI traffic forwards in the standalone PTF environment. The backend portion (SwitchVppFdb.cpp) is in the VPP SAI backend PR. Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
73630af to
02b11fa
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…SER) - gen_compatibility_matrix.py: prefer defusedxml for parsing PTF JUnit XML (XXE-hardened), with a stdlib fallback; input is our own local test output. - Dockerfile: annotate the root entrypoint with a nosemgrep justification — the --privileged harness must run as root to start VPP/Redis/saiserver and manage veth/AF_PACKET; it is a disposable test container, never a deployed service. Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
02b11fa to
4618cda
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Satisfy tests/checkwhitespace.sh (Azure Build amd64 gate). Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 14 out of 15 changed files in this pull request and generated no new comments.
Suppressed comments (4)
vslib/vpp/SwitchVppRif.cpp:359
- getPortHwifNameFromLane uses a fixed 8-entry buffer for SAI_PORT_ATTR_HW_LANE_LIST and treats any non-success as “lane list unavailable”. If the port ever reports more lanes than fit, the call will typically fail with SAI_STATUS_BUFFER_OVERFLOW, and this path will silently fall back to TAP mapping (or fail later) without a clear error. Handle BUFFER_OVERFLOW explicitly and include the status code in the debug log so failures are diagnosable.
uint32_t lanes[8] = {};
sai_attribute_t attr = {};
attr.id = SAI_PORT_ATTR_HW_LANE_LIST;
attr.value.u32list.count = sizeof(lanes) / sizeof(lanes[0]);
attr.value.u32list.list = lanes;
.azure-pipelines/docker-sai-test-vpp/run_test.sh:1012
- run_one_ptf hard-codes the "Turn up ports..." marker string instead of using the LINK_UP_TRIGGER variable defined near the top of the script. This makes LINK_UP_TRIGGER effectively dead configuration and can confuse readers expecting it to work.
case "$ptf_line" in
*"Turn up ports..."*)
bring_up_veths
;;
esac
.azure-pipelines/docker-sai-test-vpp/run_test.sh:566
- enumerate_test_classes() is currently defined but never called (planning uses plan_test_groups() instead). Keeping an unused discovery implementation in a large script makes future maintenance harder (two code paths to keep consistent).
# Enumerate every test class under $SAI_TEST_DIR as "module.Class" selectors so
# each can run as its own config-reuse ptf invocation. Best-effort: on any
# failure prints nothing and the caller falls back to a single invocation.
enumerate_test_classes()
{
vslib/vpp/SwitchVppRif.cpp:346
- PR description states the change is “test scaffolding only (everything under .azure-pipelines/docker-sai-test-vpp/)” and “does not touch any production/runtime code”, but this PR also modifies vslib/vpp (e.g., adds lane-based interface resolution in SwitchVppRif.cpp / SwitchVpp.h). Please update the description to reflect the vslib runtime change, or split runtime changes into a separate PR if the intent is to keep this PR harness-only.
bool SwitchVpp::getPortHwifNameFromLane(
_In_ sai_object_id_t port_id,
_Out_ std::string& if_name)
{
SWSS_LOG_ENTER();
739e5de to
be770b3
Compare
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
|
||
| if (get(SAI_OBJECT_TYPE_PORT, port_id, 1, &attr) != SAI_STATUS_SUCCESS) | ||
| { | ||
| SWSS_LOG_DEBUG("lane list unavailable for port %s", |
There was a problem hiding this comment.
LANE_LIST is mandatory in PORT. This should be an error message. Same for all the DEBUG message in the returning false case in this function.
| } | ||
|
|
||
| if_name = mapped_hwifname; | ||
| SWSS_LOG_DEBUG("resolved port %s lane set to %s/%s", |
There was a problem hiding this comment.
use INFO. DEBUG level is overwhelmed in syncd due to SWSS_LOG_ENTER in every function.
Signed-off-by: Nicholas Ching <nicholaslching@gmail.com>
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
/azpw run |
|
Retrying failed(or canceled) jobs... |
|
Retrying failed(or canceled) stages in build 1187084: ✅Stage BuildAsan:
|
Description of PR
Summary:
Adds the self-contained Docker harness (
docker-sai-test-vpp) that runs the upstream OCPsai_testPTF suite against the real VPP SAI backend (libsaivs) in one container — VPP +saiserver+ PTF + veth/AF_PACKET topology — and produces a per-test compatibility matrix. This is test scaffolding only (everything under.azure-pipelines/docker-sai-test-vpp/); it does not touch any production/runtime code, so it cannot affect existingsonic-sairedisfunctionality. Reviewers can start at.azure-pipelines/docker-sai-test-vpp/README.mdandrun_test.sh.Fixes # (N/A — no upstream issue)
Type of change
Approach
What is the motivation for this PR?
There was no in-tree way to run the OCP
sai_testsuite against the VPP SAI backend and track per-test coverage. This harness provides that, plus the development docs and compatibility matrices used to drive the backend fixes.How did you do it?
Added under
.azure-pipelines/docker-sai-test-vpp/:Dockerfileandrun_test.sh(orchestrates Redis → veth/PortChannel topology → VPP → saiserver → PTF), plus T0 config (sai.profile,lanemap.ini,port-map.ini,ptf-port-map.ini) andgen_compatibility_matrix.py.saiserverprocess,run_test.shgroups tests by theirsetUpconfig signature and restarts the backend per group, so one container can run any mix of tests.ISOLATE_EACH_TEST(default on): run each test in its own group with a fresh backend + own config to eliminate cross-test config-reuse contamination; set0for faster grouped runs.run_test.shassigns the DUT-side connected IPs to each LAG (be<N>) and SVI (bvi<vlan>) so routed-to-LAG/SVI traffic forwards in the standalone PTF environment (the backend portion is in the backend-fixes PR).--debugrun forvppctlinspection.devdocs/,demodocs/, andresults/compatibility matrices;.gitignorefor generated artifacts.How did you verify/test it?
Running the harness against
sai_route_test/sai_rif_test/sai_neighbor_test/sai_ecmp_testproduces a compatibility matrix (current state: 34 PASS, captured indevdocs//results/). The harness is self-contained and does not build or run any production code.Any platform specific information?
VPP platform test infrastructure only; isolated under
.azure-pipelines/docker-sai-test-vpp/. No impact on thesonic-sairedisbuild or runtime behavior.Documentation
This PR adds the harness
README.mdplus rolling/dated progress notes and deep-dive debug logs under.azure-pipelines/docker-sai-test-vpp/devdocs/and demo docs underdemodocs/.