Neale Ranns | dfd3954 | 2020-11-09 10:09:42 +0000 | [diff] [blame] | 1 | .. _hacking: |
| 2 | |
| 3 | Get Hacking |
| 4 | ----------- |
| 5 | |
| 6 | The code's directory structure is trivial, FIB, mFIB, adj have their |
| 7 | own directories. |
| 8 | |
| 9 | for the most part, for all the FIB object types mentioned in this |
| 10 | documentation there is a corresponding .h and .c file. As with any VPP |
| 11 | component/sub-system a 'public' header file is any file that can be |
| 12 | included by another sub-system and/or plugin. These must be specified |
| 13 | in the build-system, so go look there. Public header files are always |
| 14 | a good entry point to start reading. |
| 15 | |
| 16 | FIB |
| 17 | ^^^ |
| 18 | |
| 19 | There is no direct [VPP's binary] API access to FIB, but FIB does |
| 20 | expose types that can be used on the API by FIB and by other |
| 21 | subsystems (e.g. :ref:`barnacles`). These types are specified in |
| 22 | fib.api and the encoding and decoding thereof in fib_api.[ch]. |
| 23 | |
| 24 | Most operations on a FIB entry happen as a result of an operation on a |
| 25 | FIB table; an entry does not exist in isolation. The APIs in |
| 26 | fib_table.h are well doxygen documented you should be able to figure |
| 27 | out what they do. Use this as a starting point to explore how entries |
| 28 | are created and deleted and how the source priority scheme works. |
| 29 | |
| 30 | FIB sources are defined in fib_source.h. Each source behaviour has its |
| 31 | own file fib_entry_src_*.c These define the virtual functions that |
| 32 | determine how the source behaves when actions on the FIB occur. For |
| 33 | example, what the entry must do when its covering prefix's forwarding |
| 34 | is updated. |
| 35 | |
| 36 | When creating new paths/path-lists the main action required is to |
| 37 | resolve them; see fib_path*_resolve, and once resolved to have them |
| 38 | contribute a DPO for forwarding or for the uRPF list; see |
| 39 | fib_*_contribute_forwarding and fib_*_contribute_urpf respectively. |
| 40 | |
| 41 | The data-structures that used for entry lookup are protocol |
| 42 | specific, they are implemented in separate files; ip4_fib.[ch], |
| 43 | ip6_fib.[ch] and mpls_fib.[ch]. |
| 44 | |
| 45 | FIB extranet support is implemented in fib_attached_export.[ch]. |
| 46 | FIB tracking is implemented in fib_entry_track.[ch]. |
| 47 | FIB [back]walk is implemented in fib_walk.[ch]. |
| 48 | |
| 49 | Adjacency |
| 50 | ^^^^^^^^^ |
| 51 | |
| 52 | Not much to say here, each adjacency type has it own file; use the |
| 53 | force, read the source. |
| 54 | |
| 55 | |
| 56 | Testing |
| 57 | ^^^^^^^ |
| 58 | |
| 59 | the majority of FIB coverage comes from the C Unit tests in |
| 60 | fib_test.c. I strongly encourage you to add code here. It's a much |
| 61 | easier development cycle to fire up GDB, run VPP and iterate with |
| 62 | 'test fib', than it is work in the python UT. You still need to write |
| 63 | python UT, don't get me wrong, it's just easier to do the FIB dev |
| 64 | using C UT. |
| 65 | |
| 66 | |
| 67 | |
| 68 | Enjoy! |