Dear Jon,
Yeah, without clib_time_init(...) the wheels will fall off. I should toss in a
couple of ASSERTs to make that problem totally obvious.
vpp_api_test is a simple test tool constructed for no purpose more noble than
testing vpp-side message-handlers. I’ve recently fiddled such that vpp itself
includes the business end of vpp_api_test, to facilitate single-process binary
api testing [e.g. in gdb].
The per-message “context” field is intended to help applications match requests
with replies. A fixed-size (power-of-two) ring and a 32-bit up-counter would
make a fairly snappy rx-thread reply matcher. You could also use a hash table.
The threading model is simple: binary API clients choose one of these APIs:
int
vl_client_connect_to_vlib (char *svm_name, char *client_name,
int rx_queue_size)
int
vl_client_connect_to_vlib_no_rx_pthread (char *svm_name, char *client_name,
int rx_queue_size)
In the no_rx_pthread case, some thread needs call vl_msg_api_queue_handler(q)
to process replies:
api_main_t *am = &api_main;
q = am->vl_input_queue;
vl_msg_api_queue_handler (q);
HTH... Dave
________________________________
Note that vl_msg_api_queue_handler(...) is easily made non-blocking:
void
vl_msg_api_queue_handler (unix_shared_memory_queue_t * q)
{
uword msg;
while (!unix_shared_memory_queue_sub (q, (u8 *) & msg, 0 /* 1 = non-blocking,
returns 0 if msg available to process */))
vl_msg_api_handler ((void *) msg);
}
From: Jon Loeliger [mailto:j...@netgate.com]
Sent: Friday, February 10, 2017 4:46 PM
To: Dave Barach (dbarach) <dbar...@cisco.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>; Edward Warnicke <hagb...@gmail.com>
Subject: Re: VPP API Synchronization Question
On Fri, Feb 10, 2017 at 11:23 AM, Dave Barach (dbarach)
<dbar...@cisco.com<mailto:dbar...@cisco.com>> wrote:
Dear Jon,
If you send “please dump X” API message(s), followed by a control-ping message:
when the control-ping reply appears, all of dump reply messages (if any) have
appeared.
That absolutely does work. See api_format.c:api_ip_add_del_route(...).
In standard usage, the messages are received on a separate pthread. The api
test tool uses the world’s crudest synchronization scheme.
Contact me off-list if you can’t figure out what’s wrong.
Thanks… Dave
Dave,
Spurred on by your insistence that it does work, I went digging
around in my code a whole bunch more. Specifically, I was trying
to instrument around my message-wait function some more.
Eventually, I came to realize that it was timing-out on almost every
message sent. Naturally, that didn't seem right to me...
Debugging lead me to realize that I failed to call clib_time_init()
in our early initialization sequence, and all of the timer-based
tests in message wait were instantly failing, and thus the messages
were not truly waiting for the "result ready" condition like they should.
I still don't like the use of an essentially global, volatile here; but
at least it is working, as you indicated it would.
Is there a quick outline of how the API's threading model is set up
and expected to be used? Where the vlib_global_main and vlib_mains
are established and such?
Thank you!
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
