[ovs-dev] [PATCH ovs V5 00/24] Introducing HW offload support for openvswitch

[Jiri Pirko]

Thu, Mar 23, 2017 at 08:01:35AM CET, joe at ovn.org wrote:
>On 22 March 2017 at 04:10, Roi Dayan <roid at mellanox.com> 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.
>>
>>
>> V4->V5:
>> - Fix compat
>> - Fix VXLAN IPv6 tunnel matching
>> - Fix order of actions in dump flows
>> - Update ovs-dpctl man page about the addtion of type to dump-flows
>>
>> Travis
>> https://travis-ci.org/roidayan/ovs/builds/213735371
>> AppVeyor
>> https://ci.appveyor.com/project/roidayan/ovs/build/1.0.18
>
>Hi Roi,
>
>This series does not compile on the OVS master:
>https://travis-ci.org/joestringer/openvswitch/builds/214039943
>
>I ran the make check-offloads tests on a recent net-next kernel and it
>failed, output was not as expected:
>
>../../tests/system-offloaded-traffic.at:54: ovs-appctl dpctl/dump-flows |
>grep "eth_type(0x0800)" | sed -e
>'s/used:[0-9].[0-9]*s/used:0.001s/;s/eth(src=[a-z0-9:]*,dst=[a-z0-9:]*)/eth(mac
>s)/;s/actions:[0-9,]*/actions:output/;s/recirc_id(0),//' | sort
>--- - 2017-03-22 16:43:37.598689692 -0700
>+++
>/home/vagrant/ovs/_build-clang/tests/system-offloads-testsuite.dir/at-groups/2/stdout
>2017-03-22 16:43:37.595628000 -0700
>@@ -1,3 +1,3 @@
>-in_port(2),eth(macs),eth_type(0x0800), packets:9, bytes:756, used:0.001s,
>actions:output
>-in_port(3),eth(macs),eth_type(0x0800), packets:9, bytes:756, used:0.001s,
>actions:output
>+in_port(2),eth(macs),eth_type(0x0800),ipv4(frag=no), packets:9, bytes:882,
>used:0.001s, actions:output
>+in_port(3),eth(macs),eth_type(0x0800),ipv4(frag=no), packets:9, bytes:882,
>used:0.001s, actions:output
>
>Did you end up allowing other_config:hw-offload to be configured at
>runtime? The tests seem to be assuming this, but the documentation still
>says that OVS must be restarted to enable offloads.
>
>The testsuite is an encouraging sign. I can only imagine that it's not
>attempting to comprehensively cover OVS flow translation to the tc flower
>API, because of its simplicity. Presumably you intend to improve this over
>time though?
>
>At a high level, the functionality isn't particularly compelling at this
>stage. OVS has a huge level of programmability, and the limits applied in
>this patch restrict the offloads to quite a small subset of use cases. That
>said, I believe I've mentioned off-list a couple of times that if there is
>broad interest in the OVS community regarding this series, and that
>interest is shown (for instance, by people trying out the patches,
>providing review, etc) then that's an encouraging sign that this feature is
>providing useful functionality---and therefore should be merged.

Just for the record, I'm using this patchset as well. For testing offload
of OVS on top or rack Mellanox Spectum switches - mlxsw driver in upstream
kernel. We use TCAM to offload OVS rules to.