Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: refactor
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
Change-Id: Id1801519638a9b97175847d7ed58824fb83433d6
|
|
Type: fix
This solves the ownership of vxlan-gbp tunnels. When the last reference of these goes away they need to be deleted. Currently there are two owners; gbp_itf via gef_itf and the lock held by the gbp_endpoint_location_t. The problem is that the
loc removes its reference whilst the fwd still holds the gbp_itf, and things go wrong.
This change moves the lifecycle management of the vxlan-gbp tunnel to the gbp_itf. When the last lock of the gbp_itf goes, so does the tunnel. now both the EP's loc and fwd can hold a lock on the gbp_itf and it's only removed when required.
The other change is the management of the 'user' of the gbp_itf. Since each user can enable and disable different features, it's the job of the gbp_itf to apply the combined set. determining a unique 'uesr' from the caller was near impossible, so I moved that to the gbp_itf, and return the allocated user, hence the 'handle' that encodes both user and interface.
The hash table maps from sw_if_index to pool index.
Change-Id: I4c7bf4c0e5dcf33d1c545f262365e69151febcf4
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Disable L2 BD learning for each GBP interface instead of at the bridge
level. This does not change the current behavior (learning is disabled
for all GBP interfaces) but enables turning it on selectively for future
features such as anonymous l3-out.
Type: refactor
Change-Id: Id88644277941d703600acf97d49cbc3332ae3f68
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Change-Id: I0562d597fd45c7ddcb6db42cf17d3ffb569eb140
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Id4a20066fc5be716c61a497dfcb4d00dc1dbb28d
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I15ff191ee8724a3354c074db590472db05e0652e
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Learning GBP endpoints over vxlan-gbp tunnels
Change-Id: I1db9fda5a16802d9ad8b4efd4e475614f3b21502
Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
|