Hi Leela, I presume you want to do this in C? If so it might be worth looking at VAPI too as a higher level interface.
Cheers Ole > On 31 Jul 2018, at 19:54, Gudimetla, Leela Sankar <lgudi...@ciena.com> wrote: > > 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/675193 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [otr...@employees.org] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9993): https://lists.fd.io/g/vpp-dev/message/9993 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] -=-=-=-=-=-=-=-=-=-=-=-
