lists.fd.io>
mailto:vpp-dev@lists.fd.io>> On Behalf Of Florin Coras
Sent: Monday, 2022-September-12 23:11
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] request-response between vlib processes
Hi Vratko,
Do we really need to block the binary api wai
gt;
> Vratko.
>
> From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <mailto:vpp-dev@lists.fd.io>> On Behalf Of Florin Coras
> Sent: Monday, 2022-September-12 23:11
> To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] r
tember-12 23:11
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] request-response between vlib processes
Hi Vratko,
Do we really need to block the binary api waiting for a reply from another vpp
process just to set a mac address?
If setting up the mac (or similar) cannot be done synchronously, pro
Hi Vratko,
Do we really need to block the binary api waiting for a reply from another vpp
process just to set a mac address?
If setting up the mac (or similar) cannot be done synchronously, probably api
handlers should hand over all those requests to another vpp process,
vl_api_async_req_pro
[resending to the correct vpp-dev e-mail address]
Short version:
Vratko would appreciate something like
vlib_current_process_wait_for_one_time_event_or_clock.
Medium version:
One instance of request-response interaction between vlib processes had a bug
[11].
Vratko contributed a fix [9] for th
