[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 [9] https://gerrit.fd.io/r/c/vpp/+/37083 [10] https://en.wikipedia.org/wiki/Actor_model#Behaviors [11] https://jira.fd.io/browse/VPP-2033 [12] 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 (#21871): https://lists.fd.io/g/vpp-dev/message/21871 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] -=-=-=-=-=-=-=-=-=-=-=-
