transceiver 102 and 104 fix#5642
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 introduces critical updates to support Cisco 800G ZR/ZR+ optics and improves the robustness of the transceiver testing framework. Key changes include adding specific operational modes for Cisco hardware, refining how telemetry streams are handled during interface state changes to prevent stale data, and adjusting configuration logic to better align with vendor-specific requirements. 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
|
There was a problem hiding this comment.
Code Review
This pull request adds support for Cisco-specific 800G operational modes, updates OTN and Ethernet channel configurations to handle platform deviations, and refactors telemetry validation to handle interface flapping and DOWN states. The review feedback identifies a semantic bug in the simplified pre-FEC BER validation logic where metrics are checked independently rather than ensuring they all match the same inactive value, and points out a redundant index assignment in the Ethernet channel configuration.
| isPreFECBERReady := | ||
| slices.Contains(inactivePreFECBER, val.GetOtn().GetPreFecBer().GetMin()) && | ||
| slices.Contains(inactivePreFECBER, val.GetOtn().GetPreFecBer().GetAvg()) && | ||
| slices.Contains(inactivePreFECBER, val.GetOtn().GetPreFecBer().GetMax()) && | ||
| slices.Contains(inactivePreFECBER, val.GetOtn().GetPreFecBer().GetInstant()) |
There was a problem hiding this comment.
The new logic using slices.Contains checks if each of the pre-FEC BER metrics (Min, Avg, Max, Instant) is present in inactivePreFECBER independently. This is semantically different from the original logic, which ensured that all four metrics are equal to the same inactive value (e.g., all 0.0, or all 0.5, or all 1.0). If different metrics have different inactive values, the channel should not be considered ready/inactive.
We can simplify the logic while preserving the original correctness by extracting the Min value first and then verifying that the other fields are equal to it.
| isPreFECBERReady := | |
| slices.Contains(inactivePreFECBER, val.GetOtn().GetPreFecBer().GetMin()) && | |
| slices.Contains(inactivePreFECBER, val.GetOtn().GetPreFecBer().GetAvg()) && | |
| slices.Contains(inactivePreFECBER, val.GetOtn().GetPreFecBer().GetMax()) && | |
| slices.Contains(inactivePreFECBER, val.GetOtn().GetPreFecBer().GetInstant()) | |
| min := val.GetOtn().GetPreFecBer().GetMin() | |
| isPreFECBERReady := slices.Contains(inactivePreFECBER, min) && | |
| val.GetOtn().GetPreFecBer().GetAvg() == min && | |
| val.GetOtn().GetPreFecBer().GetMax() == min && | |
| val.GetOtn().GetPreFecBer().GetInstant() == min |
| if deviations.EthChannelAssignmentCiscoNumbering(dut) { | ||
| assignment[0].Index = ygot.Uint32(1) | ||
| assignment[assignmentIndex].Index = ygot.Uint32(1) | ||
| } |
There was a problem hiding this comment.
This conditional block is completely redundant. When deviations.EthChannelAssignmentCiscoNumbering(dut) is true, assignmentIndex is set to 1, and assignment[assignmentIndex] is already initialized with Index: ygot.Uint32(assignmentIndex) (which is 1). Therefore, re-assigning assignment[assignmentIndex].Index = ygot.Uint32(1) has no effect and can be safely removed.
No description provided.