On 10 Jul 2026, at 14:57, Ilya Maximets wrote:
> On 7/10/26 2:14 PM, Eelco Chaudron wrote:
>> Partial offload was not working if the NIC did not support the tunnel
>> restoration API and OVS was compiled with ALLOW_EXPERIMENTAL_API.
>>
>> This is fixed by returning success instead of EOPNOTSUPP when the
>> tunnel restoration API is not supported.
>>
>> Fixes: 7bd1867b6d6a ("dpif-offload-dpdk: Abstract rte_flow implementation
>> from dpif-netdev.")
>> Reported-by: Ilya Maximets <[email protected]>
>> Signed-off-by: Eelco Chaudron <[email protected]>
>> ---
>> lib/dpif-offload-dpdk-netdev.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/lib/dpif-offload-dpdk-netdev.c b/lib/dpif-offload-dpdk-netdev.c
>> index efe99065e..7b444f636 100644
>> --- a/lib/dpif-offload-dpdk-netdev.c
>> +++ b/lib/dpif-offload-dpdk-netdev.c
>> @@ -3026,9 +3026,6 @@ dpdk_netdev_hw_miss_packet_recover(struct dpdk_offload
>> *offload,
>> ret = netdev_dpdk_rte_flow_get_restore_info(netdev, packet,
>> &rte_restore_info, NULL);
>> if (ret) {
>> - if (ret == -EOPNOTSUPP) {
>> - return -ret;
>> - }
>> /* This function is called for every packet, and in most cases there
>> * will be no restore info from the HW, thus error is expected.
>> */
>
> Hi, Eelco. Thanks for the patch.
>
> While this will avoid disabling the entire post processing, this removes
> the guard that protects from a performance penalty of calling into DPDK
> for every packet when the netdev doesn't actually support tunnel offload.
> This is what the api_supported guard was originally for, before the
> dpif-offload re-work.
>
> So, while partial offload will not be disabled anymore, it will take a
> significant performance hit in comparison with 3.6 and older versions.
>
> I don't see a lot of options here though. We may need to add another
> atomic boolean on the dpif-offload-dpdk level for this case and avoid
> calling netdev_dpdk_rte_flow_get_restore_info() when it is set to false.
> And set it to false in case this function returns -ENOTSUP (the actual
> error DPDK reports). We may have to store this variable in the offload
> data, i.e., struct dpdk_offload_netdev_data. There still will be some
> impact from accessing it, but maybe lower than calling into DPDK.
I'm not sure if I get your idea, but I think it's somehting like this?
data = netdev_dpdk_cast(netdev);
atomic_read_relaxed(&data->tunnel_restore_api_supported, &supported);
if (supported) {
ret = netdev_dpdk_rte_flow_get_restore_info(...);
if (ret == -ENOTSUP) {
atomic_store_relaxed(&data->tunnel_restore_api_supported, false);
return 0;
}
...
}
return 0;
> Any chance you can run some performance tests on a card that support the
> partial offload, but not the tunnel offload?
I have a looped back nic, I can try to see if I can get some simple performance
runs with iperf.
//Eelco
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
