Dash #3
Closed
Dash #3
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
Counters are port stats and queue stats. Currently only fabric asics could be collected. J2 fabric counter collection doesn't work yet. J2 fabric port counters fail to be collected due to logical port id for fabric links is set up to 512 while SAI supports at most 256 ports. J2 fabric queue counters are not supported by SAI at this moment (BCM confirmed). Signed-off-by: Maxime Lorrillere <mlorrillere@arista.com> Signed-off-by: Maxime Lorrillere <mlorrillere@arista.com>
…#2469) * [vlanmgr] Disable `arp_evict_nocarrier` for vlan host intf
…et#2440) * [DPU] Simplify SWSS initialization to meet DPU requirements. Signed-off-by: Oleksandr Ivantsiv <oivantsiv@nvidia.com>
…ic-net#2478) *Fix unit tests compilation issue after merge from the master branch:
* swss: Add Voq counter support. * Add m_voq_ids to SystemPortInfo to maintain the list of queue ids. * Add two new tables COUNTERS_SYSTEM_PORT_NAME_MAP and COUNTERS_VOQ_NAME_MAP to enable queuestat to differentiate between Port Tx queues and Voqs. * Add a new function initializeVoqs that retrieves the number of voqs for a system port and stores the voq object ids in m_voq_ids * Add code to handle queue type SAI_QUEUE_TYPE_UNICAST_VOQ. * Initialize voqs and populate COUNTERS_SYSTEM_PORT_NAME_MAP in addSystemPorts function. * Update generateQueueMap to generate queue maps for both Txqs and Voq. For PHY ports in a voq system both Txqs and Voqs are instantiated. For Voqs of remote system port, only Voq counters are initialized.
…nic-net#2412) Signed-off-by: Mariusz Stachura <mariusz.stachura@intel.com> What I did Adding the dynamic headroom calculation support for Barefoot platforms. Why I did it Enabling dynamic mode for barefoot case. How I verified it The community tests are adjusted and pass.
…onic-net#2483) - What I did I fixed an issue that on port deletion (port breakout scenario), the port OID is not removed from saiOidToAlias map, resulting in getPort returns true when querying non-existing port OID but the Port structure is not filled with correct values. Also lowered the log level on receiving non-existing port operational status update - Why I did it To fix errors in the log during breakout: Oct 4 13:15:45.654396 r-bulldog-04 NOTICE swss#orchagent: :- updatePortOperStatus: Port oper state set from unknown to down Oct 4 13:15:45.654773 r-bulldog-04 ERR swss#orchagent: :- set: switch id oid:0x0 doesn't exist Oct 4 13:15:45.654773 r-bulldog-04 WARNING swss#orchagent: :- setHostIntfsOperStatus: Failed to set operation status DOWN to host interface Oct 4 13:15:45.654773 r-bulldog-04 ERR swss#orchagent: :- updatePortOperStatus: Failed to set host interface operational status down Oct 4 13:15:45.654773 r-bulldog-04 WARNING swss#orchagent: :- flushFDBEntries: Couldn't flush FDB. Bridge port OID: 0x0 bvid:0, - How I verified it Run UT, run manual port breakout tests. Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
…r queue/pg counters (sonic-net#2473) This reverts commit f0f1eb4. - What I did Currently, in SONiC all ports queue and pg counters are created by default with the max possible amount of counters. This feature changes this behavior to poll only configured counters provided by the config DB BUFFER_PG and BUFFER_QUEUE tables. If no tables are present in the DB, no counters will be created for ports. Filter the unwanted queues/pgs returned by SAI API calls and skip the creation of these queue/pg counters. Also, allow creating/removing counters on runtime if buffer PG/Queue is configured or removed. - Why I did it Improve performance by filtering unconfigured queue/pg counters on init. - How I verified it Check after enabling the counters, if configured counters are created in Counters DB according to the configurations. Add/Remove buffer PG/Queue configurations and observe the corresponding counters created/removed accordingly. New UT was added to verify this flow.
*[teammgr] Added LAG member check into addLagMember()
…terface (sonic-net#2504) *Fix: remove vlan interface before removing the vlan itself
…buffer pools and profiles (sonic-net#2498) Signed-off-by: Stephen Sun <stephens@nvidia.com> What I did Originally, it was assumed the names of all the buffer pools follow the community buffer pool name convention ({ingress|egress}_{lossless|lossy}_pool). The heuristic algorithm to identify buffer pools and profiles was designed based on the assumption. However, some users can define the buffer pool names in other ways, which breaks the logic in the Lua plugin and introduces degradation, the pool sizes of those pools can not be generated the additional reserved memory for lossy PG can not be calculated In this PR, the logic is improved to tolerate the case. Signed-off-by: Stephen Sun stephens@nvidia.com How I verified it Manually and regression test. It has been covered by regression test and vs test. No new test case is required. Details if related Separate the buffer pools into two tables according to the direction. Iterate all the profiles, generating and recording the type (lossless/lossy) for each ingress profile which is identified by checking the pool it references Identify buffer profiles for lossy PG by checking the type (lossless/lossy) generated in 2 instead of the hardcoded name ingress_lossy_profile
* orchagent: DASH changes * Introduce DASH specific orchs - DashOrch, DashVnetOrch and DashRouteOrch * Introduce changes to handle various DASH table schemas and operations * Changes in bulker to introduce new constructors for DASH-related Entity/Object bulkers * Changes to support new DASH tables and orchs in orchdaemon * Changes to support new DASH APIs in saihelper * Makefile changes to support compilation * References: https://github.com/Azure/DASH/blob/main/documentation/general/dash-sonic-hld.md * Verifications done: Manual testing with configurations referenced in the HLD above as well as automated vstests Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
…t#2491) - What I did Extended DVS test "--graceful-stop" flag to also stop syncd. - Why I did it So ASAN can generate reports for syncd. - How I verified it Run the tests with --graceful-stop, observe that the syncd process is stopped via SIGTERM Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com>
The cleanup code for stale rif counters are now moved to syncd . Earlier as part of fix for issue sonic-net#2193 the cleanup for stale rif counters was added. But it could create a race condition between orchagent removes RIF rate counters from DB and lua script fetching them. So as a fix all such cleanup has been moved to syncd. - What I did Fix for sonic-net/sonic-buildimage#11621 As a past fix which aimed at removing stale rif counters (sonic-net#2199) , there is a chance of race condition and it leads to lua script reporting error. To handle this , the rif counters cleanup code(handled in cleanUpRifFromCounterDb) is now called from syncd ( removeCounter ) to avoid such race condition. - Why I did it The operations in Orchagent and syncd is not synchronous, so while Orchagent deletes the rif counters from Counters Db, the syncd could still access it. In race conditions the lua script trying to fetch rif counters will have errors syslog for such access as it was already deleted by orchagent. The cleanup code is removed from orchagent is added in syncd - it will make sure no such race condition would get hit. - How I verified it Followed the steps in (sonic-net/sonic-buildimage#11621) : Create RIF in SONiC, wait till RIF rates are populated in COUNTERS DB Remove RIF Repeat the steps multiple times and check if any error syslog is seen (No error syslog is seen) Also checked cleanup for rif counters. After RIF creation derived info of oid for RIF from "COUNTERS_RIF_NAME_MAP" 127) "Vlan100" 128) "oid:0x6000000000aa5" Checked all the tabled in COUNTER_DB which has same OID in keys 127.0.0.1:6379[2]> keys 6000000000aa5 1) "RATES:oid:0x6000000000aa5:RIF" 2) "COUNTERS:oid:0x6000000000aa5" 3) "RATES:oid:0x6000000000aa5" 127.0.0.1:6379[2]> Deleted the RIF by removing the ip on the intf. Checked COUNTER_DB again with same OID if there are stale entries or not. No stale entries exist now. 127.0.0.1:6379[2]> keys 6000000000aa5 (empty array) 127.0.0.1:6379[2]> Signed-off-by: Suman Kumar <suman.kumar@broadcom.com>
Upstream new development on p4orch: *Reference count bug fix in wcmp manager. *New update in gre tunnel manager. *Bulk support in wcmp group member.
…onic-net#2493) What I did Update pfc_detect_innovium.lua Why I did it pfc_detect_innovium.lua changes for master and 202111
…c-net#2174) What I did Added function to query scheduler group objects during SWSS restart. Why I did it Scheduler group objects were removed as they were missing in temp view during SWSS restart. The triggers to reproduce this issue: sudo config warm_restart enable swss sudo service swss restart How I verified it Verified scheduler group objects are not removed after the fix and are part of ASIC_DB. Details if related Mar 1 22:46:39.015724 sonic NOTICE swss#orchagent: :- setWarmStartState: orchagent warm start state changed to restored Mar 1 22:46:39.015724 sonic NOTICE swss#orchagent: :- warmRestoreAndSyncUp: Orchagent state restore done Mar 1 22:46:39.015724 sonic NOTICE swss#orchagent: :- syncd_apply_view: Notify syncd APPLY_VIEW Mar 1 22:46:39.015724 sonic NOTICE swss#orchagent: :- notifySyncd: sending syncd: APPLY_VIEW Mar 1 22:46:39.016078 sonic WARNING syncd[24]: :- processNotifySyncd: syncd received APPLY VIEW, will translate Mar 1 22:46:39.155799 sonic NOTICE syncd[24]: :- dump: getting took 0.139421 sec Mar 1 22:46:39.172973 sonic NOTICE syncd[24]: :- getAsicView: ASIC_STATE switch count: 1: Mar 1 22:46:39.172973 sonic NOTICE syncd[24]: :- getAsicView: oid:0x21000000000000: objects count: 7529 Mar 1 22:46:39.175515 sonic NOTICE syncd[24]: :- getAsicView: get asic view from ASIC_STATE took 0.159394 sec Mar 1 22:46:39.304183 sonic NOTICE syncd[24]: :- dump: getting took 0.128388 sec Mar 1 22:46:39.318381 sonic NOTICE syncd[24]: :- getAsicView: TEMP_ASIC_STATE switch count: 1: Mar 1 22:46:39.318381 sonic NOTICE syncd[24]: :- getAsicView: oid:0x21000000000000: objects count: 7174 Mar 1 22:46:39.320676 sonic NOTICE syncd[24]: :- getAsicView: get asic view from TEMP_ASIC_STATE took 0.145098 sec Mar 1 22:46:39.412827 sonic NOTICE syncd[24]: :- ComparisonLogic: srand seed for switch oid:0x21000000000000: 1646174799 Mar 1 22:46:39.413412 sonic NOTICE syncd[24]: :- matchOids: matched oids Mar 1 22:46:39.413412 sonic NOTICE syncd[24]: :- populateExistingObjects: populate existing objects Mar 1 22:46:39.414330 sonic NOTICE syncd[24]: :- checkInternalObjects: check internal objects Mar 1 22:46:39.414519 sonic WARNING syncd[24]: :- checkInternalObjects: different number of objects SAI_OBJECT_TYPE_SCHEDULER_GROUP, curr: 321, tmp 33 (not expected if warm boot) Mar 1 22:46:39.414519 sonic ERR syncd[24]: :- checkInternalObjects: object status is not MATCHED on curr: SAI_OBJECT_TYPE_SCHEDULER_GROUP:oid:0x1700000000005e Mar 1 22:46:39.414519 sonic ERR syncd[24]: :- checkInternalObjects: object status is not MATCHED on curr: SAI_OBJECT_TYPE_SCHEDULER_GROUP:oid:0x1700000000005f Mar 1 22:46:39.414519 sonic ERR syncd[24]: :- checkInternalObjects: object status is not MATCHED on curr: SAI_OBJECT_TYPE_SCHEDULER_GROUP:oid:0x17000000000060 .. .. Mar 1 22:46:39.421248 sonic ERR syncd[24]: :- checkInternalObjects: object status is not MATCHED on curr: SAI_OBJECT_TYPE_SCHEDULER_GROUP:oid:0x1700000000034e Mar 1 22:46:39.439937 sonic NOTICE syncd[24]: :- createPreMatchMap: preMatch map size: 102, tmp oid obj: 186 Mar 1 22:46:39.439937 sonic NOTICE syncd[24]: :- createPreMatchMap: create preMatch map took 0.023570 sec Mar 1 22:46:39.441150 sonic WARNING syncd[24]: :- logViewObjectCount: object count for SAI_OBJECT_TYPE_SCHEDULER_GROUP on current view 321 is different than on temporary view: 33 Mar 1 22:46:39.443028 sonic WARNING syncd[24]: :- logViewObjectCount: object count is different on both view, there will be ASIC OPERATIONS! Mar 1 22:46:39.443028 sonic NOTICE syncd[24]: :- checkMatchedPorts: all ports are matched Mar 1 22:46:39.443082 sonic WARNING syncd[24]: :- performObjectSetTransition: current attr is CREATE_ONLY and object is MATCHED: oid:0x1000000000050 transferring SAI_PORT_ATTR_HW_LANE_LIST:4:0,1,2,3 to temp object Mar 1 22:46:39.443150 sonic WARNING syncd[24]: :- performObjectSetTransition: current attr is CREATE_ONLY and object is MATCHED: oid:0x1000000000068 transferring SAI_PORT_ATTR_HW_LANE_LIST:4:4,5,6,7 to temp object .. .. Mar 1 22:46:39.444210 sonic WARNING syncd[24]: :- performObjectSetTransition: current attr is CREATE_ONLY and object is MATCHED: oid:0x1000000000338 transferring SAI_PORT_ATTR_HW_LANE_LIST:4:124,125,126,127 to temp object Mar 1 22:46:39.516195 sonic NOTICE syncd[24]: :- applyViewTransition: loop removed 288 objects Mar 1 22:46:39.516680 sonic NOTICE syncd[24]: :- applyViewTransition: comparison logic took 0.073610 sec Mar 1 22:46:39.516680 sonic NOTICE syncd[24]: :- transferNotProcessed: calling transferNotProcessed Mar 1 22:46:39.517046 sonic NOTICE syncd[24]: :- compareViews: ASIC operations to execute: 288 Mar 1 22:46:39.517992 sonic NOTICE syncd[24]: :- compareViews: all temporary view objects were processed to FINAL state Mar 1 22:46:39.518395 sonic NOTICE syncd[24]: :- compareViews: all current view objects were processed to FINAL state Mar 1 22:46:39.518395 sonic NOTICE syncd[24]: :- executeOperationsOnAsic: operations to execute on ASIC: 288 Mar 1 22:46:39.518416 sonic NOTICE syncd[24]: :- executeOperationsOnAsic: NOT optimized operations Mar 1 22:46:39.518451 sonic NOTICE syncd[24]: :- executeOperationsOnAsic: remove: SAI_OBJECT_TYPE_SCHEDULER_GROUP:oid:0x1700000000005e Mar 1 22:46:39.518451 sonic NOTICE syncd[24]: :- executeOperationsOnAsic: remove: SAI_OBJECT_TYPE_SCHEDULER_GROUP:oid:0x1700000000005f .. .. Mar 1 22:46:39.527085 sonic NOTICE syncd[24]: :- executeOperationsOnAsic: operations on SAI_OBJECT_TYPE_SCHEDULER_GROUP: 288 Mar 1 22:46:39.527085 sonic NOTICE syncd[24]: :- asicGetWithOptimizedRemoveOperations: moved 288 REMOVE operations upper in stack from total 288 operations Mar 1 22:46:39.527118 sonic NOTICE syncd[24]: :- asicGetWithOptimizedRemoveOperations: optimizing asic remove operations took 0.000160 sec Mar 1 22:46:39.530969 sonic NOTICE syncd[24]: :- executeOperationsOnAsic: asic apply took 0.012517 sec Mar 1 22:46:39.530969 sonic NOTICE syncd[24]: :- executeOperationsOnAsic: performed all operations on asic successfully Mar 1 22:46:39.589620 sonic NOTICE syncd[24]: :- threadFunction: time span 573 ms for 'notify:APPLY_VIEW'
What I did Add Azp job for DASH. Why I did it DASH needs CLI. How I verified it Check Azp. Signed-off-by: Ze Gan <ganze718@gmail.com>
…o ENI entry (sonic-net#2514) * Added SAI_ENI_ATTR_VM_UNDERLAY_DIP and SAI_ENI_ATTR_VM_VNI attributes to support inbound routing flow Signed-off-by: Prabhat Aravind <paravind@microsoft.com>
This PR is part of the following HLD: Persistent loglevel HLD: sonic-net/SONiC#1041 - What I did Deleted the LOGLEVEL_DB. After the Logger tables moved from the LOGLEVEL_DB to the CONFIG_DB and the jinja2_cache was deleted the LOGLEVEL_DB is not in use. - How I did it Removed the LOGLEVEL_DB from the SONiC code - How to verify it All tests were passed
…c-net#2492) In case of using dplane_fpm_nl zebra plugin we receive RTM_DELROUTE followed by RTM_NEWROUTE in a single FPM message when route attributes change (i.e nexthops change). Current implementation can only read the first one and ignores the rest. What I did I fixed FPM implementation to read multiple nl messages in a single FPM message. Why I did it Trying to move towards using dplane_fpm_nl. How I verified it UT and using dplane_fpm_nl zebra plugin. Details if related
Signed-off-by: Yakiv Huryk <yhuryk@nvidia.com>
…c MAC advertisement in EVPN. (sonic-net#2521) - What I did On local MAC learning, update the MAC entry as local then delete the DST entry from the Kernel for remote MAC. This will make sure that FRR doesn't reinstall the remote MAC(#12363) When installing the static MAC in the kernel set the sticky flag as well. (#12419) - How I did it Move the DST entry delete code after the MAC update code.(#12363) Pass sticky flag to the kernel in fdbsyncd code.((#12419) - How to verify it Tested MAC move from remote to local and verified the MAC is local in Kernel.(#12363) Verified in Kernel that sticky bit is set and the same as advertised by FRR in the network.((#12419) Signed-off-by: kishore.kunal@broadcom.com
…onic-net#2503) - What I did add SAI_TUNNEL_ATTR_DECAP_TTL_MODE and SAI_TUNNEL_ATTR_DECAP_DSCP_MODE - Why I did it Need to pass additional SAI attrib. Align encap end decap params 1 SAI_TUNNEL_ATTR_DECAP_DSCP_MODE Problem: Long time ago this attribute was defined as “mandatory on create” in SAI API, but at some point it was changed to “optional”. But MLNX SAI implementation didn’t change it and still expects this attribute to be always provided on tunnel creation. SONiC “dual ToR” implementation, when it creates IP-in-IP tunnel, does not provide this attribute because it is “optional”. So we get SAI error for creating tunnel because as mentioned above MLNX SAI implementation still expects this attribute as “mandatory on create”. Need to always set this attribute in “Dual ToR orchagent” on IP-in-IP tunnel creation 2 SAI_TUNNEL_ATTR_DECAP_TTL_MODE Problem: Long time ago this attribute was defined as “mandatory on create” in SAI API, but at some point it was changed to “optional”. SONiC “dual ToR” implementation, when it creates IP-in-IP tunnel, does not provide this attribute because now it is “optional”. SAI team reported: "We only support pipe, which is not the default API value of uniform, so user must provide explicit pipe This has always been the ip in ip behavior and limitation, which is also documented in our RN" So it is MLNX SAI implementation limitation that we support only “pipe” and since default value for this attribute is “uniform” we need to set it explicitly. And in our case it is becomes “mandatory on create” attribute which must be set to “pipe” value. As a result of this limitation we should update SONiC “Dual ToR” code in order to pass this attribute on IP-in-IP tunnel creation. - How I verified it tunnel successfully created Signed-off-by: Andriy Yurkiv <ayurkiv@nvidia.com>
* Use code scanning instead of LGTM
…et#2550) * Support COUNTER action in custom ACL Signed-off-by: bingwang <bingwang@microsoft.com>
…onic-net#2529 *Add centec platform to supported platform list for port isolation group
* [muxorch] Adding case for maintaining current state What I did: Added a case where if current and previous Mux states are the same, post a log entry that acknowleges this change and returns without doing anything.
…t#2552) * generateQueueMap uses m_portList[port].m_queue_ids.size to allocate m_queueStates in FlexCounterQueueStates. But m_portList[port].m_queue_ids.size is zero for system ports which results in isQueueCounterEnabled crash for system ports. Since we do not have support disable voq counters yet, do not check isQueueCounterEnabled for voqs.
* PINS Extension tables support
…nic-net#2214) [VS] click commands usage is avoided in test_virtual_chassis.py
…bled (sonic-net#2484) What I did During port init if AutoNeg is enabled do not do GET oper on SAI_PORT_ATTR_SPEED (do not call getPortSpeed) Why I did it This PR fixes an issue where in some platforms syncd crashes when AutoNeg is enabled and port is oper down. The crash happens in the warmboot recovery path: In the target image as part of portinit, GET operation on SAI_PORT_ATTR_SPEED returns a random value. This random value does not match the speed in the base image. Diff in speed causes syncd comparison logic to attempt to set newly detected speed. Comparison logic crashes in APPLY_VIEW when doing a SET speed operation on port with the new speed. Why SAI returns random value in GET oper on SAI_PORT_ATTR_SPEED: SAI returns random value as when autoneg is enabled attribute SAI_PORT_ATTR_SPEED is not set in the first place. When autoneg is enabled a list of speeds is set using attribute SAI_PORT_ATTR_ADVERTISED_SPEED (instead of SAI_PORT_ATTR_SPEED when autoneg is not enabled. In autoneg enabled case, get oper on SAI_PORT_ATTR_SPEED is not allowed as the speed on the port is not certain, and instead depends on advertised/negotiated speed.
What I did This change adds support for setting tx tap or tuning values on gearbox ports. It uses the SAI attributes such as SAI_PORT_SERDES_ATTR_TX_FIR_PRE1 to communicate with SAI-based gearbox drivers. For the values, they are provided in the format like "system_tx_fir_pre2": [1,1] for an interface from gearbox_config.json. Why I did it How I verified it We verified that values provided in sonic-net/sonic-buildimage#10084 are set to the chip with this change. Added test to tests/test_gearbox.py. The added test will not pass until the following two changes (which should be merged first) are merged: Support SAI_PORT_ATTR_PORT_SERDES_ID on vs gearbox: sonic-net/sonic-sairedis#1082 Add gearbox taps to vs gearbox_config.json: sonic-net/sonic-buildimage#11480
What I did Let mux orch skip adding kernel tunnel routes for SoC IPs. Signed-off-by: Longxiang Lyu lolv@microsoft.com Why I did it Please refer to sonic-net/SONiC#1132 for more details. How I verified it Add unittest. Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
…ic-net#2569) What I did Skip adding ACL for active-active ports. Why I did it Please refer to the HLD for more details: sonic-net/SONiC#1180 Signed-off-by: Longxiang Lyu <lolv@microsoft.com>
* In L3/L3V6 Egress ACL, Range type qualifier is not supported for Broadcom Platforms. Check is added to ignore the range type qualifier for Broadcom platforms alone.
*Align watermark flow with port configuration correct the queue, watermark and pg-drop counterpoll functionality according to cli commands
*Deleting ACL Tables deletes all the associated Rules but it doesn't delete the associated counters.
What I did Remove TODO comments which are no longer needed Why I did it MUX support has already been removed, the TODO item is not valid How I verified it Only comment change
[VS] Fix Vlan test for the signature of wait_for_n_keys
…#2522) What I did Enable show fabric counters port command: show fabric counters port ASIC PORT STATE IN_CELL IN_OCTET OUT_CELL OUT_OCTET CRC FEC_CORRECTABLE FEC_UNCORRECTABLE SYMBOL_ERR ------ ------ ------- --------- ---------- ---------- ----------- ----- ----------------- ------------------- ------------ 0 0 up 0 0 4 740 0 3 305128 3 0 1 up 0 0 4 740 0 314 232123 245 0 2 up 0 0 4 740 0 0 265156 0 ....... Enable show fabric counters queue command : ASIC PORT STATE QUEUE_ID CURRENT_BYTE CURRENT_LEVEL WATERMARK_LEVEL ------ ------ ------- ---------- -------------- --------------- ----------------- 0 0 up 0 N/A N/A N/A 0 1 up 0 N/A N/A N/A ......
…al. (sonic-net#2575) * Update FDB state table when , MAC entries are modified as dynamic_local. * commit to trigger build again.
…e. (sonic-net#2580) Signed-off-by: siqbal1486 <shahzad.iqbal@microsoft.com> orignal PR sonic-net#2508
…net#2465) * QoS changes for VoQ on chassis
oleksandrivantsiv
force-pushed
the
dash
branch
from
87eb07c to
da91c38
Compare
… ID (sonic-net#2538) * Updated handling of VRF_VNI mapping and VLAN_VNI mapping for same VNI ID
When adding a VNET map entry (from DASH_VNET_MAPPING_TABLE), if the VNET doesn't yet exist, defer the operation and retry it later. Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
…#2571) * Fixed set mtu for deleted subintf due to late notification
oleksandrivantsiv
force-pushed
the
dash
branch
from
da91c38 to
468700e
Compare
oleksandrivantsiv
pushed a commit
that referenced
this pull request
Sep 19, 2023
**What I did**
Fix the Mem Leak by moving the raw pointers in type_maps to use smart pointers
**Why I did it**
```
Indirect leak of 83776 byte(s) in 476 object(s) allocated from:
#0 0x7f0a2a414647 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x5555590cc923 in __gnu_cxx::new_allocator, std::allocator > const, referenced_object> > >::allocate(unsigned long, void const*) /usr/include/c++/10/ext/new_allocator.h:115
#2 0x5555590cc923 in std::allocator_traits, std::allocator > const, referenced_object> > > >::allocate(std::allocator, std::allocator > const, referenced_object> > >&, unsigned long) /usr/include/c++/10/bits/alloc_traits.h:460
#3 0x5555590cc923 in std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_get_node() /usr/include/c++/10/bits/stl_tree.h:584
#4 0x5555590cc923 in std::_Rb_tree_node, std::allocator > const, referenced_object> >* std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_create_node, std::allocator > const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:634
#5 0x5555590cc923 in std::_Rb_tree_iterator, std::allocator > const, referenced_object> > std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_emplace_hint_unique, std::allocator > const&>, std::tuple<> >(std::_Rb_tree_const_iterator, std::allocator > const, referenced_object> >, std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:2461
#6 0x5555590e8757 in std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::operator[](std::__cxx11::basic_string, std::allocator > const&) /usr/include/c++/10/bits/stl_map.h:501
#7 0x5555590d48b0 in Orch::setObjectReference(std::map, std::allocator >, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*, std::less, std::allocator > >, std::allocator, std::allocator > const, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*> > >&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) orchagent/orch.cpp:450
sonic-net#8 0x5555594ff66b in QosOrch::handleQueueTable(Consumer&, std::tuple, std::allocator >, std::__cxx11::basic_string, std::allocator >, std::vector, std::allocator >, std::__cxx11::basic_string, std::allocator > >, std::allocator, std::allocator >, std::__cxx11::basic_string, std::allocator > > > > >&) orchagent/qosorch.cpp:1763
sonic-net#9 0x5555594edbd6 in QosOrch::doTask(Consumer&) orchagent/qosorch.cpp:2179
sonic-net#10 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:241
sonic-net#11 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:238
sonic-net#12 0x5555590c8743 in Consumer::execute() orchagent/orch.cpp:235
sonic-net#13 0x555559090dad in OrchDaemon::start() orchagent/orchdaemon.cpp:755
sonic-net#14 0x555558e9be25 in main orchagent/main.cpp:766
sonic-net#15 0x7f0a299b6d09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09)
```
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.
What I did
Why I did it
How I verified it
Details if related