GCU: New test case for port speed change#21235
GCU: New test case for port speed change#21235okaravasi wants to merge 9 commits intosonic-net:masterfrom
Conversation
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
There was a problem hiding this comment.
Pull request overview
This PR adds a new test case for validating port speed changes using Generic Config Updater (GCU) on T2 topology. The test verifies that port speed can be changed dynamically through GCU patches, with proper updates propagated to all databases (CONFIG_DB, APPL_DB, ASIC), correct buffer profile creation, and successful traffic forwarding with ACL rule verification.
Key changes:
- Implements comprehensive port speed change test including setup, verification, and traffic scenarios
- Adds platform-specific mappings for supported speeds, lanes, and FEC values
- Validates database consistency, buffer profile generation, and ACL rule enforcement after speed changes
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 21 comments.
| File | Description |
|---|---|
| tests/generic_config_updater/add_cluster/test_port_speed_change.py | New test case implementing port speed change validation with fixtures for port selection, speed/FEC configuration, database verification, ACL setup, and traffic validation across multiple scenarios |
| tests/generic_config_updater/add_cluster/platform_constants.py | Platform-specific mappings defining supported speeds, lane counts per speed, and FEC modes for different platforms |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| For example: | ||
| 400G speeds might support rs fec while 100G speeds might support fc fec. | ||
| """ | ||
| current_fec = get_port_fec(duthost, cli_namespace_prefix, selected_random_port) |
There was a problem hiding this comment.
here we are setting the same fec value before and after speed change. Normally, the scenario is 400g with fec as None and 100g with fec=rs. How is the scenario handled?
There was a problem hiding this comment.
Hi @arlakshm
Currently, in the scenario where a port is removed and its speed is changed, a random FEC is selected from the FECs supported for the target speed. This comes from the get_fec_for_speed function, which returns a value based on a hardcoded mapping for the specific platform and speed in the add_cluster/constants.py file.
At this step, we allow the port to be non-operational, as the speed might not be supported by the SFP, so we are more relaxed about the updated FEC value. However, during the actual test operation—when we change the speed to the required one—we use the FEC that the port had initially, to ensure that it is a supported FEC.
For future reference, the get_target_fec function is implemented to return a supported FEC value based on the target speed and the FECs supported for that speed by the chip. Currently, this code is not used because the Broadcom chip on Nokia platforms has limitations and returns supported FEC values only for the initially configured speed.
| cmd = "sonic-db-cli {} CONFIG_DB HGET \"PORT|{}\" \"speed\"".format(cli_namespace_prefix, selected_random_port) | ||
| port_speed_config_db = duthost.shell(cmd, module_ignore_errors=True)['stdout'] | ||
|
|
||
| cmd = "sonic-db-cli {} APPL_DB HGET \"PORT_TABLE:{}\" \"speed\"".format(cli_namespace_prefix, selected_random_port) |
There was a problem hiding this comment.
iso adding individual shell commands here, can we update sonic_asic.py to support single and multi asic? also it can be used in other tests if needed?
There was a problem hiding this comment.
Could we handle this via a separate PR and update this code after that change? That would be more convenient for the progress of this PR. Thank you.
| with allure.step("Re-enabling loganalyzer before removing cluster - changing speeds."): | ||
| if loganalyzer and loganalyzer[duthost.hostname]: | ||
| loganalyzer[duthost.hostname].add_end_ignore_mark() | ||
|
|
There was a problem hiding this comment.
Could we verify whether BGP and the port channel are operational after the speed change, and confirm that all critical processes are running? Also, please check if the neighbor and system_neighbor entries are correct.
There was a problem hiding this comment.
@arlakshm , wondering if we might limit the scope of this test case to be a layer1 only test? For port level only perspective, does the test case cover everything? If we combine this test with bgp fact test etc, will it cover BGP/PO sanity? thanks.
|
Hi @okaravasi , could you please add some details in description on what the test case expected to do? It will be helpful to review if you could add the expected base config, config after remove operations and the patch generated for config apply-patch to understand the expectation and validate of the test meet those expectation. |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: karavasi <[email protected]>
Signed-off-by: karavasi <[email protected]>
This reverts commit fd04b44. Signed-off-by: karavasi <[email protected]>
…speed updated in SAI, verify updated pg lossless profile created Signed-off-by: karavasi <[email protected]>
Signed-off-by: karavasi <[email protected]>
… speed change case Signed-off-by: karavasi <[email protected]>
…tches only upon suggestion, 1st patch removes/adds port info + changes speed, 2nd patch applies QUEUE config Signed-off-by: karavasi <[email protected]>
Signed-off-by: karavasi <[email protected]>
7d07e8a to
ad8503e
Compare
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Signed-off-by: karavasi <[email protected]>
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Hi @anamehra , Please refer to Test Plan #21388 as I have updated with the json example files. |
@okaravasi is this answered? |
@rlhui Olympia pointed to test plan where we have detailed the test case expectations and operation |
Please update the description as well with the correct link to test plan PR. |
|
@mssonicbld please run the checks again since 14887 is merged it should not run into this error |
|
/Azp run Azure.sonic-mgmt |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
this is a new PR replacing this one #21882 |
Description of PR
Summary:
Fixes # (issue)
This PR implements the test case described in this test plan #21388.
This PR has dependency on #14887 as it imports and uses functions that are added there.
Type of change
Back port request
Approach
What is the motivation for this PR?
To add new test case for gcu port speed change.
How did you do it?
How did you verify/test it?
Any platform specific information?
generic
Supported testbed topology if it's a new test case?
t2
Documentation