summaryrefslogtreecommitdiffstats
path: root/src/vnet/vxlan-gbp/vxlan_gbp.c
AgeCommit message (Collapse)AuthorFilesLines
2019-12-17vxlan geneve gtpu: fix short helpPaul Vinciguerra1-1/+1
Type: fix Change-Id: Id53eb6ed15f270d747b9831a7b585cbafe515dd2 Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
2019-07-19fib: FIB Entry trackingNeale Ranns1-8/+7
Instead of all clients directly RR sourcing the entry they are tracking, use a deidcated 'tracker' object. This tracker object is a entry delegate and a child of the entry. The clients are then children of the tracker. The benefit of this aproach is that each time a new client tracks the entry it doesn't RR source it. When an entry is sourced all its children are updated. Thus, new clients tracking an entry is O(n^2). With the tracker as indirection, the entry is sourced only once. Type: feature Change-Id: I5b80bdda6c02057152e5f721e580e786cd840a3b Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-06-18fib: fib api updatesNeale Ranns1-4/+4
Enhance the route add/del APIs to take a set of paths rather than just one. Most unicast routing protocols calcualte all the available paths in one run of the algorithm so updating all the paths at once is beneficial for the client. two knobs control the behaviour: is_multipath - if set the the set of paths passed will be added to those that already exist, otherwise the set will replace them. is_add - add or remove the set is_add=0, is_multipath=1 and an empty set, results in deleting the route. It is also considerably faster to add multiple paths at once, than one at a time: vat# ip_add_del_route 1.1.1.1/32 count 100000 multipath via 10.10.10.11 100000 routes in .572240 secs, 174751.80 routes/sec vat# ip_add_del_route 1.1.1.1/32 count 100000 multipath via 10.10.10.12 100000 routes in .528383 secs, 189256.54 routes/sec vat# ip_add_del_route 1.1.1.1/32 count 100000 multipath via 10.10.10.13 100000 routes in .757131 secs, 132077.52 routes/sec vat# ip_add_del_route 1.1.1.1/32 count 100000 multipath via 10.10.10.14 100000 routes in .878317 secs, 113854.12 routes/sec vat# ip_route_add_del 1.1.1.1/32 count 100000 multipath via 10.10.10.11 via 10.10.10.12 via 10.10.10.13 via 10.10.10.14 100000 routes in .900212 secs, 111084.93 routes/sec Change-Id: I416b93f7684745099c1adb0b33edac58c9339c1a Signed-off-by: Neale Ranns <neale.ranns@cisco.com> Signed-off-by: Ole Troan <ot@cisco.com> Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
2019-05-16init / exit function orderingDave Barach1-6/+7
The vlib init function subsystem now supports a mix of procedural and formally-specified ordering constraints. We should eliminate procedural knowledge wherever possible. The following schemes are *roughly* equivalent: static clib_error_t *init_runs_first (vlib_main_t *vm) { clib_error_t *error; ... do some stuff... if ((error = vlib_call_init_function (init_runs_next))) return error; ... } VLIB_INIT_FUNCTION (init_runs_first); and static clib_error_t *init_runs_first (vlib_main_t *vm) { ... do some stuff... } VLIB_INIT_FUNCTION (init_runs_first) = { .runs_before = VLIB_INITS("init_runs_next"), }; The first form will [most likely] call "init_runs_next" on the spot. The second form means that "init_runs_first" runs before "init_runs_next," possibly much earlier in the sequence. Please DO NOT construct sets of init functions where A before B actually means A *right before* B. It's not necessary - simply combine A and B - and it leads to hugely annoying debugging exercises when trying to switch from ad-hoc procedural ordering constraints to formal ordering constraints. Change-Id: I5e4353503bf43b4acb11a45fb33c79a5ade8426c Signed-off-by: Dave Barach <dave@barachs.net>
2019-03-28Punt InfraNeale Ranns1-2/+15
A punt/exception path that provides: 1) clients that use the infra 2) clients can create punt reasons 3) clients can register to recieve packets that are punted for a given reason to be sent to the desired node. 4) nodes which punt packets fill in the {reason,protocol} of the buffere (in the meta-data) and send to the new node "punt-dispatch" 5) punt-dispatch sends packets to the registered nodes or drops Change-Id: Ia4f144337f1387cbe585b4f375d0842aefffcde5 Signed-off-by: Neale Ranns <nranns@cisco.com>
2019-03-05VXLAN-GBP: decap checks src,dst&VNI for unicast, then checks only dst&VNI ↵Neale Ranns1-1/+3
for multicast Change-Id: I17caf3c5a2060de497c44655b66a15a2007f716b Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-11-07GBP Endpoint LearningNeale Ranns1-34/+65
Learning GBP endpoints over vxlan-gbp tunnels Change-Id: I1db9fda5a16802d9ad8b4efd4e475614f3b21502 Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
2018-10-26vxlan-gbp: On demand udp ports registrationMohsin Kazmi1-5/+39
Change-Id: I3a47c71ad3e35df47d11fed6db95019a45f3015f Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>
2018-10-23c11 safe string handling supportDave Barach1-2/+2
Change-Id: Ied34720ca5a6e6e717eea4e86003e854031b6eab Signed-off-by: Dave Barach <dave@barachs.net>
2018-09-24Trivial: Clean up some typos.Paul Vinciguerra1-5/+5
Change-Id: I085615fde1f966490f30ed5d32017b8b088cfd59 Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
2018-09-12VXLAN-GBP: use common types on the APINeale Ranns1-7/+7
Change-Id: I11ec0d7048d36c30a97d437e5b0abd05f06ab0eb Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-09-10vxlan-gbp: Add support for vxlan gbpMohsin Kazmi1-0/+1109
This patch implements vxlan with extension of group based policy support. Change-Id: I70405bf7332c02867286da8958d9652837edd3c2 Signed-off-by: Mohsin Kazmi <sykazmi@cisco.com>