Re: [ovs-dev] [PATCH v3 3/3] xlate: call tnl_neigh_snoop() from terminate_native_tunnel()

:00:01:02:04 br-int > 192.168.0.2 5e:97:6a:82:7d:41 br-phys > > is a good example why we need Zoltan's patch. Any IP address in an ARP reply > is blindly inserted into the tunnel neighbor cache. Overlapping IP addresses > among tenants can cause frequent overwriting of c

Re: [ovs-dev] [PATCH v3 3/3] xlate: call tnl_neigh_snoop() from terminate_native_tunnel()

Hi Justin, I rebased the patches to recent master. Please find them attached. Best regards, Zoltan > -Original Message- > From: Justin Pettit [mailto:jpet...@ovn.org] > Sent: Friday, February 02, 2018 12:00 AM > To: Ben Pfaff <b...@ovn.org> > Cc: Zolt

Re: [ovs-dev] [PATCH v3 3/3] xlate: call tnl_neigh_snoop() from terminate_native_tunnel()

tan > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Tuesday, January 23, 2018 8:02 PM > To: Zoltán Balogh <zoltan.bal...@ericsson.com> > Cc: d...@openvswitch.org; Jan Scheurich <jan.scheur...@ericsson.com> > Subject: Re: [ovs-dev] [PATCH v3 3/3] x

Re: [ovs-dev] [PATCH] bfd: Send BFD packets with DSCP CS6

Hi, Acked-by: Zoltan Balogh Ben, is there a chance to get this into 2.9? Best regards, Zoltan > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Venkatesan Pradeep > Sent: Wednesday, January

Re: [ovs-dev] [PATCH v2 3/3] xlate: call tnl_neigh_snoop() from terminate_native_tunnel()

Hi Ben, > I don't understand yet the motivation here. What does it mean "to keep > ARP neighbor cache clean"? Is this a bug fix, a performance fix, a > cleanup, or something else? > > What is the goal of the filtering you mention? Is that a second change, > that can and should be a separate

Re: [ovs-dev] [PATCH] xlate: fix xport lookup for recirc

port won't matter anymore. */ > + > if (flow->packet_type != htonl(PT_ETH) && in_port && > in_port->pt_mode == NETDEV_PT_LEGACY_L3 && ctx.table_id == 0) { > /* Add dummy Ethernet header to non-L2 packet if it's coming from a > > BR, Jan

Re: [ovs-dev] [PATCH v2 1/3] ofproto-dpif-sflow: propagate actions within clone

> On Thu, Dec 14, 2017 at 09:56:19AM +0100, Zoltan Balogh wrote: > > By avoiding Tx recirculation and embracing tnl_push action within clone, > > the tunnel metadata is not propagated. Unless clone action is handled in > > the dpif_sflow_read_actions() function as well. This commit resolves > >

Re: [ovs-dev] [PATCH] xlate: fix xport lookup for recirc

> On Thu, Dec 21, 2017 at 02:22:43PM +0000, Zoltán Balogh wrote: > > Xlate_lookup and xlate_lookup_ofproto_() provides in_port and ofproto > > based on xport determined using flow, which is extracted from packet. > > The lookup can happen due to recirculation a

Re: [ovs-dev] [PATCH] tunnel: fix tnl_find() after packet_type changed

ch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh > Sent: Monday, December 11, 2017 4:39 PM > To: Jan Scheurich <jan.scheur...@ericsson.com>; d...@openvswitch.org; Ben > Pfaff <b...@ovn.org> > Subject: Re: [ovs-dev] [PATCH] tunnel: fix tnl_find() aft

[ovs-dev] [PATCH] xlate: don't add dummy eth header when doing recirc

In xlate_actions(), when packet comes from a L3 port and its packet_type is not Ethernet, then a dummy Ethernet header is added to the packet by setting flow->packet_type to Ethernet and zero out flow->dl_src and flow->dl_dst. This process should be avoided if packet is recirculated, i.e.

[ovs-dev] [PATCH] xlate: fix xport lookup for recirc

Xlate_lookup and xlate_lookup_ofproto_() provides in_port and ofproto based on xport determined using flow, which is extracted from packet. The lookup can happen due to recirculation as well. It can happen, that packet_type has been modified during xlate before recirculation is triggered, so the

Re: [ovs-dev] [PATCH 0/3] Fix tunnel neighbor cache population

> > Currenlty, OVS snoops any ARP or ND packets in any bridge and populates > > the tunnel neighbor cache with the retreived data. For instance, when > > ARP reply originated by a tenant is received on an overlay bridge, the > > ARP message is snooped and tunnel neighbor cache is filled with

Re: [ovs-dev] [PATCH] tunnel: fix tnl_find() after packet_type changed

resolve this? Maybe the vanilla code or patch port concept is broken? If we would use the original value of packet_type in tnl_find() we could still workaround this. Best regards, Zoltan > -Original Message- > From: Jan Scheurich > Sent: Friday, December 08, 2017 5:18 PM >

Re: [ovs-dev] [PATCH] tunnel: fix tnl_find() after packet_type changed

ould check > if it is a recirculation upcall, and > only if it is not, it should derive the bridge and the in_port from the flow. > Today the first recirculation check > happens later in upcall_xlate(). > > Can you look into that option and propose a better way to solve the iss

Re: [ovs-dev] [PATCH 2/2] xlate: normalize the actions after translation

> -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Monday, November 13, 2017 8:02 PM > To: Zoltán Balogh <zoltan.bal...@ericsson.com> > Cc: Chandran, Sugesh <sugesh.chand...@intel.com>; d...@openvswitch.org; Jan > Scheurich <jan.scheur...@eric

Re: [ovs-dev] [PATCH 2/2] xlate: normalize the actions after translation

Subject is incorrect, missing v2. Please use this instead: https://mail.openvswitch.org/pipermail/ovs-dev/2017-December/341658.html > -Original Message- > From: Zoltán Balogh > Sent: Wednesday, December 06, 2017 11:55 AM > To: d...@openvswitch.org > Cc: Zoltán Bal

Re: [ovs-dev] [PATCH 2/2] xlate: normalize the actions after translation

Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Tuesday, October 31, 2017 9:30 PM > To: Zoltán Balogh <zoltan.bal...@ericsson.com> > Cc: d...@openvswitch.org > Subject: Re: [ovs-dev] [PATCH 2/2] xlate: normalize the actions after > translation &g

Re: [ovs-dev] [PATCH v2] tests: fix PTAP system test to check only OF stats

30, 2017 10:33 PM > To: Zoltán Balogh <zoltan.bal...@ericsson.com> > Cc: 'd...@openvswitch.org' <d...@openvswitch.org> > Subject: Re: [ovs-dev] [PATCH v2] tests: fix PTAP system test to check only > OF stats > > On Wed, Jul 12, 2017 at 07:22:58AM +, Zoltán Balogh

[ovs-dev] review request

Hi, Could somebody have a look at these old patches, please? https://patchwork.ozlabs.org/patch/803889/ https://patchwork.ozlabs.org/patch/787037/ Best regards, Zoltan ___ dev mailing list d...@openvswitch.org

Re: [ovs-dev] [PATCH v2] netdev-dpdk: reset packet_type for reused dp_packets

; From: Darrell Ball [mailto:db...@vmware.com] > Sent: Friday, September 08, 2017 6:24 PM > To: Zoltán Balogh <zoltan.bal...@ericsson.com>; 'd...@openvswitch.org' > <d...@openvswitch.org> > Subject: Re: [ovs-dev] [PATCH v2] netdev-dpdk: reset packet_type for reuse

[ovs-dev] [PATCH v5] netdev-dpdk: reset packet_type for reused dp_packets

DPDK uses dp-packet pool for storing received packets. The pool is reused by rxq_recv funcions of the DPDK netdevs. The datapath is capable to modify the packet_type property of packets. For instance when encapsulated L3 packets are received on a ptap gre port. In this case the packet_type

Re: [ovs-dev] [PATCH v3] netdev-dpdk: reset packet_type for reused dp_packets

-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh > Sent: Friday, September 08, 2017 12:01 PM > To: 'd...@openvswitch.org' <d...@openvswitch.org> > Subject: [ovs-dev] [PATCH v3] netdev-dpdk: reset packet_type for reused > dp_packets > > DPDK uses dp-packet pool for s

Re: [ovs-dev] [PATCH v2] netdev-dpdk: reset packet_type for reused dp_packets

nal Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh > Sent: Friday, September 08, 2017 10:43 AM > To: 'd...@openvswitch.org' <d...@openvswitch.org> > Subject: [ovs-dev] [PATCH v2] netdev-dpdk: rese

[ovs-dev] [PATCH v3] netdev-dpdk: reset packet_type for reused dp_packets

DPDK uses dp-packet pool for storing received packets. The pool is reused by rxq_recv funcions of the DPDK netdevs. The datapath is capable to modify the packet_type property of packets. For instance when encapsulated L3 packets are received on a ptap gre port. In this case the packet_type

Re: [ovs-dev] [PATCH] netdev-dpdk: reset packet_type for reused dp_packets

12:45 AM > To: Zoltán Balogh <zoltan.bal...@ericsson.com>; 'd...@openvswitch.org' > <d...@openvswitch.org> > Subject: Re: [ovs-dev] [PATCH] netdev-dpdk: reset packet_type for reused > dp_packets > > > > On 9/6/17, 5:12 AM, "ovs-dev-boun...@openvswitc

[ovs-dev] [PATCH v2] netdev-dpdk: reset packet_type for reused dp_packets

DPDK uses dp-packet pool for storing received packets. The pool is reused by rxq_recv funcions of the DPDK netdevs. The datapath is capable to modify the packet_type property of packets. For instance when encapsulated L3 packets are received on a ptap gre port. In this case the packet_type

[ovs-dev] [PATCH] netdev-dpdk: reset packet_type for reused dp_packets

nvoked. This is an additional fix. Signed-off-by: Zoltán Balogh <zoltan.bal...@ericsson.com> Signed-off-by: László Sürü <laszlo.s...@ericsson.com> Co-authored-by: László Sürü <laszlo.s...@ericsson.com> CC: Jan Scheurich <jan.scheur...@ericsson.com> CC: Sugesh Chandran

Re: [ovs-dev] [PATCH v3 0/2] basic encap/decap

vs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Yang, Yi Y > Sent: Wednesday, July 26, 2017 12:52 AM > To: Zoltán Balogh <zoltan.balogh@gmail.com>; d...@openvswitch.org > Subject: Re: [ovs-dev] [PATCH v3 0/2] basic encap/decap > &g

[ovs-dev] [PATCH v3 1/2] OF support and translation of generic encap and decap

From: Jan Scheurich This commit adds support for the OpenFlow actions generic encap and decap (as specified in ONF EXT-382) to the OVS control plane. CLI syntax for encap action with properties: encap(hdr=) encap(hdr=, prop(class=,type=,val=),

[ovs-dev] [PATCH v3 2/2] tests: Extend PTAP unit tests with decap action

From: Zoltan Balogh - Checking decap() prerequisits. - Encap/decap VLAN tagged Ethernet frames. - Send L3 packet over patch port. - Output L2/L3 packet to ports with different packet_type properties. Signed-off-by: Zoltan Balogh

[ovs-dev] [PATCH v3 0/2] basic encap/decap

From: Zoltan Balogh This series is a continuation of other patch series initiated by Jan Scheurich before. These were already applied to the master branch: - userspace: Support for L3 tunneling https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/87.html

Re: [ovs-dev] [PATCH v2 4/4] tunneling: Avoid datapath-recirc by combining recirc actions at xlate.

From: Joe Stringer [mailto:j...@ovn.org] > Sent: Saturday, July 15, 2017 1:46 AM > To: Sugesh Chandran <sugesh.chand...@intel.com> > Cc: ovs dev <d...@openvswitch.org>; Andy Zhou <az...@ovn.org>; Zoltán Balogh > <zoltan.bal...@ericsson.com> > Subject: Re: [PA

[ovs-dev] [PATCH v2 3/3] tests: Extend PTAP unit tests with decap action

From: Zoltán Balogh <zoltan.bal...@ericsson.com> - Checking decap() prerequisits. - Send L3 packet over patch port. - Output L2/L3 packet to ports with different packet_type properties. Signed-off-by: Zoltán Balogh <zoltan.bal...@ericsson.com> Suggested-by: Jan Scheurich

[ovs-dev] [PATCH v2 2/3] OF support and translation of generic encap and decap

the packet type in the OF pipeline without degrading performance. Signed-off-by: Jan Scheurich <jan.scheur...@ericsson.com> Signed-off-by: Yi Yang <yi.y.y...@intel.com> Signed-off-by: Zoltán Balogh <zoltan.bal...@ericsson.com> Co-authored-by: Zoltán Balogh <zoltan.bal...@ericsso

[ovs-dev] [PATCH v2 1/3] ofproto-dpif-xlate: drop L3 packets on L2 legacy port

From: Zoltán Balogh <zoltan.bal...@ericsson.com> This commit drops packet during xlate if it is a L3 packet and output port packet_type is legacy_l2. New PTAP unit test is added. Signed-off-by: Zoltán Balogh <zoltan.bal...@ericsson.com> --- ofproto/ofproto-dpif-

[ovs-dev] [PATCH v2 0/3] basic encap/decap

From: Zoltán Balogh <zoltan.bal...@ericsson.com> This series is a continuation of other patch series initiated by Jan Scheurich before. These were already applied to the master branch: - userspace: Support for L3 tunneling https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/8

Re: [ovs-dev] [PATCH 1/4] Add OF actions for generic encap and decap

Hello Ben, > GCC says: > > ../lib/ofp-actions.c:4189:13: error: cast from 'char *' to 'struct > ofpact_encap *' increases required alignment > from 1 to 4 [-Werror,-Wcast-align] > ../lib/ofp-actions.c:4222:16: error: cast from 'const uint8_t *' (aka > 'const unsigned char *') to

Re: [ovs-dev] [PATCH 3/4] ofproto-dpif-xlate: drop L3 packets on L2 legacy port

Wednesday, July 12, 2017 8:55 AM > To: Ben Pfaff <b...@ovn.org>; Zoltán Balogh <zoltan.bal...@ericsson.com> > Cc: 'd...@openvswitch.org' <d...@openvswitch.org>; Georg Schmuecking > <georg.schmueck...@ericsson.com>; Jiri Benc > (jb...@redhat.com) <jb...@redhat.com&

Re: [ovs-dev] [PATCH] tests: fix PTAP system test to check only OF stats

Thank you for pointing this out! I've sent v2 to the list. https://patchwork.ozlabs.org/patch/787037/ /Zoltan > -Original Message- > From: Darrell Ball [mailto:db...@vmware.com] > Sent: Tuesday, July 11, 2017 6:11 PM > To: Zoltán Balogh <zoltan.bal...@ericsson.com>; 'd.

[ovs-dev] [PATCH v2] tests: fix PTAP system test to check only OF stats

bridges. Datapath flows can be checked in normal PTAP unit tests by running 'make check'. Reported-by: Darrell Ball <db...@vmware.com> Suggested-by: Jan Scheurich <jan.scheur...@ericsson.com> Tested-by: Darrell Ball <db...@vmware.com> Signed-off-by: Zoltán Balogh <zoltan.bal...@eri

Re: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline

eurich > Sent: Tuesday, July 11, 2017 10:26 AM > To: Zoltán Balogh <zoltan.bal...@ericsson.com>; Darrell Ball > <db...@vmware.com>; Yang, Yi Y <yi.y.y...@intel.com>; > Eric Garver <e...@erig.me> > Cc: 'd...@openvswitch.org' <d...@openvswitch.org>; > s

[ovs-dev] [PATCH] tests: fix PTAP system test to check only OF stats

It turned out, checking datapath flow statistics during system-userspace test is not reliable. Unwanted packets can be injected depending on system configuration. As a workaround, this commit removes checking statistics of datapath flows and does check OpenFlow statistics of the integrator

Re: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline

ation of dp flows. Best regards, Zoltan > -Original Message- > From: Darrell Ball [mailto:db...@vmware.com] > Sent: Friday, July 07, 2017 6:56 PM > To: Zoltán Balogh <zoltan.bal...@ericsson.com>; Yang, Yi Y > <yi.y.y...@intel.com>; Eric Garver <e...@erig.me> > Cc:

Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink attribute

Hi Eric, Thank you for fixing this. I'm fine with your solution. Tests do pass. Best regards, Zoltan > This still did not do the trick. The ETHERTYPE is placed at the same > level of the message as OVS_FLOW_ATTR_MASK, rather than being place > _inside_ OVS_FLOW_ATTR_MASK. > > Below is what I

Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink attribute

Hi Eric, I agree, my last patch did not help at all. We have reworked it with Jan, removed the unneeded code parts, it's simpler now. This way, removal of the PACKET_TYPE netlink attribute and adding of ETHER_TYPE netlink attribute happens at the same place. Could you have a look at it and

Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink attribute

; To: Yang, Yi Y <yi.y.y...@intel.com> > Cc: Zoltán Balogh <zoltan.bal...@ericsson.com>; 'd...@openvswitch.org' > <d...@openvswitch.org> > Subject: Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink > attribute > > On Thu, Jul 06, 2017 at 10:14:06AM

Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink attribute

ng, Yi Y [mailto:yi.y.y...@intel.com] > Sent: Thursday, July 06, 2017 11:10 AM > To: Eric Garver <e...@erig.me>; Zoltán Balogh <zoltan.bal...@ericsson.com> > Cc: 'd...@openvswitch.org' <d...@openvswitch.org> > Subject: RE: [ovs-dev] [PATCH v2] dpif-netlink: conv

Re: [ovs-dev] [PATCH] dpif-netilnk: convert packet_type netlink attribute

2017 2:10 AM > To: Eric Garver <e...@erig.me>; Zoltán Balogh <zoltan.bal...@ericsson.com> > Cc: 'd...@openvswitch.org' <d...@openvswitch.org> > Subject: RE: [ovs-dev] [PATCH] dpif-netilnk: convert packet_type netlink > attribute > > Zoltan, I tested this

[ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink attribute

attribute out, before all attributes are sent from userspace to kernel. This commit modifies the put_exclude_packet_type() function to do a proper conversation and add the missing OVS_KEY_ATTR_ETHERTYPE attribute if it's needed. Signed-off-by: Zoltán Balogh <zoltan.bal...@ericsson.com> Reported-by

Re: [ovs-dev] [PATCH] dpif-netilnk: convert packet_type netlink attribute

Thank you for testing! I'm going to fix it. /Zoltan > -Original Message- > From: Yang, Yi Y [mailto:yi.y.y...@intel.com] > Sent: Tuesday, July 04, 2017 2:10 AM > To: Eric Garver <e...@erig.me>; Zoltán Balogh <zoltan.bal...@ericsson.com> > Cc: 'd...@openvswitch

Re: [ovs-dev] [PATCH] dpif-netilnk: convert packet_type netlink attribute

Thank you for reviewing! I'm going to fix it. /Zoltan > -Original Message- > From: Eric Garver [mailto:e...@erig.me] > Sent: Monday, July 03, 2017 8:52 PM > To: Zoltán Balogh <zoltan.bal...@ericsson.com> > Cc: 'd...@openvswitch.org' <d...@openvswitch.org> >

Re: [ovs-dev] [PATCH] packet_type: Force _ETHERTYPE mask in netlink messages

...@erig.me>; d...@openvswitch.org > Cc: Zoltán Balogh <zoltan.bal...@ericsson.com> > Subject: RE: [PATCH] packet_type: Force _ETHERTYPE mask in netlink messages > > Hi Eric, > > Thanks for the catch. We seem to have overlooked this side effect on the > kernel datapath whe

[ovs-dev] [PATCH] dpif-netilnk: convert packet_type netlink attribute

attribute out, before all attributes are sent from userspace to kernel. This commit modifies the put_exclude_packet_type() function to do a proper conversation and add the missing OVS_KEY_ATTR_ETHERTYPE attribute if it's needed. Signed-off-by: Zoltán Balogh <zoltan.bal...@ericsson.com> Reported-by

[ovs-dev] [PATCH 4/4] netdev: fix crash when interface option is changed to invalid value

options:remote_ip=9.9.9 The bug is caused by trying to dereference a NULL pointer. It was introduced by the commit 9fff138ec3a6. Before that, the NULL pointer was handled by the VLOG_WARN_BUF macro. Signed-off-by: Zoltán Balogh <zoltan.bal...@ericsson.com> CC: Daniele Di Proietto <diproiet...@vmware.c

[ovs-dev] [PATCH 3/4] ofproto-dpif-xlate: drop L3 packets on L2 legacy port

This commit drops packet during xlate if it is a L3 packet and output port packet_type is legacy_l2. It completes PTAP unit tests with: - Send L3 packet over patch port. - Output L2/L3 packet to ports with different packet_type properties. Signed-off-by: Zoltán Balogh <zoltan.

[ovs-dev] [PATCH 2/4] Translation of generic encap and decap actions

From: Jan Scheurich This commit implements a skeleton for the translation of generic encap and decap actions in ofproto-dpif and adds support to encap and decap an Ethernet header. In general translation of encap commits pending actions and then rewrites struct flow

[ovs-dev] [PATCH 1/4] Add OF actions for generic encap and decap

From: Jan Scheurich This commit adds support for the OpenFlow actions generic encap and decap (as specified in ONF EXT-382) to the OVS control plane. CLI syntax for encap action with properties: encap(hdr=) encap(hdr=, prop(class=,type=,val=),

[ovs-dev] [PATCH 0/4] basic encap/decap

support to encap and decap an Ethernet header. Furthermore it contains bug fixes. Jan Scheurich (2) Add OF actions for generic encap and decap. Translation of generic encap and decap actions. Zoltán Balogh (2) ofproto-dpif-xlate: drop L3 packets on L2 legacy port. netdev: fix crash when

[ovs-dev] [PATCH v4 7/7] userspace: Introduce packet_type in OF 1.5 packet-out

Introducing packet_type in OF 1.5 packet-out. Partly based on Jean Tourrilhes's work. Add test cases for OF1.5 packet-out Add negative test case for OF1.5 packet-out Signed-off-by: Jean Tourrilhes Signed-off-by: Zoltan Balogh Co-authored-by: Jan

[ovs-dev] [PATCH v4 5/7] tests: Added unit tests in packet-type-aware.at

From: Jan Scheurich First and second unit tests perform basic verification. The third one is a triangular bridge setup test case. It tests dataplane in non-PTAP and ptap bridges in conjunction with L2 and L3 GRE tunnels. It uses veth ports, therefore requires root

[ovs-dev] [PATCH v4 6/7] userspace: Complete Packet In handling

From: Jan Scheurich Send packet_in for non-Ethernet packets. Include packet_type in Packet In for ptap bridges. Signed-off-by: Jan Scheurich Signed-off-by: Ben Pfaff --- lib/flow.c | 4

[ovs-dev] [PATCH v4 3/7] userspace: Add OXM field MFF_PACKET_TYPE

From: Jan Scheurich Allow packet type namespace OFPHTN_ETHERTYPE as alternative pre-requisite for matching L3 protocols (MPLS, IP, IPv6, ARP etc). Change the meta-flow definition of packet_type field to use the new custom format MFS_PACKET_TYPE representing

[ovs-dev] [PATCH v4 4/7] userspace: Handling of versatile tunnel ports

From: Ben Pfaff In netdev_gre_build_header(), GRE protocol and VXLAN next_potocol is set based on packet_type of flow. If it's about an Ethernet packet, it is set to ETP_TYPE_TEB. Otherwise, if the name space is OFPHTN_ETHERNET, it is set according to the name space type.

[ovs-dev] [PATCH v4 2/7] nx-match: Add context argument to nxm_put__().

From: Ben Pfaff An upcoming commit will need to pass an extra piece of data from nx_put_raw() into all of its direct and indirect calls to nxm_put__(). This commit prepares for that by switching from a "struct ofpbuf *" parameter to a context structure that, currently, contains

[ovs-dev] [PATCH v4 1/7] ofpbuf: New function ofpbuf_insert().

From: Ben Pfaff This will receive its first users in an upcoming commit. Signed-off-by: Ben Pfaff --- include/openvswitch/ofpbuf.h | 1 + lib/ofpbuf.c | 18 ++ 2 files changed, 19 insertions(+) diff --git

[ovs-dev] [PATCH v4 0/7] Packet type aware pipeline

t(). nx-match: Add context argument to nxm_put__(). userspace: Handling of versatile tunnel ports Jan Scheurich (3): userspace: Add OXM field MFF_PACKET_TYPE tests: Added unit tests in packet-type-aware.at userspace: Complete Packet In handling Zoltán Balogh (1): userspace: Introduce pa

Re: [ovs-dev] [PATCH v2 12/12] work on packet aware test

sage- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh > Sent: Tuesday, June 20, 2017 6:28 PM > To: Jan Scheurich <jan.scheur...@ericsson.com>; Ben Pfaff <b...@ovn.org>; > d...@openvswitch.org > Subject:

Re: [ovs-dev] [PATCH v2 12/12] work on packet aware test

From: Jan Scheurich Re-introduced packet-type-aware unit tests Reverted test with triangular bridge setup to using patch ports to avoid dependency on veth ports and root privilidges. Adapted to changes in Ben's ptap series. Dependent on patches for using port names

Re: [ovs-dev] [PATCH v3 7/7] userspace: Introduce packet_type in OF 1.5 packet-out

@ovn.org] > Sent: Tuesday, June 20, 2017 4:23 AM > To: d...@openvswitch.org > Cc: Ben Pfaff <b...@ovn.org>; Zoltán Balogh <zoltan.bal...@ericsson.com>; > Jean Tourrilhes <j...@labs.hpe.com>; Jan > Scheurich <jan.scheur...@ericsson.com> > Subject: [PATCH v3

Re: [ovs-dev] [PATCH v2 00/12] Packet type aware pipeline

> > OVS_KEY_ATTR_PACKET_TYPE is represented with OVS_KEY_ATTR_ETHERNET and > > OVS_KEY_ATTR_ETHERTYPE in the kernel. > > From Google doc: > > "The presence of netlink key attribute OVS_KEY_ATTR_ETHERNET is used to > > indicate if it's about L2 or L3 packet on > the netlink interface. The "L3"

Re: [ovs-dev] [PATCH v2 08/12] userspace: Handling of versatile tunnel ports

Hi Ben, I guess you meant "options:packet_type" instead of "other-config:packet_type", since it's about an interface not a bridge property. Best regards, Zoltan > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Tuesday, June 20, 201

Re: [ovs-dev] [PATCH v2 07/12] userspace: Add OXM field MFF_PACKET_TYPE

Hi Ben, I've been testing L2/L3 tunneling and ptap ports receiving/transmitting L2 and L3 packets. I observed, that 'ovs-appctl dpctl/dump-flows' prints out packet_type 'id' in decimal format. For instance, in case of receiving a L3 MPLS packet on a ptap port results in:

Re: [ovs-dev] [PATCH v2 11/12] userspace: Introduce packet_type in OF 1.5 packet-out

inal Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Monday, June 19, 2017 1:30 AM > To: d...@openvswitch.org > Cc: Ben Pfaff <b...@ovn.org>; Zoltán Balogh <zoltan.bal...@ericsson.com>; > Jean Tourrilhes <j...@labs.hpe.com>; Jan > Scheurich <jan.scheur...@

Re: [ovs-dev] [PATCH v2 08/12] userspace: Handling of versatile tunnel ports

Hi Ben, In the lib/meta-flow.xml, you introduced the 'packet type-aware pipeline' concept. You mentioned, controllers can turn off legacy behavior by setting 'other-config:packet-type' bridge property to 'ptap'. As far as I know, you discussed on Friday, there will be only one property for

Re: [ovs-dev] [PATCH v2 00/12] Packet type aware pipeline

> > A new concern came up while thinking about this series. The > OVS_ATTR_PACKET_TYPE does not appear to be implemented in the kernel > module, and what's more, because of #ifdefs, OVS_ATTR_PACKET_TYPE will > actually have a different value in the kernel module than in userspace. > What's the

Re: [ovs-dev] [PATCH v8 3/3] userspace: add vxlan gpe support to vport

Hi, V9 was sent to the mailing list, please review that one: https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/89.html /Zoltan > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh >

Re: [ovs-dev] [PATCH v8 2/3] userspace: L3 tunnel support for GRE and LISP

Hi, V9 was sent to the mailing list, please review that one: https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/88.html /Zoltan > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh >

Re: [ovs-dev] [PATCH v8 1/3] userspace: Switching of L3 packets in L2 pipeline

Hi, V9 was sent to the mailing list, please review that one: https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/86.html /Zoltan > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh >

[ovs-dev] [PATCH v3 3/6] userspace: Handling of versatile tunnel ports

From: Jan Scheurich In netdev_gre_build_header(), GRE protocol and VXLAN next_potocol is set based on packet_type of flow. If it's about an Ethernet packet, it is set to ETP_TYPE_TEB. Otherwise, if the name space is OFPHTN_ETHERNET, it is set according to the name

[ovs-dev] [PATCH v3 1/6] userspace: Add OXM field MFF_PACKET_TYPE

From: Jan Scheurich Allow packet type namespace OFPHTN_ETHERTYPE as alternative pre-requisite for matching L3 protocols (MPLS, IP, IPv6, ARP etc). Change the meta-flow definition of packet_type field to use the new custom format MFS_PACKET_TYPE representing

[ovs-dev] [PATCH v3 2/6] userspace: Add bridge property 'packet-type-aware'

From: Jan Scheurich New boolean parameter "other-config:packet-type-aware' in bridge table. Pass non-Ethernet packets unchanged into packet-type-aware bridges. Do not convert packet type when sending packet from packet-type-aware bridge to a port. Only include field

[ovs-dev] [PATCH v9 3/3] userspace: add vxlan gpe support to vport

From: Georg Schmuecking This patch is based on the "datapath: enable vxlangpe creation in compat mode" from Yi Yang. It introduces an extension option "gpe" to the vxlan port in the netdev-dpdk datapath. Description of vxlan gpe protocoll was added to header file

[ovs-dev] [PATCH v9 0/3] userspace: Support for L3 tunneling

From: Jan Scheurich This patch set is part of an initiative to deal with non-Ethernet packets in OVS for advanced use cases like L3 tunneling or NSH. The initiative is centering on the new OpenFlow concepts of "Packet type-aware pipeline" (PTAP) and "Generic

[ovs-dev] [PATCH v9 1/3] userspace: Switching of L3 packets in L2 pipeline

From: Jan Scheurich Ports have a new layer3 attribute if they send/receive L3 packets. The packet_type included in structs dp_packet and flow is considered in ofproto-dpif. The classical L2 match fields (dl_src, dl_dst, dl_type, and vlan_tci, vlan_vid, vlan_pcp) now

[ovs-dev] [PATCH v2 ] bfd: Detect Multiplier configuration

From: Gábor Szűcs Hi, hereby I'm sending an implementation of configurable BFD Detect Multiplier. Mult value (bfd.DetectMult in RFC5880) is hard-coded and equal to 3 in current openvswitch. As a consequence remote and local mult is the same. In this commit the mult

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

Hi Joe, > Backing up a bit for context, the stats attribution goes roughly like this: > * First upcall, handler thread calls through the translate code with a > packet. The resubmit_stats are derived from that packet. This goes > through xlate_actions(). > * First dump of flow from revalidator

Re: [ovs-dev] [PATCH v7 3/3] userspace: add vxlan gpe support to vport

Hi, Please have a look at v8: https://mail.openvswitch.org/pipermail/ovs-dev/2017-May/332898.html Best regards, Zoltan > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh > Sent: Thursday, May 2

Re: [ovs-dev] [PATCH v7 2/3] userspace: L3 tunnel support for GRE and LISP

Hi, Please have a look at v8: https://mail.openvswitch.org/pipermail/ovs-dev/2017-May/332897.html Best regards, Zoltan > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh > Sent: Thursday, May 2

Re: [ovs-dev] [PATCH v7 1/3] userspace: Switching of L3 packets in L2 pipeline

Hi, Please have a look at v8: https://mail.openvswitch.org/pipermail/ovs-dev/2017-May/332896.html Best regards, Zoltan > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh > Sent: Thursday, May 2

Re: [ovs-dev] [PATCH v7 0/3] userspace: Support for L3 tunneling

://mail.openvswitch.org/pipermail/ovs-dev/2017-May/332898.html Best regards, Zoltan > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh > Sent: Thursday, May 25, 2017 5:37 PM > To: 'd...@open

[ovs-dev] [PATCH v8 3/3] userspace: add vxlan gpe support to vport

From: Georg Schmuecking This patch is based on the "datapath: enable vxlangpe creation in compat mode" from Yi Yang. It introduces an extension option "gpe" to the vxlan port in the netdev-dpdk datapath. Description of vxlan gpe protocoll was added to header file

[ovs-dev] [PATCH v8 2/3] userspace: L3 tunnel support for GRE and LISP

From: Jan Scheurich Add a boolean "layer3" configuration option for tunnel vports. The layer3 option defaults to false for all ports except LISP. GRE ports accept both true and false for "layer3". A tunnel vport configured with layer3=true receives L3 packets. which

[ovs-dev] [PATCH v8 1/3] userspace: Switching of L3 packets in L2 pipeline

From: Jan Scheurich Ports have a new layer3 attribute if they send/receive L3 packets. The packet_type included in structs dp_packet and flow is considered in ofproto-dpif. The classical L2 match fields (dl_src, dl_dst, dl_type, and vlan_tci, vlan_vid, vlan_pcp) now

[ovs-dev] [PATCH v8 0/3] userspace: Support for L3 tunneling

From: Jan Scheurich This patch set is part of an initiative to deal with non-Ethernet packets in OVS for advanced use cases like L3 tunneling or NSH. The initiative is centering on the new OpenFlow concepts of "Packet type-aware pipeline" (PTAP) and "Generic

[ovs-dev] [PATCH v7 3/3] userspace: add vxlan gpe support to vport

From: Georg Schmuecking This patch is based on the "datapath: enable vxlangpe creation in compat mode" from Yi Yang. It introduces an extension option "gpe" to the vxlan port in the netdev-dpdk datapath. Description of vxlan gpe protocoll was added to header file

[ovs-dev] [PATCH v7 2/3] userspace: L3 tunnel support for GRE and LISP

From: Jan Scheurich Add a boolean "layer3" configuration option for tunnel vports. The layer3 option defaults to false for all ports except LISP. GRE ports accept both true and false for "layer3". A tunnel vport configured with layer3=true receives L3 packets. which

[ovs-dev] [PATCH v7 1/3] userspace: Switching of L3 packets in L2 pipeline

From: Jan Scheurich Ports have a new layer3 attribute if they send/receive L3 packets. The packet_type included in structs dp_packet and flow is considered in ofproto-dpif. The classical L2 match fields (dl_src, dl_dst, dl_type, and vlan_tci, vlan_vid, vlan_pcp) now

[ovs-dev] [PATCH v7 0/3] userspace: Support for L3 tunneling

From: Jan Scheurich This patch set is part of an initiative to deal with non-Ethernet packets in OVS for advanced use cases like L3 tunneling or NSH. The initiative is centering on the new OpenFlow concepts of "Packet type-aware pipeline" (PTAP) and "Generic

[ovs-dev] [PATCH v2 5/6] userspace: Complete Packet In handling

From: Jan Scheurich Send packet_in for non-Ethernet packets. Include packet_type in Packet In for ptap bridges. Signed-off-by: Jan Scheurich --- lib/flow.c | 4 lib/ofp-print.c | 3 +--

[ovs-dev] [PATCH v2 4/6] tests: Added unit tests in packet-type-aware.at

From: Jan Scheurich Packet type-aware unit tests. ptap - create packet-type-aware bridge ptap - legal flow entries in ptap bridge ptap - triangle bridge setup with L2 and L3 GRE tunnels First and second unit tests perform basic verification. The third one is a

  1   2   >