summaryrefslogtreecommitdiffstats
path: root/src/vnet/adj/adj_bfd.c
AgeCommit message (Collapse)AuthorFilesLines
2019-05-16init / exit function orderingDave Barach1-7/+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-28Typos. A bunch of typos I've been collecting.Paul Vinciguerra1-5/+5
Change-Id: I53ab8d17914e6563110354e4052109ac02bf8f3b Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
2018-07-16Adjacency-BFD: assume BFD down on createNeale Ranns1-8/+16
Change-Id: I13279a1a96df457209fb25748a643c01b18ff4e0 Signed-off-by: Neale Ranns <nranns@cisco.com>
2018-02-21Adj Delegates; don't store raw pointersNeale Ranns1-16/+7
... you'd think I'd have leanred by now... Change-Id: I65c54feb2ec016baa07ed96c81ab8f60277c3418 Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
2018-02-19Adjacency Delegate updatesNeale Ranns1-10/+103
- Register new type (for use from puglins) - Memory for delegate is provided by delegate provider Change-Id: I5ece86b1fe84e3028a5c853871476c4ba015b2eb Signed-off-by: Neale Ranns <neale.ranns@cisco.com>
2018-02-16Adj: VFTs for adjacency sub-blocksOle Troan1-0/+19
Change-Id: I85602b0178315023bb512babdd5b7dd4263a322d Signed-off-by: Ole Troan <ot@cisco.com>
2018-02-15Revert "Adj: VFTs for adjacency sub-blocks"Ole Trøan1-19/+0
This reverts commit a44b015aa012d3b07ed873925d47c6d5955b7dd2. Change-Id: I2d76bc0844f58e5ddf3f3a4326b86076f46e3751 Signed-off-by: Ole Troan <ot@cisco.com>
2018-02-15Adj: VFTs for adjacency sub-blocksOle Troan1-0/+19
Change-Id: I19390f87343bacea84b49fc5d08af38875fdafdd Signed-off-by: Ole Troan <ot@cisco.com>
2017-04-06BFD-FIB interactionsNeale Ranns1-0/+184
- single-hop BFD: attach a delegate to the appropriate adjacency - multi-hop BFD [not supported yet]: attach a delegate to the FIB entry. adjacency/fib_entry state tracks the BFD session state. when the state is down the object does not contribute forwarding hence and hence dependent objects will not use it. For example, if a route is ECMP via two adjacencies and one of them is BFD down, then only the other is used to forward (i.e. we don't drop half the traffic). Change-Id: I0ef53e20e73b067001a132cd0a3045408811a822 Signed-off-by: Neale Ranns <nranns@cisco.com>