On 11/03/2026 10:56, Eelco Chaudron wrote: > External email: Use caution opening links or attachments > > > On 10 Mar 2026, at 17:23, Ilya Maximets wrote: > >> On 2/10/26 10:56 AM, Eelco Chaudron via dev wrote: >>> This series adds infrastructure for hardware offload providers to >>> register callbacks that execute as part of PMD thread processing, and >>> uses this infrastructure to implement simulated hardware offload in the >>> dummy offload provider. >>> >>> Patch 1 adds the PMD thread lifecycle hooks that allow offload providers >>> to initialize per-PMD contexts, register work callbacks that run in each >>> PMD iteration, and properly clean up on thread exit. Cycle statistics >>> are integrated into the existing PMD performance metrics. >> >> Hi, Eelco. As we talked before, this infrastructure resembles the async >> work infra that was proposed in the past for the use case of async vhost >> processing. And I don't see any real use case proposed for it here nor >> in the RFC, where the question was asked, but not replied. > > ACK, I've copied Eli and Gaetan in the to:, hopefully they can clarify > their need better. >
Hi Ilya, Eelco, Thanks for the patch and for the review. The use-case on our side is distributed data-structures in DOCA that requires each participating threads to do maintenance work periodically. Specifically, offload threads will insert offload objects. Those will reserve entries in a map that can be resized. The DOCA implementation requires any thread that owns an entry to perform the work of moving it to the new bucket / space after resize is initiated. This is a pervasive design choice in DOCA, they write most of their APIs assuming participating threads are periodically calling into these maintenance functions. Some of such work is also time-sensitive, for example the current implementation requires a CT offload thread to receive completions after some hardware initialization. Until this completion is done, the CT offload entry is not fully usable (cannot be queried for activity / counters). We cannot leave batches of CT offload entry waiting for completion, assuming that at some later point, we will eventually re-execute something in our offload provider: it leaves a few stranded connection objects incomplete. This has the result of having hardware execution of a flow with CT actions, but no activity counters: the software datapath then deletes the connection and/or flow due to inactivity. -- Gaetan _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
