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. 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]> > 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
