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_process, that takes care of async execution and generation of api replies. You could also pass opaques in requests and maybe expect backends, like avf_process, to bounce that opaques back for demuxing. Regards, Florin > On Sep 12, 2022, at 4:49 AM, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES > at Cisco) via lists.fd.io <vrpolak=cisco....@lists.fd.io> wrote: > > [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 the immediate issue, > but the proper fix was left hinted in TODOs (and discussed in the long > version). > > Long version: > > Vlib supports processes and signals, see corresponding sections in the docs > [7]. > Using the actor model vocabulary, a (vlib) process is an actor, > and (vlib) signaling a (vlib) event means sending a message between actors. > There is no vlib name for actor behavior [10]. > > The typical use of event signaling in VPP is “fire and forget”, > meaning a “request” without any need to respond. > That means a typical process has just one behavior; > the side effects of a process are given by event type (and data), > not directly by the sequence of previous events received. > > But there is an exception (and in future there may be more). > The process avf_process, when handling AVF_PROCESS_EVENT_REQ > and detecting that was signaled by some other process, > it signals back a “response” event. > The main reason is that some operations may take unreasonably long time, > and we prefer VPP to crash there (instead of getting stuck) > so we can see the backtrace. > > A typical process that signaled AVF_PROCESS_EVENT_REQ is vl_api_clnt_process, > whose loop usually handles SOCKET_READ_EVENT events. > I mean, this socket API handling process has no idea about AVF plugin > specific needs, > but it can call avf_process_request function which (upon detecting it is not > called > from avf_process process) does the signaling and waiting. > > But this means vl_api_clnt_process is the first process (that I know of) with > two behaviors. > The first one focuses on handling new API messages, > the second one focuses on handling the AVF response (especially the lack > thereof in time). > As clib_panic is called when the response does not arrive, > (and I hope there are never two requests at the same time) > the first behavior never encounters the AVF response. > But the second behavior can encounter SOCKET_READ_EVENT. > The VPP-2033 [11] bug is what happens in that case. > > A minor issue is that the “response” event is defined just by > event type being zero, which would not work in (hypothetical future) scenarios > when a single process waits for two different responses. > > Reading through node_funcs.h I found > vlib_current_process_wait_for_one_time_event [12], > which looks suited for waiting for “single response” events, > but it lacks the time awareness of vlib_process_wait_for_event_or_clock. > If we had something like vlib_current_process_wait_for_one_time_event_or_clock > (and its example usage in the docs), handling the response would become > easier. > > Vratko. > > [7] > https://github.com/FDio/vpp/blob/9ad39c026c8a3c945a7003c4aa4f5cb1d4c80160/docs/developer/corearchitecture/vlib.rst > > <https://github.com/FDio/vpp/blob/9ad39c026c8a3c945a7003c4aa4f5cb1d4c80160/docs/developer/corearchitecture/vlib.rst> > [9] https://gerrit.fd.io/r/c/vpp/+/37083 > <https://gerrit.fd.io/r/c/vpp/+/37083> > [10] https://en.wikipedia.org/wiki/Actor_model#Behaviors > <https://en.wikipedia.org/wiki/Actor_model#Behaviors> > [11] https://jira.fd.io/browse/VPP-2033 <https://jira.fd.io/browse/VPP-2033> > [12] > https://github.com/FDio/vpp/blob/16052480c377127f9cb7facbab53f46e595b27cf/src/vlib/node_funcs.h#L1186 > > <https://github.com/FDio/vpp/blob/16052480c377127f9cb7facbab53f46e595b27cf/src/vlib/node_funcs.h#L1186> > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#21872): https://lists.fd.io/g/vpp-dev/message/21872 Mute This Topic: https://lists.fd.io/mt/93630182/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
