[buffermgrd]: Update PG profile on cable length change #4004

jithenderkondam · 2025-11-17T20:01:08Z

Why I did it:
When the cable length of a port changes, the Buffer PG profile isn't automatically updated. This causes a mismatch between the actual cable length and the buffer configuration, potentially leading to inefficient or incorrect buffer allocation.

How I did it:
The fix ensures that whenever a valid cable length is set, the buffer profile is recalculated and updated accordingly (by calling doSpeedUpdateTask). This maintains alignment between the hardware setup and buffer management.

How to verify it:
Can be verified by running below test
test_buffer_traditional.py::TestBuffer::test_update_buffer_pg_for_cable_len_change

Which release branch to backport (provide reason below if selected):

202505

Tested branch (Please provide the tested image version):

202505

mssonicbld · 2025-11-17T20:01:16Z

/azp run

azure-pipelines · 2025-11-17T20:01:26Z

Azure Pipelines successfully started running 1 pipeline(s).

kperumalbfn · 2025-11-17T21:55:59Z

cfgmgr/buffermgr.cpp

-    m_cableLenLookup[port] = cable_length;
-    SWSS_LOG_INFO("Cable length set to %s for port %s", m_cableLenLookup[port].c_str(), port.c_str());
+
+    if (cable_length != "None" && m_cableLenLookup[port] != cable_length)


You could change None --> "0m"

@jithenderkondam could you update the PR with the comments addressed.

@kperumalbfn
During dynamic port breakout, the CABLE_LENGTH parameter is passed as None, which is why a check is implemented to handle this case.
For a cable length of "0m", the handling is done within the "doSpeedUpdateTask" function.

root@sonic:/home/admin# redis-cli -n 4 MONITOR | grep "CABLE_LENGTH" 1764201567.816362 [4 127.0.0.1:34584] "HGETALL" "CABLE_LENGTH|AZURE" 1764201567.897019 [4 127.0.0.1:34604] **"HSET" "CABLE_LENGTH|AZURE" "Ethernet0" "None"** 1764201567.898136 [4 unix:/var/run/redis/redis.sock] "HGETALL" "CABLE_LENGTH|AZURE" 1764201567.901065 [4 127.0.0.1:34604] "HGETALL" "CABLE_LENGTH|AZURE" 1764201567.901277 [4 127.0.0.1:34604] "HGETALL" "CABLE_LENGTH|AZURE" 1764201567.901579 [4 127.0.0.1:34604] "HSET" "CABLE_LENGTH|AZURE" "Ethernet8" "40m" 1764201567.901883 [4 unix:/var/run/redis/redis.sock] "HGETALL" "CABLE_LENGTH|AZURE" 1764201567.901939 [4 127.0.0.1:34604] "HDEL" "CABLE_LENGTH|AZURE" "Ethernet0" 1764201567.902200 [4 unix:/var/run/redis/redis.sock] "HGETALL" "CABLE_LENGTH|AZURE"

@jithenderkondam which module sets the cable-length as None during breakout?

kperumalbfn · 2025-11-17T22:14:28Z

tests/test_buffer_traditional.py

+            fvs_buffer_pg = self.config_db.get_entry("BUFFER_PG", pg_field_key)
+
+            # Check if fvs_buffer_pg profile is not equal to expected dynamic profile
+            expected_profile = "pg_lossless_{}_{}_profile".format(test_speed, test_cable_len)


In addition to buffer_profile name, could you also check xon, threshold and xon_offset values of the profile to confirm the profile is generated with correct values.

@kperumalbfn These values are dynamic and are determined based on either the "static headroom lookup" or "the dynamic headroom calculation" approach.
Given that, could you clarify what the comparison should involve—specifically, when reading the associated buffer_profile, what should these values be compared against?

kperumalbfn · 2025-11-17T22:15:24Z

tests/test_buffer_traditional.py

+            # Check if fvs_buffer_pg profile is not equal to expected dynamic profile
+            expected_profile = "pg_lossless_{}_{}_profile".format(test_speed, test_cable_len)
+            if fvs_buffer_pg.get("profile") != expected_profile:
+                assert False, "BUFFER_PG profile {} is not {}".format(fvs_buffer_pg.get("profile"), expected_profile)


Pls add one more test to revert the cable_length to "0m" to remove the pg_profile from the port.

@kperumalbfn , Could you confirm the expected behavior when the cable length is configured as "0m"?
From reviewing the code, it appears that the "doSpeedUpdateTask" function exits without performing any operations in this case.

For cable-length 0m, there shouldn't be any PG profile attached.

mssonicbld · 2025-11-24T18:44:07Z

/azp run

azure-pipelines · 2025-11-24T18:44:17Z

Azure Pipelines successfully started running 1 pipeline(s).

tests/test_buffer_traditional.py

+
+            # Save original port speed and admin status
+            orig_fvs_port = self.config_db.get_entry("PORT", self.INTF)
+            orig_port_speed = orig_fvs_port.get("speed") if orig_fvs_port else None


tests/test_buffer_traditional.py

+            # Save original port speed and admin status
+            orig_fvs_port = self.config_db.get_entry("PORT", self.INTF)
+            orig_port_speed = orig_fvs_port.get("speed") if orig_fvs_port else None
+            orig_port_status = orig_fvs_port.get("admin_status") if orig_fvs_port else None


prsunny · 2025-11-25T01:28:51Z

@kperumalbfn , would you review/approve?

mssonicbld · 2025-11-26T21:25:40Z

/azp run

azure-pipelines · 2025-11-26T21:25:50Z

Azure Pipelines successfully started running 1 pipeline(s).

mssonicbld · 2025-11-27T00:11:30Z

/azp run

azure-pipelines · 2025-11-27T00:11:40Z

Azure Pipelines successfully started running 1 pipeline(s).

Why I did it: When the cable length of a port changes, the Buffer PG profile isn't automatically updated. This causes a mismatch between the actual cable length and the buffer configuration, potentially leading to inefficient or incorrect buffer allocation. How I did it: The fix ensures that whenever a valid cable length is set, the buffer profile is recalculated and updated accordingly (by calling doSpeedUpdateTask). This maintains alignment between the hardware setup and buffer management. How to verify it: Can be verified by running below test test_buffer_traditional.py::TestBuffer::test_update_buffer_pg_for_cable_len_change Which release branch to backport (provide reason below if selected): 202505 Tested branch (Please provide the tested image version): 202505 Signed-off-by: Jithender Kondam <[email protected]>

mssonicbld · 2025-12-02T00:33:35Z

/azp run

azure-pipelines · 2025-12-02T00:33:45Z

Azure Pipelines successfully started running 1 pipeline(s).

jithenderkondam requested review from kperumalbfn and prsunny as code owners November 17, 2025 20:01

kperumalbfn reviewed Nov 17, 2025

View reviewed changes

jithenderkondam force-pushed the fix/pg-profile-cable-len-change branch from b706286 to 2e9aabf Compare November 24, 2025 18:44

github-advanced-security bot found potential problems Nov 24, 2025

View reviewed changes

jithenderkondam force-pushed the fix/pg-profile-cable-len-change branch from 2e9aabf to 1fcdce1 Compare November 26, 2025 21:25

jithenderkondam force-pushed the fix/pg-profile-cable-len-change branch from 1fcdce1 to e6616ce Compare November 27, 2025 00:11

jithenderkondam force-pushed the fix/pg-profile-cable-len-change branch from e6616ce to 43d7e9b Compare December 2, 2025 00:32

[buffermgrd]: Update PG profile on cable length change #4004

Are you sure you want to change the base?

[buffermgrd]: Update PG profile on cable length change #4004

Uh oh!

Conversation

jithenderkondam commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mssonicbld commented Nov 17, 2025

Uh oh!

azure-pipelines bot commented Nov 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mssonicbld commented Nov 24, 2025

Uh oh!

azure-pipelines bot commented Nov 24, 2025

Uh oh!

Check notice

Check notice

prsunny commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mssonicbld commented Nov 26, 2025

Uh oh!

azure-pipelines bot commented Nov 26, 2025

Uh oh!

mssonicbld commented Nov 27, 2025

Uh oh!

azure-pipelines bot commented Nov 27, 2025

Uh oh!

mssonicbld commented Dec 2, 2025

Uh oh!

azure-pipelines bot commented Dec 2, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jithenderkondam commented Nov 17, 2025 •

edited

Loading

prsunny commented Nov 25, 2025 •

edited

Loading