Hi Benoit. From an earlier e-mail:
> - in the fastpath, handoff [2] the specific packets to your slowpath node in > the slowpath workers > > That should guarantee that slowpath packets will not delay fastpath packets. > [2] https://s3-docs.fd.io/vpp/26.02/developer/plugindoc/handoffdemo.html That basically boils down to adding a piece of new VPP code that calls vlib_buffer_enqueue_to_thread when some conditions are met. (Although I am not sure which graph node reads those packets on receiving worker.) > what I described is not a hack nor novel, it is the typical way of doing it. I think this e-mail thread represents a user feedback, suggesting that "add your own code" is not a very user-friendly way to support common use cases. Maybe I am over-generalizing, as Gulshan mentioned they "can do this in DPDK", so adding new code is probably not a blocker for them. If I understand the intended processing flow correctly, it would involve two (pools of) workers: io-bound (dataplane, fast path) worker and cpu-bound (crypto, slow path) worker. NIC RX queues will be handled by io-bound workers only. The critical packet path will be: 1. Arrive at io-worker, some lightweight initial processing. 2. Classifier on io-worker identifies which packets need the slow path. 3. Handoff to cpu-bound worker. 4. QUIC decrypt on cpu-bound worker. 5. DPI, perhaps with additional classifiers to "mark" the packet. 6. Handoff back to io-bound worker (not sure which packet, I am afraid the undecrypted one). 7. The rest of processing depending on the "mark" value. From what I know, the ability to "decrypt a packet and keep also the undecrypted copy" is definitely not supported by VPP. Especially if the two need to share the "mark" value. But even if that is not a blocker (if cpu-worker can "re-encrypt" the previously decrypted packet), the combination of steps 2 and 3 is not supported in VPP (as far as I know). Classifiers are flexible and can choose next graph node, but not next worker. Soft-rss can choose next worker, but I doubt its inputs (based on Toeplitz hashes, and only works on hardware interfaces, if I understand correctly) are flexible enough for this scenario. I see some occurrences of "handoff" string in src/vnet/policer/, but I am not sure if that can do the work required in this processing flow. The async software crypto framework is an example of steps 3 and 6 being tightly integrated with a specific protocol (ipsec in this case), as opposed to a generic classifier. There are other instances of "-handoff" in VPP code, usually involved with stateful stuff like NAT, SFDP, ipsec, wireguard, ike2 and aforementioned policer. Whether the "missing feature" is a similar tight integration of handoff with QUIC, or a generic "handoff capable classifier", I feel some users will appreciate if some reusable code was available in main repo (not requiring user-written plugins). I think that the main hurdle for implementing "handoff capable classifier" is to ensure any target graph node on the receiving worker knows to (also) read from its handoff queue, which can get tricky, especially if feature arcs are involved. Maybe it is already possible to force classifier to direct packets to soft-rss? I can imagine some ugly hacks involving "loopback interfaces" or even memif links between workers, but I do not think we should encourage such hacks. To be clear, I know VPP developers are already stretched thin, reading this e-mail is perhaps already more time spent than warranted. I am just starting a discussion, hoping for somebody saying it is on their TODO list, or at least willing to review contributions (from Gulshan probably). Vratko. -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Benoit Ganne (bganne) via lists.fd.io Sent: Friday, 30 January, 2026 11:14 To: [email protected] Subject: Re: [vpp-dev] Doing DPI on a slow thread/child thread. #vppctl #vpp-dev #vppinfra #dpdk #mellanox > Thank You benoit, i'll check that. But i think this is really a big missing > feature from VPP, for problem statement like this. Is your point that there is no clear documentation or a more packaged library? Because what I described is not a hack nor novel, it is the typical way of doing it. Best ben
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#26766): https://lists.fd.io/g/vpp-dev/message/26766 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]] -=-=-=-=-=-=-=-=-=-=-=-
