On 14 Jul 2026, at 12:49, Ilya Maximets wrote:
> On 7/14/26 12:28 PM, Eelco Chaudron wrote:
>>
>>
>> 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;
>>
>
> Yes, but
>
> data = ovsrcu_get(void *, &netdev->hw_info.offload_data);
>
> instead of netdev_dpdk_cast().
>
>>> 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.
>
> OK. Thanks. The most impact should be on small UDP packets, as usual though.
>>> 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;
>>
>
> Yes, but
>
> data = ovsrcu_get(void *, &netdev->hw_info.offload_data);
>
> instead of netdev_dpdk_cast().
>
>>> 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.
>
> OK. Thanks. The most impact should be on small UDP packets, as usual though.
Yes did some tests, but my system is not tuned/stabel enough for real numbers,
but with the suggested change above I see numbers between 10-20% improvement.
Engouth to warent the flag, will send out a v2.
//Eelco
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
