Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: refactor
Change-Id: I5235bf3e9aff58af6ba2c14e8c6529c4fc9ec86c
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Type: improvement
Signed-off-by: Josh Dorsey <jdorsey@netgate.com>
Change-Id: Iee43ca9278922fc7396764b88cff1a87bcb28349
|
|
Type: fix
When registering a new FIB node type, no name was required on the API, and so no name was printed.
Signed-off-by: Neale Ranns <neale@graphiant.com>
Change-Id: I8a99cf29c194637a550061b0a5e9782ffe8b31dd
|
|
Type: refactor
Change-Id: Ie67dc579e88132ddb1ee4a34cb69f96920101772
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
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>
|
|
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>
|
|
Change-Id: I22f866bacbc9c6e3abb0405f5c5a205910cec17b
Signed-off-by: Igor Mikhailov (imichail) <imichail@cisco.com>
|
|
Change-Id: Ic69a68665dcff4e4d48803b634aa2cf234c3944b
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I085615fde1f966490f30ed5d32017b8b088cfd59
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
Change-Id: Ieb8b53977fc8484c19780941e232ee072b667de3
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
in more than one C file
Including the exports.h from multiple .c files belonging to a single plugin results in an error.
Rework the approach to require the table of function pointers to be filled in by
the initialization function.
Since the inline functions are compiled in the "caller" context,
there is no knowledge about the acl_main structure used by the ACL
plugin. To help with that, the signature of inline functions is slightly
different, taking the p_acl_main pointer as the first parameter.
That pointer is filled into the .p_acl_main field of the method
table during the initialization - since the calling of non-inline variants
would have required filling the method table, this should give
minimal headaches during the use and switch between the two methods.
Change-Id: Icb70695efa23579c46c716944838766cebc8573e
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
|
|
A poor man's flow switching or policy based rounting.
An ACL is used to match packets and is associated with a [set of] forwarding paths
that determine how to forward matched packets - collectively this association is a
'policy'.
Policies are then 'attached', in a priority order, to an interface when thaey are
encountered as an input feature. If a packet matches no policies it is forwarded
normally in the IP FIB.
This commit is used to test the "ACL-as-a-service" functionality,
which currently compiles, and the existing traffic ACL tests pass in both hash and linear modes.
Change-Id: I0b274ec9f2e645352fa898b43eb54c457e195964
Signed-off-by: Neale Ranns <nranns@cisco.com>
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Signed-off-by: Ole Troan <ot@cisco.com>
|