Td2: Reclaim buffer from unused ports #1830

neethajohn · 2021-07-20T23:07:54Z

By default, lossless profiles are attached to PGs 3, 4 of all ports which results in a lot of buffer wastage when most of those ports are unused (not associated with a DEVICE_NEIGHBOR). In TD2, ingress pool size comprises of the reserved space as well. Hence making use of a special cable length of '0m' to identify unused ports and skip reserving space for those ports

What I did

In buffermgr, if port with cable len '0m' is identified, return immediately without creating pg lossless profile or attaching profile to the lossless pgs of that port
Listen to 'admin_status' update as well from the PORT table and update port-speed mapping. This is to handle add-rack scenario where a port is added later
- The port starts of with cable length 0m
- Configlet to add a port is applied. The order of operations specifc to the PORT/CABLE_LENGTH table are - port is initially set to admin down, cable length is updated for that port, port table attributes are defined and port is set to admin up
- speed update might not be seen when the port is set to admin up. Hence port-speed mapping will capture the speed update whenever its seen and once the cable length is updated while the port is brought back up, profiles can be attached to the lossless pgs of the port

How I verified it

Manual tests done. Verified that no space is reserved for unused ports
Verified that when a port is added using 'add-rack' scenario, profile is attached to pgs of that port
New VS test added

Signed-off-by: Neetha John <[email protected]>

…updates from PORT table Signed-off-by: Neetha John <[email protected]>

Signed-off-by: Neetha John <[email protected]>

cfgmgr/buffermgr.cpp

Signed-off-by: Neetha John <[email protected]>

cfgmgr/buffermgr.cpp

prsunny · 2021-07-25T15:49:32Z

/azp run

azure-pipelines · 2021-07-25T15:49:41Z

Azure Pipelines successfully started running 1 pipeline(s).

Signed-off-by: Neetha John <[email protected]> By default, lossless profiles are attached to PGs 3, 4 of all ports which results in a lot of buffer wastage when most of those ports are unused (not associated with a DEVICE_NEIGHBOR). In TD2, ingress pool size comprises of the reserved space as well. Hence making use of a special cable length of '0m' to identify unused ports and skip reserving space for those ports What I did * In buffermgr, if port with cable len '0m' is identified, return immediately without creating pg lossless profile or attaching profile to the lossless pgs of that port * Listen to 'admin_status' update as well from the PORT table and update port-speed mapping. This is to handle add-rack scenario where a port is added later - The port starts of with cable length 0m - Configlet to add a port is applied. The order of operations specifc to the PORT/CABLE_LENGTH table are - port is initially set to admin down, cable length is updated for that port, port table attributes are defined and port is set to admin up - speed update might not be seen when the port is set to admin up. Hence port-speed mapping will capture the speed update whenever its seen and once the cable length is updated while the port is brought back up, profiles can be attached to the lossless pgs of the port How I verified it - Manual tests done. Verified that no space is reserved for unused ports - Verified that when a port is added using 'add-rack' scenario, profile is attached to pgs of that port - New VS test added

Update submodule for swss f54b7d0b [Dynamic Buffer Calc][202012]Bug fix: Don't create lossless buffer profile for active ports without speed configured (sonic-net/sonic-swss#1820) ac7f5cff Td2: Reclaim buffer from unused ports (sonic-net/sonic-swss#1830) 04105a4b [debugcounterorch] check if counter type is supported before querying (sonic-net/sonic-swss#1789) a67d8af6 [202012][portsorch] fix errors when moving port from one lag to another. (sonic-net/sonic-swss#1819)

This PR includes the following commits a67d8af [202012][portsorch] fix errors when moving port from one lag to another (sonic-net/sonic-swss#1819) 04105a4 [debugcounterorch] check if counter type is supported before querying (sonic-net/sonic-swss#1789) ac7f5cff Td2: Reclaim buffer from unused ports (sonic-net/sonic-swss#1830) f54b7d0 [Dynamic Buffer Calc][202012]Bug fix: Don't create lossless buffer profile for active ports without speed configured (sonic-net/sonic-swss#1820) Signed-off-by: Neetha John <[email protected]>

Signed-off-by: Neetha John <[email protected]> As part of the buffer reclamation efforts for TD2, setting the default cable len to 0m which means unused ports will have a cable len of 0m. Why I did it To align with the changes in sonic-net/sonic-swss#1830 How to verify it With the default cable len set to 0m and the associated changes in swss, CABLE_LENGTH table had '0m' set for unused ports and accordingly more space was reserved for the shared pool

Update sonic-swss submodule head to include below fixes: Ignore ALREADY_EXIST error in FDB creation (sonic-net/sonic-swss#1815) Update MACsec SA PN counter to support SAI API 1.8 (sonic-net/sonic-swss#1818) [swss]: Allow portsyncd to run on system without ports (sonic-net/sonic-swss#1808) [debugcounterorch] check if counter type is supported before querying… (sonic-net/sonic-swss#1789) [configure.ac] Add the option of passing libnl path to configure script (sonic-net/sonic-swss#1824) refactor(fdbsyncd): Convert files with dos2unix (sonic-net/sonic-swss#1828) [VS] Fix for VS test failures (sonic-net/sonic-swss#1836) Td2: Reclaim buffer from unused ports (sonic-net/sonic-swss#1830) [gearbox] Set context for phys based on configs (sonic-net/sonic-swss#1826) [Dynamic Buffer Calc] Bug fix: Don't create lossless buffer profile for active ports without speed configured (sonic-net/sonic-swss#1822) Bridge mac setting, fix statedb time format (sonic-net/sonic-swss#1844) [cfgmgr]: Introduce common libs. (sonic-net/sonic-swss#1842)

This reverts commit 7f80f06.

Signed-off-by: Neetha John <[email protected]> As part of the buffer reclamation efforts for TD2, setting the default cable len to 0m which means unused ports will have a cable len of 0m. Why I did it To align with the changes in sonic-net/sonic-swss#1830 How to verify it With the default cable len set to 0m and the associated changes in swss, CABLE_LENGTH table had '0m' set for unused ports and accordingly more space was reserved for the shared pool

* Update default cable len to 0m for TD2 (#8298) * Update sonic-cfggen tests with the correct cable len Signed-off-by: Neetha John <[email protected]> As part of the buffer reclamation efforts for TD2, setting the default cable len to 0m which means unused ports will have a cable len of 0m. Why I did it To align with the changes in sonic-net/sonic-swss#1830 How to verify it - With the default cable len set to 0m and the associated changes in swss, CABLE_LENGTH table had '0m' set for unused ports and accordingly more space was reserved for the shared pool - Cfggen tests passed with the cable len update

Signed-off-by: Neetha John <[email protected]> As part of the buffer reclamation efforts for TD2, setting the default cable len to 0m which means unused ports will have a cable len of 0m. Why I did it To align with the changes in sonic-net/sonic-swss#1830 How to verify it With the default cable len set to 0m and the associated changes in swss, CABLE_LENGTH table had '0m' set for unused ports and accordingly more space was reserved for the shared pool

…t#8313) Update sonic-swss submodule head to include below fixes: Ignore ALREADY_EXIST error in FDB creation (sonic-net/sonic-swss#1815) Update MACsec SA PN counter to support SAI API 1.8 (sonic-net/sonic-swss#1818) [swss]: Allow portsyncd to run on system without ports (sonic-net/sonic-swss#1808) [debugcounterorch] check if counter type is supported before querying… (sonic-net/sonic-swss#1789) [configure.ac] Add the option of passing libnl path to configure script (sonic-net/sonic-swss#1824) refactor(fdbsyncd): Convert files with dos2unix (sonic-net/sonic-swss#1828) [VS] Fix for VS test failures (sonic-net/sonic-swss#1836) Td2: Reclaim buffer from unused ports (sonic-net/sonic-swss#1830) [gearbox] Set context for phys based on configs (sonic-net/sonic-swss#1826) [Dynamic Buffer Calc] Bug fix: Don't create lossless buffer profile for active ports without speed configured (sonic-net/sonic-swss#1822) Bridge mac setting, fix statedb time format (sonic-net/sonic-swss#1844) [cfgmgr]: Introduce common libs. (sonic-net/sonic-swss#1842)

) * Update default cable len to 0m for TD2 (sonic-net#8298) * Update sonic-cfggen tests with the correct cable len Signed-off-by: Neetha John <[email protected]> As part of the buffer reclamation efforts for TD2, setting the default cable len to 0m which means unused ports will have a cable len of 0m. Why I did it To align with the changes in sonic-net/sonic-swss#1830 How to verify it - With the default cable len set to 0m and the associated changes in swss, CABLE_LENGTH table had '0m' set for unused ports and accordingly more space was reserved for the shared pool - Cfggen tests passed with the cable len update

Signed-off-by: Neetha John <[email protected]> By default, lossless profiles are attached to PGs 3, 4 of all ports which results in a lot of buffer wastage when most of those ports are unused (not associated with a DEVICE_NEIGHBOR). In TD2, ingress pool size comprises of the reserved space as well. Hence making use of a special cable length of '0m' to identify unused ports and skip reserving space for those ports What I did * In buffermgr, if port with cable len '0m' is identified, return immediately without creating pg lossless profile or attaching profile to the lossless pgs of that port * Listen to 'admin_status' update as well from the PORT table and update port-speed mapping. This is to handle add-rack scenario where a port is added later - The port starts of with cable length 0m - Configlet to add a port is applied. The order of operations specifc to the PORT/CABLE_LENGTH table are - port is initially set to admin down, cable length is updated for that port, port table attributes are defined and port is set to admin up - speed update might not be seen when the port is set to admin up. Hence port-speed mapping will capture the speed update whenever its seen and once the cable length is updated while the port is brought back up, profiles can be attached to the lossless pgs of the port How I verified it - Manual tests done. Verified that no space is reserved for unused ports - Verified that when a port is added using 'add-rack' scenario, profile is attached to pgs of that port - New VS test added

sonic-net#1831) #### What I did Fixing issue sonic-net#1830 #### How I did it Problem we consume the function `loadData` from sonic-yang-mgmt pkg that always crops tables without YANG models from configdb json object. It does it as a side-effect and is not an expected outcome of the function. The fix here is to crop the current/target tables before doing any sorting, this way gurantee we avoid this bug. I think the better soln is to fix sonic-yang-mgmt pkg. Will look into this more next week. #### How to verify it Run the command in the issue, it will result in the expected outcome #### Previous command output (if the output of a command-line utility has changed) #### New command output (if the output of a command-line utility has changed)

neethajohn added 5 commits July 20, 2021 15:22

Introduce new var for port-speed mapping and update method signature

b06e8a5

Signed-off-by: Neetha John <[email protected]>

Skip PG profile creation for 0m cable len and listen to admin_status …

16f5c44

…updates from PORT table Signed-off-by: Neetha John <[email protected]>

Add VS test for zero cable len scenario

d08f029

Signed-off-by: Neetha John <[email protected]>

Fix alignment

c119a3a

Signed-off-by: Neetha John <[email protected]>

Remove leading tabs

c86a70e

Signed-off-by: Neetha John <[email protected]>

neethajohn added Enhancement ➕ Request for 202012 Branch Request for 202106 Branch labels Jul 20, 2021

neethajohn requested review from lguohan and yxieca July 20, 2021 23:07

neethajohn requested a review from prsunny as a code owner July 20, 2021 23:07

yxieca reviewed Jul 20, 2021

View reviewed changes

cfgmgr/buffermgr.cpp Outdated Show resolved Hide resolved

Raise log level to NOTICE when profile skip logic is hit

11ee222

Signed-off-by: Neetha John <[email protected]>

prsunny reviewed Jul 21, 2021

View reviewed changes

cfgmgr/buffermgr.cpp Show resolved Hide resolved

sonic-net deleted a comment from neethajohn Jul 25, 2021

sonic-net deleted a comment from azure-pipelines bot Jul 25, 2021

yxieca approved these changes Jul 26, 2021

View reviewed changes

prsunny approved these changes Jul 26, 2021

View reviewed changes

neethajohn merged commit 7f80f06 into sonic-net:master Jul 26, 2021

neethajohn deleted the td2_buf_reclaim branch July 26, 2021 17:42

qiluo-msft added the Included in 202012 Branch label Jul 27, 2021

stephenxs mentioned this pull request Jul 29, 2021

[sonic-swss][202012] Update submodule sonic-net/sonic-buildimage#8286

Merged

5 tasks

neethajohn mentioned this pull request Jul 29, 2021

[sonic-swss] [202012] Advance submodule sonic-net/sonic-buildimage#8288

Merged

5 tasks

neethajohn mentioned this pull request Jul 30, 2021

Update default cable len to 0m for TD2 sonic-net/sonic-buildimage#8298

Merged

5 tasks

vaibhavhd mentioned this pull request Aug 2, 2021

[advance submodule] Update sonic-swss master head to latest sonic-net/sonic-buildimage#8313

Merged

5 tasks

qiluo-msft added a commit to qiluo-msft/sonic-swss that referenced this pull request Aug 4, 2021

Revert "Td2: Reclaim buffer from unused ports (sonic-net#1830)"

7c2c2bb

This reverts commit 7f80f06.

judyjoseph added the Included in 202106 Branch label Aug 18, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Td2: Reclaim buffer from unused ports #1830

Td2: Reclaim buffer from unused ports #1830

neethajohn commented Jul 20, 2021

prsunny commented Jul 25, 2021

azure-pipelines bot commented Jul 25, 2021

Td2: Reclaim buffer from unused ports #1830

Td2: Reclaim buffer from unused ports #1830

Conversation

neethajohn commented Jul 20, 2021

prsunny commented Jul 25, 2021

azure-pipelines bot commented Jul 25, 2021