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? 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