Use 8 instead of 9 total ixia ports for LAG tests#5137
Use 8 instead of 9 total ixia ports for LAG tests#5137gggsmith merged 1 commit intoopenconfig:mainfrom
Conversation
Summary of ChangesHello @frasieroh, 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 optimizes the resource allocation for Link Aggregation Group (LAG) tests by decreasing the required Ixia ports from nine to eight. This change significantly improves testbed utilization and cost-effectiveness by preventing the unnecessary allocation of an entire Ixia resource group for a single port. The modifications span across test definitions, documentation, and protobuf configurations to ensure consistency with the new 8-link setup. Highlights
Changelog
Activity
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 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 counter productive. 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. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. 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 aims to reduce the number of Ixia ports used in LAG tests from 9 to 8, which is a sensible optimization for testbed resource allocation. The changes are mostly consistent across documentation, testbed definitions, and test code. I've identified a couple of minor inconsistencies in the documentation that should be corrected to ensure accuracy and prevent confusion, and these comments have been retained as they do not conflict with any provided rules.
gggsmith
left a comment
gggsmith
left a comment
There was a problem hiding this comment.
Thank you @frasieroh - I don't have any concerns about reducing the port number for all of the cases updated here. Could you please address minor comments? Thank you!
frasieroh
force-pushed
the
fnt-7lag
branch
3 times, most recently
from
43695ca to
890928f
Compare
Ixia ports are organized into resource groups (RGs). The AresONE 400g traffic generator assigns two 400g ports to each resource group. These can be broken out into 4 100g ports each for a total of 8 100g ports per RG. Some operations to ixia ports apply to all ports in the same RG, so resource groups must be statically allocated to testbeds to avoid conflicts. If two testbeds were to use two ports within the same RG concurrently, configuring one port could cause conflicts with the other port. The choice of these lag tests to use 9 ports means we must allocate 2 RGs to any testbed which intends to run them. The second resource group is only used for a single port for these 4 tests, nonetheless, it cannot be used for anything else. This is prohibitively expensive. By marginally reducing the port scale we can double the number of applicable testbeds in our environment. The modified tests pass in our environment with the exception or RT-5.3 which has never passed.
Ixia ports are organized into resource groups (RGs). The AresONE 400g traffic generator assigns two 400g ports to each resource group. These can be broken out into 4 100g ports each for a total of 8 100g ports per RG. Some operations to ixia ports apply to all ports in the same RG, so resource groups must be statically allocated to testbeds to avoid conflicts. If two testbeds were to use two ports within the same RG concurrently, configuring one port could cause conflicts with the other port. The choice of these lag tests to use 9 ports means we must allocate 2 RGs to any testbed which intends to run them. The second resource group is only used for a single port for these 4 tests, nonetheless, it cannot be used for anything else. This is prohibitively expensive. By marginally reducing the port scale we can double the number of applicable testbeds in our environment. The modified tests pass in our environment with the exception or RT-5.3 which has never passed.
Ixia ports are organized into resource groups (RGs). The AresONE 400g traffic generator assigns two 400g ports to each resource group. These can be broken out into 4 100g ports each for a total of 8 100g ports per RG. Some operations to ixia ports apply to all ports in the same RG, so resource groups must be statically allocated to testbeds to avoid conflicts. If two testbeds were to use two ports within the same RG concurrently, configuring one port could cause conflicts with the other port. The choice of these lag tests to use 9 ports means we must allocate 2 RGs to any testbed which intends to run them. The second resource group is only used for a single port for these 4 tests, nonetheless, it cannot be used for anything else. This is prohibitively expensive. By marginally reducing the port scale we can double the number of applicable testbeds in our environment. The modified tests pass in our environment with the exception or RT-5.3 which has never passed.
4 participants
Ixia ports are organized into resource groups (RGs). The AresONE 400g traffic generator assigns two 400g ports to each resource group. These can be broken out into 4 100g ports each for a total of 8 100g ports per RG.
Some operations to ixia ports apply to all ports in the same RG, so resource groups must be statically allocated to testbeds to avoid conflicts. If two testbeds were to use two ports within the same RG concurrently, configuring one port could cause conflicts with the other port.
The choice of these lag tests to use 9 ports means we must allocate 2 RGs to any testbed which intends to run them. The second resource group is only used for a single port for these 4 tests, nonetheless, it cannot be used for anything else. This is prohibitively expensive. By marginally reducing the port scale we can double the number of applicable testbeds in our environment.
The modified tests pass in our environment with the exception or RT-5.3 which has never passed.