-
Notifications
You must be signed in to change notification settings - Fork 531
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
EVPN VxLAN enhancement to support P2MP tunnel based programming for Layer2 extension #1858
Conversation
This pull request introduces 11 alerts and fixes 9 when merging 6cc06ec into df96059 - view on LGTM.com new alerts:
fixed alerts:
|
This pull request fixes 9 alerts when merging beeb58a into df96059 - view on LGTM.com fixed alerts:
|
@@ -190,11 +203,13 @@ class VxlanTunnel | |||
// Total Routes using the DIP tunnel. | |||
int getDipTunnelRefCnt(const std::string); | |||
int getDipTunnelIMRRefCnt(const std::string); | |||
int getDipTunnelIPRefCnt(const std::string); | |||
int getRemoteEndPointIPRefCnt(const std::string); |
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.
Not sure why this name change was required. The previous 2 functions have the name as getDipTunnelXXX so
I would recommend keeping it the same as earlier. IPRefcnt represented the IP routes.
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.
After this implementation there are two logics, one using DIP tunnels and anther not using it. There are some APIs that are common on both places and the current naming with DipTunnel naming will lead to confusion. So I renamed the APIs that are used commonly in both logics generically so they can be used in both flows.
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.
Sure I understand that we would like a naming common for P2P and P2MP. So it might be better to change the naming for the IMR as well as the total refcnt i.e. we can eliminate the use of DipTunnel in the name for all the common cases.
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.
Modified as suggested.
} | ||
else | ||
{ | ||
it->second.ip_refcnt++; |
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.
shouldn't the tnl_users_[remote_vtep] need to be updated here ?
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.
Both are same. auto it = tnl_users_.find(remote_vtep); -->If remote vtep exists in the map it.second will be referencing the value of tnl_users_[remote_vtep]
@srj102 I have given explanation for some review comments and the rest I have addressed in code (marked those as resolved). |
This pull request fixes 9 alerts when merging 04858de into eb79ca4 - view on LGTM.com fixed alerts:
|
@@ -804,9 +821,6 @@ void FdbOrch::doTask(Consumer& consumer) | |||
} | |||
port = tunnel_orch->getTunnelPortName(remote_ip); | |||
} | |||
|
|||
|
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.
Is this an intentional change ? By not removing this line the message will continue to remain in the m_tosync queue and be processed infinitely.
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.
That's a good catch. It got removed during a merge conflict. I have added it back.
orchagent/fdborch.cpp
Outdated
@@ -1147,7 +1161,7 @@ bool FdbOrch::addFdbEntry(const FdbEntry& entry, const string& port_name, | |||
} | |||
|
|||
/* Retry until port is member of vlan*/ | |||
if (vlan.m_members.find(port_name) == vlan.m_members.end()) | |||
if (check_vlan_member && vlan.m_members.find(port_name) == vlan.m_members.end()) |
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 see that the EvpnRemoteVnip2mpOrch::addOperation already has a call to
gPortsOrch->addVlanMember in which case I don't see why this check is required.
if we call portsorch->isVlanMember.. It should work for both P2P and P2MP ?
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.
Actually I thought of a better logic to include checks for P2P and P2MP. In P2MP scenario, the vlan member differentiator is remote IP (since only one port exists based on SIP tunnel) and thus including that in check will ensure it works in both scenarios.
orchagent/fdborch.cpp
Outdated
@@ -1121,15 +1135,15 @@ void FdbOrch::updateVlanMember(const VlanMemberUpdate& update) | |||
} | |||
|
|||
bool FdbOrch::addFdbEntry(const FdbEntry& entry, const string& port_name, | |||
FdbData fdbData) | |||
FdbData fdbData, bool check_vlan_member) |
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.
Do we need to change the API signature ? If there is a need to check for vlan member it can be done using the isDipTunnelSupported call ?
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.
Removed changes to API signature.
This pull request fixes 9 alerts when merging 9e07e78 into 62f7200 - view on LGTM.com fixed alerts:
|
@srj102 Can you please review? I have addressed your review comments. |
Thanks for taking care of the comments. Changes look good. |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
This pull request fixes 9 alerts when merging a74eb57 into 57d21e7 - view on LGTM.com fixed alerts:
|
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
orchagent/main.cpp
Outdated
@@ -643,6 +644,32 @@ int main(int argc, char **argv) | |||
orchDaemon = make_shared<FabricOrchDaemon>(&appl_db, &config_db, &state_db, chassis_app_db.get()); | |||
} | |||
|
|||
uint32_t max_tunnel_modes = 2; |
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 check if this can be moved to vxlan constructor?
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.
Done
orchagent/portsorch.cpp
Outdated
@@ -4348,8 +4406,10 @@ bool PortsOrch::addVlan(string vlan_alias) | |||
|
|||
sai_vlan_id_t vlan_id = (uint16_t)stoi(vlan_alias.substr(4)); | |||
sai_attribute_t attr; | |||
|
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.
Please keep existing changes as is
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.
Done
orchagent/portsorch.cpp
Outdated
|
||
} | ||
|
||
bool PortsOrch::addVlanMember(Port &vlan, Port &port, string &tagging_mode, string end_point_ip) |
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.
Can you check if you can keep it similar to removeVlanMember?
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.
Done
This pull request fixes 9 alerts when merging c750f17 into ef6b5d4 - view on LGTM.com fixed alerts:
|
This pull request fixes 9 alerts when merging c0631dc into fd0cafe - view on LGTM.com fixed alerts:
|
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
@srj102 Can you please reapprove? I addressed some comments from Prince and your approval got removed |
…net#1858) #### What I did Made a change for aclshow and counterpoll that adds support for ACL flex counters. DEPENDS ON: sonic-net/sonic-swss-common#533 sonic-net/sonic-sairedis#953 sonic-net#1943 HLD: sonic-net/SONiC#857 #### How I did it Modified aclshow and counterpoll and UT. #### How to verify it Together with depends PRs. Run ACL/Everflow test suite.
What I did
Added support to identify based on sai attribute capability if P2P tunnels are support and if not achieve L2 extension using P2MP tunnels. This involves adding P2MP tunnel bridgeport, remote endpoint IP combination to L2MC group in VLAN that is using combined mode.
Why I did it
Certain platforms support P2P tunnels and while few prefer using P2MP tunnels for L2 extension due to resource constraints.
How I verified it
Added VS test cases to cover all the existing scenarios using P2MP model for programming SAI.
Details if related
Refactored existing tests, to reuse the helper APIs across both P2P and P2MP.