On 21.04.2019 11:26, Ophir Munk wrote:
> From: Roni Bar Yanai <[email protected]>
>
> vport offloaded functions should have a different implementation for
> kernel based OVS versus dpdk based OVS. Currently there is an unconditional
> execution of a kernel based calls even if the vport was added by dpif-netdev
> rather than by dpif-netlink. Before this commit and in case hw-offload=true
> adding a netdev datapath vport resulted in an error since the vport kernel
> based APIs were called. In practice the API returned immediately on a
> get_ifindex() failure (see [1]), which caused no harm, but it is required
> to avoid such scenarios in advance. In case of a netdev datapath vport flow
> functions must be updated at runtime. This commit reassigns flow functions
> to NULL when such a vport is added. It uses a duplicated vport class to
> keep the original default kernel vport class intact. This enables using
> vports in a mixed environment of kernel and netdev (userspace) bridges at
> the same time.
>
> [1]
> ovs|00002|netdev_tc_offloads(dp_netdev_flow_5)|ERR|flow_put: failed to
> get ifindex for vxlan_sys_4789: No such device
>
> Reviewed-by: Asaf Penso <[email protected]>
> Co-authored-by: Ophir Munk <[email protected]>
> Signed-off-by: Ophir Munk <[email protected]>
> Signed-off-by: Roni Bar Yanai <[email protected]>
> ---
Hi Ophir.
I tried to look at this issue from the architecture point of view and end up
with a different solution that should allow us to overcome most of issues
connected with choosing the right flow API for particular netdev.
Could you, please, take a look:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-April/358400.html
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
