Difference between revisions of "VPP/API Concepts"
From fd.io
< VPP
(→Conventions) |
|||
Line 15: | Line 15: | ||
A request/reply call must be structured as follows: | A request/reply call must be structured as follows: | ||
− | <nowiki> | + | <nowiki> |
define show_version { | define show_version { | ||
u32 client_index; | u32 client_index; | ||
Line 36: | Line 36: | ||
A Dump/Details call must be structured as follows: | A Dump/Details call must be structured as follows: | ||
− | <nowiki> | + | <nowiki> |
define map_domain_dump { | define map_domain_dump { |
Revision as of 07:22, 10 May 2016
General considerations
The VPP binary API is a message passing API. A message from a client must include the 'client_index', an opaque cookie identifying the sender, and a 'context' field to let the client match request with reply. There are three classes of methods supported by the API as outlined below.
- Request/Reply
- Dump/Detail
- Want
Conventions
A request/reply call must be structured as follows:
define show_version { u32 client_index; u32 context; }; define show_version_reply { u32 context; i32 retval; u8 program[32]; u8 version[32]; u8 build_date[32]; u8 build_directory[256]; };
With the reply message having the API method name concatenated with the string "_reply".
A Dump/Details call must be structured as follows:
define map_domain_dump { u32 client_index; u32 context; }; define map_domain_details { u32 context; u32 domain_index; u8 ip6_prefix[16]; u8 ip4_prefix[4]; u8 ip6_src[16]; u8 ip6_prefix_len; u8 ip4_prefix_len; u8 ip6_src_len; u8 ea_bits_len; u8 psid_offset; u8 psid_length; u8 flags; u16 mtu; u8 is_translation; };
Issues
- Use of variable length arrays
- Pointers to shared memory blocks
- String versus binary arrrays
- Dump/Details calls where multiple message types are sent in return, not only the _details message. E.g. sw_interface_dump()
Open questions
- Make a common message header containing length, context and client_index
- Can manual_java tags be removed?