Thanks Dave for the details. Since the client is a single-threaded, I would want to take a synchronous approach.
To be specific, I would want the response to be returned from the request call. So that the typical C construct create_subif(param1, param2, … *ret1) would do the job and return the reply_t which has sw_ifindex in ret1. If there is a way to return the response from reply_t_handlers to the request call without using the global structures like vat_main, I also would not want go for synchronous approach. Thanks, Leela sankar From: "Dave Barach (dbarach)" <dbar...@cisco.com> Date: Monday, July 30, 2018 at 3:34 PM To: Leela Gudimetla <lgudi...@ciena.com>, "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io> Subject: [**EXTERNAL**] RE: Synchronous VPP-client over SHM At least in C, it’s perfectly possible: use vl_client_connect_to_vlib_no_rx_pthread(...). Follow the sketch in the default rx_thread_fn(..) pretty carefully. You’ll need to manually implement a non-while(1) version of vl_msg_api_queue_handler(...). Spin-waiting for replies will completely consume a CPU core. Such a spin-wait certainly requires a deadman timeout, and should do something to relinquish the cpu core. Be aware that xxx_dump API messages result in multiple replies. The standard scheme for detecting the end of such a message set is to send an echo-request message immediately after xxx_dump. When the echo-reply arrives, the preceding message set is complete. Personally, I wouldn’t go there. Vpp_api_test shows how to make the binary APIs appear to be synchronous. HTH... Dave From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Gudimetla, Leela Sankar Sent: Monday, July 30, 2018 5:19 PM To: vpp-dev@lists.fd.io Subject: [vpp-dev] Synchronous VPP-client over SHM Hello, We are writing a client for VPP to configure it over the shared-memory interface (similar to what VAT does). I see that there is a rx_thread for processing responses from the server (VPP) to process the replies asynchronously. Do we need to use the thread? Or Can we get rid of it and process the responses synchronously probably by introducing a wait if there is only one request at time from the client? This way I can use the same request context to catch the “reply_t” structure. If it works, I can have request – response in a single call and return the response structure. Please let me know if I can get rid of the rx_thread and handle this synchronously. Thanks, Leela sankar
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9989): https://lists.fd.io/g/vpp-dev/message/9989 Mute This Topic: https://lists.fd.io/mt/23923692/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
