Dpu npu new test - #34
Open
JibinBao wants to merge 2 commits into
Open
Conversation
…PU Interconnect. Please refer to the PR: sonic-net/sonic-buildimage#18465 Change-Id: I6f23e1ef43dff7892a8bd591970af64b5917bc89
Remove sku_dpu_pdu_ports_map, instead get the dpu npu ports from hwsku.json Change-Id: I459a3d035c2b94914dde808963363ec77030bf19
JibinBao
pushed a commit
that referenced
this pull request
May 15, 2026
) When `sudo monit validate` is run just before `sudo monit status`, the status output may still carry the **old** "data collected" timestamp because monit hasn&sonic-net#39;t finished its internal refresh cycle yet. This causes the memory-utilization plugin to read stale baseline data before or after a test run. Signed-off-by: xuliping <xuliping@microsoft.com>
JibinBao
pushed a commit
that referenced
this pull request
Jul 30, 2026
…ry_table_after_syncd_orchagent (sonic-net#25085) ### Description of PR Summary: This PR makes two related fixes to `tests/lldp/test_lldp_syncd.py::test_lldp_entry_table_after_syncd_orchagent`, which deliberately restarts `swss`/`syncd` and cascades to a `bgp` container restart. #### Commit 1 — Replace `time.sleep(60)` with a BGP convergence wait After restarting `swss`/`syncd`, the test currently waits a hardcoded `time.sleep(60)` before proceeding. On a DUT with many BGP neighbors (e.g., T1/T2 with 7050CX3), 60 seconds is **not enough** for bgpd to fully re-converge after the cascade restart. This leaves bgpd in a warming-up state by the time the test ends. The **next test** (e.g. `test_lldp_entry_table_after_cont_flap`) then takes its memory baseline snapshot while bgpd RSS is still low. When bgpd subsequently reaches its normal post-init RSS during the next test, the framework&sonic-net#39;s memory monitor reports a large increase (e.g. +139 MB > 128 MB threshold) and fails the next test with a **false-positive memory alarm**. Replace `time.sleep(60)` with `wait_until(duthost.check_bgp_session_state, ...)` so the test deterministically waits for all BGP sessions to reach `Established` state before exiting. #### Commit 2 — Disable `memory_utilization` check for this test This test deliberately restarts swss/syncd, which cascades to a `bgp` container restart. The `memory_utilization` fixture takes before/after snapshots that become meaningless across such a restart (bgpd RSS drops to ~0 then warms back up over several minutes), so the in-test memory delta has no signal. Add `@pytest.mark.disable_memory_utilization` to make the test intent explicit and prevent future framework changes (e.g. alarming on volatility or absolute decreases) from flagging this test on a meaningless measurement. This is consistent with other restart-style tests (e.g. `test_advanced_reboot`, `test_warm_reboot`, `test_container_autorestart`). ADO: https://msazure.visualstudio.com/One/_workitems/edit/38230412 ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 ### Approach #### What is the motivation for this PR? Observed in plan `6a1b270895e3f84fd1e9ace9` (7050cx3.m1-128.202603 NightlyTest, branch `20260310.11`) on `testbed-bjw3-can-7050c-6`: - `test_lldp_entry_table_after_syncd_orchagent` restarted swss/syncd (which cascades to bgp container) - `time.sleep(60)` returned while bgpd RSS was still 67.9 MB (mid-convergence) - Next test `test_lldp_entry_table_after_cont_flap` took its "before" snapshot: bgpd = 67.9 MB - 16 minutes later, bgpd had warmed up to its normal 207.1 MB - Framework reported `+139.2 MB > 128 MB threshold` → ALARM → next test FAILED `vtysh show memory bgp` (FRR internal allocator counter) showed a consistent 204 MB both before and after the next test — proving bgpd did not actually leak memory. Only `top` RSS appeared to grow because the baseline was taken too early. #### How did you do it? **Commit 1 — wait for BGP convergence instead of sleep(60):** ```python bgp_neighbors = list(duthost.get_bgp_neighbors().keys()) pytest_assert( wait_until(300, 10, 30, duthost.check_bgp_session_state, bgp_neighbors), "BGP sessions did not reach Established state after swss restart", ) ``` - Uses existing `duthost.get_bgp_neighbors()` to dynamically fetch the neighbor list (works on all topologies) - Uses existing `duthost.check_bgp_session_state()` (default expected state = `"established"`) - Parameters: `timeout=300s`, `interval=10s`, `delay=30s` **Commit 2 — disable memory check on this test:** ```python @pytest.mark.disable_loganalyzer @pytest.mark.disable_memory_utilization # NEW def test_lldp_entry_table_after_syncd_orchagent(...): ``` The two changes are complementary: - **Commit 1** prevents pollution of the next test (wait for BGP convergence before exit) - **Commit 2** disables the meaningless measurement on this test itself #### How did you verify/test it? Logic review against existing helpers (`get_bgp_neighbors`, `check_bgp_session_state`, `wait_until`, `disable_memory_utilization` marker) — all are widely used elsewhere in sonic-mgmt. Behavior change matrix for Commit 1: - Healthy fast DUT (T0): exits in ~20–30 s (faster than old 60s sleep) - Slow DUT (T1 with many neighbors): waits up to 300 s for actual convergence (vs. silently returning after insufficient 60s) A real run on testbed-bjw3-can-7050c-7 / 7050c-6 will be needed to confirm the next-test memory alarm cascade no longer fires. #### Any platform specific information? None — both changes are platform-agnostic. The helpers used are standard sonic-mgmt helpers. #### Supported testbed topology if it&sonic-net#39;s a new test case? N/A — not a new test case. The existing test continues to run on all topologies where it currently runs. ### Documentation N/A ### Elastic Test Jobs - testbed-bjw3-can-7050c-7: https://elastictest.org/scheduler/testplan/6a20dc922047c3c4a9f91c7c - testbed-bjw3-can-7050c-8: https://elastictest.org/scheduler/testplan/6a20dc94729d944bd21c92e0 - testbed-bjw3-can-7050c-11: https://elastictest.org/scheduler/testplan/6a20dc962296f2ad62e47dbc --------- Signed-off-by: lipxu <lipxu@microsoft.com> Signed-off-by: Liping Xu <108326363+lipxu@users.noreply.github.com>
JibinBao
pushed a commit
that referenced
this pull request
Jul 30, 2026
…ious config_reload (sonic-net#25116) ### Description of PR The `clean_passw_policies` teardown in `tests/passw_hardening` reset the password hardening policies to a set of hard-coded "default" values. Whenever those hard-coded values drifted from the real SONiC boot defaults (defined in `init_cfg.json.j2`), the module-scoped config check detected a `CONFIG_DB` diff and ran `config_reload`. That `config_reload` restarts BGP, which produces spurious `bgpd memory increased` alarms on the **next, unrelated test** (e.g. `test_snmp_memory`), causing flaky failures. This PR replaces the hard-coded reset with a **snapshot/restore** approach: - `get_passw_policies()` captures the DUT&sonic-net#39;s actual `PASSW_HARDENING|POLICIES` values once per module. - `restore_passw_policies()` in teardown re-applies **only the fields that changed** during the test. A test that does not touch the policies now issues **zero** CLI commands in teardown, so no `CONFIG_DB` diff is created and no `config_reload` is triggered. Summary: Fixes spurious `test_snmp_memory` (and other downstream) failures caused by password hardening teardown triggering `config_reload`. ADO: https://msazure.visualstudio.com/One/_workitems/edit/38230412 ### Type of change - [x] Bug fix - [ ] Testbed and Framework(new/improvement) - [ ] New Test case - [ ] Skipped for non-supported platforms - [x] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 ### Approach #### What is the motivation for this PR? `test_snmp_memory` (and other tests) intermittently fail with `bgpd memory increased` alarms. Root cause: the password hardening test teardown resets policies to hard-coded "default" values that drift from the image&sonic-net#39;s real boot defaults. The resulting `CONFIG_DB` diff triggers `config_reload` → BGP restart → memory alarm on the subsequent test. #### How did you do it? - Added `get_passw_policies(duthost)` to snapshot the live `PASSW_HARDENING|POLICIES` hash from `CONFIG_DB` (parsed with `ast.literal_eval`; returns `None` and logs a warning on read/parse failure). - Added `restore_passw_policies(duthost, snapshot)` which reads the live state at teardown and re-applies only the fields whose value differs from the snapshot. `state` is applied last. If the live state cannot be read, it conservatively restores every snapshot field. CONFIG_DB field names (underscores) are mapped to the `config passw-hardening policies` CLI subcommands (hyphens) via `field.replace(&sonic-net#39;_&sonic-net#39;, &sonic-net#39;-&sonic-net#39;)`, removing the previous hand-maintained key map. - Replaced the module fixture so it snapshots the actual values (`passw_policies_snapshot`); `clean_passw_policies` now restores from that snapshot. #### How did you verify/test it? - Verified `sonic-db-cli CONFIG_DB hgetall "PASSW_HARDENING|POLICIES"` output and `ast.literal_eval` parsing on a live DUT (Arista-7050CX3). - Confirmed all 10 DB fields map 1:1 to `config passw-hardening policies` CLI subcommands via pure `_`→`-` transform. - Unit-simulated the restore diff logic: unchanged → 0 commands; changed fields → only those re-applied with `state` last; live-read `None` → restore all; snapshot `None` → skip. - flake8 (max-line-length=120) clean; `py_compile` passes. #### Any platform specific information? None. The fix is platform-agnostic. #### Supported testbed topology if it&sonic-net#39;s a new test case? N/A — existing test improvement. ### Documentation N/A ### Elastic Test Jobs - testbed-bjw3-can-7050c-11: https://elastictest.org/scheduler/testplan/6a28e79d2047c3c4a9f924b1 Signed-off-by: Liping Xu <108326363+lipxu@users.noreply.github.com>
JibinBao
pushed a commit
that referenced
this pull request
Jul 30, 2026
…version baseline per image type (sonic-net#25035) ### Description of PR Summary: Adds `tests/platform_tests/test_sai_ocp_version.py` — a new platform test that verifies the BRCM SAI / OCP SAI version baseline on the DUT against an expected version-per-image-type matrix. Starting from SONiC build `20251110`, different HwSKUs run different target image types (e.g., `legacy-th` for the Arista 7060CX family), each requiring specific BRCM SAI and OCP SAI versions. This test: 1. Skips if the SONiC build date is before `20251110` 2. Skips if the ASIC vendor is not Broadcom 3. Skips if the DUT HwSKU is not present in `HWSKU_IMAGE_TYPE_MAP` 4. Runs `bcmcmd bsv` and parses BRCM SAI / OCP SAI / SDK versions 5. Asserts BRCM SAI same `major.minor.patch` and `build >= baseline`; OCP SAI header `>= minimum` The version table (`IMAGE_TYPE_VERSIONS`) and the HwSKU mapping (`HWSKU_IMAGE_TYPE_MAP`) are the only two places to edit as the support matrix evolves — adding a new HwSKU or image type is a few-line change with no test-logic edit required. Testgap: sonic-net#25036 Fixes sonic-net#25036 ### Type of change - [ ] Bug fix - [ ] Testbed and Framework(new/improvement) - [x] New Test case - [x] Skipped for non-supported platforms - [ ] Test case improvement ### Back port request - [ ] 202205 - [ ] 202305 - [ ] 202311 - [ ] 202405 - [ ] 202411 - [ ] 202505 - [ ] 202511 ### Approach #### What is the motivation for this PR? Catch SAI version regressions early on supported HwSKUs after the `20251110` image-type split. The previous monolithic SAI version assumption no longer holds — Arista 7060CX (Tomahawk) now ships with an older BRCM SAI paired with the latest OCP SAI header (the `legacy-th` image type), while other HwSKUs use the standard build. A single hard-coded check across all platforms would either spuriously fail on 7060CX or silently pass when a real regression slips through on other platforms. This PR closes the testgap tracked in sonic-net#25036 — "Add test coverage for new legacy-th image". #### How did you do it? Mapping-driven design: - `IMAGE_TYPE_VERSIONS` — per-image-type expected version constants (BRCM SAI baseline, OCP SAI minimum) - `HWSKU_IMAGE_TYPE_MAP` — maps each supported HwSKU to its image type - Test resolves DUT HwSKU → image type → expected versions, then parses `bcmcmd bsv` and compares Behavior is fail-closed: any HwSKU NOT in `HWSKU_IMAGE_TYPE_MAP` causes a `pytest.skip`, so unknown HwSKUs never break CI. #### How did you verify/test it? Cherry-picked the same content from the internal sonic-mgmt-int branch `dev/xuliping/20260602_internal_sai_check` (commit `cdedfd937e`) — the version was validated against `bcmcmd bsv` output on Arista 7060CX testbeds. #### Any platform specific information? Broadcom-only — the test uses `bcmcmd bsv` which exists only on Broadcom ASICs. Cleanly skips on Mellanox / Cisco / Nokia / others via the ASIC-vendor gate. #### Supported testbed topology if it&sonic-net#39;s a new test case? `pytest.mark.topology(&sonic-net#39;any&sonic-net#39;)` and `pytest.mark.device_type(&sonic-net#39;physical&sonic-net#39;)` — runs on any topology with a physical Broadcom DUT. ### Documentation N/A — single-file test, no Wiki page required. ### Elastic Test Jobs | Testbed | HW / Topo | Image | Plan | |---|---|---|---| | `testbed-bjw3-can-t0-7060-7` | Arista 7060CX legacy-th / t0 | internal-202511 (no install/pretest) | [6a2f96a153b3182993b4fecb](https://elastictest.org/scheduler/testplan/6a2f96a153b3182993b4fecb) | | `testbed-bjw2-can-t1-7260-11` | Arista 7260CX3 / t1-64-lag | internal-202511 (no install/pretest) | [6a2f9702729d944bd21ca2fd](https://elastictest.org/scheduler/testplan/6a2f9702729d944bd21ca2fd) | | `testbed-bjw3-can-t0-7060-8` | Arista 7060CX legacy-th / t0 | internal (with image install + pretest) | [6a2f975303b7f75ed1c22f23](https://elastictest.org/scheduler/testplan/6a2f975303b7f75ed1c22f23) | | `testbed-bjw3-can-t0-7060-7` | Arista 7060CX legacy-th / t0 | internal (with image install + pretest) | [6a2fe13b2047c3c4a9f92d56](https://elastictest.org/scheduler/testplan/6a2fe13b2047c3c4a9f92d56) | | `testbed-bjw3-can-t0-7060-8` | Arista 7060CX legacy-th / t0 | internal-202511 (with image install + pretest) | [6a2fe13b95ed954f0d3d7e9d](https://elastictest.org/scheduler/testplan/6a2fe13b95ed954f0d3d7e9d) | --------- Signed-off-by: lipxu <lipxu@microsoft.com> Signed-off-by: Liping Xu <xuliping@microsoft.com> Signed-off-by: Liping Xu <108326363+lipxu@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of PR
Add test_dpu_npu_port test, because we introduce a new role for DPU-NPU Interconnect. Please refer to the PR: sonic-net/sonic-buildimage#18465
Summary:
Fixes # (issue)
Type of change
Back port request
Approach
What is the motivation for this PR?
Add one new case for PR: sonic-net/sonic-buildimage#18465
How did you do it?
Add test_dpu_npu_port
How did you verify/test it?
Run it on smartswitch
Any platform specific information?
Smartswitch
Supported testbed topology if it's a new test case?
Any
Documentation