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.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
