In the first part of our new series, we will be building our first VPP platform plug-in, using basic examples. We will start with a first-dive into plugin creation and finish with introducing VAPI into this configuration.
If you do not know what VPP is, please visit our introductory post regarding VPP and why you should consider using it.
Table of contents:
- How to write a new VPP Plugin
- 1. Preparing your new VPP plugin
- 2. Building & running your new plugin
- How to create new API messages
- How to call the binary API
- Additional C/C++ Examples
How to write a new VPP Plugin
The principle of VPP is, that you can plug in a new graph node, adapt it to your network purposes and run it right off the bat. Including a new plugin does not mean, you need to change your core-code with each new addition. Plugins can be either included in the processing graph, or they can be built outside the source tree and become an individual component in your build.
Furthermore, this separation of plugins makes crashes a matter of a simple process restart, which does not require your whole build to be restarted because of one plugin failure.
1. Preparing your new VPP plugin
The easiest way how to create a new plugin that integrates with VPP is to reuse the sample code at “src/examples/sample-plugin”. The sample code implements a trivial “macswap” algorithm that demonstrates the plugins run-time integration with the VPP graph hierarchy, API and CLI.
-
To create a new plugin based on the sample plugin, copy and rename the sample plugin directory
There are the are following files:
-
- node.c – implements functionality of this graph node (swap source and destination address) -update according to your requirements.
- newplugin.api – defines plugin’s API, see below
- newplugin.c, newplugin_test.c – implements plugin functionality, API handlers, etc.
- Update CMakeLists.txt in newplugin directory to reflect your requirements:
- Update sample.c to hook your plugin into the VPP graph properly:
- Update newplugin.api to define your API requests/replies. For more details see “API message creation” below.
- Update node.c to do required actions on input frames, such as handling incoming packets and more
2. Building & running your new plugin
- Build vpp and your plugin. New plugins will be built and integrated automatically, based on the CMakeLists.txt
- (Optional) Build & install vpp packages for your platform
- The binary-api header files you can include later are located in build-root/build-vpp_debug-native/vpp/vpp-api/vapi
- If vpp is installed, they are located in /usr/include/vapi
- Run vpp and check whether your plugin is loaded (newplugin has to be loaded and listed using the show plugin CLI command)
How to create new API messages
API messages are defined in *.api files – see src/vnet/devices/af_packet.api, src/vnet/ip/ip.api, etc. These API files are used to generate corresponding message handlers. There are two types of API messages – non-blocking and blocking. These messages are used to communicate with the VPP Engine to configure and modify data path processing.
Non-blocking messages use one request and one reply message. Message replies can be auto-generated, or defined manually. Each request contains two mandatory fields – “client-index” and “context“, and each reply message contains mandatory fields – “context” and “retval“.
-
API message with auto-generated reply
- API message with manually defined reply
Blocking messages use one request and series of replies defined in *.api file. Each request contains two mandatory fields – “client-index” and “context“, and each reply message contains mandatory field – “context“.
-
Blocking message is defined using two structs – *-dump and *_details
Once you define a message in an API file, you have to define and implement the corresponding handlers for given request/reply message. These handlers are defined in one of component/plugin file and they use predefined naming – vl_api_…_t_handler – for each API message.
Here is an example for existing API messages (you can check it in src/vnet/ip component):
Request and reply handlers are usually defined in api_format.c (or in plugin). Request uses a predefined naming – api_… for each API message and you have to also define help for each API message :
Replies can be auto-generated or manually defined.
- auto-generated reply using define foreach_standard_reply_retval_handler, with predefined naming
- manually defined reply with details
How to call the binary API
In order to call the binary API, we will introduce VAPI to our configuration.
VAPI is the high-level C/C++ binary API. Please refer to src/vpp-api/vapi/vapi_doc.md for details.
VAPI’s multitude of advantages include:
- All headers in a single place – /usr/include/vapi => simplifies code generation
- Hidden internals – one no longer has to care about message IDs, byte-order conversion
- Easier binapi calls – passing user provided context between callbacks
We can use the following C++ code to call our new plugins’s binary API.
Additional C/C++ Examples
Furthermore, you are encouraged to try the minimal VAPI example provided in vapi_minimal.zip. This example creates a loopback interface, assigns it an IPv4 address and then prints the address.
Follow these steps:
- Install VPP
- Extract the archive, build & run examples
In conclusion, we have:
- successfully built and ran our first VPP plugin
- created and called an API message in VPP
Our next post will introduce and highlight the key reasons, why you should consider Honeycomb/hc2vpp in your VPP build.
You can contact us at https://pantheon.tech/
Explore our Pantheon GitHub. Follow us on Twitter.
Watch our YouTube Channel.