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.
> The async work infra was unnecessary and this one also seems unnecessary.
> Even more unnecessary as it has no real use case. So, I'd like to not
> have it as it stands right now, unless there is a good reason for it, and
> what it needs to accomplish can't be done by other means like doing a bit
> more work on tx/rx instead.
I do not know how much extra work is needed, but it brings up the
pollution part of the used cycles, which might impact the rebalance
decisions. But let's wait for Eli and/or Gaetan's response.
>> Patch 2 leverages this infrastructure to implement full hardware offload
>> simulation in the dummy provider. Packets matching fully-offloaded flows
>> are queued and processed asynchronously by the PMD work callback,
>> bypassing the software datapath entirely. This allows testing of
>> hardware offload behavior.
>>
>> Together, these patches enable testing of hardware offload scenarios
>> and features in userspace datapath configurations.
>
> The offload simulation can be done without any changes in the dpif-netdev.
> We have netdev_run() called for all the maintenance that needs to happen.
> And it actually handles the initial admission of all the packets that
> are coming into the dummy netdev, so it can handle the simulated offload
> as well, AFAIU.
I agree, but this API was allowing for a nice clean separation (and a
use case ;).
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
