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 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)"
> Date: Monday, July 30, 2018 at 3:34 PM
> To: Leela Gudimetla , "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 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]
-=-=-=-=-=-=-=-=-=-=-=-
