On Mon, Sep 5, 2022 at 4:47 PM Eli Britstein via dev <[email protected]> wrote: > > When using a userspace vport ("vxlan0"), dpif-netdev adds an additional > netdev ("vxlan_sys_4789"). The dpif netdev ("vxlan0") is added to the > netdev-offload ports map, thus flows are associated on this netdev. > > However, flushing is done on the dpif-netdev level ("vxlan_sys_4789"), > and relevant offload flows are not destroyed. > > To fix it, add the datapath netdev to the netdev-offload ports map. In > case there is no different internal netdev, use the dpif netdev, as before. > > Fixes: adbd4301a249 ("netdev-offload-dpdk: Use per-netdev offload metadata.") > Signed-off-by: Eli Britstein <[email protected]>
Sorry, this mail was in my drafts list as I was looking at patch 1 of the series, and I forgot about it... sending now. I was wondering if this specificity could be hidden within dpif-netdev.c. But I found no elegant solution. From my limited understanding, the dpif generic layer populates the offload map for use by the dpif implementation later. So it needs to be aware of the dpif implementation netdevs. I ran a few simple scenario deleting vxlan ports, flushing flows manually and I saw nothing broken. Reviewed-by: David Marchand <[email protected]> -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
