On Wed, Jan 25, 2017 at 10:49 AM, Dave Barach (dbarach) <dbar...@cisco.com> wrote:
> Dear Jon, > > > > Sorry for the delayed response. > > > > Anyhow, the constant VL_MSG_FIRST_AVAILABLE is a historical name for a > simple thing: the number of binary API messages defined by a given plugin. > Understood. > I’m not sure what you’re trying to do, but it’s actually just as well that > you ran into a compile error. I need to explain a number of details so you > won’t end up seriously annoyed after wasting a bunch of your time. > Hrm. Maybe too late for that... :-) So, let me give a bit of insight into what I am doing, because I think my intent may be being misunderstood a little. I am doing what I suspect might be the obvious Use Case for the C API to VPP lib. Effectively we are are writing a totally different CLI front-end to VPP through the VPP lib API. We are strictly *using* vlib -- we are not, at this time, writing any new plugin to VPP, nor are we extending VPP's functionality via a new plugin. However, we have need to use multiple plugins. If you consider the "vpe" pieces one plugin, then currently our next plug we need is SNAT. When the vpp data-plane loads plugins, each plugin which defines a binary > API is expected to do something like the following: > > > > name = format (0, "snat_%08x%c", api_version, 0); > > > > /* Ask for a correctly-sized block of API message decode slots */ > > sm->msg_id_base = vl_msg_api_get_msg_ids > > ((char *) name, VL_MSG_FIRST_AVAILABLE); > > > > The data-plane plugin asks for a block of message-ID’s. > vl_msg_api_get_msg_ids(...) makes a string-hash entry, to map the string > <plugin-name>_<api-version> to the base of the message-id block. > OK, good. I get that, I believe. > When it comes time to send binary API messages to a given plugin, the > control-plane agent recovers msg_id_base like so: > > > > /* Ask the vpp engine for the first assigned message-id */ > > name = format (0, "snat_%08x%c", api_version, 0); > > sm->msg_id_base = vl_client_get_first_plugin_msg_id ((char *) name); > > > > and adds it to the enumerated message id values: > > > > mp->_vl_msg_id = ntohs (msg_id_base + VL_API_some_msg_id); > This is the code that we can't currently write. I have need of both the interface and SNAT APIs in one C source file. In that case, I had intended to make both interface and SNAT API message calls. I'm happy to offset the number scheme for one of these sets, or both, by an offset. But I can't include both of the msg_id enumberations in the same C file because they collide on the definition of the VL_MSG_FIRST_AVAILABLE as found in the enum definitions. Are we expected to have to interface to each plugin from a separate C source file? I can add an extra set of routines to hide all this in an additional C source file if needed, I guess. Would it make more sense for these enums to provide VL_MSG_ID_SNAT_N_MSGS or something unique to that enum? Also, is there an API call to "load" a plugin that I missed somewhere? How does my main-line code tell VLIB that the SNAT plugin will need to be loaded? Since the set of plugins can change between runs, absolute message ID’s > can’t be guaranteed. > Yep, I get that too. Where is all this plugin stuff described? I see, for example, the "sample" plugin src/examples/sample-plugin/sample/. However, I think that describes how to write a new plugin to extend VPP's functionality. That's not what I'm doing. Please let me know if there are other questions I could answer to help clarify what I'm trying to do here! Thanks… Dave > Thanks, jdl
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
