.io
*Subject:* Re: [vpp-dev] API and plugins
These “New” plugins are not disabled by default, how comes they are
not loaded in your scenario if you say you don’t know about them?
What does the config that experiences problems look like ?
--a
On 8 Nov 2019, at 14:47, Vratko Polak -X (vrpo
You can look up the msg_id against the plugin registration. No?
I was looking at this to squash the papi log messages for when a plugin is
not loaded.
DBGvpp# show api plugin
Plugin API message ID ranges...
Name First-ID Last-ID
abf_fc925b52
> On 8 Nov 2019, at 17:16, Andrew Yourtchenko wrote:
>
> Unlike an API change, which can have a huge impact radius, the decision about
> the breaking case of the “chipped off” plugin takes O(1) time when manual
> (and can be trivially fully automated), so a blocking process does not appear
>
default { disable } plugin dpdk_plugin.so { enable } }
>
> Vratko.
>
> From: vpp-dev@lists.fd.io On Behalf Of Andrew
> Yourtchenko
> Sent: Friday, November 8, 2019 4:17 PM
> To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco)
> Cc: vpp-api-...@lists.fd.io; v
To: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco)
Cc: vpp-api-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] API and plugins
These “New” plugins are not disabled by default, how comes they are not loaded
in your scenario if you say you don’t know about them?
What does the con
These “New” plugins are not disabled by default, how comes they are not loaded
in your scenario if you say you don’t know about them?
What does the config that experiences problems look like ?
--a
> On 8 Nov 2019, at 14:47, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at
> Cisco) via List
Questions: If an API message handler is moved into a different plugin,
does it constitute a (backward incompatible) API change?
If yes, should we use similar checks and processes as for CRC changes?
Example (not merged yet): sw_interface_ip6nd_ra_config
is being moved from vnet [0] to plugins/ip6
