On 10/05/2017 17:29, Flavio Leitner wrote:
On Wed, May 10, 2017 at 10:44:46AM +0300, Roi Dayan wrote:


On 09/05/2017 22:05, Flavio Leitner wrote:
On Sun, May 07, 2017 at 10:55:32AM +0300, Roi Dayan wrote:


On 03/05/2017 18:58, Federico Iezzi wrote:
On Wed, May 3, 2017 at 5:07 PM, Roi Dayan <r...@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.
This series was tested against sriov vfs vports representors of the
Mellanox 100G ConnectX-4 series exposed by the mlx5 kernel driver.


V7->V8
    - Refactor dpif logging functions and use them in dpif-netlink
    - Ignore internal devices from netdev hashmap
    - Refactor netdev hmap naming to prefix netdev_ports_*
    - Use single hashmap with 2 nodes for ufid/tc mapping
    - Verify ifindex is valid in netdev_hmap_port_add
    - Close netdev in netdev_tc_flow_get error flow
    - Improve comments for flow offload api
    - Reorder flow api output args to be last args
    - Remove redundant netdev_flow_support
    - Fix using uninitialized var 's'

Not done:
refactor netdev_ports_* functions to accept a typed obj
(e.g. netdev_ports struct) instead of void*.
    We can do it as a follow-up commit later.

...

Might be worth to mention this series on the NEWS as well?


Sure. thanks.

It should include a brief documentation about how it works from
a high level (including the configuration) and known limitations.

inside the NEWS file?

sorry, I was referring to the patchset.


ok. will add something.

shouldn't we do that in the docs?

yes.


This new documentation should also tell the feature status which
we seem to agree it is experimental for now.  And that it can
be removed in the future if it proves to be not much useful.

I did some comments on V7 which were not included in V8 nor
replied, so not sure if you missed them or what else happened.

Hi Flavio,

I looked in my mailbox and couldn't find replies from you on V7.
I looked online in the ovs-dev April archive and see your replies there.
I'll go over the archive and try to address them for V9 and if I missed
something let me know.

Alright, thank you!

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to