Add coverage for heterogenous port tests#5571
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the existing packet-based link qualification test suite by adding support for heterogeneous port speeds and complex production-like configurations, such as Port-Channels. The changes ensure that the DUT can reliably initialize and perform link qualification even when interfaces are part of an active LAG, providing more robust validation for real-world deployment scenarios. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
Pull Request Functional Test Report for #5571 / 16c4e07Virtual Devices
Hardware Devices
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the packet-based link qualification test documentation and metadata to support broader port speeds and configurations, specifically adding a new test case for heterogeneous breakout and overlaid Port-Channel configurations along with a canonical OpenConfig example. The review feedback highlights inconsistencies in the new test case's topology description and API enum naming (using 'REFLECTOR' instead of 'FAR_END'), and recommends cleaning up redundant headers and placeholder text in the newly added DUT platform requirements section.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| * **Configure Heterogeneous Topology**: | ||
| * Setup the physical/logical links such that the Generator port on the local DUT is in native speed (e.g., 400G), and the Reflector port on the peer DUT is a breakout sub-port (e.g., 4x100G channel). | ||
| * **Apply Production Profile (Overlaid LAG)**: | ||
| * Map both interfaces as members of a Port-Channel (LAG) in the device's base configuration. | ||
| * **Trigger Reflector (Far-End)**: | ||
| * Issue the `gnoi.LinkQualification.Create` RPC to the far-end DUT, setting its `EndpointType` as `REFLECTOR` (ASIC or PMD loopback as supported). | ||
| * **Trigger Generator (Near-End)**: | ||
| * Issue the `gnoi.LinkQualification.Create` RPC to the local DUT, setting its `EndpointType` as `NEAR_END` (PacketGenerator) and defining the target packet size (e.g., max MTU) and transmission rate. |
There was a problem hiding this comment.
The topology is defined as a single-DUT loopback (dut1 to dut1), but the procedure for Test Case 2 refers to a 'local DUT', 'peer DUT', and 'far-end DUT'. Additionally, the endpoint type is incorrectly documented as 'REFLECTOR' instead of 'FAR_END' (which is the correct gNOI LinkQualification API enum value and matches Test Case 1). Please update the text to refer to a single DUT and use the correct 'FAR_END' endpoint type.
| * **Configure Heterogeneous Topology**: | |
| * Setup the physical/logical links such that the Generator port on the local DUT is in native speed (e.g., 400G), and the Reflector port on the peer DUT is a breakout sub-port (e.g., 4x100G channel). | |
| * **Apply Production Profile (Overlaid LAG)**: | |
| * Map both interfaces as members of a Port-Channel (LAG) in the device's base configuration. | |
| * **Trigger Reflector (Far-End)**: | |
| * Issue the `gnoi.LinkQualification.Create` RPC to the far-end DUT, setting its `EndpointType` as `REFLECTOR` (ASIC or PMD loopback as supported). | |
| * **Trigger Generator (Near-End)**: | |
| * Issue the `gnoi.LinkQualification.Create` RPC to the local DUT, setting its `EndpointType` as `NEAR_END` (PacketGenerator) and defining the target packet size (e.g., max MTU) and transmission rate. | |
| * **Configure Heterogeneous Topology**: | |
| * Setup the physical/logical links such that the Generator port on the DUT is in native speed (e.g., 400G), and the Reflector port on the same DUT is a breakout sub-port (e.g., 4x100G channel). | |
| * **Apply Production Profile (Overlaid LAG)**: | |
| * Map both interfaces as members of a Port-Channel (LAG) in the device's base configuration. | |
| * **Trigger Reflector (Far-End)**: | |
| * Issue the gnoi.LinkQualification.Create RPC to the DUT for the reflector port, setting its EndpointType as FAR_END (ASIC or PMD loopback as supported). | |
| * **Trigger Generator (Near-End)**: | |
| * Issue the gnoi.LinkQualification.Create RPC to the DUT for the generator port, setting its EndpointType as NEAR_END (PacketGenerator) and defining the target packet size (e.g., max MTU) and transmission rate. |
| ## Required DUT platform | ||
|
|
||
| * Specify the minimum DUT-type | ||
| * FFF - fixed form factor is enough for this test. However it can run also | ||
| on a MFF testbed. | ||
| gNMI.Set: | ||
|
|
||
| ## Minimum DUT platform requirement | ||
| * FFF - fixed form factor |
There was a problem hiding this comment.
The section contains redundant headers (## Required DUT platform and ## Minimum DUT platform requirement), placeholder template instructions (* Specify the minimum DUT-type), and dangling text (gNMI.Set:). These should be cleaned up and consolidated into a single, clean section.
| ## Required DUT platform | |
| * Specify the minimum DUT-type | |
| * FFF - fixed form factor is enough for this test. However it can run also | |
| on a MFF testbed. | |
| gNMI.Set: | |
| ## Minimum DUT platform requirement | |
| * FFF - fixed form factor | |
| ## Minimum DUT platform requirement | |
| * FFF - fixed form factor is enough for this test. However, it can also run on an MFF testbed. |
2 participants
This is to enhance the existing testcase realted to packet linkqualification test to do following
Verify that the DUT can successfully initialize, generate, and reflect link qualification packets over heterogeneous port combinations (native 800G/400G to breakout 8x100G and vice-versa) breakout and vice-versa link qual support. -->, even when the underlying interface carries active production configurations (like Port-Channel or LAG assignments)