On Mon, Mar 13, 2017 at 03:36:50PM +0200, Roi Dayan wrote:
> This patch series introduces rule offload functionality to dpif-netlink
> via netdev ports new flow offloading API. The user can specify whether to
> enable rule offloading or not via OVS configuration. Netdev providers
> are able to implement netdev flow offload API in order to offload rules.
> 
> This patch series also implements one offload scheme for netdev-linux,
> using TC flower classifier, which was chosen because its sort of natural
> to state OVS DP rules for this classifier. However, the code can be
> extended to support other classifiers such as U32, eBPF, etc which support
> offload as well.
> 
> The use-case we are currently addressing is the newly sriov switchdev mode
> in the Linux kernel which was introduced in version 4.8 [1][2].
> This series was tested against sriov vfs vports representors of the
> Mellanox 100G ConnectX-4 series exposed by the mlx5 kernel driver.
> 
> 
> V3->V4:
>     - Move declarations to the right commit with implementation
>     - Fix tc_get_flower flow return false success 
>     - Fix memory leaks - not releasing tc_transact replies
>     - Fix travis failure for OSX compilation
>     - Fix loop in dpif_netlink_flow_dump_next
>     - Fix declared default value for tc-policy in vswitch.xml
>     - Refactor loop in netdev_tc_flow_dump_next
>     - Add missing error checks in parse_flow_put
>     - Fix handling modify request where old rule is in hw and new
>       rule is not supported and needs to be in sw.
>     - Use 2 hashmaps instead of 1 for faster reverse lookup of ufid from tc
>     - Init ports when enabling hw-offload after OVS is running
> 
>     TODO: Fix breaking of datapath compilation
>           Fix testsuite failures

Hi again,

I think that once the TODO items above are resolved - both of which I have
provided some feedback on separately - some consideration should be given
to merging this patchset.

>From my point of view it introduces important features for those interested
in offloading OvS using the Linux kernel while having minimal impact on
those who are not. I think it provides a good basis for further work on
such offloads. And as we are some distance away from the next release
we should have plenty of time to iron any problems that may be
inadvertently introduced by this patchset.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to