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.
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.
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.
HTH,
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
