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

Reply via email to