[snappi] Derive TGEN link_training from DUT instead of hardcoding it - #26889
Open
YatishSVC wants to merge 1 commit into
Open
[snappi] Derive TGEN link_training from DUT instead of hardcoding it#26889YatishSVC wants to merge 1 commit into
YatishSVC wants to merge 1 commit into
Conversation
snappi_dut_base_config hardcodes auto_negotiation.link_training=True for single-DUT testbeds (added in sonic-net#14361). On optical 400G single-DUT beds where the DUT runs link_training=off (e.g. NH-5010), forcing link training on at the TGEN causes mac_local/remote_fault; the link never trains, ARP never resolves, and every snappi test fails. Read link_training from the DUT CONFIG_DB PORT table (per peer_port) and apply it to the TGEN. Falls back to the previous behavior when the DUT does not set link_training, so beds that do not configure it are unchanged. Tested: test_pfcwd_basic_single_lossless_prio -> 2 passed on an NH-5010 400G single-DUT snappi testbed (previously mac_local/remote_fault, ARP not resolved).
Collaborator
|
/azp run |
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
github-actions
Bot
requested review from
developfast,
rraghav-cisco and
sdszhang
August 7, 2026 18:08
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| if lt_val is not None: | ||
| lt_from_dut = str(lt_val).lower() in ['on', 'true', 'yes', '1'] | ||
| break | ||
| except Exception: |
mssonicbld
added
the
Request for 202511 branch
Collaborator
|
This PR has backport request for branch(es): 202511. ---Powered by SONiC BuildBot
|
Collaborator
|
This PR has backport request label(s) for branch(es): 202511, but is missing required test information. Please make sure you tick the tested branch(es) in the Tested branch section and provide test evidence (e.g., 202511: <test result>) in the Test result section as well in your PR description. ---Powered by SONiC BuildBot
|
Contributor
Author
|
cc: @atul-nexthop |
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
4 participants
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
snappi_dut_base_confighardcodes the traffic generator'sauto_negotiation.link_training = Truefor single-DUT testbeds (introduced in #14361). On optical 400G single-DUT beds where the DUT runslink_training: off(e.g. Q3D), forcing link training on at the TGEN makes the DUT↔TGEN link fault (mac_local_fault/mac_remote_fault); the link never trains, so ARP never resolves and every snappi test on that bed fails.This change derives
link_trainingfrom the DUT's CONFIG_DBPORTtable (perpeer_port) and applies it to the TGEN, so the TGEN matches the DUT's actual link-training setting.Summary:
link_trainingfrom the DUT running-configPORT[<peer_port>].auto_negotiation.link_training.multidut → False, single-DUT →True) when the DUT does not setlink_training, so beds that don't configure it are unchanged (backward compatible).Type of change
Back port request
Approach
What is the motivation for this PR?
Single-DUT snappi testbeds with optical 400G links that run
link_training: off(e.g. Q3D) cannot bring up the DUT↔TGEN link, because the TGEN is hardcoded tolink_training = True, producingmac_local_fault/mac_remote_fault. The link never trains, ARP never resolves, and every snappi test on the bed fails.How did you do it?
In
snappi_dut_base_config, readlink_trainingfrom the DUT CONFIG_DBPORTtable for the testpeer_ports and set the TGEN'sauto_negotiation.link_trainingto that value. The previous hardcoded defaults are kept as a fallback for the case where the DUT does not setlink_training(or the read fails), so existing behavior is preserved for those beds.How did you verify/test it?
Ran
snappi_tests/pfcwd/test_pfcwd_basic_with_snappi.py::test_pfcwd_basic_single_lossless_prioon Q3D platform(400G,link_training: off, RS-FEC) single-DUT snappi testbed:mac_local_fault/mac_remote_fault,ARP is not resolved in 60 seconds, all tests fail.Any platform specific information?
Affects single-DUT snappi testbeds whose DUT sets
link_training(notably optical 400G platforms that requirelink_training: off). No behavior change for beds that don't setlink_training.