[QoS] Resolve an issue in the sequence where a referenced object removed and then the referencing object deleting and then re-adding #2210

stephenxs · 2022-03-30T09:41:29Z

What I did
Resolve an issue in the following scenario
Suppose object a in table A references object b in table B. When a user is going to remove items in table A and B, the notifications can be received in the following order:

The notification of removing object b
Then the notification of removing object a
And then the notification of re-adding object a
The notification of re-adding object b.

Object b can not be removed in the 1st step because it is still referenced by object a. In case the system is busy, the notification of removing a remains in m_toSync when the notification of re-adding it is coming, which results in both notifications being handled together and the reference to object b not being cleared.
As a result, notification of removing b will never be handled and remain in m_toSync forever.

Solution:

Introduce a flag pending remove indicating whether an object is about to be removed but pending on some reference.
- pending remove is set once a DEL notification is received for an object with non-zero reference.
When resolving references in step 3, a pending remove object will be skipped and the notification will remain in m_toSync.
SET operation will not be carried out in case there is a pending remove flag on the object to be set.

By doing so, when object a is re-added in step 3, it can not retrieve the dependent object b. And step 1 will be handled and drained successfully.

Why I did it
Fix bug.

How I verified it
Mock test and manually test (eg. config qos reload)

Details if related

Orch::parseReference skips a pending-remove object which it is resolving a reference.
A common logic for objects that can be referenced by other objects,
- Return task_process_status::task_need_retry when a pending-remove object is about to be created. This is to prevent step 4, which is re-adding the pending-remove object, from being executed.
- Initialize pendingRemove to false on creating an object
- Set pendingRemove to true when an object can not be removed because of non empty references

including the following objects

`BUFFER_POOL` which is handled by `BufferOrch::processBufferPool`,
`BUFFER_PROFILE` which is handled by `BufferOrch::processBufferProfile`,
`SCHEDULER` which is handled by `QosOrch::handleSchedulerTable`,
All types of QoS maps which are handled by `QosMapHandler::processWorkItem`

Remove function QosOrch::ResolveMapAndApplyToPort. I remove it in this PR because
- I have to adjust the function accordingly
- The function has never been called by any other function since 2018, which means I'm not able to cover the change in unit test. To meet the coverage requirement, I remove it.

stephenxs · 2022-03-30T16:08:31Z

Don't quite understand the coverage report. Looks like many sentences covered by the mock test were eventually identified as uncovered.
@liat-grozovik @prsunny where can I find some documents related to this coverage report? thanks

prsunny · 2022-03-30T16:52:40Z

@theasianpianist , could you please help @stephenxs with the coverage info?

stephenxs · 2022-03-31T03:55:31Z

@theasianpianist , could you please help @stephenxs with the coverage info?

Uncovered lines reported for qosorch.cpp are 117-118,164,1134,1136-1137,1260,1665,1668-1669,1671,1673-1674,1684

For line 164 and 1260, they are definitely covered by mock tests (see below backtrace). I don't understand why they were identified as uncovered.
For the rest, they are not covered.
- for 117-118, 1134,1136-1137, I enhanced mock test to cover them. it also depends on PR [QosOrch] The notifications cannot be drained in QosOrch in case the first one needs to retry #2206 to be merged
- for 1665,1668-1669,1671,1673-1674,1684, they are in a function that has never be called since 2018. I removed the function for better coverage as well as cleaning up.

Coverage of line 164:

Thread 1 "tests" hit Breakpoint 2, QosMapHandler::processWorkItem (this=<optimized out>, consumer=...) at ../../orchagent/qosorch.cpp:164
164                 (*(QosOrch::getTypeMap()[qos_map_type_name]))[qos_object_name].m_pendingRemove = true;
(gdb) bt
#0  QosMapHandler::processWorkItem (this=<optimized out>, consumer=...) at ../../orchagent/qosorch.cpp:164
#1  0x0000555555759d1f in QosOrch::handleDscpToTcTable (this=<optimized out>, consumer=...) at ../../orchagent/qosorch.cpp:335
#2  0x0000555555758870 in QosOrch::doTask (this=0x555555bb2580, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#3  0x0000555555758b47 in QosOrch::doTask (this=<optimized out>) at ../../orchagent/qosorch.cpp:1887
#4  0x00005555556678fe in qosorch_test::QosOrchTest_QosOrchTestPortQosMapRemoveOneField_Test::TestBody (this=0x555555c7cac0) at qosorch_ut.cpp:441

Coverage of L1260

Thread 1 "tests" hit Breakpoint 4, QosOrch::handleSchedulerTable (this=0x555555bb2580, consumer=...) at ../../orchagent/qosorch.cpp:1260
1260                (*(m_qos_maps[qos_map_type_name]))[qos_object_name].m_pendingRemove = true;
(gdb) bt
#0  QosOrch::handleSchedulerTable (this=0x555555bb2580, consumer=...) at ../../orchagent/qosorch.cpp:1260
#1  0x0000555555758870 in QosOrch::doTask (this=0x555555bb2580, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#2  0x0000555555758b47 in QosOrch::doTask (this=<optimized out>) at ../../orchagent/qosorch.cpp:1887
#3  0x00005555556697c3 in qosorch_test::QosOrchTest_QosOrchTestQueueRemoveScheduler_Test::TestBody (this=0x555555c36230) at qosorch_ut.cpp:538

theasianpianist · 2022-03-31T18:51:24Z

@stephenxs I'm looking in to the coverage discrepancies, hope to have it resolved soon. Don't believe it's a problem on your end.

Signed-off-by: Stephen Sun <stephens@nvidia.com>

…r to retry Signed-off-by: Stephen Sun <stephens@nvidia.com>

Signed-off-by: Stephen Sun <stephens@nvidia.com>

Cover the case where a referenced object is created when it is pending remove Signed-off-by: Stephen Sun <stephens@nvidia.com>

…nce 2018 Signed-off-by: Stephen Sun <stephens@nvidia.com>

Signed-off-by: Stephen Sun <stephens@nvidia.com>

stephenxs · 2022-04-02T22:29:35Z

/azpw run

mssonicbld · 2022-04-02T22:29:36Z

/AzurePipelines run

azure-pipelines · 2022-04-02T22:29:47Z

Azure Pipelines successfully started running 1 pipeline(s).

stephenxs · 2022-04-04T14:48:35Z

Mock test has been added for buffer orch. Now all the changes have been covered

liat-grozovik · 2022-04-04T16:43:53Z

@neethajohn could you please help to review?

liat-grozovik · 2022-04-08T12:00:32Z

@theasianpianist, @neethajohn could you please help to signoff?

orchagent/orch.cpp

orchagent/qosorch.cpp

neethajohn · 2022-04-13T20:24:30Z

LGTM. but code coverage still fails

Signed-off-by: Stephen Sun <stephens@nvidia.com>

stephenxs · 2022-04-14T11:22:33Z

/azpw run

mssonicbld · 2022-04-14T11:22:34Z

/AzurePipelines run

azure-pipelines · 2022-04-14T11:22:44Z

Azure Pipelines successfully started running 1 pipeline(s).

stephenxs · 2022-04-15T02:44:30Z

@theasianpianist
I noticed the coverage was identified as 43% but all the changes have been covered by the mocked tests.
Is there anything I can do to overcome the issue or can we merge the PR without coverage identified as "meet"?
Thanks.

stephenxs · 2022-04-15T02:59:41Z

List of the coverage of all the code changes (by gdb)

Thread 1 "tests" hit Breakpoint 3, BufferOrch::processBufferPool (this=0x555555cb33b0, tuple=std::tuple containing = {...})
    at ../../orchagent/bufferorch.cpp:573
573                 (*(m_buffer_type_maps[map_type_name]))[object_name].m_pendingRemove = false;
(gdb) bt
#0  BufferOrch::processBufferPool (this=0x555555cb33b0, tuple=std::tuple containing = {...}) at ../../orchagent/bufferorch.cpp:573
#1  0x00005555557710ac in BufferOrch::doTask (this=0x555555cb33b0, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#2  0x000055555577149d in BufferOrch::doTask (this=0x555555cb33b0) at /usr/include/c++/8/bits/stl_tree.h:285
#3  0x00005555556524ce in portsorch_test::PortsOrchTest_PortReadinessColdBoot_Test::TestBody (this=0x555555ca07f0) at portsorch_ut.cpp:360


Thread 1 "tests" hit Breakpoint 6, BufferOrch::processBufferProfile (this=0x555555cb33b0, tuple=std::tuple containing = {...})
    at ../../orchagent/bufferorch.cpp:802
802                 (*(m_buffer_type_maps[map_type_name]))[object_name].m_pendingRemove = false;
(gdb) bt
#0  BufferOrch::processBufferProfile (this=0x555555cb33b0, tuple=std::tuple containing = {...}) at ../../orchagent/bufferorch.cpp:802
#1  0x00005555557710ac in BufferOrch::doTask (this=0x555555cb33b0, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#2  0x00005555557714ad in BufferOrch::doTask (this=0x555555cb33b0) at /usr/include/c++/8/bits/stl_tree.h:285
#3  0x00005555556524ce in portsorch_test::PortsOrchTest_PortReadinessColdBoot_Test::TestBody (this=0x555555ca07f0) at portsorch_ut.cpp:360


Thread 1 "tests" hit Breakpoint 7, BufferOrch::processBufferProfile (this=0x555555c31840, tuple=...) at ../../orchagent/bufferorch.cpp:815
815                 (*(m_buffer_type_maps[map_type_name]))[object_name].m_pendingRemove = true;
(gdb) bt
#0  BufferOrch::processBufferProfile (this=0x555555c31840, tuple=...) at ../../orchagent/bufferorch.cpp:815
#1  0x00005555557710ac in BufferOrch::doTask (this=0x555555c31840, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#2  0x00005555557714ad in BufferOrch::doTask (this=0x555555c31840) at /usr/include/c++/8/bits/stl_tree.h:285
#3  0x00005555556801d7 in bufferorch_test::BufferOrchTest_BufferOrchTestBufferPgReferencingObjRemoveThenAdd_Test::TestBody (this=0x555555cdf0c0) at bufferorch_ut.cpp:299


Thread 1 "tests" hit Breakpoint 5, BufferOrch::processBufferProfile (this=0x555555e35610, tuple=std::tuple containing = {...})
    at ../../orchagent/bufferorch.cpp:659
659                 SWSS_LOG_NOTICE("Entry %s %s is pending remove, need retry", map_type_name.c_str(), object_name.c_str());
(gdb) bt
#0  BufferOrch::processBufferProfile (this=0x555555e35610, tuple=std::tuple containing = {...}) at ../../orchagent/bufferorch.cpp:659
#1  0x00005555557710ac in BufferOrch::doTask (this=0x555555e35610, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#2  0x00005555557714ad in BufferOrch::doTask (this=0x555555e35610) at /usr/include/c++/8/bits/stl_tree.h:285
#3  0x00005555556814aa in bufferorch_test::BufferOrchTest_BufferOrchTestReferencingObjRemoveThenAdd_Test::TestBody (this=0x555555d00330)
    at bufferorch_ut.cpp:373


Thread 1 "tests" hit Breakpoint 4, BufferOrch::processBufferPool (this=0x555555e35610, tuple=std::tuple containing = {...})
    at ../../orchagent/bufferorch.cpp:588
588                 (*(m_buffer_type_maps[map_type_name]))[object_name].m_pendingRemove = true;
(gdb) bt
#0  BufferOrch::processBufferPool (this=0x555555e35610, tuple=std::tuple containing = {...}) at ../../orchagent/bufferorch.cpp:588
#1  0x00005555557710ac in BufferOrch::doTask (this=0x555555e35610, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#2  0x000055555577149d in BufferOrch::doTask (this=0x555555e35610) at /usr/include/c++/8/bits/stl_tree.h:285
#3  0x00005555556819a0 in bufferorch_test::BufferOrchTest_BufferOrchTestReferencingObjRemoveThenAdd_Test::TestBody (this=0x555555d00330) at bufferorch_ut.cpp:396

Thread 1 "tests" hit Breakpoint 2, BufferOrch::processBufferPool (this=0x555555e35610, tuple=std::tuple containing = {...})
    at ../../orchagent/bufferorch.cpp:394
394                 SWSS_LOG_NOTICE("Entry %s %s is pending remove, need retry", map_type_name.c_str(), object_name.c_str());
(gdb) bt
#0  BufferOrch::processBufferPool (this=0x555555e35610, tuple=std::tuple containing = {...}) at ../../orchagent/bufferorch.cpp:394
#1  0x00005555557710ac in BufferOrch::doTask (this=0x555555e35610, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#2  0x000055555577149d in BufferOrch::doTask (this=0x555555e35610) at /usr/include/c++/8/bits/stl_tree.h:285
#3  0x00005555556819a0 in bufferorch_test::BufferOrchTest_BufferOrchTestReferencingObjRemoveThenAdd_Test::TestBody (this=0x555555d00330) at bufferorch_ut.cpp:396


Thread 1 "tests" hit Breakpoint 8, Orch::parseReference (this=<optimized out>, type_maps=std::map with 13 elements = {...}, ref_in="AZURE",
    type_name="DSCP_TO_TC_MAP", object_name="") at ../../orchagent/orch.cpp:362
362             SWSS_LOG_NOTICE("map:%s contains a pending removed object %s, skip\n", type_name.c_str(), ref_in.c_str());
(gdb) bt
#0  Orch::parseReference (this=<optimized out>, type_maps=std::map with 13 elements = {...}, ref_in="AZURE", type_name="DSCP_TO_TC_MAP", object_name="")
    at ../../orchagent/orch.cpp:362
#1  0x00005555556b9998 in Orch::resolveFieldRefValue (this=this@entry=0x555555d92150, type_maps=std::map with 13 elements = {...},
    field_name="dscp_to_tc_map", ref_type_name="DSCP_TO_TC_MAP", tuple=std::tuple containing = {...}, sai_object=@0x7fffffffd840: 140737488345168,
    referenced_object_name="") at ../../orchagent/orch.cpp:392
#2  0x000055555576e136 in QosOrch::handlePortQosMapTable (this=0x555555d92150, consumer=..., tuple=std::tuple containing = {...})
    at /usr/include/c++/8/bits/basic_string.h:390
#3  0x0000555555769844 in QosOrch::doTask (this=0x555555d92150, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#4  0x0000555555769b5d in QosOrch::doTask (this=<optimized out>) at ../../orchagent/qosorch.cpp:1813
#5  0x0000555555675824 in qosorch_test::QosOrchTest_QosOrchTestPortQosMapReferencingObjRemoveThenAdd_Test::TestBody (this=0x555555c93b60) at qosorch_ut.cpp:801


Thread 1 "tests" hit Breakpoint 1, QosMapHandler::processWorkItem (this=0x7fffffffd128, consumer=..., tuple=...) at ../../orchagent/qosorch.cpp:146
146                 (*(QosOrch::getTypeMap()[qos_map_type_name]))[qos_object_name].m_pendingRemove = false;
(gdb) bt
#0  QosMapHandler::processWorkItem (this=0x7fffffffd128, consumer=..., tuple=...) at ../../orchagent/qosorch.cpp:146
#1  0x000055555576ab17 in QosOrch::handleDscpToTcTable (this=<optimized out>, consumer=..., tuple=std::tuple containing = {...})
    at ../../orchagent/qosorch.cpp:333
#2  0x0000555555769844 in QosOrch::doTask (this=0x555555d92150, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#3  0x0000555555769b17 in QosOrch::doTask (this=<optimized out>) at ../../orchagent/qosorch.cpp:1810
#4  0x000055555567d7a2 in qosorch_test::QosOrchTest::SetUp (this=<optimized out>) at qosorch_ut.cpp:370


Thread 1 "tests" hit Breakpoint 2, QosOrch::handleSchedulerTable (this=0x555555d92150, consumer=..., tuple=...) at ../../orchagent/qosorch.cpp:1243
1243                (*(m_qos_maps[qos_map_type_name]))[qos_object_name].m_pendingRemove = false;
(gdb) bt
#0  QosOrch::handleSchedulerTable (this=0x555555d92150, consumer=..., tuple=...) at ../../orchagent/qosorch.cpp:1243
#1  0x0000555555769844 in QosOrch::doTask (this=0x555555d92150, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#2  0x0000555555769b17 in QosOrch::doTask (this=<optimized out>) at ../../orchagent/qosorch.cpp:1810
#3  0x000055555567d7a2 in qosorch_test::QosOrchTest::SetUp (this=<optimized out>) at qosorch_ut.cpp:370


Thread 1 "tests" hit Breakpoint 2, QosMapHandler::processWorkItem (this=<optimized out>, consumer=..., tuple=...) at ../../orchagent/qosorch.cpp:162
162                 (*(QosOrch::getTypeMap()[qos_map_type_name]))[qos_object_name].m_pendingRemove = true;
(gdb) bt
#0  QosMapHandler::processWorkItem (this=<optimized out>, consumer=..., tuple=...) at ../../orchagent/qosorch.cpp:162
#1  0x000055555576ab17 in QosOrch::handleDscpToTcTable (this=<optimized out>, consumer=..., tuple=std::tuple containing = {...})
    at ../../orchagent/qosorch.cpp:333
#2  0x0000555555769844 in QosOrch::doTask (this=0x555555d92150, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#3  0x0000555555769b17 in QosOrch::doTask (this=<optimized out>) at ../../orchagent/qosorch.cpp:1810
#4  0x000055555566ea8e in qosorch_test::QosOrchTest_QosOrchTestPortQosMapRemoveOneField_Test::TestBody (this=0x555555c963a0) at qosorch_ut.cpp:441


Thread 1 "tests" hit Breakpoint 4, QosOrch::handleSchedulerTable (this=0x555555d92150, consumer=..., tuple=std::tuple containing = {...})
    at ../../orchagent/qosorch.cpp:1257
1257                (*(m_qos_maps[qos_map_type_name]))[qos_object_name].m_pendingRemove = true;
(gdb) bt
#0  QosOrch::handleSchedulerTable (this=0x555555d92150, consumer=..., tuple=std::tuple containing = {...}) at ../../orchagent/qosorch.cpp:1257
#1  0x0000555555769844 in QosOrch::doTask (this=0x555555d92150, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#2  0x0000555555769b17 in QosOrch::doTask (this=<optimized out>) at ../../orchagent/qosorch.cpp:1810
#3  0x0000555555670b10 in qosorch_test::QosOrchTest_QosOrchTestQueueRemoveScheduler_Test::TestBody (this=0x555555d04020) at qosorch_ut.cpp:538


Thread 1 "tests" hit Breakpoint 1, QosMapHandler::processWorkItem (this=0x7fffffffdc58, consumer=..., tuple=std::tuple containing = {...})
    at ../../orchagent/qosorch.cpp:115
115                 SWSS_LOG_NOTICE("Entry %s %s is pending remove, need retry", qos_map_type_name.c_str(), qos_object_name.c_str());
(gdb) bt
#0  QosMapHandler::processWorkItem (this=0x7fffffffdc58, consumer=..., tuple=std::tuple containing = {...}) at ../../orchagent/qosorch.cpp:115
#1  0x000055555576ab17 in QosOrch::handleDscpToTcTable (this=<optimized out>, consumer=..., tuple=std::tuple containing = {...})
    at ../../orchagent/qosorch.cpp:333
#2  0x0000555555769844 in QosOrch::doTask (this=0x555555d92150, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#3  0x0000555555769b17 in QosOrch::doTask (this=<optimized out>) at ../../orchagent/qosorch.cpp:1810
#4  0x0000555555675dd3 in qosorch_test::QosOrchTest_QosOrchTestPortQosMapReferencingObjRemoveThenAdd_Test::TestBody (this=0x555555c93b60) at qosorch_ut.cpp:836


Thread 1 "tests" hit Breakpoint 3, QosOrch::handleSchedulerTable (this=0x555555d92150, consumer=..., tuple=std::tuple containing = {...})
    at ../../orchagent/qosorch.cpp:1133
1133                SWSS_LOG_NOTICE("Entry %s %s is pending remove, need retry", qos_map_type_name.c_str(), qos_object_name.c_str());
(gdb) bt
#0  QosOrch::handleSchedulerTable (this=0x555555d92150, consumer=..., tuple=std::tuple containing = {...}) at ../../orchagent/qosorch.cpp:1133
#1  0x0000555555769844 in QosOrch::doTask (this=0x555555d92150, consumer=...) at /usr/include/c++/8/bits/basic_string.h:936
#2  0x0000555555769b17 in QosOrch::doTask (this=<optimized out>) at ../../orchagent/qosorch.cpp:1810
#3  0x0000555555677518 in qosorch_test::QosOrchTest_QosOrchTestQueueReferencingObjRemoveThenAdd_Test::TestBody (this=0x555555cc8800) at qosorch_ut.cpp:922

liat-grozovik · 2022-04-18T06:01:41Z

as discussed offline, coverage is ok for new code and the error is on different test. not relevant for these changes.

…ved and then the referencing object deleting and then re-adding (#2210) - What I did Resolve an issue in the following scenario Suppose object a in table A references object b in table B. When a user is going to remove items in table A and B, the notifications can be received in the following order: The notification of removing object b Then the notification of removing object a And then the notification of re-adding object a The notification of re-adding object b. Object b can not be removed in the 1st step because it is still referenced by object a. In case the system is busy, the notification of removing a remains in m_toSync when the notification of re-adding it is coming, which results in both notifications being handled together and the reference to object b not being cleared. As a result, notification of removing b will never be handled and remain in m_toSync forever. Solution: Introduce a flag pending remove indicating whether an object is about to be removed but pending on some reference. pending remove is set once a DEL notification is received for an object with non-zero reference. When resolving references in step 3, a pending remove object will be skipped and the notification will remain in m_toSync. SET operation will not be carried out in case there is a pending remove flag on the object to be set. By doing so, when object a is re-added in step 3, it can not retrieve the dependent object b. And step 1 will be handled and drained successfully. - Why I did it Fix bug. - How I verified it Mock test and manually test (eg. config qos reload) Signed-off-by: Stephen Sun <stephens@nvidia.com>

…ved and then the referencing object deleting and then re-adding (sonic-net#2210) - What I did Resolve an issue in the following scenario Suppose object a in table A references object b in table B. When a user is going to remove items in table A and B, the notifications can be received in the following order: The notification of removing object b Then the notification of removing object a And then the notification of re-adding object a The notification of re-adding object b. Object b can not be removed in the 1st step because it is still referenced by object a. In case the system is busy, the notification of removing a remains in m_toSync when the notification of re-adding it is coming, which results in both notifications being handled together and the reference to object b not being cleared. As a result, notification of removing b will never be handled and remain in m_toSync forever. Solution: Introduce a flag pending remove indicating whether an object is about to be removed but pending on some reference. pending remove is set once a DEL notification is received for an object with non-zero reference. When resolving references in step 3, a pending remove object will be skipped and the notification will remain in m_toSync. SET operation will not be carried out in case there is a pending remove flag on the object to be set. By doing so, when object a is re-added in step 3, it can not retrieve the dependent object b. And step 1 will be handled and drained successfully. - Why I did it Fix bug. - How I verified it Mock test and manually test (eg. config qos reload) Signed-off-by: Stephen Sun <stephens@nvidia.com>

stephenxs requested a review from prsunny as a code owner March 30, 2022 09:41

stephenxs requested a review from neethajohn March 30, 2022 09:42

stephenxs added the Bug 🐛 label Mar 30, 2022

keboliu previously approved these changes Mar 30, 2022

View reviewed changes

stephenxs dismissed keboliu’s stale review via a728183 March 31, 2022 03:48

stephenxs added 6 commits April 1, 2022 07:55

Handle the case that a DEL followed by a ADD

23fe3a5

Signed-off-by: Stephen Sun <stephens@nvidia.com>

Skip a pending remove object when parsing reference and ask the calle…

c5e5b82

…r to retry Signed-off-by: Stephen Sun <stephens@nvidia.com>

Add mock test

595dcd9

Signed-off-by: Stephen Sun <stephens@nvidia.com>

Enhance mock test

46e312b

Signed-off-by: Stephen Sun <stephens@nvidia.com>

Add mock test for better coverage

eb7eeb6

Cover the case where a referenced object is created when it is pending remove Signed-off-by: Stephen Sun <stephens@nvidia.com>

Remove function ResolveMapAndApplyToPort which has never been used si…

8713aaa

…nce 2018 Signed-off-by: Stephen Sun <stephens@nvidia.com>

stephenxs force-pushed the fix-add-del-seq branch from a728183 to 8713aaa Compare April 1, 2022 00:09

stephenxs requested a review from keboliu April 1, 2022 01:31

Add mock test for buffer orch to meet the coverage requirement

d377248

Signed-off-by: Stephen Sun <stephens@nvidia.com>

stephenxs added the Request for 202111 Branch label Apr 4, 2022

neethajohn reviewed Apr 13, 2022

View reviewed changes

orchagent/orch.cpp Show resolved Hide resolved

orchagent/qosorch.cpp Show resolved Hide resolved

Remove applyMapToPort which is not called after ResolveMapAndAddToPort

9bf087a

Signed-off-by: Stephen Sun <stephens@nvidia.com>

neethajohn approved these changes Apr 14, 2022

View reviewed changes

Merge branch 'Azure:master' into fix-add-del-seq

d4c4484

liat-grozovik merged commit d8fadc6 into sonic-net:master Apr 18, 2022

stephenxs deleted the fix-add-del-seq branch April 18, 2022 06:18

judyjoseph added the Included in 202111 Branch label Apr 25, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[QoS] Resolve an issue in the sequence where a referenced object removed and then the referencing object deleting and then re-adding #2210

[QoS] Resolve an issue in the sequence where a referenced object removed and then the referencing object deleting and then re-adding #2210

stephenxs commented Mar 30, 2022 •

edited

Loading

stephenxs commented Mar 30, 2022

prsunny commented Mar 30, 2022

stephenxs commented Mar 31, 2022

theasianpianist commented Mar 31, 2022

stephenxs commented Apr 2, 2022

mssonicbld commented Apr 2, 2022

azure-pipelines bot commented Apr 2, 2022

stephenxs commented Apr 4, 2022

liat-grozovik commented Apr 4, 2022

liat-grozovik commented Apr 8, 2022

neethajohn commented Apr 13, 2022

stephenxs commented Apr 14, 2022

mssonicbld commented Apr 14, 2022

azure-pipelines bot commented Apr 14, 2022

stephenxs commented Apr 15, 2022

stephenxs commented Apr 15, 2022

liat-grozovik commented Apr 18, 2022

[QoS] Resolve an issue in the sequence where a referenced object removed and then the referencing object deleting and then re-adding #2210

[QoS] Resolve an issue in the sequence where a referenced object removed and then the referencing object deleting and then re-adding #2210

Conversation

stephenxs commented Mar 30, 2022 • edited Loading

stephenxs commented Mar 30, 2022

prsunny commented Mar 30, 2022

stephenxs commented Mar 31, 2022

theasianpianist commented Mar 31, 2022

stephenxs commented Apr 2, 2022

mssonicbld commented Apr 2, 2022

azure-pipelines bot commented Apr 2, 2022

stephenxs commented Apr 4, 2022

liat-grozovik commented Apr 4, 2022

liat-grozovik commented Apr 8, 2022

neethajohn commented Apr 13, 2022

stephenxs commented Apr 14, 2022

mssonicbld commented Apr 14, 2022

azure-pipelines bot commented Apr 14, 2022

stephenxs commented Apr 15, 2022

stephenxs commented Apr 15, 2022

liat-grozovik commented Apr 18, 2022

stephenxs commented Mar 30, 2022 •

edited

Loading