You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue#
On some of SAI implementation we have seen race condition between processing ARP Reply and FDB which can cause resource leak of Nexthop in ASIC. One of scenario that can happen and need to be verifed:
a)Create of Neighbor Entry N1 for which Mac is not learnt . This will create Host Entry point to Drop Interface. One way to simulate this is by (sending ARP Reply with Multicast Source MAC)
b)Send some generic L2 Data Traffic so that Mac Learning happening so that SAI L2 thread is kept busy processing those FDB Events
c)Now create Neighbor Entry N1 entry with for which MAC will be learnt (Again Send Arp Reply)
After doing (c) first neighbor set entry gets processed and because of our artificial delay cause (b) Mac Event is processed later and this result a scenario where we crerate extra Nexthop/Neighbor resource in ASIC and does create Leak.
Another way where L2 Thread can be busy is if lot of Aging events are happening.
Ideally for ARP packet should get MAC Event processing should happen first and then Nexighbor Event processing should happen but because of race-condition between 2 thread order can change.
Expectation from test case is to try simulate this race-condition and make sure things are fine irrespective of order in which events are processed.
The text was updated successfully, but these errors were encountered:
Issue#
On some of SAI implementation we have seen race condition between processing ARP Reply and FDB which can cause resource leak of Nexthop in ASIC. One of scenario that can happen and need to be verifed:
a)Create of Neighbor Entry N1 for which Mac is not learnt . This will create Host Entry point to Drop Interface. One way to simulate this is by (sending ARP Reply with Multicast Source MAC)
b)Send some generic L2 Data Traffic so that Mac Learning happening so that SAI L2 thread is kept busy processing those FDB Events
c)Now create Neighbor Entry N1 entry with for which MAC will be learnt (Again Send Arp Reply)
After doing (c) first neighbor set entry gets processed and because of our artificial delay cause (b) Mac Event is processed later and this result a scenario where we crerate extra Nexthop/Neighbor resource in ASIC and does create Leak.
Another way where L2 Thread can be busy is if lot of Aging events are happening.
Ideally for ARP packet should get MAC Event processing should happen first and then Nexighbor Event processing should happen but because of race-condition between 2 thread order can change.
Expectation from test case is to try simulate this race-condition and make sure things are fine irrespective of order in which events are processed.
The text was updated successfully, but these errors were encountered: