Fork Sync: Update from parent repository#4
Merged
github-actions[bot] merged 4 commits intobradh352:master-broadcomfrom Nov 20, 2024
Merged
Fork Sync: Update from parent repository#4github-actions[bot] merged 4 commits intobradh352:master-broadcomfrom
github-actions[bot] merged 4 commits intobradh352:master-broadcomfrom
Conversation
* Applied changes from PR #1817 Why I did it Unlock erspan capability on td3 and beyond that supports erspan ipv6 encap. What I did Extend test_MirrorAddSetRemove, test_MirrorToVlanAddRemove, test_MirrorToLagAddRemove, test_MirrorDestMoveVlan, test_MirrorDestMoveLag to vs test erspan ipv6 encap On td3
What I did asic type checks for innovium platforms renamed innovium to marvell-teralynx Why I did it asictype is being renamed in sonic-buildimage repo and hence respective platform checks needs changes in swss
#3307) What I did This PR adds the logical table UNDERLAY_SET_DSCP and UNDERLAY_SET_DSCPV6. This feature allows SONIC to match an ingress L4 packet and change the DSCP field of the outer header when the packet is egressing. These tables are only created on Cisco-8000, Mlnx and VS platforms. The PR also adds support to check if the platform supports the following SAI attributes. SAI_SWITCH_ATTR_ACL_USER_META_DATA_RANGE SAI_ACL_ENTRY_ATTR_ACTION_SET_ACL_META_DATA SAI_ACL_ENTRY_ATTR_FIELD_ACL_USER_META
What I did When grabbing the second route group OID, ensure that it is distinct from the first route group OID Why I did it The order in which DB keys are returned is not deterministic, so blindly taking the last key returned will sometimes lead to selecting the wrong OID
github-actions bot
pushed a commit
that referenced
this pull request
Feb 21, 2025
…tries in gRouteBulker (sonic-net#3526) <!-- Please make sure you have read and understood the contribution guildlines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md 1. Make sure your commit includes a signature generted with `git commit -s` 2. Make sure your commit title follows the correct format: [component]: description 3. Make sure your commit message contains enough details about the change and related tests 4. Make sure your pull request adds related reviewers, asignees, labels Please also provide the following information in this pull request: --> **What I did** Avoid removing a VRF routing table when there are pending creation entries in gRouteBulker 1. Remove a VRF routing table when a routing entry is removed only if there is no pending creation entry in gRouteBulker 2. Avoid uninitialized value SAI IP address/prefix structure **Why I did it** Fix issue: out of range exception can be thrown in `addRoutePost` due to non exist VRF ``` (gdb) bt #0 0x00007f5791aedebc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f5791a9efb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007f5791a89472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007f5791de0919 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x00007f5791debe1a in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x00007f5791debe85 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x00007f5791dec0d8 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6 #7 0x00007f5791de3240 in std::__throw_out_of_range(char const*) () from /lib/x86_64-linux-gnu/libstdc++.so.6 #8 0x00005594e856d956 in std::map<unsigned long, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > >, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > > > > >::at (this=<optimized out>, __k=<optimized out>) at /usr/include/c++/12/bits/stl_map.h:551 #9 0x00005594e8564beb in RouteOrch::addRoutePost (this=this@entry=0x5594ea13e080, ctx=..., nextHops=...) at ./orchagent/routeorch.cpp:2145 #10 0x00005594e856b0b2 in RouteOrch::doTask (this=0x5594ea13e080, consumer=...) at ./orchagent/routeorch.cpp:1021 #11 0x00005594e85282d2 in Orch::doTask (this=0x5594ea13e080) at ./orchagent/orch.cpp:553 #12 0x00005594e851909a in OrchDaemon::start (this=this@entry=0x5594ea0a0950) at ./orchagent/orchdaemon.cpp:895 #13 0x00005594e8485632 in main (argc=<optimized out>, argv=<optimized out>) at ./orchagent/main.cpp:818 ``` **How I verified it** Unit (mock) test **Details if related** Originally, it cleaned up a VRF routing table whenever a prefix of the VRF was removed if 1. there was no routing entry in the VRF routing table and 2. the prefix was not pending creation in gRouteBulker The motivation is to remove a VRF routing table if there is no routing entry in the VRF and no routing entry pending creation for that VRF. However, condition 2 does not guarantee that. The ideal way of the 2nd condition is to check pending creation entries of a certain VRF, which we can not do. So, we are using strict conditions here as the following: 1. there is no routing entry in the VRF routing table and 2. there is no pending creating routing entry in gRouteBulker regardless of which VRF it belongs to
bradh352
pushed a commit
that referenced
this pull request
May 3, 2025
…tries in gRouteBulker (sonic-net#3526) <!-- Please make sure you have read and understood the contribution guildlines: https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md 1. Make sure your commit includes a signature generted with `git commit -s` 2. Make sure your commit title follows the correct format: [component]: description 3. Make sure your commit message contains enough details about the change and related tests 4. Make sure your pull request adds related reviewers, asignees, labels Please also provide the following information in this pull request: --> **What I did** Avoid removing a VRF routing table when there are pending creation entries in gRouteBulker 1. Remove a VRF routing table when a routing entry is removed only if there is no pending creation entry in gRouteBulker 2. Avoid uninitialized value SAI IP address/prefix structure **Why I did it** Fix issue: out of range exception can be thrown in `addRoutePost` due to non exist VRF ``` (gdb) bt #0 0x00007f5791aedebc in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f5791a9efb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007f5791a89472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007f5791de0919 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x00007f5791debe1a in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x00007f5791debe85 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x00007f5791dec0d8 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6 #7 0x00007f5791de3240 in std::__throw_out_of_range(char const*) () from /lib/x86_64-linux-gnu/libstdc++.so.6 #8 0x00005594e856d956 in std::map<unsigned long, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > >, std::less<unsigned long>, std::allocator<std::pair<unsigned long const, std::map<swss::IpPrefix, RouteNhg, std::less<swss::IpPrefix>, std::allocator<std::pair<swss::IpPrefix const, RouteNhg> > > > > >::at (this=<optimized out>, __k=<optimized out>) at /usr/include/c++/12/bits/stl_map.h:551 #9 0x00005594e8564beb in RouteOrch::addRoutePost (this=this@entry=0x5594ea13e080, ctx=..., nextHops=...) at ./orchagent/routeorch.cpp:2145 #10 0x00005594e856b0b2 in RouteOrch::doTask (this=0x5594ea13e080, consumer=...) at ./orchagent/routeorch.cpp:1021 #11 0x00005594e85282d2 in Orch::doTask (this=0x5594ea13e080) at ./orchagent/orch.cpp:553 #12 0x00005594e851909a in OrchDaemon::start (this=this@entry=0x5594ea0a0950) at ./orchagent/orchdaemon.cpp:895 #13 0x00005594e8485632 in main (argc=<optimized out>, argv=<optimized out>) at ./orchagent/main.cpp:818 ``` **How I verified it** Unit (mock) test **Details if related** Originally, it cleaned up a VRF routing table whenever a prefix of the VRF was removed if 1. there was no routing entry in the VRF routing table and 2. the prefix was not pending creation in gRouteBulker The motivation is to remove a VRF routing table if there is no routing entry in the VRF and no routing entry pending creation for that VRF. However, condition 2 does not guarantee that. The ideal way of the 2nd condition is to check pending creation entries of a certain VRF, which we can not do. So, we are using strict conditions here as the following: 1. there is no routing entry in the VRF routing table and 2. there is no pending creating routing entry in gRouteBulker regardless of which VRF it belongs to
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
No description provided.