Hi Jon,
On 5/17/17, Jon Loeliger <j...@netgate.com> wrote:
> On Wed, May 17, 2017 at 4:35 PM, Andrew 👽 Yourtchenko <ayour...@gmail.com>
> wrote:
>
>> Jon,
>>
>> No, you are not missing anything, there is a ping missing there indeed...
>> :-)
>>
>
> Hi Andrew,
>
> OK, *phew*. Not this time then. Good to know!
>
>
>> At the time I could not figure out how to get the CONTROL_PING to be
>> sent from within the VAT, and since the main use case was
>> programmatic-API driven (I had used VAT primarily during the initial
>> debugging/sanity checks), it fell through the cracks. Appears the
>> solution is not trivial though - the SNAT plugin seems to define its
>> own CONTROL_PING flavour ping, with its own reply code which is
>> exactly the same as the "real" CONTROL_PING handler...
>>
>> That seems a bit wasteful....
>>
>
> There are two competing factors at work there.
>
> One can not #include both the VPE message enum file and the
> plugin's message enum file. The issue is conflicting notions of
> the LAST_MESSAGE.
>
Indeed.
> The reason SNAT has its own CONTROL_PING is so that when the
> plugin is used in stand-alone testing, it can have a CONTROL_PING
> to coordinate its DUMP messaging synchronization.
>
> Technically, it doesn't need to have its own; it could use the CONTROL_PING
> from VPE, except for the stand-alone case where it wouldn't be present.
>
Oh, interesting! I had assumed the CONTROL_PING message is always
present... Do you have any more pointers about such "standalone"
deployment scenario ? What other facilities will be missing in that
case ?
> I wrote a simple interface to the VPE control ping like this:
>
> int vmgmt_control_ping_sync(void)
> {
> vl_api_control_ping_t *mp_ping;
> int ret;
>
> vmgmt_msg_alloc(VL_API_CONTROL_PING, mp_ping);
> vmgmt_msg_send((u8 *)&mp_ping);
>
> ret = vmgmt_msg_wait();
>
> return ret;
> }
>
> and have used that in the ACL code to gain synchronization with
> its REPLY and DETAILS handlers.
>
> But, for ACL to continue to have a standalone testing mechanism,
> I think it will need to have its own ACL_CONTROL_PING added
> just like SNAT does.
>
> I am pretty sure this will generalize to all of the VPP plugins that
> send/receive messages.
Ok, cool... If there is a compelling reason to have ACL_CONTROL_PING
added, why not... would you like to push it to gerrit ?
This does technically qualify as an "API change" - although, I think
since the functionality is fully compatible, we would probably be ok
with bumping just the minor version...
--a
>
> HTH,
> jdl
>
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
