Re: [ovs-dev] [PATCH ovs V8 01/26] tc: Add tc flower interface

On Sun, May 07, 2017 at 02:46:14PM +0300, Roi Dayan wrote: > > > On 04/05/2017 19:35, Simon Horman wrote: > >On Wed, May 03, 2017 at 06:07:52PM +0300, Roi Dayan wrote: > >>From: Paul Blakey > >> > >>Add tc flower interface that will be used to offload flows via tc > >>flower

Re: [ovs-dev] [PATCH 2/2] Ovn tunnel encapsulation should consider both local and remote

If one end is configured external-ids:ovn-encap-type=geneve,stt,the other end is configured external-ids:ovn-encap-type=stt, then the tunnel is not available based on the current implementation,because one end is geneve,the other end is stt. After this revision,the tunnel will be stt on both

Re: [ovs-dev] 答复: Re: 答复: Re: [PATCH] ovn-controller: Support vxlan tunnel in ovn

There are some assumptions that you are making which need to be called out. These assumptions may not hold going forward. In fact I refer to two different patches below that are currently under review, that break your assumptions. On Fri, May 5, 2017 at 7:18 PM, wrote: >

Re: [ovs-dev] [PATCH v5] tunneling: Avoid recirculation on datapath by computing the recirculate actions at translate time.

> >> I have a patch that fixes tunneling over patch ports. The 14th > >> system-userspace > >> test still does fail, but now the packet size in the dump flow remains 242. > >> > >> ./system-traffic.at:554: ovs-ofctl dump-flows br0 | grep "in_port=2" | sed > >> -n 's/.*\(n\_bytes=[0-9]*\).*/\1/p'

Re: [ovs-dev] [PATCH 4/6] ovsdb: add support for role-based access controls

> From: "Ben Pfaff" > To: "Lance Richardson" > Cc: d...@openvswitch.org > Sent: Saturday, 6 May, 2017 12:41:37 AM > Subject: Re: [ovs-dev] [PATCH 4/6] ovsdb: add support for role-based access > controls > > On Mon, May 01, 2017 at 10:13:21AM -0400, Lance

Re: [ovs-dev] [PATCH v3] Windows: Secure the namedpipe implementation

Thanks a lot for the patch! Me and Sai talked offline and we will add the creator (owner) user to be added in another incremental. Could you please apply it on master, branch-2.7, branch-2.6? Tested-by: Alin Gabriel Serdean Acked-by: Alin Gabriel Serdean

[ovs-dev] [PATCH v4 7/7] dpif-netlink: Probe for out-of-tree tunnels, decides used interface

On dpif init, probe for whether tunnels are created using in-tree (upstream linux) or out-of-tree (OVS). This is done by probing for the existence of "ovs_geneve" via rtnetlink. This is used to determine how to create the tunnel devices. For out-of-tree tunnels, only try genetlink/compat. For

[ovs-dev] [PATCH v4 6/7] dpif-netlink-rtnl: add GENEVE creation support

Creates GENEVE devices using rtnetlink and tunnel metadata. Co-Authored-by: Thadeu Lima de Souza Cascardo Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Eric Garver --- lib/dpif-netlink-rtnl.c | 51

[ovs-dev] [PATCH v4 4/7] dpif-netlink-rtnl: add VXLAN creation support

Creates VXLAN devices using rtnetlink and tunnel metadata. Co-Authored-by: Thadeu Lima de Souza Cascardo Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Eric Garver --- lib/dpif-netlink-rtnl.c | 80

[ovs-dev] [PATCH v4 2/7] dpif-netlink: break up code that creates compat ports

This breaks up creating compat ports so we can reuse some of the code to create ports with rtnetlink. Co-authored-by: Thadeu Lima de Souza Cascardo Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Eric Garver Acked-by: Joe

[ovs-dev] [PATCH v4 3/7] dpif-netlink: Support rtnetlink port creation.

In order to be able to add those tunnels, we need to add code to create the tunnels and add them as NETDEV vports. And when there is no support to create them, we need to fallback to compatibility code and add them as tunnel vports. When removing those tunnels, we need to remove the interfaces as

[ovs-dev] [PATCH v4 1/7] netdev: get device type from vport prefix if it uses one

From: Thadeu Lima de Souza Cascardo If the device name uses a vport prefix, then use that vport type. Since these names are reserved, we can assume this is the right type. This is important when we are querying the datapath right after vswitch has started and using the

[ovs-dev] [PATCH v4 0/7] create tunnel devices using rtnetlink interface

This series adds support for the creation of tunnels using the rtnetlink interface. This will open the possibility for new features and flags on those vports without the need to change vport compatibility code. Support for STT and LISP have not been added because these are not upstream yet, so we

Re: [ovs-dev] 答复: Re: 答复: Re: [PATCH] ovn-controller: Support vxlan tunnel in ovn

On Sat, May 06, 2017 at 10:18:58AM +0800, xu.r...@zte.com.cn wrote: > Hi,Russell > > We think vxlan is the most commonly used tunnel encapsulation in the > overlay network openstack,ovn should better consider it. > > As my workmate wang qianyu said,we would consider computer node connect >

Re: [ovs-dev] [PATCH 1/2] sparse: Add rte_memcpy.h replacement header.

OK, I added that it affects i386 and applied this to master. Thank you! On Sat, May 06, 2017 at 08:27:47PM +, Darrell Ball wrote: > I am not able to reproduce this using 64bit arch., although Sparse does work > for me. >(I guess I should install a 32 bit VM at some point, but I am low

Re: [ovs-dev] [PATCH ovs V8 01/26] tc: Add tc flower interface

On 04/05/2017 19:35, Simon Horman wrote: On Wed, May 03, 2017 at 06:07:52PM +0300, Roi Dayan wrote: From: Paul Blakey Add tc flower interface that will be used to offload flows via tc flower classifier. Depending on the flag used (skip_sw/hw) flower will pass those to HW

Re: [ovs-dev] [PATCH ovs V8 00/26] Introducing HW offload support for openvswitch

On 03/05/2017 18:58, Federico Iezzi wrote: On Wed, May 3, 2017 at 5:07 PM, 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