Nathan Skrzypczak 9ad39c026c docs: better docs, mv doxygen to sphinx
This patch refactors the VPP sphinx docs
in order to make it easier to consume
for external readers as well as VPP developers.

It also makes sphinx the single source
of documentation, which simplifies maintenance
and operation.

Most important updates are:

- reformat the existing documentation as rst
- split RELEASE.md and move it into separate rst files
- remove section 'events'
- remove section 'archive'
- remove section 'related projects'
- remove section 'feature by release'
- remove section 'Various links'
- make (Configuration reference, CLI docs,
  developer docs) top level items in the list
- move 'Use Cases' as part of 'About VPP'
- move 'Troubleshooting' as part of 'Getting Started'
- move test framework docs into 'Developer Documentation'
- add a 'Contributing' section for gerrit,
  docs and other contributer related infos
- deprecate doxygen and test-docs targets
- redirect the "make doxygen" target to "make docs"

Type: refactor

Change-Id: I552a5645d5b7964d547f99b1336e2ac24e7c209f
Signed-off-by: Nathan Skrzypczak <nathan.skrzypczak@gmail.com>
Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
2021-10-13 23:22:32 +00:00

88 lines
2.5 KiB
ReStructuredText

Multi-Architecture Arbitrary Function Cookbook
==============================================
Optimizing arbitrary functions for multiple architectures is simple
enough, and very similar to process used to produce multi-architecture
graph node dispatch functions.
As with multi-architecture graph nodes, we compile source files
multiple times, generating multiple implementations of the original
function, and a public selector function.
Details
-------
Decorate function definitions with CLIB_MARCH_FN macros. For example:
Change the original function prototype...
::
u32 vlib_frame_alloc_to_node (vlib_main_t * vm, u32 to_node_index,
u32 frame_flags)
...by recasting the function name and return type as the first two
arguments to the CLIB_MARCH_FN macro:
::
CLIB_MARCH_FN (vlib_frame_alloc_to_node, u32, vlib_main_t * vm,
u32 to_node_index, u32 frame_flags)
In the actual vpp image, several versions of vlib_frame_alloc_to_node
will appear: vlib_frame_alloc_to_node_avx2,
vlib_frame_alloc_to_node_avx512, and so forth.
For each multi-architecture function, use the CLIB_MARCH_FN_SELECT
macro to help generate the one-and-only multi-architecture selector
function:
::
#ifndef CLIB_MARCH_VARIANT
u32
vlib_frame_alloc_to_node (vlib_main_t * vm, u32 to_node_index,
u32 frame_flags)
{
return CLIB_MARCH_FN_SELECT (vlib_frame_alloc_to_node)
(vm, to_node_index, frame_flags);
}
#endif /* CLIB_MARCH_VARIANT */
Once bound, the multi-architecture selector function is about as
expensive as an indirect function call; which is to say: not very
expensive.
Modify CMakeLists.txt
---------------------
If the component in question already lists "MULTIARCH_SOURCES", simply
add the indicated .c file to the list. Otherwise, add as shown
below. Note that the added file "new_multiarch_node.c" should appear in
*both* SOURCES and MULTIARCH_SOURCES:
::
add_vpp_plugin(myplugin
SOURCES
multiarch_code.c
...
MULTIARCH_SOURCES
multiarch_code.c
...
)
A Word to the Wise
------------------
A file which liberally mixes functions worth compiling for multiple
architectures and functions which are not will end up full of
#ifndef CLIB_MARCH_VARIANT conditionals. This won't do a thing to make
the code look any better.
Depending on requirements, it may make sense to move functions to
(new) files to reduce complexity and/or improve legibility of the
resulting code.