Hi Hyong, It ultimately depends on what “function” does and how you plan to solve worker contention for whatever resources need to be shared. Assuming that 1) “function” must be executed asynchronously and 2) the node forwards the packets after it copies the interesting data out of them, some of the options would be: - Do the rpc to main thread using vl_api_rpc_call_main_thread. Note however that vpp processes, including the cli, run on the main thread. So if the function does not yield the cpu for a long time it could lead to other types of problems. Workers synchronize via the underlying svm queue used by the rpc infra and if the amount of data is relatively small, you can even use the queue to pass data around. Otherwise you’ll need something custom. - Write a vpp process node (see nodes with type VLIB_NODE_TYPE_PROCESS). You can then signal, i.e., wake up, the process from any worker with vlib_process_signal_event_mt (an rpc). In this case, you’ll need a custom infra to move data around but now you can write the process such that it only does a moderate amount of work per dispatch before it yields the cpu. Thereby you can somewhat mitigate the issue above. - If “function” is complicated enough that it’d be good to distribute the load over multiple threads, you could consider writing an input node that works in interrupt mode. See nodes of type VLIB_NODE_TYPE_INPUT and vlib_node_set_interrupt_pending. This also needs an infra to move data around and solve contention between workers but now the load can be distributed. As a downside, any time spent executing the “function”, is time a worker is not spending forwarding packets. - Finally, if the cost of executing the function within vpp is too large, ship the data outside using memif or tap interfaces. You can also use vcl, but you’d have to write both a vpp builtin app and an external app, so not trivial.
Take these are rough guidelines. With a bit more context, I’m sure others would be able to provide better alternatives. Regards, Florin > On Feb 25, 2021, at 6:04 PM, hyong...@gmail.com wrote: > > Hi, > > Say we will have Plugin A that needs to: > > 1. Receive packets at an interface > 2. Update some state about received packets > 3. Send the updated state to another "function" for further processing > 4. Forward received packets to the next node > > What would be the best practice for the design of Step 3 in vpp? The > processing of the updated state data is external to the vpp graph. Can the > "function" in Step 3 be another plugin that does not process any packets but > wait for the state update, assuming such a plugin is even possible? Or can > the function be part of a small builtin application and receive the state > data from Plugin A with something like "vl_api_rpc_call_main_thread()"? > While I'm a newbie with little experience in vpp dev, it feels there must be > a more straightforward approach. Any suggestions or information on where to > look would be much appreciated. > > Thanks, > --Hyong > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18808): https://lists.fd.io/g/vpp-dev/message/18808 Mute This Topic: https://lists.fd.io/mt/80918458/21656 Mute #vpp:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp Mute #vppcapi:https://lists.fd.io/g/vpp-dev/mutehashtag/vppcapi Mute #vapi:https://lists.fd.io/g/vpp-dev/mutehashtag/vapi Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
