Prevent Profile Creation for Invalid Cable Length #2
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jianyuewu
force-pushed
the
skip_0m_profile
branch
from
472939a to
ed56339
Compare
…agMember for strip tag (sonic-net#3343) What I did Added child_ports check in addLagMember and removeLagMember for strip tag Why I did it portorch sets LAG member's strip tag when adding subport: // Change hostif vlan tag for the parent port only when a first subport is created if (parentPort.m_child_ports.empty()) { if (!setHostIntfsStripTag(parentPort, SAI_HOSTIF_VLAN_TAG_KEEP)) but if a new member is added later, in addLagMember function, it does not handle strip tag anymore. Cause the new added lag member has wrong tag mode.
…-net#3520) *What I did: Added Change to Skip Route Programming if NH is link/oper down. With Scale Route testing of 60K+ routes when we toggle all the interfaces[14+ interface back to back] as done here: https://github.com/sonic-net/sonic-mgmt/blob/master/tests/snappi_tests/multidut/bgp/test_bgp_outbound_uplink_multi_po_flap.py we see because of slowness of FRR Route APP_DB processing compare to Link Notification Handling where we have updated the Nexthop Group as part of Link Notification handling to point to default route via sonic-net#3389 [if eligible] FRR slowness can reprogram the Route back to Nexthop which is link down. This change is similar to sonic-net#3394 which was done for Nexthop Group.
…-net#3517) * Set Port UPDATE_DSCP attribute when TC_TO_DSCP map is attached What I did Set Port SAI attribute SAI_PORT_ATTR_UPDATE_DSCP when TC_TO_DSCP map is attached to the port. Why I did it Some vendor SAI expects Sonic to set this attribute explicitly when TC_TO_DSCP map is attached to the port to modify DSCP value of the packet.
jianyuewu
force-pushed
the
skip_0m_profile
branch
2 times, most recently
from
975e019 to
5cf753f
Compare
stephenxs
suggested changes
Feb 26, 2025
|
I believe we also need to add a test case to cover the scenario that it changes between 0m and other values |
* Add appliance entry validation (sonic-net#3494) - Do not allow more than 1 entry in DASH Appliance table. - Do not allow DASH VNET creation before DASH Appliance entry creation. - DASH ENI already has similar check for Appliance entry.
* [smartswitch] Add support for ENI Based Forwarding HLD: sonic-net/SONiC#1842 Requires sonic-net/sonic-swss-common#976 Add DashEniFwdOrch which installs ACL rules to Redirect the DASH packet to corresponding DPU
jianyuewu
force-pushed
the
skip_0m_profile
branch
2 times, most recently
from
9ebe39c to
cea0057
Compare
stephenxs
reviewed
Feb 27, 2025
stephenxs
reviewed
Feb 27, 2025
jianyuewu
force-pushed
the
skip_0m_profile
branch
from
cea0057 to
46699ab
Compare
stephenxs
reviewed
Feb 27, 2025
jianyuewu
force-pushed
the
skip_0m_profile
branch
from
46699ab to
5402d6a
Compare
What I did Initialize the port error status map only once Why I did it Any change in CONFIG_DB PORT table was resulting in updating the port error status map resulting in change in error count = 0 How I verified it Verified by raising RF and LF error events on the port
…3502) * Use non-zero trap priority for default trap group This priority is used internally in some vendor SAI implementations and causes undesirable packet trapping behavior. How I verified it By running copp tests which include rate-limiting tests for TTL 1 packets on on Cisco/Mellanox/Arista platforms. By manual tests with TTL 1 packets generated by scapy
…r poll calls and communication between swss/sairedis (sonic-net#3504) * Use flex counter manager for the following counter groups - priority group watermark - priority group drop - queue watermark - port counter group Signed-off-by: Stephen Sun <stephens@nvidia.com> * Fix compiling error Signed-off-by: Stephen Sun <stephens@nvidia.com> * Support bulk create also for WRED/ECN counter groups Signed-off-by: Stephen Sun <stephens@nvidia.com> * Fix review comments Signed-off-by: Stephen Sun <stephens@nvidia.com> --------- Signed-off-by: Stephen Sun <stephens@nvidia.com>
stephenxs
reviewed
Mar 4, 2025
Do not unheal internal links, even in private PR. Please delete it. |
stephenxs
reviewed
Mar 4, 2025
stephenxs
reviewed
Mar 4, 2025
stephenxs
reviewed
Mar 4, 2025
stephenxs
reviewed
Mar 4, 2025
stephenxs
reviewed
Mar 4, 2025
jianyuewu
force-pushed
the
skip_0m_profile
branch
from
ec26c0c to
61afaa6
Compare
stephenxs
reviewed
Mar 4, 2025
stephenxs
reviewed
Mar 4, 2025
stephenxs
reviewed
Mar 4, 2025
stephenxs
reviewed
Mar 4, 2025
jianyuewu
force-pushed
the
skip_0m_profile
branch
2 times, most recently
from
c883461 to
58ada9e
Compare
stephenxs
reviewed
Mar 4, 2025
Changes: - Skip PG creation when both cable length is 0m AND PG is lossless - Allow lossy PGs to be created regardless of cable length Test: - Add unit test to verify lossy PG can be created with 0m cable length - Verify lossy PG profile and attributes are set correctly Signed-off-by: Jianyue Wu <jianyuew@nvidia.com>
jianyuewu
force-pushed
the
skip_0m_profile
branch
from
58ada9e to
74e9e63
Compare
stephenxs
reviewed
Mar 4, 2025
jianyuewu
force-pushed
the
skip_0m_profile
branch
from
d6bf42f to
3f54ab4
Compare
stephenxs
reviewed
Mar 5, 2025
When 0m cable, lossy PG and profile can still be created, while lossless profile will be deleted. Signed-off-by: Jianyue Wu <jianyuew@nvidia.com>
jianyuewu
force-pushed
the
skip_0m_profile
branch
from
3f54ab4 to
3494eae
Compare
|
Do not suggest force pushing frequently. I can hardly figure out what has been changed between commits. |
Signed-off-by: Jianyue Wu <jianyuew@nvidia.com>
OK, understand, I'll use incremental commit instead😊 |
stephenxs
reviewed
Mar 7, 2025
Co-authored-by: Stephen Sun <5379172+stephenxs@users.noreply.github.com>
stephenxs
approved these changes
Mar 7, 2025
What I did Provide an explicit value for send_sci in the macsec vstest Why I did it The kernel 5.15 requires the send_sci to be true if the sci value was provided explicitly.
…on one-arm MCLAG interface down. (sonic-net#3524) * [MCLAG] Fix a racce condition when moving MAC addresses to MCLAG peer on one-arm MCLAG interface down. What I did Avoid flushing MAC addresses for the MCLAG interface when the MCLAG interface goes down. This is because ICCPD will take care of those MAC addresses by moving them to the MCLAG peer interface. Why I did it Fix issue sonic-net#2913 and also replace PR sonic-net#2539. When the MCLAG interface goes down, the iccpd will move the MAC addresses associated with this particular MCLAG interface to the peer link, according the MCLAG HLD:
…es. (sonic-net#3552) What I did Add entries to the gitignore file for fabricmgrd, stpmgrd, and the p4orch_tests binaries. Why I did it When these binaries were added they were not included in the gitignore file. Adding them ensures that they cannot be accidentally committed.
* Use software_bfd instead of switch_type. What I did *Removed software BFD dependence on switch_type 'dpu'. Added checks SAI_SWITCH_ATTR_SUPPORTED_IPV4_BFD_SESSION_OFFLOAD_TYPE and SAI_SWITCH_ATTR_SUPPORTED_IPV6_BFD_SESSION_OFFLOAD_TYPE instead. *Will use software BFD if either return SAI_BFD_SESSION_OFFLOAD_TYPE_NONE Why I did it Request in sonic-net#3406 to allow software BFD to be enabled independent of switch_type 'dpu'.
…nic-net#3447) * [orchagent] Do not restore port admin if port admin is configured Issue: The pCfg.admin_status might be overridden by prior configurations. Solution: Only restore port admin if port admin is not configured.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added a check in BufferMgrDynamic::allocateProfile to skip profile creation when the cable length is 0m.
What I did
Prevent profile creation for invalid cable length.
Why I did it
Ensures that profiles are not created for invalid cable lengths, preventing potential configuration errors.
How I verified it
Local test: "config interface cable-length Ethernet0 5m" and "buffershow -l" to see if 0m profile is created.
Details if related
With out this change, profile will be created, log is:
2025 Feb 24 07:17:38.926732 r-leopard-70 NOTICE swss#buffermgrd: :- allocateProfile: Creating new profile 'pg_lossless_200000_0m_profile'
2025 Feb 24 07:17:38.928570 r-leopard-70 NOTICE swss#buffermgrd: :- allocateProfile: BUFFER_PROFILE pg_lossless_200000_0m_profile has been created successfully
2025 Feb 24 07:17:38.938143 r-leopard-70 NOTICE swss#orchagent: :- processBufferProfile: Created buffer profile pg_lossless_200000_0m_profile with type BUFFER_PROFILE_TABLE
2025 Feb 24 07:17:38.939078 r-leopard-70 NOTICE swss#orchagent: :- processPriorityGroup: Set buffer PG Ethernet0:3-4 to BUFFER_PROFILE_TABLE:pg_lossless_200000_0m_profile