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.
Any chance you can run some performance tests on a card that support the
partial offload, but not the tunnel offload?
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
