Update TE-14.3 & TE.4 with the physical output setup change#5482
Update TE-14.3 & TE.4 with the physical output setup change#5482gggsmith wants to merge 4 commits into
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 updates the physical topology for gRIBI scaling tests (TE-14.3 and TE-14.4) to improve test stability. By increasing the number of physical links used, the configuration avoids overloading individual ports with a high volume of sub-interfaces, ensuring that test results are more representative of production environments and less prone to artificial hardware limitations. 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
|
![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 gRIBI full-scale test configurations for targets T1 and T2, transitioning from a 2-link to an 8-link testbed. The documentation for the T1 test was updated to describe the distribution of 640 L3 sub-interfaces across multiple physical ports. A review comment correctly identified a mathematical inconsistency in the README, noting that the range from port 2 to port 7 represents 6 port pairs rather than 8, which is necessary for the sub-interface count to total 640.
| - DUT [port1] -> 1 L3 sub-interface <-> ATE [port1] 1 L3 sub-interface , subnet `192.0.2.0/30` | ||
| - DUT [port2] -> 640 L3 sub-interfaces <-> ATE [port2] 640 L3 sub-interfaces, Use Vlan tagging for differentiation - `198.18.0.0/20` subdivided into `/30` chunks | ||
|
|
||
| Each of the 8 port pairs (DUT/ATE [port2] through [port7]) is configured with 90 L3 sub-interfaces, and [port8] - with 100 L3 sub-interfaces. |
There was a problem hiding this comment.
The text mentions '8 port pairs' but the range '(DUT/ATE [port2] through [port7])' only covers 6 port pairs. Based on the math (6 * 90 + 100 = 640), it appears that only 6 ports are configured with 90 sub-interfaces each. This should be corrected to '6' to ensure the documentation accurately reflects the test configuration.
| Each of the 8 port pairs (DUT/ATE [port2] through [port7]) is configured with 90 L3 sub-interfaces, and [port8] - with 100 L3 sub-interfaces. | |
| Each of the 6 port pairs (DUT/ATE [port2] through [port7]) is configured with 90 L3 sub-interfaces, and [port8] is configured with 100 L3 sub-interfaces. |
References
- Test code must follow the steps documented in the test README.md. Accurate documentation is essential for maintaining alignment between the test plan and the implementation. (link)
- Ensure correct grammar, including subject-verb agreement and proper use of singular/plural forms.
2 participants
Distributing sub-interfaces across multiple physical ports is necessary to prevent resource exhaustion and instability on the Device Under Test (DUT).
Concentrating a large number of sub-interfaces (e.g., 640) on a single physical port overloads the port's resources, causing the device to become unresponsive. This configuration does not reflect production environments, where logical interfaces are spread across numerous physical interfaces.
Using multiple physical ports (e.g., 7 ports with approx 90 sub-interfaces each) provides a more realistic test scenario, reduces the load on any single port, and ensures that test failures are due to actual feature issues rather than artificial hardware limitations. This change aims to improve test reliability and better mimic production network behavior.