> We have seen a similar issue related to the same ‘API refactoring : dpdk’ > change. > We are using an external API binding layer in C-language in our VPP based > solution. > After the change, it took some digging to add –DDPDK=1 to get things back to > working. > > Looking forward, should it be considered a standard practice in VPP for the > API (IDs) to be dependent on the features compiled (enabled) in VPP? > In such case, should we consider having a generated config.h (similar to > Linux kernel) to be included by the external C-code?
The API message id to name mapping is now part of the API itself. See commit 557d128b Use the u32 vl_api_get_msg_index (u8 * name_and_crc) API. Or do it via the pneum library. O. > > Thanks, > -AI > > From: <vpp-dev-boun...@lists.fd.io> on behalf of Jon Loeliger > <j...@netgate.com> > Date: Tuesday, January 17, 2017 at 11:12 AM > To: vpp-dev <vpp-dev@lists.fd.io> > Subject: Re: [vpp-dev] Weird VPP API message processing failure > > > > On Mon, Jan 16, 2017 at 6:33 PM, Jon Loeliger <j...@netgate.com> wrote: > Folks, > > We are seeing a really strange VPP API message processing problem. > The scenario goes like this... > > > I've started to isolate it with git bisect, and so far I believe the > behavior changed between these commits: > > $ git log --oneline > ... > 553a411 VPP-585: vhost-user interface deletion leaks memory. > ffc18f5 japi: include tests in jar files > 738f3f2 API refactoring : dpdk > 6bbf83a Revert "vppctl: bash completion for vppctl commands" > 842b9c5 Self-service garbage collection for the API message allocator > d995c75 vppctl: bash completion for vppctl commands > 0d3c1cc VPP-279: af_packet via Command-line Arg should no longer be supported > 48c1824 Update CSIT tests 170101 -> 170108 > ... > > I've not had a chance to look at them yet, but of those, the most > suspicious looking one to me is: > 842b9c5 Self-service garbage collection for the API message allocator > > If no one beats me to it, I'll continue bisecting it tomorrow... > > Thanks, > jdl > > So, our message processing issue was one of the commits > listed above. Specifically, it is this: > 738f3f2 API refactoring : dpdk > > In that commit, API messages (and their IDs) are made conditionally > present based on the symbol DPDK being greater than 0. That has > yielded an inconsistent build scenario where the include files used > by other components do not have DPDK set, and the internally built > components (vl_api_test) do see it set. That results in API message > IDs that are skewed by 6. > > jdl > > > > > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
