On 11 Nov 2025, at 15:05, Eelco Chaudron <[email protected]> wrote:
!-------------------------------------------------------------------| CAUTION: External Email |-------------------------------------------------------------------! On 11 Nov 2025, at 4:57, Rama Shankar Pandey wrote: Hi Eelco, I made few changes in local ovs code to selectively initialize flow_api only on few interfaces. This ensures that these interface will only have ovs-kernel data path flows configured, even when hw-offload is enabled. The flow_modify sets err=0 in line 2361 below because del_err is set to EOPNOTSUPP on line 2349, hence the ovs-kernel flow modification is not triggered. I made changes to mimic the behaviour of ovs-kernel dp where there would be no entry for flow in tc. Is there any other reason for your suggestion like backward compatibility to older kernel versions or anything else? Hi Rama, If I understand correctly, you’re suggesting a change to the upstream code to support a downstream-only modification you’ve made. I don’t think that’s a viable request. However, if you’re looking to implement selective offload, you might want to take a look at the hardware offload rework RFC patch series that’s currently on the mailing list. It allows per-port offload configuration. Please note that there’s a known issue in the current version (TC offload stops working after a restart), but I’ll be sending an updated version soon. HI Eelco, Can you please share with me the relevant patch link? I am not able to find this patch series online. It is true that this issue is easily reproduced with my local patch. However, I think the data path with kernel offloads doesn’t handle EOPNOTSUPP error. This patch may still be applicable for flows configured on internal ports, Hence I raised this request. Best Regards, Rama Shankar Cheers, Eelco Best Regards, Rama Shankar On 15 Oct 2025, at 20:17, Eelco Chaudron <[email protected]> wrote: !-------------------------------------------------------------------| CAUTION: External Email |-------------------------------------------------------------------! On 14 Oct 2025, at 18:58, Rama Shankar Pandey wrote: When certain interfaces are selectively excluded to use TC datapath, flow_modify can fail with EOPNOTSUPP and since the error value gets explicitly set to 0, The flows are not deleted from kernel. Avoid setting error value to 0 if flow_api and /or flow_del are NULL. Signed-off-by: Rama Shankar Pandey <[email protected]> Hi Rama, Can you explain a bit more why this is happening? Which EOPNOTSUPP is being hit? Maybe add a unit test? Also, you mentioned that the flows are not deleted from the kernel, but the flow should have been modified in the kernel, since it was not offloaded earlier. So maybe the fix should be (not sure, as I’d like to understand the root cause first), it also needs the comment updated: 2343 out: 2344 if (err && err != EEXIST && (put->flags & DPIF_FP_MODIFY)) { 2345 /* Modified rule can't be offloaded, try and delete from HW */ 2346 int del_err = 0; 2347 2348 if (!info.tc_modify_flow_deleted) { 2349 del_err = netdev_flow_del(dev, put->ufid, put->stats); 2350 } 2351 --++ if (!del_err || del_err == EOPNOTSUPP) { 2353 /* Delete from hw success, so old flow was offloaded. 2354 * Change flags to create the flow in kernel */ 2355 put->flags &= ~DPIF_FP_MODIFY; 2356 put->flags |= DPIF_FP_CREATE; 2357 } else if (del_err != ENOENT) { 2358 VLOG_ERR_RL(&rl, "failed to delete offloaded flow: %s", 2359 ovs_strerror(del_err)); 2360 /* stop proccesing the flow in kernel */ 2361 err = 0; 2362 } 2363 } Cheers, Eelco --- lib/dpif-netlink.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c index 7587c9c3e..57900cd38 100644 --- a/lib/dpif-netlink.c +++ b/lib/dpif-netlink.c @@ -2354,7 +2354,8 @@ out: * Change flags to create the flow in kernel */ put->flags &= ~DPIF_FP_MODIFY; put->flags |= DPIF_FP_CREATE; - + } else if (del_err != ENOENT && + del_err != EOPNOTSUPP) { VLOG_ERR_RL(&rl, "failed to delete offloaded flow: %s", ovs_strerror(del_err)); /* stop proccesing the flow in kernel */ -- 2.51.0 _______________________________________________ dev mailing list [email protected]<mailto:[email protected]><mailto:[email protected]> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=yxpujFwLAEz1fgBNS8okgBq0WGuTA6oJ64Bwqnzsk-k&m=rq6aOFR8X40JCIHD2ILyBHszYTZmFkuN9ZEhWqjENTfPsyTtdGx78mN6_8q9_4m9&s=zBsM3kxaPnix2D_-Udx880hffLSmnk18i6if730W_aE&e= _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
