> On 17 Jan 2017, at 22:53, Jon Loeliger <j...@netgate.com> wrote:
>
>
> On Tue, Jan 17, 2017 at 3:45 PM, Alexander Popovsky (apopovsk)
> <apopo...@cisco.com <mailto:apopo...@cisco.com>> wrote:
> 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
>
> Right.
>
> Except it is more insidious than that. The installed include files
> have an #ifdef in them that changes the message ID values.
> The corresponding libraries were compiled using on or the other
> of those choices. Which one? No way to tell. But one of them
> is right and the other is wrong.
>
> I think the include file should never present the ability to make the
> message ID values be variant.
As Ole explained, please use vl_api_get_msg_index.
-DDPDK=1 will disappear soon when dpdk becomes a plugin…
Thanks,
Damjan
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
