> instead of this thread handoff > better method where we can launch thread
No. I mean, it is possible to code that, but I recommend not doing so. There are good reasons why VPP does not handle “thread” as a directly usable primitive, except it being a part of the “worker” primitive. For example, the main thread needs to be able to enact a “worker barrier” to ensure no worker reads some global structure that is being edited. (There are several open issues where VPP does not apply the barrier, leading to segmentation faults.) Even if you launched an “external thread”, there is still a question of how to handle frames, buffers and similar memory-centered constructs. Writing buffers indices into a shared memory for the external thread to read them is the easy part. The hard part is getting rewritten (or empty) buffers back under VPP control for reuse, including deallocations done by NIC drivers. If you are going to code your own solution, you will inevitably end up creating “handoff queues” and graph nodes reading from them, at which point it will start making sense doing copy&edit of some existing VPP code instead. Or going fully asynchronous, relying on memif interfaces instead of custom shared memory solutions. But yes, VPP could prepare some “generic handoff framework”, similarly to how RX and TX queue handling has been centralized into src/vnet/interface/. Vratko. From: [email protected] <[email protected]> On Behalf Of Gulshan via lists.fd.io Sent: Wednesday, 4 February, 2026 04:37 To: [email protected] Subject: Re: [vpp-dev] Doing DPI on a slow thread/child thread. #vppctl #vpp-dev #vppinfra #dpdk #mellanox Thank you Vratko for explaining the complexities that will come in the way of implementing this worker handoff method, like this will get complex when we try to implement a slow thread for every worker node like for TCP, UDP, IPsec where we need to implement some behaviourqal basis or VPN/TOR detection then we need another thread again. So, instead of this thread handoff if there would have been a better method where we can launch thread after defining it in startup.conf file.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26791): https://lists.fd.io/g/vpp-dev/message/26791 Mute This Topic: https://lists.fd.io/mt/117523632/21656 Mute #vppctl:https://lists.fd.io/g/vpp-dev/mutehashtag/vppctl Mute #vpp-dev:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp-dev Mute #vppinfra:https://lists.fd.io/g/vpp-dev/mutehashtag/vppinfra Mute #dpdk:https://lists.fd.io/g/vpp-dev/mutehashtag/dpdk Mute #mellanox:https://lists.fd.io/g/vpp-dev/mutehashtag/mellanox Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
