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:
|
| 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.
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.
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.
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.
Modified as suggested.
| } | ||
| else | ||
| { | ||
| it->second.ip_refcnt++; |
There was a problem hiding this comment.
shouldn't the tnl_users_[remote_vtep] need to be updated here ?
There was a problem hiding this comment.
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:
|
| port = tunnel_orch->getTunnelPortName(remote_ip); | ||
| } | ||
|
|
||
|
|
There was a problem hiding this comment.
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.
That's a good catch. It got removed during a merge conflict. I have added it back.
orchagent/fdborch.cpp
Outdated
|
|
||
| /* 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.
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.
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
|
|
||
| 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.
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.
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
| 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.
Could you check if this can be moved to vxlan constructor?
orchagent/portsorch.cpp
Outdated
|
|
||
| sai_vlan_id_t vlan_id = (uint16_t)stoi(vlan_alias.substr(4)); | ||
| sai_attribute_t attr; | ||
|
|
There was a problem hiding this comment.
Please keep existing changes as is
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.
Can you check if you can keep it similar to removeVlanMember?
|
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.
…ayer2 extension (sonic-net#1858) * Vxlan evpn p2mp changes for Layer2 functionality
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.