-
Notifications
You must be signed in to change notification settings - Fork 525
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[fdborch] support mac update #877
Conversation
pull from origin
Signed-off-by: shine.chen <shine.chen@nephosinc.com>
@shine4chen , this is a mac-move case. Can we handle it by setting the attribute |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As comments
please add vs test cases here. |
If we set the attribute |
@jianjundong , so when were remove and add, we also get SAI_FDB_EVENT_AGED and SAI_FDB_EVENT_LEARNED as well? If so, then i'm thinking we may have some issue since you are now removing and adding and SAI events can come later. |
We don't find the result of test is not correctly. Although SAI events may be come later, SAI_FDB_EVENT_LEARNED is the last event, in theory it will add the MAC into ASIC_DB by syncd. |
Ok, Can you address the |
OK, we will do this ASAP. thanks. |
Signed-off-by: leo.li <leo.li@nephosinc.com>
Signed-off-by: shine.chen <shine.chen@nephosinc.com>
tests/test_fdb_update.py
Outdated
("SAI_FDB_ENTRY_ATTR_BRIDGE_PORT_ID", iface_2_bridge_port_id["Ethernet4"]), | ||
('SAI_FDB_ENTRY_ATTR_PACKET_ACTION', 'SAI_PACKET_ACTION_FORWARD')] | ||
) | ||
assert ok, str(extra) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you tear down all the configurations after the test is finished?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, we have add it. Pls review
Signed-off-by: leo.li <leo.li@nephosinc.com>
The vstest has been updated, please review. Thanks! |
|
@yxieca to review. I'm not very convinced on the sequencing impact it can have. For e.g, you add entry, insert to cache |
Could you add one VS test case that a |
@prsunny , If we handle it by setting the attribute SAI_FDB_ENTRY_ATTR_BRIDGE_PORT_ID if there is a change, this will result in an event SAI_FDB_EVENT_MOVE. In current codes, SAI_FDB_EVENT_MOVE is the same as SAI_FDB_EVENT_MOVE. The entry may be not exist because of the time difference between ASIC_DB and ASIC. |
@jipanyang , The FDB entry in this VS test case is already 'dynamic'. |
@jianjundong I mean the dynamic FDB which comes from syncd, not the one faked in appDB. You may find example in this link: https://github.com/Azure/sonic-swss/blob/master/tests/test_fdb_warm.py#L134 FDB processing currently has caveat of race condition, it may result in SAI failure and orchagent to exit. Would like to check this case. |
Signed-off-by: leo.li <leo.li@nephosinc.com>
@jipanyang , The corresponding VS test case has been added, please review. |
@@ -483,6 +475,11 @@ bool FdbOrch::addFdbEntry(const FdbEntry& entry, const string& port_name, const | |||
attr.value.s32 = SAI_PACKET_ACTION_FORWARD; | |||
attrs.push_back(attr); | |||
|
|||
if (m_entries.count(entry) != 0) // we already have such entries | |||
{ | |||
removeFdbEntry(entry); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest we still keep the original code location to remove the FDB entry at the entrance of this function. Other than this, the PR looks good to me.
This would undergo a change based on this PR. Does that mean, this change needs to be revisited? |
I think PR can fix the bug of MAC move. There is no conflict between PR and this modification. If we set the attribute SAI_FDB_ENTRY_ATTR_BRIDGE_PORT_ID when the port is a change, this MAC item may be not exist in SAI and ASIC, such as MAC is aged, and this will cause fail to update. |
I think in PR. mac update logic should be same as this PR. Since the dynamic mac addresses may be aged out anytime in asic/sdk. When you use SAI-mac-set API to update port , the mac address in asic chip may disappear and set operation would fail. So using the deletion and add combination is more safe operation. |
retest this please |
* [Phase 1] Multi ASIC config command changes, db_mgrator.py script updates for handing namespace. * Fixes and comment updates * Comments addressed + added support for user to input the config files per namespace also. * Updates per comments + based on the updated SonicV2Connector/ConfigDBConnector class design * Review comments update. * Help string updated for config save/reload/load
What I did
support mac update on fdborch
Why I did it
Some apps such as MCLAG need update mac address
How I verified it
test it on nephos lab
Details if related
If the FDB entry is already exist when the event is ADD, remove the entry first, then add the entry.