Re: [ovs-dev] [PATCH] ofp-actions: Correct execution of encap/decap actions in action set
Jan, sorry for late reply, I have been waiting for Sangfor guy's confirmation.
With this patch https://patchwork.ozlabs.org/patch/895405/, they won't have any
issue any more. So now it can work well, thank you so much.
-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Monday, April 9, 2018 3:12 PM
To: Yang, Yi Y ; d...@openvswitch.org
Subject: RE: [PATCH] ofp-actions: Correct execution of encap/decap actions in
action set
Hi Yi,
The assertion failure is indeed caused by the incorrect implementation of
double encap() and should be fixed by the patch you mention (which is merged to
master by now).
Prior to the below fix this happened with every encap(nsh) in an group bucket.
I can't say why it still happens periodically every few minutes in your test.
You'd need to carefully analyze a crash dump to try to understand the packet
processing history that leads to a double encap() or perhaps decap().
It is definitely worth trying whether the problem is already resolved on the
latest master.
BR, Jan
> -Original Message-
> From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
> Sent: Sunday, 08 April, 2018 10:27
> To: Jan Scheurich ; d...@openvswitch.org
> Subject: RE: [PATCH] ofp-actions: Correct execution of encap/decap
> actions in action set
>
> Hi, Jan
>
> Sangfor guy tried this one, he still encountered assert issue after
> ovs ran for about 20 minutes, moreover it appeared periodically. I'm not sure
> if https://patchwork.ozlabs.org/patch/895405/ is helpful for this issue. Do
> you think what the root cause is?
>
> -Original Message-
> From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
> Sent: Monday, March 26, 2018 3:36 PM
> To: d...@openvswitch.org
> Cc: Yang, Yi Y ; Jan Scheurich
>
> Subject: [PATCH] ofp-actions: Correct execution of encap/decap actions
> in action set
>
> The actions encap, decap and dec_nsh_ttl were wrongly flagged as
> set_field actions in ofpact_is_set_or_move_action(). This caused them
> to be executed twice in the action set or a group bucket, once
> explicitly in
> ofpacts_execute_action_set() and once again as part of the list of set_field
> or move actions.
>
> Fixes: f839892a ("OF support and translation of generic encap and
> decap")
> Fixes: 491e05c2 ("nsh: add dec_nsh_ttl action")
>
> Signed-off-by: Jan Scheurich
>
> ---
>
> The fix should be backported to OVS 2.9 and OVS 2.8 (without the case for
> OFPACT_DEC_NSH_TTL introduced in 2.9).
>
>
> lib/ofp-actions.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c index
> db85716..87797bc 100644
> --- a/lib/ofp-actions.c
> +++ b/lib/ofp-actions.c
> @@ -6985,9 +6985,6 @@ ofpact_is_set_or_move_action(const struct ofpact *a)
> case OFPACT_SET_TUNNEL:
> case OFPACT_SET_VLAN_PCP:
> case OFPACT_SET_VLAN_VID:
> -case OFPACT_ENCAP:
> -case OFPACT_DECAP:
> -case OFPACT_DEC_NSH_TTL:
> return true;
> case OFPACT_BUNDLE:
> case OFPACT_CLEAR_ACTIONS:
> @@ -7025,6 +7022,9 @@ ofpact_is_set_or_move_action(const struct ofpact *a)
> case OFPACT_WRITE_METADATA:
> case OFPACT_DEBUG_RECIRC:
> case OFPACT_DEBUG_SLOW:
> +case OFPACT_ENCAP:
> +case OFPACT_DECAP:
> +case OFPACT_DEC_NSH_TTL:
> return false;
> default:
> OVS_NOT_REACHED();
> --
> 1.9.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofp-actions: Correct execution of encap/decap actions in action set
Hi, Jan
Sangfor guy tried this one, he still encountered assert issue after ovs ran for
about 20 minutes, moreover it appeared periodically. I'm not sure if
https://patchwork.ozlabs.org/patch/895405/ is helpful for this issue. Do you
think what the root cause is?
-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Monday, March 26, 2018 3:36 PM
To: d...@openvswitch.org
Cc: Yang, Yi Y ; Jan Scheurich
Subject: [PATCH] ofp-actions: Correct execution of encap/decap actions in
action set
The actions encap, decap and dec_nsh_ttl were wrongly flagged as set_field
actions in ofpact_is_set_or_move_action(). This caused them to be executed
twice in the action set or a group bucket, once explicitly in
ofpacts_execute_action_set() and once again as part of the list of set_field or
move actions.
Fixes: f839892a ("OF support and translation of generic encap and decap")
Fixes: 491e05c2 ("nsh: add dec_nsh_ttl action")
Signed-off-by: Jan Scheurich
---
The fix should be backported to OVS 2.9 and OVS 2.8 (without the case for
OFPACT_DEC_NSH_TTL introduced in 2.9).
lib/ofp-actions.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c index db85716..87797bc 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -6985,9 +6985,6 @@ ofpact_is_set_or_move_action(const struct ofpact *a)
case OFPACT_SET_TUNNEL:
case OFPACT_SET_VLAN_PCP:
case OFPACT_SET_VLAN_VID:
-case OFPACT_ENCAP:
-case OFPACT_DECAP:
-case OFPACT_DEC_NSH_TTL:
return true;
case OFPACT_BUNDLE:
case OFPACT_CLEAR_ACTIONS:
@@ -7025,6 +7022,9 @@ ofpact_is_set_or_move_action(const struct ofpact *a)
case OFPACT_WRITE_METADATA:
case OFPACT_DEBUG_RECIRC:
case OFPACT_DEBUG_SLOW:
+case OFPACT_ENCAP:
+case OFPACT_DECAP:
+case OFPACT_DEC_NSH_TTL:
return false;
default:
OVS_NOT_REACHED();
--
1.9.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS will hit an assert if encap(nsh) is done in bucket of group
Jan, thank you so much, very exhaustive analysis :), I'll double check your fix patch. From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] Sent: Sunday, March 25, 2018 9:09 AM To: Yang, Yi Y Cc: d...@openvswitch.org; Zoltán Balogh Subject: RE: OVS will hit an assert if encap(nsh) is done in bucket of group Hi Yi, Part of the seemingly strange behavior of the encap(nsh) action in a group is caused by the (often forgotten) fact that group buckets do not contain action *lists* but action *sets*. I have no idea why it was defined like this when groups were first introduced in OpenFlow 1.1. In my view it was a bad decision and causes a lot of limitation for using groups. But that's the way it is. In action sets there can only be one action of a kind (except for set_field, where there can be one action per target field). If there are multiple actions of the same kind specified, only the last one taken, the earlier ones ignored. Furthermore, the order of execution of the actions in the action set is not given by the order in which they are listed but defined by the OpenFlow standard (see chapter 5.6 of OF spec 1.5.1). Of course the generic encap() and decap() actions are not standardized yet, so the OF spec doesn't specify where to put them in the sequence. We had to implement something that follows the spirit of the specification, knowing that whatever we chose may fit some but won't fit many other legitimate use cases. OVS's order is defined in ofpacts_execute_action_set() in ofp-actions.c: OFPACT_STRIP_VLAN OFPACT_POP_MPLS OFPACT_DECAP OFPACT_ENCAP OFPACT_PUSH_MPLS OFPACT_PUSH_VLAN OFPACT_DEC_TTL OFPACT_DEC_MPLS_TTL OFPACT_DEC_NSH_TTL All OFP_ACT SET_FIELD and OFP_ACT_MOVE (target) OFPACT_SET_QUEUE Now, your specific group bucket use case: encap(nsh),set_field:->nsh_xxx,output:vxlan_gpe_port should be a lucky fit and execute as expected, whereas the analogous use case encap(nsh),set_field:->nsh_xxx,encap(ethernet), output:ethernet_port fails with the error Dropping packet as encap(ethernet) is not supported for packet type ethernet. because the second encap(ethernet) action replaces the encap(nsh) in the action set and is executed first on the original received Ethernet packet. Boom! So, why does your valid use case cause an assertion failure? It's a consequence of two faults: 1. In the conversion of the group bucket's action list to the bucket action set in ofpacts_execute_action_set() the action list is filtered with ofpact_is_set_or_move_action() to select the set_field actions. This function incorrectly flagged OFPACT_ENCAP, OFPACT_DECAP and OFPACT_DEC_NSH_TTL as set_field actions. That's why the encap(nsh) action is wrongly copied twice to the action set. 2. The translation of the second encap(nsh) action in the action set doesn't change the packet_type as it is already (1,0x894f). Hence, the commit_packet_type_change() triggered at output to vxlan_gpe port misses to generate a second encap_nsh datapath action. The logic here is obviously not complete to cover the NSH in NSH use case that we intended to support and must be enhanced. The commit of the changes to the NSH header in commit_set_nsh_action() then triggers assertion failure because the translation of the second encap(nsh) action did overwrite the original nsh_np (0x3 for Ethernet in NSH) in the flow with 0x4 (for NSH in NSH). Since it is not allowed to modify the nsh_np with set_field this is what triggers the assertion. I believe this assertion to be correct. It did detect the combination of the above two faults. The solution to 1 is trivial. I'll post a bug fix straight away. That should suffice for your problem. The solution to 2 requires a bit more thinking. I will send a fix when I have found it. BR, Jan > -Original Message- > From: Yang, Yi [mailto:yi.y.y...@intel.com] > Sent: Friday, 23 March, 2018 08:55 > To: Jan Scheurich > mailto:jan.scheur...@ericsson.com>> > Cc: d...@openvswitch.org<mailto:d...@openvswitch.org>; Zoltán Balogh > mailto:zoltan.bal...@ericsson.com>> > Subject: Re: OVS will hit an assert if encap(nsh) is done in bucket of group > > On Fri, Mar 23, 2018 at 07:51:45AM +, Jan Scheurich wrote: > > Hi Yi, > > > > Could you please provide the OF pipeline (flows and groups) and an > > ofproto/trace command that triggers that fault? > > > > Thanks, Jan > > Hi, Jan > > my br-int has the below ports: > > 1(dpdk0): addr:08:00:27:c6:9f:ff > config: 0 > state: LIVE > current:1GB-FD AUTO_NEG > speed: 1000 Mbps now, 0 Mbps max > 2(vxlangpe1): addr:16:04:0c:e5:f1:2c > config: 0 > state: LIVE > speed: 0 Mbps now, 0 Mbps max
Re: [ovs-dev] when the physical compute receive vxlan-gpe-nsh packet whose size>256, the ovs flow table not match and ovs crash.
Ovs 2.8 can't support kernel data path for NSH, are you sure you're using OVS-DPDK. -Original Message- From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Glend REN Sent: Friday, March 9, 2018 7:33 PM To: ovs-dev@openvswitch.org Subject: [ovs-dev] when the physical compute receive vxlan-gpe-nsh packet whose size>256, the ovs flow table not match and ovs crash. Hi all: Now I use vxlan-gpe-nsh with ovs-2.8.0 The environment is : compute1 and compute2 wth ovs2.8.0 installed. the two computes are both physical servers. A vm of the compute1 sends a icmp packet, when the packet arrives the br-int of the compute1, it will be encapsulated vxlan-gpe-nsh, and sent to the compute2. But the strange problem is if the size of icmp packet< 126 byte(vxlan-gpe-nsh packet <256), the communication is normal. If the size >126, after arriving compute2 ,the flow table not match the packet., and >if ping several times, the network and ovs of compute2 collapse ：The network connection goes down for one minute,and one minute later the network recovery;The ovs stop and the kernel module is deleted; All the OVS br-int virtual machine tap port is deleted, unable to connect to the controller. If the icmp packet is not encapsulated by vxlan-gpe-nsh but only vxlan-gpe, no matter what the size is ,the communication is normal. And if compue1 and compute2 are not physical servers, but the virtual machine, regardless of the size of ICMP packet , through the vxlan-gpe-nsh encapsulation the communication is normal. It is that now the physical environment has above problems, but the virtual environment is normal. so can you tell me how to solve the problems? Thank you ! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode
It still failed. Does "encap ip" require any special kernel module? vagrant@gbpsfc4:~/ovs-nsh-test$ export PATH=/home/vagrant/iproute2-4.9.0/ip:$PATH vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip link add dev at_vxlan1 type vxlan dstport 4790 external gpe vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip addr add dev at_vxlan1 10.1.1.1/24 vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip link set dev at_vxlan1 mtu 1450 up vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1 RTNETLINK answers: Operation not supported vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip id 1 dst 172.31.1.100 dev at_vxlan1 RTNETLINK answers: Operation not supported vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip dst 172.31.1.100 dev at_vxlan1 RTNETLINK answers: Operation not supported vagrant@gbpsfc4:~/ovs-nsh-test$ lsmod Module Size Used by vxlan 53248 0 ip6_udp_tunnel 16384 1 vxlan udp_tunnel 16384 1 vxlan ip6_tunnel 32768 0 tunnel616384 1 ip6_tunnel ipip 16384 0 tunnel416384 1 ipip ip_tunnel 24576 1 ipip veth 16384 0 nf_conntrack_ipv6 20480 0 nf_defrag_ipv6 36864 1 nf_conntrack_ipv6 xt_addrtype16384 2 xt_conntrack 16384 1 ipt_MASQUERADE 16384 1 nf_nat_masquerade_ipv416384 1 ipt_MASQUERADE iptable_nat16384 1 dm_crypt 36864 0 nf_conntrack_ipv4 16384 3 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 nf_nat_ipv416384 1 iptable_nat nf_nat 28672 2 nf_nat_masquerade_ipv4,nf_nat_ipv4 nf_conntrack 131072 7 nf_conntrack_ipv6,nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat bridge143360 0 stp16384 1 bridge llc16384 2 bridge,stp dm_thin_pool 65536 1 dm_persistent_data 69632 1 dm_thin_pool dm_bio_prison 20480 1 dm_thin_pool dm_bufio 28672 1 dm_persistent_data libcrc32c 16384 3 nf_conntrack,dm_persistent_data,nf_nat nfsd 299008 2 iptable_filter 16384 1 ip_tables 24576 2 iptable_filter,iptable_nat x_tables 36864 5 ip_tables,iptable_filter,ipt_MASQUERADE,xt_addrtype,xt_conntrack auth_rpcgss57344 1 nfsd nfs_acl16384 1 nfsd nfs 241664 0 lockd 90112 2 nfsd,nfs grace 16384 2 nfsd,lockd sunrpc327680 6 auth_rpcgss,nfsd,nfs_acl,lockd,nfs fscache65536 1 nfs psmouse 139264 0 e1000 139264 0 ppdev 20480 0 parport_pc 32768 0 i2c_piix4 24576 0 mac_hid16384 0 sb_edac24576 0 serio_raw 16384 0 lp 20480 0 parport49152 3 lp,parport_pc,ppdev pata_acpi 16384 0 video 40960 0 vagrant@gbpsfc4:~/ovs-nsh-test$ -Original Message- From: Eric Garver [mailto:e...@erig.me] Sent: Thursday, February 1, 2018 5:10 AM To: Yang, Yi Y Cc: d...@openvswitch.org Subject: Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode On Wed, Jan 31, 2018 at 02:12:14PM +0000, Yang, Yi Y wrote: > Hi, Eric > > My kernel is 4.13.0-rc6, so I'm very sure it can support vxlan-gpe, I > can add vxlan-gpe port without any issue by command line, so I don't > know what happened. Your output below indicates this is failing on this line: 25 NS_CHECK_EXEC([at_ns0], [ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1]) It does not appear to be an OVS issue. Maybe encap id 0 is not accepted on older kernels. Try changing it to a non-zero value. > > Greg, I checked unit tests in tests/system-traffic.at and > tests/system-layer3-tunnels.at for vxlan and vxlan-gpe, I think they are very > tricky, for NSH, they won't work, current test infrastructure can't handle > NSH unit test in kernel data path, so I don't think I can add it. I have > posted v2 patch series, I have sfc test environment in my machine and have > verified kernel data path, my test environment has two vagrant VMs, each one > VM starts two containers which play SF roles, end-to-end ping and http are > both ok. > > -Original Message- > From: Eric Garver [mailto:e...@erig.me] > Sent: Tuesday, January 30, 2018 9:53 PM > To: Yang, Yi Y > Cc: Gregory Rose ; d...@openvswitch.org > Subject: Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in > kernel compat mode > > On Tue, Jan 30, 2018 at 11:33:55AM +, Yang, Yi Y wrote: > > Hi, Greg > > > &g
Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode
Hi, Eric
My kernel is 4.13.0-rc6, so I'm very sure it can support vxlan-gpe, I can add
vxlan-gpe port without any issue by command line, so I don't know what happened.
Greg, I checked unit tests in tests/system-traffic.at and
tests/system-layer3-tunnels.at for vxlan and vxlan-gpe, I think they are very
tricky, for NSH, they won't work, current test infrastructure can't handle NSH
unit test in kernel data path, so I don't think I can add it. I have posted v2
patch series, I have sfc test environment in my machine and have verified
kernel data path, my test environment has two vagrant VMs, each one VM starts
two containers which play SF roles, end-to-end ping and http are both ok.
-Original Message-
From: Eric Garver [mailto:e...@erig.me]
Sent: Tuesday, January 30, 2018 9:53 PM
To: Yang, Yi Y
Cc: Gregory Rose ; d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel
compat mode
On Tue, Jan 30, 2018 at 11:33:55AM +, Yang, Yi Y wrote:
> Hi, Greg
>
> I installed linux 3.10.107 in Ubuntu 14.04 and fixed
> skb_gso_error_unwind issue, but for unit test,
> tests/system-layer3-tunnels.at is a good reference for it because we
> used vxlan-gpe for nsh, I ran unit test 90, but it always fails (I
> have installed and used net-next kernel and the latest iproute2)
>
> Here is error log
>
> ./system-layer3-tunnels.at:25: ip netns exec at_ns0 sh <<
> NS_EXEC_HEREDOC ip route add 10.1.1.2/32 encap ip id 0 dst
> 172.31.1.100 dev at_vxlan1 NS_EXEC_HEREDOC
> --- /dev/null 2018-01-30 02:18:43.272647961 +
> +++
> /home/vagrant/ovs-nsh-test/tests/system-kmod-testsuite.dir/at-groups/90/stderr
> 2018-01-30 09:45:15.415934534 +
> @@ -0,0 +1 @@
> +RTNETLINK answers: Operation not supported
> ./system-layer3-tunnels.at:25: exit code was 2, expected 0
>
> I think my system missed something so “ip route add 10.1.1.2/32 encap
> ip id 0 dst 172.31.1.100 dev at_vxlan1 “ failed, Eric, what linux
> distribution do you know I can run “ping over VXLAN-GPE” successfully, I’ll
> use it as baseline to add NSH unit test for kernel data path.
When I added the tests it was on RHEL-7.4 with a net-next kernel. It should
skip the tests if the installed iproute2 does not have the options for GPE.
The error you're seeing likely means your kernel does not have GPE support.
VXLAN-GPE first appeared in kernel 4.7.
e1e5314de08b ("vxlan: implement GPE")
As such, I think the VXLAN-GPE test case should pass on any distro with a 4.7+
kernel.
>
> From: Gregory Rose [mailto:gvrose8...@gmail.com]
> Sent: Tuesday, January 30, 2018 1:51 AM
> To: Yang, Yi Y ; d...@openvswitch.org
> Cc: b...@ovn.org; jan.scheur...@ericsson.com
> Subject: Re: [PATCH v1 0/5] datapath: enable NSH support in kernel
> compat mode
>
> On 1/10/2018 11:53 PM, Yi Yang wrote:
>
>
> This patch series is to backport NSH support patches in Linux net-next
> tree
>
> to OVS in order that it can support NSH in kernel compat mode.
>
>
>
> Yi Yang (5):
>
> datapath: ether: add NSH ethertype
>
> datapath: vxlan: factor out VXLAN-GPE next protocol
>
> datapath: net: add NSH header structures and helpers
>
> datapath: nsh: add GSO support
>
> datapath: enable NSH support
>
>
>
> NEWS | 1 +
>
> datapath/Modules.mk | 4 +-
>
> datapath/actions.c| 116
>
> datapath/datapath.c | 4 +
>
> datapath/flow.c | 51
>
> datapath/flow.h | 7 +
>
> datapath/flow_netlink.c | 343
> +-
>
> datapath/flow_netlink.h | 5 +
>
> datapath/linux/Modules.mk | 2 +
>
> datapath/linux/compat/include/linux/if_ether.h| 4 +
>
> datapath/linux/compat/include/linux/openvswitch.h | 6 +-
>
> datapath/linux/compat/include/net/nsh.h | 313
>
> datapath/linux/compat/include/net/tun_proto.h | 49
>
> datapath/linux/compat/include/net/vxlan.h | 6 -
>
> datapath/linux/compat/vxlan.c | 32 +-
>
> datapath/nsh.c| 142 +
>
> 16 files changed, 1048 insertions(+), 37 deletions(-)
>
> create mode 100644 datapath/linux/compat/include/net/nsh.h
>
> create mode 100644 datapath/linux/compat/include/net/tun_proto.h
>
> create mode 100644 datapath/nsh.c
>
>
>
> Hi Yi,
>
> My apologies for the del
Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode
Hi, Greg I installed linux 3.10.107 in Ubuntu 14.04 and fixed skb_gso_error_unwind issue, but for unit test, tests/system-layer3-tunnels.at is a good reference for it because we used vxlan-gpe for nsh, I ran unit test 90, but it always fails (I have installed and used net-next kernel and the latest iproute2) Here is error log ./system-layer3-tunnels.at:25: ip netns exec at_ns0 sh << NS_EXEC_HEREDOC ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1 NS_EXEC_HEREDOC --- /dev/null 2018-01-30 02:18:43.272647961 + +++ /home/vagrant/ovs-nsh-test/tests/system-kmod-testsuite.dir/at-groups/90/stderr 2018-01-30 09:45:15.415934534 + @@ -0,0 +1 @@ +RTNETLINK answers: Operation not supported ./system-layer3-tunnels.at:25: exit code was 2, expected 0 I think my system missed something so “ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1 “ failed, Eric, what linux distribution do you know I can run “ping over VXLAN-GPE” successfully, I’ll use it as baseline to add NSH unit test for kernel data path. From: Gregory Rose [mailto:gvrose8...@gmail.com] Sent: Tuesday, January 30, 2018 1:51 AM To: Yang, Yi Y ; d...@openvswitch.org Cc: b...@ovn.org; jan.scheur...@ericsson.com Subject: Re: [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode On 1/10/2018 11:53 PM, Yi Yang wrote: This patch series is to backport NSH support patches in Linux net-next tree to OVS in order that it can support NSH in kernel compat mode. Yi Yang (5): datapath: ether: add NSH ethertype datapath: vxlan: factor out VXLAN-GPE next protocol datapath: net: add NSH header structures and helpers datapath: nsh: add GSO support datapath: enable NSH support NEWS | 1 + datapath/Modules.mk | 4 +- datapath/actions.c| 116 datapath/datapath.c | 4 + datapath/flow.c | 51 datapath/flow.h | 7 + datapath/flow_netlink.c | 343 +- datapath/flow_netlink.h | 5 + datapath/linux/Modules.mk | 2 + datapath/linux/compat/include/linux/if_ether.h| 4 + datapath/linux/compat/include/linux/openvswitch.h | 6 +- datapath/linux/compat/include/net/nsh.h | 313 datapath/linux/compat/include/net/tun_proto.h | 49 datapath/linux/compat/include/net/vxlan.h | 6 - datapath/linux/compat/vxlan.c | 32 +- datapath/nsh.c| 142 + 16 files changed, 1048 insertions(+), 37 deletions(-) create mode 100644 datapath/linux/compat/include/net/nsh.h create mode 100644 datapath/linux/compat/include/net/tun_proto.h create mode 100644 datapath/nsh.c Hi Yi, My apologies for the delay in reviewing this series. I've finished up my review and I think it mostly looks pretty good but I did find an issue compiling on a 3.10.107 kernel build: CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/vport-netdev.o /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:17: error: undefined identifier 'skb_gso_error_unwind' CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: In function ‘nsh_gso_segment’: /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:3: error: implicit declaration of function ‘skb_gso_error_unwind’ [-Werror=implicit-function-declaration] skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len, ^ cc1: some warnings being treated as errors make[3]: *** [/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [_module_/home/travis/build/gvrose8192/ovs-experimental/datapath/linux] Error 2 make[2]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/linux-3.10.107' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/datapath/linux' make: *** [all-recursive] Error 1 So we'll need to fix that up and I also think the patches will need to be rebased to current master. That second part is my fault... so sorry again about that. One other thing, I ran this through our standard 'make check and make check-kmod' tests and everything was fine so the patches don't seem break anything. I'm still concerned though that the test coverage probably didn't hit any parts of your code. I'm wondering if there is some way I can test the code path and get some test coverage there. Could you write up a self test for the tests/system-traffic.at kernel test? Of if that's
Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode
Greg, thank you so much for your reviewing, which Linux distribution version has linux-3.10.107 kernel? I’ll add a test case for kernel datapath, fix compiling issue on linux-3.10.107 and rebase it to master. From: Gregory Rose [mailto:gvrose8...@gmail.com] Sent: Tuesday, January 30, 2018 1:51 AM To: Yang, Yi Y ; d...@openvswitch.org Cc: b...@ovn.org; jan.scheur...@ericsson.com Subject: Re: [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode On 1/10/2018 11:53 PM, Yi Yang wrote: This patch series is to backport NSH support patches in Linux net-next tree to OVS in order that it can support NSH in kernel compat mode. Yi Yang (5): datapath: ether: add NSH ethertype datapath: vxlan: factor out VXLAN-GPE next protocol datapath: net: add NSH header structures and helpers datapath: nsh: add GSO support datapath: enable NSH support NEWS | 1 + datapath/Modules.mk | 4 +- datapath/actions.c| 116 datapath/datapath.c | 4 + datapath/flow.c | 51 datapath/flow.h | 7 + datapath/flow_netlink.c | 343 +- datapath/flow_netlink.h | 5 + datapath/linux/Modules.mk | 2 + datapath/linux/compat/include/linux/if_ether.h| 4 + datapath/linux/compat/include/linux/openvswitch.h | 6 +- datapath/linux/compat/include/net/nsh.h | 313 datapath/linux/compat/include/net/tun_proto.h | 49 datapath/linux/compat/include/net/vxlan.h | 6 - datapath/linux/compat/vxlan.c | 32 +- datapath/nsh.c| 142 + 16 files changed, 1048 insertions(+), 37 deletions(-) create mode 100644 datapath/linux/compat/include/net/nsh.h create mode 100644 datapath/linux/compat/include/net/tun_proto.h create mode 100644 datapath/nsh.c Hi Yi, My apologies for the delay in reviewing this series. I've finished up my review and I think it mostly looks pretty good but I did find an issue compiling on a 3.10.107 kernel build: CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/vport-netdev.o /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:17: error: undefined identifier 'skb_gso_error_unwind' CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: In function ‘nsh_gso_segment’: /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:3: error: implicit declaration of function ‘skb_gso_error_unwind’ [-Werror=implicit-function-declaration] skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len, ^ cc1: some warnings being treated as errors make[3]: *** [/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [_module_/home/travis/build/gvrose8192/ovs-experimental/datapath/linux] Error 2 make[2]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/linux-3.10.107' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/datapath/linux' make: *** [all-recursive] Error 1 So we'll need to fix that up and I also think the patches will need to be rebased to current master. That second part is my fault... so sorry again about that. One other thing, I ran this through our standard 'make check and make check-kmod' tests and everything was fine so the patches don't seem break anything. I'm still concerned though that the test coverage probably didn't hit any parts of your code. I'm wondering if there is some way I can test the code path and get some test coverage there. Could you write up a self test for the tests/system-traffic.at kernel test? Of if that's not practical is there some other way I could test this code? Thanks, - Greg ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] FYI: NSH is an ITEF standard RFC 8300 now
NSH RFC: https://tools.ietf.org/html/rfc8300 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] nsh: rework NSH netlink keys and actions
Jan, MD2 is flexible enough, so we mustn't worry there will be one MDx, it is
very weird to use OVS_NSH_PUSH_ATTR_CONTEXT as sub key of OVS_KEY_ATTR_NSH.
For PUSH_NSH, the below format is clear enough, it won't make people confused.
Yes, maybe we won't use OVS_NSH_KEY_ATTR_MD2 to transfer MD2 match fields, but
this isn't a good reason why we want to use a worse name.
OVS_ACTION_ATTR_PUSH_NSH
-- OVS_NSH_KEY_ATTR_BASE
-- OVS_NSH_KEY_ATTR_MD1
Or
OVS_ACTION_ATTR_PUSH_NSH
-- OVS_NSH_KEY_ATTR_BASE
-- OVS_NSH_KEY_ATTR_MD2
I have worked out a version with ttl key and aligned to the lasted NSH draft, I
have double confirmed from its author, this will be final version, NSH header
format won't be changed anymore except some text changes, I'll send out this
version today to catch up with OVS guys' review, kernel version will be sent
out later today.
If other guys think your change is reasonable enough, I will send out next
version with this, but now I don't think we have strong reason to change it.
-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Thursday, August 17, 2017 8:04 PM
To: Yang, Yi Y ; d...@openvswitch.org
Subject: RE: [ovs-dev] [PATCH] nsh: rework NSH netlink keys and actions
Hi Yi,
As discussed please adjust the netlink uAPI for NSH as follows:
OVS_KEY_ATTR_NSH
-- OVS_NSH_KEY_ATTR_BASEmandatory
-- OVS_NSH_KEY_ATTR_MD1 conditional: if mdtype=MD1
OVS_ACTION_ATTR_PUSH_NSH
-- OVS_NSH_KEY_ATTR_BASEmandatory
-- OVS_NSH_PUSH_ATTR_CONTEXTconditional: currently if MD1 or
MD2 with TLV encap properties
OVS_ACTION_ATTR_POP_NSH no data
Remove OVS_NSH_KEY_ATTR_MD2 because the MD2 context headers will not
be modelled as dedicated key fields but mapped to some generic TLV fields,
similar to but independent from the current tunnel metadata TLV registers.
Using the name OVS_NSH_KEY_ATTR_MD2 for the opaque context data in
PUSH_NSH would be misleading as the variable length byte array can carry
any type of metadata format: MD1, MD2, or any future MD type. For that
reason I prefer the generic name OVS_NSH_PUSH_ATTR_CONTEXT.
Note that this attribute will not be used as part of the NSH key, so you might
consider generalizing the NSH attribute enum definition to
enum ovs_nsh_attr {
OVS_NSH_KEY_ATTR_BASE, /* struct ovs_nsh_key_base. */
OVS_NSH_KEY_ATTR_MD1, /* struct ovs_nsh_key_md1. */
OVS_NSH_PUSH_ATTR_CONTEXT, /* opaque context headers */
__OVS_NSH_ATTR_MAX
};
BR, Jan
> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Yi Yang
> Sent: Wednesday, 16 August, 2017 09:56
> To: d...@openvswitch.org
> Subject: [ovs-dev] [PATCH] nsh: rework NSH netlink keys and actions
>
> Per kernel data path requirements, this patch changes
> OVS_KEY_ATTR_NSH
> to nested attribute and adds three new NSH sub attribute keys:
>
> OVS_NSH_KEY_ATTR_BASE: for length-fixed NSH base header
> OVS_NSH_KEY_ATTR_MD1: for length-fixed MD type 1 context
> OVS_NSH_KEY_ATTR_MD2: for length-variable MD type 2 metadata
>
> NSH match fields, set and PUSH_NSH action all use the below
> nested attribute format:
>
> OVS_KEY_ATTR_NSH begin
> OVS_NSH_KEY_ATTR_BASE
> OVS_NSH_KEY_ATTR_MD1
> OVS_KEY_ATTR_NSH end
>
> or
>
> OVS_KEY_ATTR_NSH begin
> OVS_NSH_KEY_ATTR_BASE
> OVS_NSH_KEY_ATTR_MD2
> OVS_KEY_ATTR_NSH end
>
> In addition, NSH encap and decap actions are renamed as push_nsh
> and pop_nsh to meet action naming convention.
>
> Signed-off-by: Yi Yang
> ---
> datapath/linux/compat/include/linux/openvswitch.h | 57 +-
> include/openvswitch/nsh.h | 32 +-
> include/openvswitch/packets.h | 11 +-
> lib/dpif-netdev.c | 4 +-
> lib/dpif.c| 4 +-
> lib/flow.c| 15 +-
> lib/match.c | 12 +-
> lib/meta-flow.c | 13 +-
> lib/nx-match.c| 4 +-
> lib/odp-execute.c | 76 ++-
> lib/odp-util.c| 713
> ++
> lib/odp-util.h| 4 +
> lib/packets.c | 24 +-
> lib/packets.h | 6 +-
> ofproto/ofproto-dpif-ipfix.c | 4 +-
> ofproto/ofproto-dpif-sflow.c | 4 +-
> ofproto/ofproto-dpif-xlate.c | 24 +-
> tests/nsh.at
Re: [ovs-dev] Compliance of NSH implementation with latest NSH draft
Jan, I think we can adjust struct nsh_hdr to adapt to new nsh draft, do you have time to add nsh_ttl match field and a corresponding dec_nsh_ttl action? You can use ovs_key_nsh_rework in gitlab, I have updated to the new changes I did and it can work as before. From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] Sent: Thursday, August 17, 2017 12:22 AM To: Yang, Yi Y ; Zoltán Balogh Cc: Ben Pfaff (b...@ovn.org) ; Jiri Benc (jb...@redhat.com) ; 'ovs-dev@openvswitch.org' ; Eric Garver Subject: Compliance of NSH implementation with latest NSH draft I checked the IETF tracker for NSH draft version 19: It seems like final IETF reviews are concluding (deadline Aug 25), so we might consider updating the OVS implementation in 2.8 to align with version 19. At minimum this would mean restricting the nsh_mdtype field to 4 bits and possibly adjust the nsh_flags field to the changed bits in the base header. I believe the we could add the nsh_ttl match field and a corresponding dec_nsh_ttl action at a later stage. What do you think? BR, Jan From: Jan Scheurich Sent: Wednesday, 16 August, 2017 16:05 To: Yang, Yi Y mailto:yi.y.y...@intel.com>>; Zoltán Balogh mailto:zoltan.bal...@ericsson.com>> Cc: Ben Pfaff (b...@ovn.org<mailto:b...@ovn.org>) mailto:b...@ovn.org>>; Jiri Benc (jb...@redhat.com<mailto:jb...@redhat.com>) mailto:jb...@redhat.com>>; ovs-dev@openvswitch.org<mailto:ovs-dev@openvswitch.org> Subject: RE: Yang, Yi Y sent you a message in Skype for Business-FYI: basically I have worked out a ovs nsh version per their requirements Hi Yi, It is not correct that our implementation does not support MD2. OVS 2.8 will be able to receive and forward packets with NSH MD1 and MD2 headers (SFF use case). It should also be able to push an NSH header MD1 or MD2 format, with MD2 TLVs specified as encap properties, (Classifier use case) and pop an NSH header with MD1 or MD2 format (last SFF use case). The only limitation OVS 2.8 has is that it cannot match on or modify MD2 TLV metadata. This will require the introduction of generic TLV match fields to be mapped to specific TLV protocol headers, which we have postponed to a future release. Regarding the Netlink representation of NSH key and PUSH_NSH action: For the NSH key we agreed with Jiri and Ben that the nested OVS_KEY_ATTR_NSH must have separate members OVS_NSH_KEY_ATTR_BASE and OVS_NSH_KEY_ATTR_MD1, as presence of MD1 is optional. A specific MD1 attribute is required to carry the four fixed context headers as key fields. We do have a problem with the NSH_KEY_BASE as the base header remains a moving target in the NSH draft. The format has evolved as follows from 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|C|R|R|R|R|R|R| Length| MD type | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in version 12 (Feb 2017), we based on, to +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|U|TTL| Length |U|U|U|U|MD Type| Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ in version 19 today (actually changed in June). Field "nsh_mdtype" is shrunk from 8 to 4 bits, field "nsh_flags" would now split over two segments and shrunk from 8 to 2+4 bits, and there should be a new field "nsh_ttl". So, whatever we release in OVS 2.8 will be compliant only to some version of the NSH draft (probably outdated). If we don't adjust to version 19, our "nsh_flags" field will contain the TTL value and the "nsh_mdtype" field includes some now unassigned bits. Will break as soon as future drafts start assigning bits previously part of the MD type field. To me this indicates that we should mark the NSH implementation in OVS 2.8 as "experimental" and reserve the right to align the implementation with the approved NSH RFC later, even if that should break backward compatibility on the OpenFlow interface. If that is not an option on the Netlink uAPI for the kernel datapath, we may not be able to offer NSH support with the kernel now. Or we accept that we need to supersede the initial OVS_NSH_KEY_ attributes with an updated version later on. For the push_nsh action, the nested OVS_ACTION_ATTR_PUSH_NSH re-uses OVS_NSH_KEY_ATTR_BASE for the fixed part of the NSH header (inheriting the same issues as above). But the push_nsh action needs no insight whatsoever in the context data. So the PUSH_NSH attribute just adds the opaque OVS_NSH_KEY_ATTR_CONTEXT carrying whatever context data as variable length byte array. This is a simple and future proof representation of arbitrarily formatted context data in the data path which can deal with both MD1 and MD2 already today. BR Jan From
Re: [ovs-dev] [PATCH net-next v2] openvswitch: enable NSH support
So far, we're not clear how we can support MD type 2 better, as I explained before, we need to reuse tun_metadata in struct flow_tnl which is the thing Geneve is using. Geneve predefined 64 keys for this from tun_metadata0 to tun_metadata63, we will reuse it for MD type 2. But you know NSH is not tunnel, so it has to be changed to support both Geneve and NSH. Anyway, they won't be part of ovs_key_nsh. -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Jiri Benc Sent: Friday, August 11, 2017 5:11 PM To: Yang, Yi Y Cc: net...@vger.kernel.org; d...@openvswitch.org Subject: Re: [PATCH net-next v2] openvswitch: enable NSH support On Fri, 11 Aug 2017 16:47:23 +0800, Yang, Yi wrote: > is "__be32 context[4]" ok? Yes, that looks better. > So define three new netlink attributes > > OVS_ACTION_ATTR_NSH_BASE_HEADER > OVS_ACTION_ATTR_NSH_MD1_DATA > OVS_ACTION_ATTR_NSH_MD2_DATA > > OVS_ACTION_ATTR_PUSH_NSH is nested netlink attribute, it will nest > OVS_ACTION_ATTR_NSH_BASE_HEADER and OVS_ACTION_ATTR_NSH_MD1_DATA for > MD type 1, it will nest OVS_ACTION_ATTR_NSH_BASE_HEADER and > OVS_ACTION_ATTR_NSH_MD2_DATA for MD type 2. I'll compeletely remove > struct ovs_action_push_nsh, is it ok? Yes, that's the way to do it. What should be done with struct ovs_key_nsh? Even with "c" renamed to "context", it's still MD type 1 only structure. What is the plan for MD type 2 support wrt. this structure? Thanks, Jiri ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support
struct ovs_action_encap_nsh is the only one way we transfer all the data for
encap_nsh, netlink allows variable attribute, so I don't think we break netlink
convention or abuse this variable feature.
Even if we bring nested attributes to handle this, OVS_ACTION_ATTR_ENCAP_NSH is
still length-variable, OVS_NSH_ATTR_MD2 is also length-variable (it can be from
0 to 248), so I don't think such way can avoid the issue you're addressing.
The result will be worse, it will make many difficulties when we transfer all
the data for encap_nsh between OVS' components.
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Thursday, August 10, 2017 4:54 AM
To: Yang, Yi Y
Cc: Jan Scheurich ; d...@openvswitch.org;
net...@vger.kernel.org; Jiri Benc ; da...@davemloft.net;
Zoltán Balogh
Subject: Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support
On Wed, Aug 09, 2017 at 08:12:36PM +, Yang, Yi Y wrote:
> Ben, do you mean we bring two new attributes (OVS_NSH_ATTR_MD1 and
> OVS_NSH_ATTR_MD2) and embed one of them in OVS_ACTION_ATTR_ENCAP_NSH?
Yes.
> Anyway we need to use a struct or something else to transfer those
> metadata between functions, how do you think we can handle this
> without metadata in struct ovs_action_encap_nsh? I mean how we handle
> the arguments for function encap_nsh.
I guess that a pointer to the embedded nlattr with type OVS_NSH_ATTR_MD1 or
OVS_NSH_ATTR2 should work OK.
Keep in mind that I'm not a kernel-side maintainer of any kind. I am only
passing along what I've perceived to be common Netlink protocol design patterns.
> -Original Message-
> From: netdev-ow...@vger.kernel.org
> [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Ben Pfaff
> Sent: Thursday, August 10, 2017 2:09 AM
> To: Yang, Yi Y
> Cc: Jan Scheurich ; d...@openvswitch.org;
> net...@vger.kernel.org; Jiri Benc ;
> da...@davemloft.net; Zoltán Balogh
> Subject: Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support
>
> On Wed, Aug 09, 2017 at 09:41:51AM +, Yang, Yi Y wrote:
> > Hi, Jan
> >
> > I have worked out a patch, will send it quickly for Ben. In
> > addition, I also will send out a patch to change encap_nsh
> > &decap_nsh to push_nsh and pop_nsh. Per comments from all the
> > people, we all agreed to do so :-)
> >
> > diff --git a/datapath/linux/compat/include/linux/openvswitch.h
> > b/datapath/linux/compat/include/linux/openvswitch.h
> > index bc6c94b..4936c12 100644
> > --- a/datapath/linux/compat/include/linux/openvswitch.h
> > +++ b/datapath/linux/compat/include/linux/openvswitch.h
> > @@ -793,7 +793,7 @@ struct ovs_action_push_eth {
> > struct ovs_key_ethernet addresses; };
> >
> > -#define OVS_ENCAP_NSH_MAX_MD_LEN 16
> > +#define OVS_ENCAP_NSH_MAX_MD_LEN 248
> > /*
> > * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
> > * @flags: NSH header flags.
> > @@ -809,7 +809,7 @@ struct ovs_action_encap_nsh {
> > uint8_t mdlen;
> > uint8_t np;
> > __be32 path_hdr;
> > -uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
> > +uint8_t metadata[];
> > };
>
> This brings the overall format of ovs_action_encap_nsh to:
>
> struct ovs_action_encap_nsh {
> uint8_t flags;
> uint8_t mdtype;
> uint8_t mdlen;
> uint8_t np;
> __be32 path_hdr;
> uint8_t metadata[];
> };
>
> This is an unusual format for a Netlink attribute. More commonly, one would
> put variable-length data into an attribute of its own, which allows that data
> to be handled using the regular Netlink means. Then the mdlen and metadata
> members could be removed, since they would be part of the additional
> attribute, and one might expect the mdtype member to be removed as well since
> each type of metadata would be in a different attribute type.
>
> So, a format closer to what I expect to see in Netlink is something
> like
> this:
>
> /**
> * enum ovs_nsh_attr - Metadata attributes for %OVS_ACTION_ENCAP_NSH action.
> *
> * @OVS_NSH_ATTR_MD1: Contains 16-byte NSH type-1 metadata.
> * @OVS_NSH_ATTR_MD2: Contains 0- to 255-byte variable-length NSH
> type-2
> * metadata. */
> enum ovs_nsh_attr {
> OVS_NSH_ATTR_MD1,
> OVS_NSH_ATTR_MD2
> };
>
> /*
> * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
> *
> * @path_hdr: NSH service path id and service index.
> * @flags: NSH header flags.
> * @np: NSH next_protocol: Inner packet type.
> *
> * Followed by either %OVS_NSH_ATTR_MD1 or %OVS_NSH_ATTR_MD2 attribute.
> */
> struct ovs_action_encap_nsh {
> __be32 path_hdr;
> uint8_t flags;
> uint8_t np;
> };
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support variable length
Noticed, please check the reply for that one.
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Thursday, August 10, 2017 4:04 AM
To: Yang, Yi Y
Cc: d...@openvswitch.org
Subject: Re: [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support
variable length
I gave a more detailed explanation later:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337164.html
On Wed, Aug 09, 2017 at 07:52:38PM +, Yang, Yi Y wrote:
> Ben, no matter it is MD type 1 or MD type 2, we use the same netlink
> attribute OVS_ACTION_ATTR_ENCAP_NSH to transfer these data, another netlink
> attribute OVS_KEY_ATTR_NSH is for struct ovs_key_nsh. So I can't catch your
> point, can you explain it more?
>
> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Thursday, August 10, 2017 2:01 AM
> To: Yang, Yi Y
> Cc: d...@openvswitch.org
> Subject: Re: [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to
> support variable length
>
> On Wed, Aug 09, 2017 at 07:45:13PM +0800, Yi Yang wrote:
> > In order to adapt to MD type 1 and MD type 2 at the same time and
> > avoid breaking Linux kernel uAPI later, we change struct
> > ovs_action_encap_nsh to the below format.
> >
> > struct ovs_action_encap_nsh {
> > uint8_t flags;
> > uint8_t mdtype;
> > uint8_t mdlen;
> > uint8_t np;
> > __be32 path_hdr;
> > uint8_t metadata[];
> > };
> >
> > struct ovs_action_encap_nsh will be allocated dynamically when it is
> > used.
> >
> > The following patch will change encap_nsh and decap_nsh into
> > push_nsh and pop_nsh, respectively, Linux kernel guys prefer
> > push_* and pop_*.
> >
> > Signed-off-by: Yi Yang
>
> This is an unusual format for a Netlink attribute. More commonly, one would
> put variable-length data into an attribute of its own, which allows that data
> to be handled using the regular Netlink means. Then the mdlen and metadata
> members could be removed, since they would be part of the additional
> attribute, and one might expect the mdtype member to be removed as well since
> each type of metadata would be in a different attribute type.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support
Ben, do you mean we bring two new attributes (OVS_NSH_ATTR_MD1 and
OVS_NSH_ATTR_MD2) and embed one of them in OVS_ACTION_ATTR_ENCAP_NSH? Anyway we
need to use a struct or something else to transfer those metadata between
functions, how do you think we can handle this without metadata in struct
ovs_action_encap_nsh? I mean how we handle the arguments for function encap_nsh.
-Original Message-
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
Behalf Of Ben Pfaff
Sent: Thursday, August 10, 2017 2:09 AM
To: Yang, Yi Y
Cc: Jan Scheurich ; d...@openvswitch.org;
net...@vger.kernel.org; Jiri Benc ; da...@davemloft.net;
Zoltán Balogh
Subject: Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support
On Wed, Aug 09, 2017 at 09:41:51AM +, Yang, Yi Y wrote:
> Hi, Jan
>
> I have worked out a patch, will send it quickly for Ben. In addition,
> I also will send out a patch to change encap_nsh &decap_nsh to
> push_nsh and pop_nsh. Per comments from all the people, we all agreed
> to do so :-)
>
> diff --git a/datapath/linux/compat/include/linux/openvswitch.h
> b/datapath/linux/compat/include/linux/openvswitch.h
> index bc6c94b..4936c12 100644
> --- a/datapath/linux/compat/include/linux/openvswitch.h
> +++ b/datapath/linux/compat/include/linux/openvswitch.h
> @@ -793,7 +793,7 @@ struct ovs_action_push_eth {
> struct ovs_key_ethernet addresses; };
>
> -#define OVS_ENCAP_NSH_MAX_MD_LEN 16
> +#define OVS_ENCAP_NSH_MAX_MD_LEN 248
> /*
> * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
> * @flags: NSH header flags.
> @@ -809,7 +809,7 @@ struct ovs_action_encap_nsh {
> uint8_t mdlen;
> uint8_t np;
> __be32 path_hdr;
> -uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
> +uint8_t metadata[];
> };
This brings the overall format of ovs_action_encap_nsh to:
struct ovs_action_encap_nsh {
uint8_t flags;
uint8_t mdtype;
uint8_t mdlen;
uint8_t np;
__be32 path_hdr;
uint8_t metadata[];
};
This is an unusual format for a Netlink attribute. More commonly, one would
put variable-length data into an attribute of its own, which allows that data
to be handled using the regular Netlink means. Then the mdlen and metadata
members could be removed, since they would be part of the additional attribute,
and one might expect the mdtype member to be removed as well since each type of
metadata would be in a different attribute type.
So, a format closer to what I expect to see in Netlink is something like
this:
/**
* enum ovs_nsh_attr - Metadata attributes for %OVS_ACTION_ENCAP_NSH action.
*
* @OVS_NSH_ATTR_MD1: Contains 16-byte NSH type-1 metadata.
* @OVS_NSH_ATTR_MD2: Contains 0- to 255-byte variable-length NSH type-2
* metadata. */
enum ovs_nsh_attr {
OVS_NSH_ATTR_MD1,
OVS_NSH_ATTR_MD2
};
/*
* struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
*
* @path_hdr: NSH service path id and service index.
* @flags: NSH header flags.
* @np: NSH next_protocol: Inner packet type.
*
* Followed by either %OVS_NSH_ATTR_MD1 or %OVS_NSH_ATTR_MD2 attribute.
*/
struct ovs_action_encap_nsh {
__be32 path_hdr;
uint8_t flags;
uint8_t np;
};
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support variable length
Ben, no matter it is MD type 1 or MD type 2, we use the same netlink attribute
OVS_ACTION_ATTR_ENCAP_NSH to transfer these data, another netlink attribute
OVS_KEY_ATTR_NSH is for struct ovs_key_nsh. So I can't catch your point, can
you explain it more?
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Thursday, August 10, 2017 2:01 AM
To: Yang, Yi Y
Cc: d...@openvswitch.org
Subject: Re: [PATCH v1 1/2] nsh: enable struct ovs_action_encap_nsh to support
variable length
On Wed, Aug 09, 2017 at 07:45:13PM +0800, Yi Yang wrote:
> In order to adapt to MD type 1 and MD type 2 at the same time and
> avoid breaking Linux kernel uAPI later, we change struct
> ovs_action_encap_nsh to the below format.
>
> struct ovs_action_encap_nsh {
> uint8_t flags;
> uint8_t mdtype;
> uint8_t mdlen;
> uint8_t np;
> __be32 path_hdr;
> uint8_t metadata[];
> };
>
> struct ovs_action_encap_nsh will be allocated dynamically when it is
> used.
>
> The following patch will change encap_nsh and decap_nsh into push_nsh
> and pop_nsh, respectively, Linux kernel guys prefer
> push_* and pop_*.
>
> Signed-off-by: Yi Yang
This is an unusual format for a Netlink attribute. More commonly, one would
put variable-length data into an attribute of its own, which allows that data
to be handled using the regular Netlink means. Then the mdlen and metadata
members could be removed, since they would be part of the additional attribute,
and one might expect the mdtype member to be removed as well since each type of
metadata would be in a different attribute type.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] nsh: enable struct ovs_action_encap_nsh to support variable length
Please ignore this one and use this series
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337128.html which
includes this one.
-Original Message-
From: Yang, Yi Y
Sent: Wednesday, August 9, 2017 5:56 PM
To: d...@openvswitch.org
Cc: b...@ovn.org; Yang, Yi Y
Subject: [PATCH] nsh: enable struct ovs_action_encap_nsh to support variable
length
In order to adapt to MD type 1 and MD type 2 at the same time and avoid
breaking Linux kernel uAPI later, we change struct ovs_action_encap_nsh to the
below format.
struct ovs_action_encap_nsh {
uint8_t flags;
uint8_t mdtype;
uint8_t mdlen;
uint8_t np;
__be32 path_hdr;
uint8_t metadata[];
};
struct ovs_action_encap_nsh will be allocated dynamically when it is used.
The following patch will change encap_nsh and decap_nsh into push_nsh and
pop_nsh, respectively, Linux kernel guys prefer
push_* and pop_*.
Signed-off-by: Yi Yang
---
datapath/linux/compat/include/linux/openvswitch.h | 4 +-
lib/odp-util.c| 101 +-
tests/nsh.at | 10 +--
3 files changed, 65 insertions(+), 50 deletions(-)
diff --git a/datapath/linux/compat/include/linux/openvswitch.h
b/datapath/linux/compat/include/linux/openvswitch.h
index bc6c94b..4936c12 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -793,7 +793,7 @@ struct ovs_action_push_eth {
struct ovs_key_ethernet addresses;
};
-#define OVS_ENCAP_NSH_MAX_MD_LEN 16
+#define OVS_ENCAP_NSH_MAX_MD_LEN 248
/*
* struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
* @flags: NSH header flags.
@@ -809,7 +809,7 @@ struct ovs_action_encap_nsh {
uint8_t mdlen;
uint8_t np;
__be32 path_hdr;
-uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
+uint8_t metadata[];
};
/**
diff --git a/lib/odp-util.c b/lib/odp-util.c index ef8b39d..91452f5 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -1785,7 +1785,8 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf
*actions) {
int n = 0;
int ret = 0;
-struct ovs_action_encap_nsh encap_nsh;
+struct ovs_action_encap_nsh *encap_nsh =
+xmalloc(sizeof *encap_nsh + OVS_ENCAP_NSH_MAX_MD_LEN);
uint32_t spi;
uint8_t si;
uint32_t cd;
@@ -1796,11 +1797,11 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf
*actions)
}
/* The default is NSH_M_TYPE1 */
-encap_nsh.flags = 0;
-encap_nsh.mdtype = NSH_M_TYPE1;
-encap_nsh.mdlen = NSH_M_TYPE1_MDLEN;
-encap_nsh.path_hdr = htonl(255);
-memset(encap_nsh.metadata, 0, NSH_M_TYPE1_MDLEN);
+encap_nsh->flags = 0;
+encap_nsh->mdtype = NSH_M_TYPE1;
+encap_nsh->mdlen = NSH_M_TYPE1_MDLEN;
+encap_nsh->path_hdr = htonl(255);
+memset(encap_nsh->metadata, 0, encap_nsh->mdlen);
for (;;) {
n += strspn(s + n, delimiters); @@ -1808,17 +1809,17 @@
parse_odp_encap_nsh_action(const char *s, struct ofpbuf *actions)
break;
}
-if (ovs_scan_len(s, &n, "flags=%"SCNi8, &encap_nsh.flags)) {
+if (ovs_scan_len(s, &n, "flags=%"SCNi8, &encap_nsh->flags)) {
continue;
}
-if (ovs_scan_len(s, &n, "mdtype=%"SCNi8, &encap_nsh.mdtype)) {
-switch (encap_nsh.mdtype) {
+if (ovs_scan_len(s, &n, "mdtype=%"SCNi8, &encap_nsh->mdtype)) {
+switch (encap_nsh->mdtype) {
case NSH_M_TYPE1:
/* This is the default format. */;
break;
case NSH_M_TYPE2:
/* Length will be updated later. */
-encap_nsh.mdlen = 0;
+encap_nsh->mdlen = 0;
break;
default:
ret = -EINVAL;
@@ -1826,24 +1827,24 @@ parse_odp_encap_nsh_action(const char *s, struct ofpbuf
*actions)
}
continue;
}
-if (ovs_scan_len(s, &n, "np=%"SCNi8, &encap_nsh.np)) {
+if (ovs_scan_len(s, &n, "np=%"SCNi8, &encap_nsh->np)) {
continue;
}
if (ovs_scan_len(s, &n, "spi=0x%"SCNx32, &spi)) {
-encap_nsh.path_hdr =
+encap_nsh->path_hdr =
htonl(((spi << NSH_SPI_SHIFT) & NSH_SPI_MASK) |
-(ntohl(encap_nsh.path_hdr) & ~NSH_SPI_MASK));
+(ntohl(encap_nsh->path_hdr) &
+ ~NSH_SPI_MASK));
continue;
}
if (ovs_scan_len(s, &n, "si=%"SCNi8, &si)) {
-encap_nsh.path_hdr =
+encap_nsh->path_hdr =
htonl((si << NSH_SI_SHIFT) |
-(ntohl(encap_nsh.path_hdr) & ~NSH_SI_MASK));
+
Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support
&n, "md2=0x%511[0-9a-fA-F]", buf)) {
-ofpbuf_use_stub(&b, encap_nsh.metadata,
+ofpbuf_use_stub(&b, encap_nsh->metadata,
OVS_ENCAP_NSH_MAX_MD_LEN);
ofpbuf_put_hex(&b, buf, &mdlen);
-encap_nsh.mdlen = mdlen;
+encap_nsh->mdlen = mdlen;
ofpbuf_uninit(&b);
}
continue;
}
}
out:
-if (ret < 0) {
-return ret;
-} else {
-size_t size = offsetof(struct ovs_action_encap_nsh, metadata)
-+ ROUND_UP(encap_nsh.mdlen, 4);
-nl_msg_put_unspec(actions, OVS_ACTION_ATTR_ENCAP_NSH,
- &encap_nsh, size);
-return n;
+if (ret >= 0) {
+size_t size = sizeof(struct ovs_action_encap_nsh)
+ + ROUND_UP(encap_nsh->mdlen, 4);
+size_t pad_len = size - sizeof(struct ovs_action_encap_nsh)
+ - encap_nsh->mdlen;
+if (encap_nsh->mdlen > NSH_M_TYPE1_MDLEN && pad_len > 0) {
+memset(encap_nsh->metadata + encap_nsh->mdlen, 0, pad_len);
+}
+nl_msg_put_unspec(actions, OVS_ACTION_ATTR_ENCAP_NSH, encap_nsh, size);
+ret = n;
}
+free(encap_nsh);
+return ret;
}
static int
@@ -6798,19 +6803,22 @@ odp_put_encap_nsh_action(struct ofpbuf *odp_actions,
const struct flow *flow,
struct ofpbuf *encap_data)
{
-struct ovs_action_encap_nsh encap_nsh;
-
-encap_nsh.flags = flow->nsh.flags;
-encap_nsh.mdtype = flow->nsh.mdtype;
-encap_nsh.np = flow->nsh.np;
-encap_nsh.path_hdr = htonl((ntohl(flow->nsh.spi) << NSH_SPI_SHIFT) |
+size_t size;
+size_t pad_len;
+struct ovs_action_encap_nsh *encap_nsh =
+xmalloc(sizeof *encap_nsh + OVS_ENCAP_NSH_MAX_MD_LEN);
+
+encap_nsh->flags = flow->nsh.flags;
+encap_nsh->mdtype = flow->nsh.mdtype;
+encap_nsh->np = flow->nsh.np;
+encap_nsh->path_hdr = htonl((ntohl(flow->nsh.spi) << NSH_SPI_SHIFT) |
flow->nsh.si);
-switch (encap_nsh.mdtype) {
+switch (encap_nsh->mdtype) {
case NSH_M_TYPE1: {
struct nsh_md1_ctx *md1 =
-ALIGNED_CAST(struct nsh_md1_ctx *, encap_nsh.metadata);
-encap_nsh.mdlen = NSH_M_TYPE1_MDLEN;
+ALIGNED_CAST(struct nsh_md1_ctx *, encap_nsh->metadata);
+encap_nsh->mdlen = NSH_M_TYPE1_MDLEN;
for (int i = 0; i < 4; i++) {
put_16aligned_be32(&md1->c[i], flow->nsh.c[i]);
}
@@ -6819,18 +6827,25 @@ odp_put_encap_nsh_action(struct ofpbuf *odp_actions,
case NSH_M_TYPE2:
if (encap_data) {
ovs_assert(encap_data->size < OVS_ENCAP_NSH_MAX_MD_LEN);
-encap_nsh.mdlen = encap_data->size;
-memcpy(encap_nsh.metadata, encap_data->data, encap_data->size);
+encap_nsh->mdlen = encap_data->size;
+memcpy(encap_nsh->metadata, encap_data->data, encap_data->size);
} else {
-encap_nsh.mdlen = 0;
+encap_nsh->mdlen = 0;
}
break;
default:
-encap_nsh.mdlen = 0;
+encap_nsh->mdlen = 0;
break;
}
-nl_msg_put_unspec(odp_actions, OVS_ACTION_ATTR_ENCAP_NSH,
- &encap_nsh, sizeof(encap_nsh));
+size = sizeof(struct ovs_action_encap_nsh)
+ + ROUND_UP(encap_nsh->mdlen, 4);
+ pad_len = size - sizeof(struct ovs_action_encap_nsh)
+ - encap_nsh->mdlen;
+if (pad_len > 0) {
+memset(encap_nsh->metadata + encap_nsh->mdlen, 0, pad_len);
+}
+nl_msg_put_unspec(odp_actions, OVS_ACTION_ATTR_ENCAP_NSH, encap_nsh, size);
+free(encap_nsh);
}
static void
-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Wednesday, August 9, 2017 4:32 PM
To: Ben Pfaff ; Yang, Yi Y
Cc: d...@openvswitch.org; net...@vger.kernel.org; Jiri Benc ;
da...@davemloft.net; Zoltán Balogh
Subject: RE: [ovs-dev] [PATCH net-next] openvswitch: add NSH support
Hi all,
In OVS 2.8 we support only fixed size NSH MD1 context data for matching and in
set/copy_field actions. OVS parses an MD2 NSH header but does not make any TLV
headers available to OF. The plan is to add support for matching/manipulating
NSH MD2 TLVs through a new infrastructure of generic TLV match fields that can
be dynamically mapped to specific protocol TLVs, similar to the way this is
done for GENEVE tunnel metadata TLVs today. But this is work for an upcoming
OVS release.
However, in encap() and decap() NSH actions we do support MD2 format already.
The encap_nsh datapath action is agnostic of the MD format. Any MD2 TLV
metadata are provided as encap properties in the OF encap() op
Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support
Hi, Jiri
Thank you for your comments.
__be32 c[4] is the name Ben Pfaff suggested, the original name is c1, c2, c3,
c4, they are context data, so c seems ok, too :-)
OVS has merged it and has the same name, maybe the better way is adding comment
/* Context data */ after it.
For MD type 2, struct ovs_key_nsh is very difficult to cover it, so far we
don't know how to support MD type 2 better, Geneve defined 64 tun_metadata0-63
to handle this, those keys are parts of struct flow_tnl, the highest
possibility is to reuse those keys.
So for future MD type 2, we will have two parts of keys, one is from struct
ovs_key_nsh, another is from struct flow_tnl, this won't break the old uAPI.
"#define OVS_ENCAP_NSH_MAX_MD_LEN 16" is changed per Ben's comment from 256,
Ben thinks 256 is too big but we only support MD type 1 now. We still have ways
to extend it, for example:
struct ovs_action_encap_nsh * oaen = (struct ovs_action_encap_nsh *) malloc
(sizeof(struct ovs_action_encap_nsh) + ANY_SIZE);
nl_msg_put_unspec(actions, OVS_ACTION_ATTR_ENCAP_NSH,
oaen, sizeof(struct ovs_action_encap_nsh) + ANY_SIZE);
In addition, we also need to consider, OVS userspace code must be consistent
with here, so keeping it intact will be better, we have way to support
dynamically extension when we add MD type 2 support.
About action name, unfortunately, userspace data plane has named them as
encap_nsh & decap_nsh, Jan, what do you think about Jiri's suggestion?
But from my understanding, encap_* & decap_* are better because they
corresponding to generic encap & decap actions, in addition, encap semantics
are different from push, encap just pushed an empty header with default values,
users must use set_field to set the content of the header.
Again, OVS userspace code must be consistent with here, so keeping it intact
will be better because OVS userspace code was there.
-Original Message-
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
Behalf Of Jiri Benc
Sent: Tuesday, August 8, 2017 10:28 PM
To: Yang, Yi Y
Cc: net...@vger.kernel.org; d...@openvswitch.org; da...@davemloft.net
Subject: Re: [PATCH net-next] openvswitch: add NSH support
On Tue, 8 Aug 2017 12:59:40 +0800, Yi Yang wrote:
> +struct ovs_key_nsh {
> + __u8 flags;
> + __u8 mdtype;
> + __u8 np;
> + __u8 pad;
> + __be32 path_hdr;
> + __be32 c[4];
"c" is a very poor name. Please rename it to something that expresses what this
field contains.
Also, this looks like MD type 1 only. How are those fields going to work with
MD type 2? I don't think MD type 2 implementation is necessary in this patch
but I'd like to know how this is going to work - it's uAPI and thus set in
stone once this is merged. The uAPI needs to be designed with future use in
mind.
> +#define OVS_ENCAP_NSH_MAX_MD_LEN 16
> +/*
> + * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
> + * @flags: NSH header flags.
> + * @mdtype: NSH metadata type.
> + * @mdlen: Length of NSH metadata in bytes.
> + * @np: NSH next_protocol: Inner packet type.
> + * @path_hdr: NSH service path id and service index.
> + * @metadata: NSH metadata for MD type 1 or 2 */ struct
> +ovs_action_encap_nsh {
> + __u8 flags;
> + __u8 mdtype;
> + __u8 mdlen;
> + __u8 np;
> + __be32 path_hdr;
> + __u8 metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
This is wrong. The metadata size is set to a fixed size by this and cannot be
ever extended, or at least not easily. Netlink has attributes for exactly these
cases and that's what needs to be used here.
> @@ -835,6 +866,8 @@ enum ovs_action_attr {
> OVS_ACTION_ATTR_TRUNC,/* u32 struct ovs_action_trunc. */
> OVS_ACTION_ATTR_PUSH_ETH, /* struct ovs_action_push_eth. */
> OVS_ACTION_ATTR_POP_ETH, /* No argument. */
> + OVS_ACTION_ATTR_ENCAP_NSH,/* struct ovs_action_encap_nsh. */
> + OVS_ACTION_ATTR_DECAP_NSH,/* No argument. */
Use "push" and "pop", not "encap" and "decap" to be consistent with the naming
in the rest of the file. We use encap and decap for tunnel operations. This
code does not use lwtunnels, thus push and pop is more appropriate.
Jiri
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 0/5] Generic Encap & Decap based NSH implementation
Ben, thank you so much, we're done finally and hit ovs 2.8. Here is the patch for NEWS. https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336952.html Is it ok? -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Tuesday, August 8, 2017 2:34 AM To: Yang, Yi Y Cc: d...@openvswitch.org Subject: Re: [PATCH v4 0/5] Generic Encap & Decap based NSH implementation Thanks. I applied this series to master and branch-2.8. I'd appreciate it if you'd follow up with a patch that adds an appropriate item to NEWS. On Sat, Aug 05, 2017 at 01:41:07PM +0800, Yi Yang wrote: > v3->v4 > - Merge Ben's incrmental patches > - Rebase to current master > - Fix two compiling warnings > - Resize metedata to 16 bytes in struct ovs_action_encap_nsh > - Fix aligned cast errors > - Folded patch 2 in v3 to patch 1 > - Move some changes in patch 5 in v3 to patch 1 > > v2->v3 > - Rebase to current master > - Fix warnings reported by checkpatch > - Correct commit log with right encap syntax > > v1->v2 > - Rebase to current master > - Fix comments By Joe and Jiri Benc > > This patch series implemented NSH (Network Service Header, > https://www.ietf.org/id/draft-ietf-sfc-nsh-13.txt). > > It also includes unit tests which can verify Eth+NSH and > VxLAN-gpe+NSH very well. > > I also verified it on my local Eth+NSH and VxLAN-gpe+NSH hybrid mode > service function chaining environment. > > This work is collectively done by Ericsson (Jan Scheurich, Zoltán > Balogh, etc.) and Intel (Yi Yang, etc.) > > Jan Scheurich (5): > userspace: Add support for NSH MD1 match fields > Adding nsh.at for NSH unit tests > userspace: add NSH support to vxlan-gpe tunnels > Generic encap and decap support for NSH > NSH unit test cases using encap and decap actions > > build-aux/extract-odp-netlink-h | 6 +- > build-aux/extract-ofp-fields | 2 + > datapath/linux/compat/include/linux/openvswitch.h | 33 ++ > include/openvswitch/automake.mk | 3 +- > include/openvswitch/flow.h| 8 +- > include/openvswitch/match.h | 12 + > include/openvswitch/meta-flow.h | 95 +++ > include/openvswitch/nsh.h | 135 + > include/openvswitch/ofp-ed-props.h| 44 +- > include/openvswitch/packets.h | 16 + > lib/dpif-netdev.c | 2 + > lib/dpif.c| 2 + > lib/flow.c| 103 +++- > lib/flow.h| 3 +- > lib/match.c | 59 +- > lib/meta-flow.c | 154 + > lib/meta-flow.xml | 67 ++- > lib/netdev-native-tnl.c | 6 + > lib/nx-match.c| 17 +- > lib/odp-execute.c | 81 +++ > lib/odp-util.c| 497 +++- > lib/odp-util.h| 5 +- > lib/ofp-actions.c | 5 + > lib/ofp-ed-props.c| 179 ++ > lib/ofp-util.c| 2 +- > lib/packets.c | 82 +++ > lib/packets.h | 7 + > ofproto/ofproto-dpif-ipfix.c | 2 + > ofproto/ofproto-dpif-rid.h| 2 +- > ofproto/ofproto-dpif-sflow.c | 3 + > ofproto/ofproto-dpif-xlate.c | 182 +- > tests/automake.mk | 3 +- > tests/classifier.at | 20 +- > tests/nsh.at | 676 > ++ > tests/ofproto-dpif.at | 22 +- > tests/ofproto.at | 11 +- > tests/testsuite.at| 1 + > tests/tunnel.at | 18 +- > 38 files changed, 2480 insertions(+), 85 deletions(-) create mode > 100644 include/openvswitch/nsh.h create mode 100644 tests/nsh.at > > -- > 2.1.0 > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 5/6] Generic encap and decap support for NSH
Ben, thank you so much for your comments, I have fixed your comments, moved some changes in this patch to patch 1, fixed compiling warnings and aligned cast errors, new version v4 has been posted out. https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336864.html -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Saturday, August 5, 2017 4:39 AM To: Yang, Yi Y Cc: d...@openvswitch.org; Jan Scheurich Subject: Re: [PATCH v3 5/6] Generic encap and decap support for NSH On Thu, Aug 03, 2017 at 09:14:59AM +0800, Yi Yang wrote: > From: Jan Scheurich > > This commit adds translation and netdev datapath support for generic > encap and decap actions for the NSH MD1 header. The generic encap and > decap actions are mapped to specific encap_nsh and decap_nsh actions > in the datapath. > > The translation follows that general scheme that decap() of an NSH > packet triggers recirculation after decapsulation, while encap(nsh) > just modifies struct flow and sets the ctx->pending_encap flag to > generate the encap_nsh action at the next commit to be able to include > subsequent set_field actions for NSH headers. > > Support for the flexible MD2 format using TLV properties is foreseen > in encap(nsh), but not yet fully implemented. > > The CLI syntax for encap of NSH is > encap(nsh(md_type=1)) > encap(nsh(md_type=2[,tlv(,,),...])) > > Signed-off-by: Jan Scheurich > Signed-off-by: Yi Yang I don't see the new parts added to openvswitch.h in upstream Linux (even in net-next), so I think that all of them should be enclosed in #ifndef __KERNEL__ to make that clear. struct ovs_action_encap_nsh is absurdly large due to the metadata array. It does not make sense for it to be that big given only MD1 support. Ideally, struct ovs_action_encap_nsh would be converted into nested Netlink attributes; then, the metadata could be variable length. That is the right way to add kernel support. Before kernel support, though, it would make more sense to just use a __be32[4] metadata array. This patch seems to make a lot of changes that should have been made in whatever patch originally added the code. For example, all the changes to format_nsh_key() and format_be32_masked() appear to be in this category. There are some new compiler warnings or errors: ../ofproto/ofproto-dpif-ipfix.c:2793:17: error: enumeration values 'OVS_ACTION_ATTR_ENCAP_NSH' and 'OVS_ACTION_ATTR_DECAP_NSH' not explicitly handled in switch [-Werror,-Wswitch-enum] ../ofproto/ofproto-dpif-xlate.c:5824:43: error: cast from 'const char *' to 'struct ofpact_ed_prop *' increases required alignment from 1 to 2 [-Werror,-Wcast-align] ../lib/odp-util.c:1847:21: error: cast from 'uint8_t *' (aka 'unsigned char *') to 'struct nsh_md1_ctx *' increases required alignment from 1 to 4 [-Werror,-Wcast-align] ../lib/odp-util.c:6818:35: error: cast from 'uint8_t *' (aka 'unsigned char *') to 'struct nsh_md1_ctx *' increases required alignment from 1 to 4 [-Werror,-Wcast-align] ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 4/6] userspace: add NSH support to vxlan-gpe tunnels
Patch 5 in v4 (patch 6 in v3) has covered this. -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Saturday, August 5, 2017 4:13 AM To: Yang, Yi Y Cc: d...@openvswitch.org; Jan Scheurich Subject: Re: [PATCH v3 4/6] userspace: add NSH support to vxlan-gpe tunnels On Thu, Aug 03, 2017 at 09:14:58AM +0800, Yi Yang wrote: > From: Jan Scheurich > > Signed-off-by: Yi Yang > Signed-off-by: Jan Scheurich Looks good to me, but are there any tests? (Do the later patches test this support?) ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 3/6] Adding nsh.at for NSH unit tests
Fixed in the new version v4. https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336864.html -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Saturday, August 5, 2017 4:11 AM To: Yang, Yi Y Cc: d...@openvswitch.org; Jan Scheurich Subject: Re: [PATCH v3 3/6] Adding nsh.at for NSH unit tests On Thu, Aug 03, 2017 at 09:14:57AM +0800, Yi Yang wrote: > From: Jan Scheurich > > First basic NSH test case implemented and working. > > Unconditionally show matched packet_type in megaflows, even when > matching on eth. > > Signed-off-by: Jan Scheurich I needed to add the following to fix one remaining test (maybe because it was added recently). Please fold it in. --8<--cut here-->8-- diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at index 8aaa1d264ff7..284a65ec6524 100644 --- a/tests/ofproto-dpif.at +++ b/tests/ofproto-dpif.at @@ -4785,7 +4785,7 @@ AT_CHECK([grep "Final flow:" stdout], [0], [Final flow: icmp,tun_id=0x6,in_port= ]) AT_CHECK([ovs-appctl ofproto/trace ovs-dummy "$flow,recirc_id(1)" -generate], [0], [stdout]) -AT_CHECK([grep "Final flow:" stdout], [0], [Final flow: recirc_id=0x1,icmp,tun_id=0x6,in_port=1,vlan_tci=0x,dl_src=50:54:00:00:00:05,dl_dst=50:54:00:00:00:07,nw_src=192.168.0.1,nw_dst=192.168.0.2,nw_tos=0,nw_ecn=0,nw_ttl=128,icmp_type=8,icmp_code=0 +AT_CHECK([grep "Final flow:" stdout], [0], [Final flow: +recirc_id=0x1,eth,icmp,tun_id=0x6,in_port=1,vlan_tci=0x,dl_src=50:5 +4:00:00:00:05,dl_dst=50:54:00:00:00:07,nw_src=192.168.0.1,nw_dst=192.16 +8.0.2,nw_tos=0,nw_ecn=0,nw_ttl=128,icmp_type=8,icmp_code=0 ]) OVS_VSWITCHD_STOP ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 2/6] userspace: enable set_field support for nsh fields
Ben, thank you so much for your comments and incremental patch, I have fixed
your comments and merged your incremental patch and folded patch 2 to patch 1,
new version v4 has been posted.
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336864.html
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Saturday, August 5, 2017 3:59 AM
To: Yang, Yi Y
Cc: d...@openvswitch.org; Jan Scheurich
Subject: Re: [PATCH v3 2/6] userspace: enable set_field support for nsh fields
On Thu, Aug 03, 2017 at 09:14:56AM +0800, Yi Yang wrote:
> From: Jan Scheurich
>
> Signed-off-by: Yi Yang
> Signed-off-by: Jan Scheurich
Thanks for working on this.
I think that this should be folded into patch 1, since it fixes what is
essentially a bug in patch 1.
I noticed that struct nsh_hdr (introduced in the previous patch) isn't suitable
for 16-bit alignment, since it has 32-bit members. Our practice is to use
appropriate type to ensure safety for 16-bit alignment, like this:
/**
* struct nsh_md1_ctx - Keeps track of NSH context data
* @nshc<1-4>: NSH Contexts.
*/
struct nsh_md1_ctx {
ovs_16aligned_be32 c[4];
};
struct nsh_md2_tlv {
ovs_be16 md_class;
uint8_t type;
uint8_t length;
uint8_t md_value[];
};
struct nsh_hdr {
ovs_be16 ver_flags_len;
uint8_t md_type;
uint8_t next_proto;
ovs_16aligned_be32 path_hdr;
union {
struct nsh_md1_ctx md1;
struct nsh_md2_tlv md2[0];
};
};
This makes it harder to forget to use the proper accessors to read misaligned
data, since the types more or less ensure it.
I noticed that it's easier to just use arrays of 4 elements (c[4]) than
separate members (c1, c2, c3, c4).
I'm appending an incremental that can be applied on top of patches 1 and
2 to achieve many of the suggestions I've made. It includes the incremental
for patch 1. I haven't tested anything, beyond compiling.
--8<--cut here-->8--
diff --git a/build-aux/extract-odp-netlink-h b/build-aux/extract-odp-netlink-h
index a509adb88f79..bc1cc35a7e9b 100755
--- a/build-aux/extract-odp-netlink-h
+++ b/build-aux/extract-odp-netlink-h
@@ -45,7 +45,11 @@ s,#.*,,
s/__u8[[:space:]]*\([a-zA-Z0-9_]*\)[[:space:]]*\[[[:space:]]*ETH_ALEN[[:space:]]*\]/struct
eth_addr \1/
# Transform IPv6 addresses from an array to struct in6_addr
-s/__be32[[:space:]]*\([a-zA-Z0-9_]*\)[[:space:]]*\[[[:space:]]*4[[:space:]]*\]/struct
in6_addr \1/
+#
+# As a very special case, only transform member names with more than #
+one character because struct ovs_key_nsh has a member "__be32 c[4];"
+# that is not an IPv6 address.
+s/__be32[[:space:]]*\([a-zA-Z0-9_]\{2,\}\)[[:space:]]*\[[[:space:]]*4[[
+:space:]]*\]/struct in6_addr \1/
# Transform most Linux-specific __u types into C99 uint_t types, # and
most Linux-specific __be into Open vSwitch ovs_be, diff --git
a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields index
7b6151f3384b..184b75e36bef 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -67,9 +67,9 @@ PREREQS = {"none": "MFP_NONE", # If a name matches more than
one prefix, the longest one is used.
OXM_CLASSES = {"NXM_OF_":(0, 0x),
"NXM_NX_":(0, 0x0001),
+ "NXOXM_NSH_": (0x005ad650, 0x),
"OXM_OF_":(0, 0x8000),
"OXM_OF_PKT_REG": (0, 0x8001),
- "OXM_NSH_": (0, 0x8004),
"ONFOXM_ET_": (0x4f4e4600, 0x),
# This is the experimenter OXM class for Nicira, which is the
diff --git a/datapath/linux/compat/include/linux/openvswitch.h
b/datapath/linux/compat/include/linux/openvswitch.h
index 2381ed2c8c3c..5806aba93f73 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -360,9 +360,6 @@ enum ovs_key_attr {
OVS_KEY_ATTR_CT_LABELS, /* 16-octet connection tracking labels */
OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4, /* struct ovs_key_ct_tuple_ipv4 */
OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV6, /* struct ovs_key_ct_tuple_ipv6 */
-#ifndef __KERNEL__
- OVS_KEY_ATTR_NSH, /* struct ovs_key_nsh */
-#endif
#ifdef __KERNEL__
/* Only used within kernel data path. */ @@ -372,6 +369,7 @@ enum
ovs_key_attr { #ifndef __KERNEL__
/* Only used within userspace data path. */
OVS_KEY_ATTR_PACKET_TYPE, /* be32 packet type */
+ OVS_KEY_ATTR_NSH, /* struct ovs_key_nsh */
#endif
__OVS_KEY_ATTR_MAX
@@ -500,10 +498,7 @@ struct ovs_key_nsh {
__u8 np;
__u8 pad;
__be32 path_hdr;
-__be32 c1;
-__be32 c2;
-__be32 c3;
-__be32 c4;
+__be32 c[4];
};
/* OVS_KEY_ATTR_CT_STATE flags
Re: [ovs-dev] [PATCH v3 1/6] userspace: Add support for NSH MD1 match fields
Ben, thank you so much for your comments and incremental, I have fixed your
comments and merged your incremental patch, new version v4 has been posted.
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336864.html
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Saturday, August 5, 2017 2:19 AM
To: Yang, Yi Y
Cc: d...@openvswitch.org; Jan Scheurich
Subject: Re: [PATCH v3 1/6] userspace: Add support for NSH MD1 match fields
On Thu, Aug 03, 2017 at 09:14:55AM +0800, Yi Yang wrote:
> From: Jan Scheurich
>
> This patch adds support for NSH packet header fields to the OVS
> control plane and the userspace datapath. Initially we support the
> fields of the NSH base header as defined in
> https://www.ietf.org/id/draft-ietf-sfc-nsh-13.txt
> and the fixed context headers specified for metadata format MD1.
> The variable length MD2 format is parsed but the TLV context headers
> are not yet available for matching.
>
> The NSH fields are modelled as OXM fields with the dedicated OXM class
> 0x8004 proposed for NSH in ONF. The following fields are defined:
>
> OXM codeofctl nameSize Comment
> =
> OXM_NSH_FLAGS nsh_flags 8 Bits 2-9 of 1st NSH word
> (0x8004,1)
> OXM_NSH_MDTYPE nsh_mdtype 8 Bits 16-23
> (0x8004,2)
> OXM_NSH_NEXTPROTO nsh_np 8 Bits 24-31
> (0x8004,3)
> OXM_NSH_SPI nsh_spi 24 Bits 0-23 of 2nd NSH word
> (0x8004,4)
> OXM_NSH_SI nsh_si 8 Bits 24-31
> (0x8004,5)
> OXM_NSH_C1 nsh_c1 32 Maskable, nsh_mdtype==1
> (0x8004,6)
> OXM_NSH_C2 nsh_c2 32 Maskable, nsh_mdtype==1
> (0x8004,7)
> OXM_NSH_C3 nsh_c3 32 Maskable, nsh_mdtype==1
> (0x8004,8)
> OXM_NSH_C4 nsh_c4 32 Maskable, nsh_mdtype==1
> (0x8004,9)
>
> Co-authored-by: Johnson Li
> Signed-off-by: Yi Yang
> Signed-off-by: Jan Scheurich
Thanks for working on this!
I do not think that we should use the ONF-reserved class 0x8004.
Although some drafts assign 0x8004 for NSH use, I do not think that any of them
have been officially approved. So, I suggest that we use a randomly chosen OUI
to form an experimenter class.
The documentation in meta-flow.xml is incomplete. Please expand it to include
the kinds of details that we see in other sections of the document.
Please add OVS_KEY_ATTR_NSH to the existing #ifndef __KERNEL__ block.
In meta-flow.xml, please indicate the 24-bit size of nsh_spi as part of the
type. Also, it's not necessary to redundantly include the size in a comment.
I find the NSH version field confusing. The diagram shows the version as the
most significant 2 bits of the first 16-bit field of the header, and
NSH_VER_MASK is a 2-bit mask, but NSH_VER_SHIFT is defined as 12.
Why isn't it 14?
I don't see anything in parse_nsh() that verifies that the packet's length is
long enough for the NSH header length. Probably, it needs to check before
trying to access the length field, and then again when to verify that it's long
enough for the encoded length.
In format_nsh_masked(), it is redundant to check the masks before each call,
because the format_*_masked() functions check them too.
In mf_is_value_valid(), I think we should verify that the high 8 bits of
MFF_NSH_SPI are zero, since it is a 24-bit field.
I'm appending a suggested incremental that addresses many of the issues I noted
above.
Thanks,
Ben.
--8<--cut here-->8--
diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields index
7b6151f3384b..184b75e36bef 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -67,9 +67,9 @@ PREREQS = {"none": "MFP_NONE", # If a name matches more than
one prefix, the longest one is used.
OXM_CLASSES = {"NXM_OF_":(0, 0x),
"NXM_NX_":(0, 0x0001),
+ "NXOXM_NSH_": (0x005ad650, 0x),
"OXM_OF_":(0, 0x8000),
"OXM_OF_PKT_REG": (0, 0x8001),
- "OXM_NSH_": (0, 0x8004),
"ONFOXM_ET_": (0x4f4e4600, 0x),
# This is the experimenter OXM class for Nicira, which is the
diff --git a/datapath/linux/compat/include/linux/openvswitch.h
b/datapath/linux/compat/include/linux/openvswitch.h
index 2381ed2c8c3c..a98ecc0ebedc 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -360,9 +360,6 @@ enum ovs_key_attr {
OVS_KEY_ATTR_CT_LABELS, /* 16
Re: [ovs-dev] [PATCH v2 0/6] Generic Encap & Decap based NSH implementation
Hi, Ben I have fixed all the errors and warnings reported by checkpatch as well as a comment you mentioned and posted out v3, please use the new one for review or merge. -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Thursday, August 3, 2017 6:40 AM To: Yang, Yi Y Cc: d...@openvswitch.org Subject: Re: [PATCH v2 0/6] Generic Encap & Decap based NSH implementation On Thu, Aug 03, 2017 at 04:56:51AM +0800, Yi Yang wrote: > v1->v2 > - Rebase to current master > - Fix comments By Joe and Jiri Benc I took a very quick first pass on this series, really just applying and building them. Can you fix them up for a v3? Thanks, Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] RFC: Let's branch for 2.8 today
Thanks Ben, I have posted out NSH patch series v2, please help review, thank you in advance. https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336643.html https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336645.html https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336644.html https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336647.html https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336646.html https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336648.html https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336649.html -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Wednesday, August 2, 2017 11:47 PM To: Yang, Yi Y Cc: d...@openvswitch.org Subject: Re: [ovs-dev] RFC: Let's branch for 2.8 today We'd very much like for 2.8 to include NSH support. We are already about a month late on branching, and NSH support is one of the main reasons we've delayed branching this long. But we need to keep approximately to schedule, so we can't wait forever. On Wed, Aug 02, 2017 at 01:49:00AM +, Yang, Yi Y wrote: > Ericsson, Redhat and Intel has thought OVS 2.8 would include NSH support, > there are some projects depending on this, for example, Opendaylight > (Openflowplugin, SFC and NetVirt), OPNFV and Openstack (networking-sfc). > > This email is long and easy to make people misunderstand :-) my readout is > OVS 2.8 will include NSH support although it is branched now, can you double > confirm this? My stakeholders need an affirmative answer. > > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Ben Pfaff > Sent: Wednesday, August 2, 2017 1:24 AM > To: d...@openvswitch.org > Subject: [ovs-dev] RFC: Let's branch for 2.8 today > > I'd like to create branch-2.8 today in preparation for releasing OVS 2.8 > later in August. I sent the patch that would lead off the branch a few > minutes ago: > > https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336544.html > > According to our published schedule, we should have create branch-2.8 at the > beginning of July, but we delayed to allow some more features to enter the > 2.8 release. There continue to be reasonable arguments along these lines in > favor of delaying branching further: > > * Many DPDK patches have been posted but are still under review > or awaiting application. > > * Multiple series of patches leading up to NSH support have been > posted but are still iterating through reviews. > > The primary argument in favor of branching quickly is to keep to a regular > release cadence. My understanding is that multiple downstream projects rely > on prompt Open vSwitch releases. (This is mainly based on speaking to > Russell Bryant at Red Hat; he can fill in the details if need be.) I'd > prefer to stick to our schedule for this reason. > > I propose that we branch today, with the following further details: > > * Continue to apply patches that add features, that as of now > have already been posted and ready for review or iterating on > reviews, until approximately this Friday. These patches will > need to be committed both to master and branch-2.8. > > * As always, bug fix patches are acceptable on any branch at any > time. > > * Plan to release, given acceptable quality, during the last > week of August. > > Thoughts? > > Thanks, > > Ben. > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 1/2] OF support and translation of generic encap and decap
Hi, Ben
I have posted v5 which included your incremental patch and encap reformat, here
they are:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336594.html
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336595.html
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336596.html
encap is reformatted as below
encap(ethernet)
encap(nsh)
encap(nsh(md_type=1))
encap(nsh(md_type=2,tlv(0x1000,10,0x12345678),tlv(0x2000,20,0xfedcba9876543210)))
No property for Ethernet encap.
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Tuesday, August 1, 2017 11:56 PM
To: Yang, Yi Y
Cc: d...@openvswitch.org; Jan Scheurich ; Zoltan
Balogh
Subject: Re: [PATCH v4 1/2] OF support and translation of generic encap and
decap
On Tue, Aug 01, 2017 at 08:06:59PM +0800, Yi Yang wrote:
> 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=),
> prop(class=,type=,val()))
>
> CLI syntax for decap action:
> decap()
> decap(packet_type(ns=,type=))
>
> The first header supported for encap and decap is "ethernet" to
> convert packets between packet_type (1,Ethertype) and (0,0).
>
> This commit also 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 in accordance with the new packet type and
> header. In the case of encap(ethernet) it suffices to change the
> packet type from (1, Ethertype) to (0,0) and set the dl_type
> accordingly. A new pending_encap flag in xlate ctx is set to mark that
> an corresponding datapath encap action must be triggered at the next
> commit. In the case of encap(ethernet) ofproto generetas a push_eth action.
>
> The general case for translation of decap() is to emit a datapath
> action to decap the current outermost header and then recirculate the
> packet to reparse the inner headers. In the special case of an
> Ethernet packet,
> decap() just changes the packet type from (0,0) to (1, dl_type)
> without a need to recirculate. The emission of the pop_eth action for
> the datapath is postponed to the next commit.
>
> Hence encap(ethernet) and decap() on an Ethernet packet are OF octions
> that only incur a cost in the dataplane when a modifed packet is
> actually committed, e.g. because it is sent out. They can freely be
> used for normalizing the packet type in the OF pipeline without
> degrading performance.
>
> Signed-off-by: Jan Scheurich
> Signed-off-by: Yi Yang
> Signed-off-by: Zoltan Balogh
> Co-authored-by: Zoltan Balogh
Thanks for iterating so quickly!
Besides the syntax for properties, which I still think should be simplified to
e.g. nsh(md_type=1), I have only a few remaining comments.
I don't think there's any value in the n_props member in nx_action_encap.
(This is about the OpenFlow wire format now, not the internal format.) The
properties are the whole tail of the structure and having a count doesn't make
anything easier. Can you remove it? It will allow us to drop 8 bytes from the
action structure due to padding.
(In case it can't be removed, I'm providing a spelling fix.)
decode_ed_prop() still doesn't check the length properly, so I'm providing a
fix.
I'm appending my suggested incremental.
Thanks again!
--8<--cut here-->8--
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c index
d0437f20922a..c7d47eb5dd71 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -4036,7 +4036,7 @@ struct nx_action_encap {
ovs_be16 subtype; /* NXAST_ENCAP. */
ovs_be16 hdr_size; /* Header size in bytes, 0 = 'not specified'.*/
ovs_be32 new_pkt_type; /* Header type to add and PACKET_TYPE of result. */
-ovs_be16 n_props; /* Number of the following endecap properties. */
+ovs_be16 n_props; /* Number of the following encap properties. */
uint8_t pad[6];/* Align to 8 bytes boundary */
struct ofp_ed_prop_header props[]; /* Encap TLV properties. */ }; @@
-4263,6 +4263,11 @@ decode_NXAST_RAW_DECAP(const struct nx_action_decap *nad,
enum ofp_version ofp_version OVS_UNUSED,
struct ofpbuf *ofpacts) {
+if (ntohs(nad->len) > sizeof *nad) {
+/* No properties supported yet. */
+return OFPERR_OFPBPC_BAD_TYPE;
+}
+
struct ofpact_decap * decap;
decap = ofpact_put_DECAP(ofpacts);
diff --git a/lib/o
Re: [ovs-dev] RFC: Let's branch for 2.8 today
Hi, Ben Ericsson, Redhat and Intel has thought OVS 2.8 would include NSH support, there are some projects depending on this, for example, Opendaylight (Openflowplugin, SFC and NetVirt), OPNFV and Openstack (networking-sfc). This email is long and easy to make people misunderstand :-) my readout is OVS 2.8 will include NSH support although it is branched now, can you double confirm this? My stakeholders need an affirmative answer. -Original Message- From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Ben Pfaff Sent: Wednesday, August 2, 2017 1:24 AM To: d...@openvswitch.org Subject: [ovs-dev] RFC: Let's branch for 2.8 today I'd like to create branch-2.8 today in preparation for releasing OVS 2.8 later in August. I sent the patch that would lead off the branch a few minutes ago: https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336544.html According to our published schedule, we should have create branch-2.8 at the beginning of July, but we delayed to allow some more features to enter the 2.8 release. There continue to be reasonable arguments along these lines in favor of delaying branching further: * Many DPDK patches have been posted but are still under review or awaiting application. * Multiple series of patches leading up to NSH support have been posted but are still iterating through reviews. The primary argument in favor of branching quickly is to keep to a regular release cadence. My understanding is that multiple downstream projects rely on prompt Open vSwitch releases. (This is mainly based on speaking to Russell Bryant at Red Hat; he can fill in the details if need be.) I'd prefer to stick to our schedule for this reason. I propose that we branch today, with the following further details: * Continue to apply patches that add features, that as of now have already been posted and ready for review or iterating on reviews, until approximately this Friday. These patches will need to be committed both to master and branch-2.8. * As always, bug fix patches are acceptable on any branch at any time. * Plan to release, given acceptable quality, during the last week of August. Thoughts? Thanks, Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 1/2] OF support and translation of generic encap and decap
Maybe encap(nsh(md_type=2,tlv(0x1000,10,0x12345678),tlv(0x2000,20,0xfedcba9876543210)) is better, the below are possible formats, I think they are all ok, what do you think about them? encap(nsh) encap(nsh()) encap(nsh(md_type=1)) encap(nsh(md_type=2,tlv(0x1000,10,0x12345678),tlv(0x2000,20,0xfedcba9876543210)) -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Wednesday, August 2, 2017 7:17 AM To: Yang, Yi Y Cc: d...@openvswitch.org; Jan Scheurich ; Zoltan Balogh Subject: Re: [PATCH v4 1/2] OF support and translation of generic encap and decap encap(hdr=nsh,nsh(md_type=2,tlv(0x1000,10,0x12345678),tlv(0x2000,20,0xfedcba9876543210)) On Tue, Aug 01, 2017 at 10:53:27PM +, Yang, Yi Y wrote: > Ben, because we're considering to cover NSH md type 2 case, for NSH TLV, now > we provide it by the below way. > > encap(hdr=nsh,prop(class=nsh,type=md_type,val=2),prop(class=nsh,type=t > lv,val(0x1000,10,0x12345678)),prop(class=nsh,type=tlv,val(0x2000,20,0x > fedcba9876543210))) > > Can you help provide a format you prefer to handle this use case? > > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Tuesday, August 1, 2017 11:56 PM > To: Yang, Yi Y > Cc: d...@openvswitch.org; Jan Scheurich ; > Zoltan Balogh > Subject: Re: [PATCH v4 1/2] OF support and translation of generic > encap and decap > > On Tue, Aug 01, 2017 at 08:06:59PM +0800, Yi Yang wrote: > > 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=), > > prop(class=,type=,val())) > > > > CLI syntax for decap action: > > decap() > > decap(packet_type(ns=,type=)) > > > > The first header supported for encap and decap is "ethernet" to > > convert packets between packet_type (1,Ethertype) and (0,0). > > > > This commit also 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 in accordance with the new packet type and > > header. In the case of encap(ethernet) it suffices to change the > > packet type from (1, Ethertype) to (0,0) and set the dl_type > > accordingly. A new pending_encap flag in xlate ctx is set to mark > > that an corresponding datapath encap action must be triggered at the > > next commit. In the case of encap(ethernet) ofproto generetas a push_eth > > action. > > > > The general case for translation of decap() is to emit a datapath > > action to decap the current outermost header and then recirculate > > the packet to reparse the inner headers. In the special case of an > > Ethernet packet, > > decap() just changes the packet type from (0,0) to (1, dl_type) > > without a need to recirculate. The emission of the pop_eth action > > for the datapath is postponed to the next commit. > > > > Hence encap(ethernet) and decap() on an Ethernet packet are OF > > octions that only incur a cost in the dataplane when a modifed > > packet is actually committed, e.g. because it is sent out. They can > > freely be used for normalizing the packet type in the OF pipeline > > without degrading performance. > > > > Signed-off-by: Jan Scheurich > > Signed-off-by: Yi Yang > > Signed-off-by: Zoltan Balogh > > Co-authored-by: Zoltan Balogh > > Thanks for iterating so quickly! > > Besides the syntax for properties, which I still think should be simplified > to e.g. nsh(md_type=1), I have only a few remaining comments. > > I don't think there's any value in the n_props member in nx_action_encap. > (This is about the OpenFlow wire format now, not the internal format.) The > properties are the whole tail of the structure and having a count doesn't > make anything easier. Can you remove it? It will allow us to drop 8 bytes > from the action structure due to padding. > (In case it can't be removed, I'm providing a spelling fix.) > > decode_ed_prop() still doesn't check the length properly, so I'm providing a > fix. > > I'm appending my suggested incremental. > > Thanks again! > > --8<--cut here-->8-- > > diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c index > d0437f20922a..c7
Re: [ovs-dev] [PATCH v4 1/2] OF support and translation of generic encap and decap
About why we need n_props in nx_action_encap, I added this for Opendaylight to
deserialize the wire format from OVS, n_props can clearly tell Opendaylight if
there is any property. Otherwise how do we check if there is a property
following?
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Tuesday, August 1, 2017 11:56 PM
To: Yang, Yi Y
Cc: d...@openvswitch.org; Jan Scheurich ; Zoltan
Balogh
Subject: Re: [PATCH v4 1/2] OF support and translation of generic encap and
decap
On Tue, Aug 01, 2017 at 08:06:59PM +0800, Yi Yang wrote:
> 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=),
> prop(class=,type=,val()))
>
> CLI syntax for decap action:
> decap()
> decap(packet_type(ns=,type=))
>
> The first header supported for encap and decap is "ethernet" to
> convert packets between packet_type (1,Ethertype) and (0,0).
>
> This commit also 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 in accordance with the new packet type and
> header. In the case of encap(ethernet) it suffices to change the
> packet type from (1, Ethertype) to (0,0) and set the dl_type
> accordingly. A new pending_encap flag in xlate ctx is set to mark that
> an corresponding datapath encap action must be triggered at the next
> commit. In the case of encap(ethernet) ofproto generetas a push_eth action.
>
> The general case for translation of decap() is to emit a datapath
> action to decap the current outermost header and then recirculate the
> packet to reparse the inner headers. In the special case of an
> Ethernet packet,
> decap() just changes the packet type from (0,0) to (1, dl_type)
> without a need to recirculate. The emission of the pop_eth action for
> the datapath is postponed to the next commit.
>
> Hence encap(ethernet) and decap() on an Ethernet packet are OF octions
> that only incur a cost in the dataplane when a modifed packet is
> actually committed, e.g. because it is sent out. They can freely be
> used for normalizing the packet type in the OF pipeline without
> degrading performance.
>
> Signed-off-by: Jan Scheurich
> Signed-off-by: Yi Yang
> Signed-off-by: Zoltan Balogh
> Co-authored-by: Zoltan Balogh
Thanks for iterating so quickly!
Besides the syntax for properties, which I still think should be simplified to
e.g. nsh(md_type=1), I have only a few remaining comments.
I don't think there's any value in the n_props member in nx_action_encap.
(This is about the OpenFlow wire format now, not the internal format.) The
properties are the whole tail of the structure and having a count doesn't make
anything easier. Can you remove it? It will allow us to drop 8 bytes from the
action structure due to padding.
(In case it can't be removed, I'm providing a spelling fix.)
decode_ed_prop() still doesn't check the length properly, so I'm providing a
fix.
I'm appending my suggested incremental.
Thanks again!
--8<--cut here-->8--
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c index
d0437f20922a..c7d47eb5dd71 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -4036,7 +4036,7 @@ struct nx_action_encap {
ovs_be16 subtype; /* NXAST_ENCAP. */
ovs_be16 hdr_size; /* Header size in bytes, 0 = 'not specified'.*/
ovs_be32 new_pkt_type; /* Header type to add and PACKET_TYPE of result. */
-ovs_be16 n_props; /* Number of the following endecap properties. */
+ovs_be16 n_props; /* Number of the following encap properties. */
uint8_t pad[6];/* Align to 8 bytes boundary */
struct ofp_ed_prop_header props[]; /* Encap TLV properties. */ }; @@
-4263,6 +4263,11 @@ decode_NXAST_RAW_DECAP(const struct nx_action_decap *nad,
enum ofp_version ofp_version OVS_UNUSED,
struct ofpbuf *ofpacts) {
+if (ntohs(nad->len) > sizeof *nad) {
+/* No properties supported yet. */
+return OFPERR_OFPBPC_BAD_TYPE;
+}
+
struct ofpact_decap * decap;
decap = ofpact_put_DECAP(ofpacts);
diff --git a/lib/ofp-ed-props.c b/lib/ofp-ed-props.c index
260adc30acf0..6bba3ac7d982 100644
--- a/lib/ofp-ed-props.c
+++ b/lib/ofp-ed-props.c
@@ -32,6 +32,9 @@ decode_ed_prop(const struct ofp_ed_prop_header **ofp_prop,
uint16_t prop_class = ntohs((*ofp_
Re: [ovs-dev] [PATCH v3 1/2] OF support and translation of generic encap and decap
Got it, thanks a lot.
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Wednesday, August 2, 2017 6:51 AM
To: Yang, Yi Y
Cc: Zoltán Balogh ; d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v3 1/2] OF support and translation of generic
encap and decap
I don't understand your explanation. decode_NXAST_RAW_DECAP() converts an
OpenFlow action in wire format into OVS internal format. The OpenFlow action
that it contains might have been generated by anything (for example, a
controller). parse_ENCAP() doesn't have anything to do with it as far as I can
tell.
On Tue, Aug 01, 2017 at 10:45:50PM +0000, Yang, Yi Y wrote:
> Ben, thank you for your patch, but from my understanding, parse_ENCAP has
> ensured it is impossible to have any property for decap, so I'm not sure in
> what case this will happened.
>
> -Original Message-
> From: Ben Pfaff [mailto:b...@ovn.org]
> Sent: Tuesday, August 1, 2017 11:26 PM
> To: Yang, Yi Y
> Cc: Zoltán Balogh ; d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v3 1/2] OF support and translation of
> generic encap and decap
>
> On Tue, Aug 01, 2017 at 12:32:20PM +, Yang, Yi Y wrote:
> > #2.
> > [Ben] I suspect that decode_NXAST_RAW_DECAP() should report an error if
> > properties are present, since it doesn't support properties.
> >
> > [Yi] It is impossible.
>
> What is impossible? It is easy to detect that properties are present and
> report an error:
>
> diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c index
> d0437f20922a..7be302a4005d 100644
> --- a/lib/ofp-actions.c
> +++ b/lib/ofp-actions.c
> @@ -4263,6 +4263,11 @@ decode_NXAST_RAW_DECAP(const struct nx_action_decap
> *nad,
> enum ofp_version ofp_version OVS_UNUSED,
> struct ofpbuf *ofpacts) {
> +if (ntohs(nad->len) > sizeof *nad) {
> +/* No properties supported yet. */
> +return OFPERR_OFPBPC_BAD_TYPE;
> +}
> +
> struct ofpact_decap * decap;
>
> decap = ofpact_put_DECAP(ofpacts);
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 1/2] OF support and translation of generic encap and decap
Ben, because we're considering to cover NSH md type 2 case, for NSH TLV, now we
provide it by the below way.
encap(hdr=nsh,prop(class=nsh,type=md_type,val=2),prop(class=nsh,type=tlv,val(0x1000,10,0x12345678)),prop(class=nsh,type=tlv,val(0x2000,20,0xfedcba9876543210)))
Can you help provide a format you prefer to handle this use case?
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Tuesday, August 1, 2017 11:56 PM
To: Yang, Yi Y
Cc: d...@openvswitch.org; Jan Scheurich ; Zoltan
Balogh
Subject: Re: [PATCH v4 1/2] OF support and translation of generic encap and
decap
On Tue, Aug 01, 2017 at 08:06:59PM +0800, Yi Yang wrote:
> 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=),
> prop(class=,type=,val()))
>
> CLI syntax for decap action:
> decap()
> decap(packet_type(ns=,type=))
>
> The first header supported for encap and decap is "ethernet" to
> convert packets between packet_type (1,Ethertype) and (0,0).
>
> This commit also 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 in accordance with the new packet type and
> header. In the case of encap(ethernet) it suffices to change the
> packet type from (1, Ethertype) to (0,0) and set the dl_type
> accordingly. A new pending_encap flag in xlate ctx is set to mark that
> an corresponding datapath encap action must be triggered at the next
> commit. In the case of encap(ethernet) ofproto generetas a push_eth action.
>
> The general case for translation of decap() is to emit a datapath
> action to decap the current outermost header and then recirculate the
> packet to reparse the inner headers. In the special case of an
> Ethernet packet,
> decap() just changes the packet type from (0,0) to (1, dl_type)
> without a need to recirculate. The emission of the pop_eth action for
> the datapath is postponed to the next commit.
>
> Hence encap(ethernet) and decap() on an Ethernet packet are OF octions
> that only incur a cost in the dataplane when a modifed packet is
> actually committed, e.g. because it is sent out. They can freely be
> used for normalizing the packet type in the OF pipeline without
> degrading performance.
>
> Signed-off-by: Jan Scheurich
> Signed-off-by: Yi Yang
> Signed-off-by: Zoltan Balogh
> Co-authored-by: Zoltan Balogh
Thanks for iterating so quickly!
Besides the syntax for properties, which I still think should be simplified to
e.g. nsh(md_type=1), I have only a few remaining comments.
I don't think there's any value in the n_props member in nx_action_encap.
(This is about the OpenFlow wire format now, not the internal format.) The
properties are the whole tail of the structure and having a count doesn't make
anything easier. Can you remove it? It will allow us to drop 8 bytes from the
action structure due to padding.
(In case it can't be removed, I'm providing a spelling fix.)
decode_ed_prop() still doesn't check the length properly, so I'm providing a
fix.
I'm appending my suggested incremental.
Thanks again!
--8<--cut here-->8--
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c index
d0437f20922a..c7d47eb5dd71 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -4036,7 +4036,7 @@ struct nx_action_encap {
ovs_be16 subtype; /* NXAST_ENCAP. */
ovs_be16 hdr_size; /* Header size in bytes, 0 = 'not specified'.*/
ovs_be32 new_pkt_type; /* Header type to add and PACKET_TYPE of result. */
-ovs_be16 n_props; /* Number of the following endecap properties. */
+ovs_be16 n_props; /* Number of the following encap properties. */
uint8_t pad[6];/* Align to 8 bytes boundary */
struct ofp_ed_prop_header props[]; /* Encap TLV properties. */ }; @@
-4263,6 +4263,11 @@ decode_NXAST_RAW_DECAP(const struct nx_action_decap *nad,
enum ofp_version ofp_version OVS_UNUSED,
struct ofpbuf *ofpacts) {
+if (ntohs(nad->len) > sizeof *nad) {
+/* No properties supported yet. */
+return OFPERR_OFPBPC_BAD_TYPE;
+}
+
struct ofpact_decap * decap;
decap = ofpact_put_DECAP(ofpacts);
diff --git a/lib/ofp-ed-props.c b/lib/ofp-ed-props.c index
260adc30acf0..6bba3ac7d982 100644
--- a/lib/ofp-ed-props.c
+++ b/lib/ofp-ed-props.c
@@ -32,6 +32,9 @@ decode_ed_prop(const
Re: [ovs-dev] [PATCH v3 1/2] OF support and translation of generic encap and decap
Ben, thank you for your patch, but from my understanding, parse_ENCAP has
ensured it is impossible to have any property for decap, so I'm not sure in
what case this will happened.
-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org]
Sent: Tuesday, August 1, 2017 11:26 PM
To: Yang, Yi Y
Cc: Zoltán Balogh ; d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v3 1/2] OF support and translation of generic
encap and decap
On Tue, Aug 01, 2017 at 12:32:20PM +0000, Yang, Yi Y wrote:
> #2.
> [Ben] I suspect that decode_NXAST_RAW_DECAP() should report an error if
> properties are present, since it doesn't support properties.
>
> [Yi] It is impossible.
What is impossible? It is easy to detect that properties are present and
report an error:
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c index
d0437f20922a..7be302a4005d 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -4263,6 +4263,11 @@ decode_NXAST_RAW_DECAP(const struct nx_action_decap *nad,
enum ofp_version ofp_version OVS_UNUSED,
struct ofpbuf *ofpacts) {
+if (ntohs(nad->len) > sizeof *nad) {
+/* No properties supported yet. */
+return OFPERR_OFPBPC_BAD_TYPE;
+}
+
struct ofpact_decap * decap;
decap = ofpact_put_DECAP(ofpacts);
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 1/2] OF support and translation of generic encap and decap
Hi, Ben
I have posted v4, they are:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336504.html
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336505.html
https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/336506.html
I have fixed most of issues you commented, I need to clarify the below issues,
actually they are not issues. I have explained the other issues in last email.
#1.
[Ben] I don't see anything in decode_ofp_prop() or its caller that checks that
the property fits in the available space. It looks like an integer overflow
error.
[Yi] Currently it is a stub function, it doesn't handle any property, so it
doesn't put any property into buf, so we mustn't check space at this point. Our
NSH patch series will add more pieces for this. Let us check
enum ofperr
decode_ed_prop(const struct ofp_ed_prop_header **ofp_prop,
struct ofpbuf *out OVS_UNUSED,
size_t *remaining)
We used ofpbuf_put_uninit(out, ...) to put the property to buffer, so we
needn't care the available space, ofpbuf_put_uninit will allocate on demand.
#2.
[Ben] I suspect that decode_NXAST_RAW_DECAP() should report an error if
properties are present, since it doesn't support properties.
[Yi] It is impossible.
static enum ofperr
decode_NXAST_RAW_DECAP(const struct nx_action_decap *nad,
enum ofp_version ofp_version OVS_UNUSED,
struct ofpbuf *ofpacts)
{
struct ofpact_decap * decap;
decap = ofpact_put_DECAP(ofpacts);
decap->ofpact.raw = NXAST_RAW_DECAP;
decap->new_pkt_type = nad->new_pkt_type;
return 0;
}
struct ofpact_decap {
struct ofpact ofpact;
/* New packet type.
*
* The special value (0,0xFFFE) "Use next proto" is used to request OVS to
* automatically set the new packet type based on the decap'ed header's
* next protocol.
*/
ovs_be32 new_pkt_type;
};
struct nx_action_decap {
ovs_be16 type; /* OFPAT_VENDOR. */
ovs_be16 len; /* Total size including any property TLVs. */
ovs_be32 vendor; /* NX_VENDOR_ID. */
ovs_be16 subtype; /* NXAST_DECAP. */
uint8_t pad[2];/* 2 bytes padding */
/* Packet type or result.
*
* The special value (0,0xFFFE) "Use next proto"
* is used to request OVS to automatically set the new packet type based
* on the decap'ed header's next protocol.
*/
ovs_be32 new_pkt_type;
};
-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org]
On Behalf Of Ben Pfaff
Sent: Monday, July 31, 2017 11:43 PM
To: Zoltán Balogh
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v3 1/2] OF support and translation of generic
encap and decap
On Fri, Jul 21, 2017 at 07:08:25PM +0200, Zoltán Balogh wrote:
> 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=),
> prop(class=,type=,val()))
>
> CLI syntax for decap action:
> decap()
> decap(packet_type(ns=,type=))
>
> The first header supported for encap and decap is "ethernet" to
> convert packets between packet_type (1,Ethertype) and (0,0).
>
> This commit also 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 in accordance with the new packet type and
> header. In the case of encap(ethernet) it suffices to change the
> packet type from (1, Ethertype) to (0,0) and set the dl_type
> accordingly. A new pending_encap flag in xlate ctx is set to mark that
> an corresponding datapath encap action must be triggered at the next
> commit. In the case of encap(ethernet) ofproto generetas a push_eth action.
>
> The general case for translation of decap() is to emit a datapath
> action to decap the current outermost header and then recirculate the
> packet to reparse the inner headers. In the special case of an
> Ethernet packet,
> decap() just changes the packet type from (0,0) to (1, dl_type)
> without a need to recirculate. The emission of the pop_eth action for
> the datapath is postponed to the next commit.
>
> Hence encap(ethernet) and decap() on an Ethernet packet are OF octions
> that only incur a cost in the dataplane when a modifed packet is
> actually committed, e.g. because it is sent out. They can freely be
> used for normalizing the packet type in the OF pipeline without
> degrading performance.
>
> Signed-off-by: Jan Scheurich
> Signed-off-by: Yi Yang
> Signed-off-by: Zoltan Balogh
> Co-authored-by: Zoltan Balogh
Thanks for working on this. I think that it will be a valuable feature.
First, I'm having a really hard
Re: [ovs-dev] [PATCH v3 1/2] OF support and translation of generic encap and decap
Hi, Ben Thank you so much for your great review and great comments, I'll do changes per your comments and post next version because Zoltan and Jan are taking vacation. I explained your concerns [Ben] The string format of the encap actions seems rather user unfriendly. Is there a good reason why it should be the very generic prop(class=,type=,val=) rather than something more tailored to the actual properties that users will want to set? It is hard to tell without any actual examples. [Yi] because encap is very generic action, you can add a new header/encap type and some new properties for it very easily by this kind of very generic abstraction and mustn't change generic encap implementation. I make an example, for NSH we have prop(class=nsh,type=md_type,val=1) If we add new encap/header type gtpu, we can have the below property for GTP-u prop(class=gtpu,type=teid,val=1234) Generic encap action can accept this kind of new prop without any change against generic encap action implementation, this is the magic of very generic " prop(class=,type=,val=)". [Ben] In decode_NXAST_RAW_ENCAP() and parse_ENCAP(), shouldn't there be validation of the header size value? Most header types will only have a few acceptable header sizes. [Yi] Actually header_size isn't used at all now, it is reserved for later enhancement. For NSH MD type 2, NSH header is length-variable, ranged from 8 to 264, number of props and size of each prop are also very flexible (like Geneve tunnel metadata) [Ben] The internal representation of ofpact_ed_prop, has no examples so far. How confident are you that it actually needs to be variable-length? If it does, then using a member 'n_props' in struct ofpact_encap to count the number of properties seems risky: it implicitly encourages programmers to try to index the props[] array from 0 to n_props-1. I'd encourage, in that case, switching to a length member, or just eliminating the member if ofpact_ed_props can be padded to 8-byte multiples. But it's easier if we can just make ofpact_ed_prop fixed-length for now; then we can just index props[] as an array. However, I question whether the properties actually need to be internally represented as properties at all. Presumably, OVS is only going to support a specific set of properties. Probably, it's easy to just add specific members to struct ofpact_encap that represent the values of those properties. Did you consider that? That approach usually simplifies code greatly; properties are usually needed only for external representations. [Yi] As I said above, prop is length-variable and unpredictable, especially for NSH MD type 2, so a length-fixed ofpact_ed_prop impracticable and will waste too much space, n_props can indicate number of props, actually props is a pointer, we can use uint8 props[] to replace struct ofp_ed_prop_header props[]; But I think it doesn't bring any substantial benefit from my perspective. ofpact_ed_prop is header of each peoperty, it just helps parse properties better. In addition, code is completely controllable, abuse of props[index] won't happen because you guys check every commit very carefully :-) -Original Message- From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Ben Pfaff Sent: Monday, July 31, 2017 11:43 PM To: Zoltán Balogh Cc: d...@openvswitch.org Subject: Re: [ovs-dev] [PATCH v3 1/2] OF support and translation of generic encap and decap On Fri, Jul 21, 2017 at 07:08:25PM +0200, Zoltán Balogh wrote: > 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=), > prop(class=,type=,val())) > > CLI syntax for decap action: > decap() > decap(packet_type(ns=,type=)) > > The first header supported for encap and decap is "ethernet" to > convert packets between packet_type (1,Ethertype) and (0,0). > > This commit also 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 in accordance with the new packet type and > header. In the case of encap(ethernet) it suffices to change the > packet type from (1, Ethertype) to (0,0) and set the dl_type > accordingly. A new pending_encap flag in xlate ctx is set to mark that > an corresponding datapath encap action must be triggered at the next > commit. In the case of encap(ethernet) ofproto generetas a push_eth action. > > The general case for translation of decap() is to emit a datapath > action to decap the current outermost header and then recirculate the > packet to reparse the inner headers. In the special case of an > Ethernet packet, > de
Re: [ovs-dev] [PATCH v3 0/2] basic encap/decap
Hi, folks It seems Ben is out of office in these days, can anybody help review or merge this patch series? I heard 2.8 branch would be created end of July, but we still have NSH patch series waiting for review except this series. -Original Message- From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Zoltán Balogh Sent: Saturday, July 22, 2017 1:08 AM To: d...@openvswitch.org Subject: [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 - Packet type aware pipeline https://mail.openvswitch.org/pipermail/ovs-dev/2017-June/334512.html The main purpose of this series is to add support for the OpenFlow actions generic encap and decap (ONF EXT-382) to the OVS control plane. It implements a skeleton for translation of generic encap and decap actions in ofproto-dpif and provides support to encap and decap an Ethernet header. v2->v3 - NEWS updated. - fix: drop VLAN tagged packet trying to decap it. - New unit tests for the fix. - Some tests were updated due to change in recirculation on master branch. v1->v2 - Squash 1/4 and 2/4 commits of v1. - Put unit tests in a separate commit. - Use aligned cast. - Nicira extension numbers for encap/decap action numbers and error codes. - Small fixes according to comments. Jan Scheurich (1): OF support and translation of generic encap and decap Zoltan Balogh (1): tests: Extend PTAP unit tests with decap action NEWS | 6 + include/openflow/openflow-common.h | 1 + include/openvswitch/automake.mk| 1 + include/openvswitch/ofp-actions.h | 31 +++ include/openvswitch/ofp-ed-props.h | 69 +++ include/openvswitch/ofp-errors.h | 9 + lib/automake.mk| 1 + lib/odp-util.c | 84 +--- lib/odp-util.h | 3 +- lib/ofp-actions.c | 378 +- lib/ofp-ed-props.c | 150 ++ lib/packets.h | 3 +- ofproto/ofproto-dpif-xlate.c | 116 ++- tests/packet-type-aware.at | 405 + 14 files changed, 1215 insertions(+), 42 deletions(-) create mode 100644 include/openvswitch/ofp-ed-props.h create mode 100644 lib/ofp-ed-props.c -- 1.9.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 5/6] Generic encap and decap support for NSH
Jiri, thank you for your comments.
I have used "#ifndef __KERNEL__" for OVS_KEY_ATTR_NSH in local version, will
send it as v2 after generic encap & decap patch series are merged.
OVS_ENCAP_NSH_MAX_MD_LEN is also for MD type 2, so I used a maximum value, is a
size-variable " struct ovs_action_encap_nsh " as needed possible?
For netlink attributes, Jan suggested we could use only one attribute
OVS_KEY_ATTR_NSH to put the whole nsh keys.
About action names, I think encap_* & decap_* will be better, this can make
people map to corresponding generic encap & decap, in addition, encap has
different semantics from push, encap just adds an empty header, set_field
actions must fill in fields in header. You know encap & decap are names used in
OpenFlow spec draft, they aren't named as push & pop, this is my explanation
for you :-)
-Original Message-
From: Jiri Benc [mailto:jb...@redhat.com]
Sent: Friday, July 21, 2017 8:08 PM
To: Yang, Yi Y
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH 5/6] Generic encap and decap support for NSH
My comments apply more to the yet to be submitted kernel part. Until then, I
agree with Joe that all of this should be inside #ifndef __KERNEL__. But these
are comments I'd have at netdev thus you may as well change that for v2 (or
explain that I'm wrong).
On Wed, 5 Jul 2017 11:45:42 +0800, Yi Yang wrote:
> +#define OVS_ENCAP_NSH_MAX_MD_LEN 256
This makes the size set in stone forever. I believe it is not what you want.
Netlink is based on attributes for the purpose of future extensibility and
that's exactly what's needed here. The 'metadata' field should be in its own
attribute (or, rather, attributes).
> +/*
> + * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
> + * @flags: NSH header flags.
> + * @mdtype: NSH metadata type.
> + * @mdlen: Length of NSH metadata in bytes.
> + * @np: NSH next_protocol: Inner packet type.
> + * @path_hdr: NSH service path id and service index.
> + * @metadata: NSH metadata for MD type 1 or 2 */ struct
> +ovs_action_encap_nsh {
Please call this push_nsh to be consistent with other similar uses (MPLS,
Ethernet).
> +uint8_t flags;
> +uint8_t mdtype;
> +uint8_t mdlen;
> +uint8_t np;
> +__be32 path_hdr;
> +uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
> +};
> +
> /**
> * enum ovs_nat_attr - Attributes for %OVS_CT_ATTR_NAT.
> *
> @@ -870,6 +889,8 @@ enum ovs_nat_attr {
> * @OVS_ACTION_ATTR_PUSH_ETH: Push a new outermost Ethernet header onto the
> * packet.
> * @OVS_ACTION_ATTR_POP_ETH: Pop the outermost Ethernet header off the
> packet.
> + * @OVS_ACTION_ATTR_ENCAP_NSH: encap NSH action to push NSH header.
> + * @OVS_ACTION_ATTR_DECAP_NSH: decap NSH action to remove NSH header.
> *
> * Only a single header can be set with a single %OVS_ACTION_ATTR_SET. Not
> all
> * fields within a header are modifiable, e.g. the IPv4 protocol and
> fragment @@ -905,6 +926,8 @@ enum ovs_action_attr {
> OVS_ACTION_ATTR_TRUNC,/* u32 struct ovs_action_trunc. */
> OVS_ACTION_ATTR_PUSH_ETH, /* struct ovs_action_push_eth. */
> OVS_ACTION_ATTR_POP_ETH, /* No argument. */
> + OVS_ACTION_ATTR_ENCAP_NSH,/* struct ovs_action_encap_nsh. */
> + OVS_ACTION_ATTR_DECAP_NSH,/* No argument. */
Likewise, this should be PUSH and POP, not ENCAP and DECAP.
Thanks,
Jiri
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/6] userspace: Add support for NSH MD1 match fields
Thanks Jan, I have folded it to my local branch and will include it in next
version.
-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Tuesday, July 18, 2017 12:30 AM
To: Yang, Yi Y ; d...@openvswitch.org
Cc: Mengke Liu ; Li, Ricky ; Li,
Johnson
Subject: RE: [PATCH 1/6] userspace: Add support for NSH MD1 match fields
Hi Yi,
The following incremental makes the formatting of NSH fields in OpenFlow and
datapath flows more consistent and easier to use.
- Consistently format nsh_spi as hex without leading zeros.
- Consistently format MD1 context headers nsh_c without leading zeros.
- Format nsh_c headers only if md_type is MD1.
- Bugfix: format_odp_encap_nsh_action() was casting the nlattr to
incorrect type (struct ovs_key_nsh). This is nor corrected.
The new version also dumps the complete TLV metadata as hex sequence
in case of MD2 format.
diff --git a/lib/match.c b/lib/match.c
index 67fa958..a1e4c5c 100644
--- a/lib/match.c
+++ b/lib/match.c
@@ -1158,9 +1158,9 @@ format_be32_masked_hex(struct ds *s, const char *name,
if (mask != htonl(0)) {
ds_put_format(s, "%s%s=%s", colors.param, name, colors.end);
if (mask == OVS_BE32_MAX) {
-ds_put_format(s, "0x%08"PRIx32, ntohl(value));
+ds_put_format(s, "0x%"PRIx32, ntohl(value));
} else {
-ds_put_format(s, "0x%08"PRIx32"/0x%08"PRIx32,
+ds_put_format(s, "0x%"PRIx32"/0x%"PRIx32,
ntohl(value), ntohl(mask));
}
ds_put_char(s, ',');
@@ -1260,18 +1260,20 @@ format_nsh_masked(struct ds *s, const struct flow *f,
const struct flow *m)
if (m->nsh.np)
format_uint8_masked(s, "nsh_np", f->nsh.np, m->nsh.np);
if (m->nsh.spi)
-format_be32_masked(s, "nsh_spi", f->nsh.spi, m->nsh.spi);
+format_be32_masked_hex(s, "nsh_spi", f->nsh.spi, m->nsh.spi);
if (m->nsh.si)
format_uint8_masked(s, "nsh_si", f->nsh.si, m->nsh.si);
-if (m->nsh.c1)
-format_be32_masked_hex(s, "nsh_c1", f->nsh.c1, m->nsh.c1);
-if (m->nsh.c2)
-format_be32_masked_hex(s, "nsh_c2", f->nsh.c2, m->nsh.c2);
-if (m->nsh.c3)
-format_be32_masked_hex(s, "nsh_c3", f->nsh.c3, m->nsh.c3);
-if (m->nsh.c4)
-format_be32_masked_hex(s, "nsh_c4", f->nsh.c4, m->nsh.c4);
+if (m->nsh.mdtype == UINT8_MAX && f->nsh.mdtype == NSH_M_TYPE1) {
+if (m->nsh.c1)
+format_be32_masked_hex(s, "nsh_c1", f->nsh.c1, m->nsh.c1);
+if (m->nsh.c2)
+format_be32_masked_hex(s, "nsh_c2", f->nsh.c2, m->nsh.c2);
+if (m->nsh.c3)
+format_be32_masked_hex(s, "nsh_c3", f->nsh.c3, m->nsh.c3);
+if (m->nsh.c4)
+format_be32_masked_hex(s, "nsh_c4", f->nsh.c4, m->nsh.c4);
+}
}
/* Appends a string representation of 'match' to 's'. If 'priority' is diff
--git a/lib/odp-util.c b/lib/odp-util.c index 1d8e24b..122f5b7 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -302,9 +302,9 @@ format_be32_masked(struct ds *s, bool *first, const char
*name,
}
ds_put_format(s, "%s=", name);
if (mask == OVS_BE32_MAX) {
-ds_put_format(s, "0x%08"PRIx32, ntohl(value));
+ds_put_format(s, "0x%"PRIx32, ntohl(value));
} else {
-ds_put_format(s, "0x%08"PRIx32"/0x%08"PRIx32,
+ds_put_format(s, "0x%"PRIx32"/0x%"PRIx32,
ntohl(value), ntohl(mask));
}
*first = false;
@@ -340,17 +340,36 @@ format_nsh_key_mask(struct ds *ds, const struct
ovs_key_nsh *key, }
static void
-format_odp_encap_nsh_action(struct ds *ds, const struct nlattr *attr)
+format_odp_encap_nsh_action(struct ds *ds,
+const struct ovs_action_encap_nsh
+*encap_nsh)
{
-if (nl_attr_type(attr) != OVS_ACTION_ATTR_ENCAP_NSH) {
-return;
-}
-ds_put_cstr(ds, "encap_nsh(");
+uint32_t path_hdr = ntohl(encap_nsh->path_hdr);
+uint32_t spi = (path_hdr & NSH_SPI_MASK) >> NSH_SPI_SHIFT;
+uint8_t si = (path_hdr & NSH_SI_MASK) >> NSH_SI_SHIFT;
+bool first = true;
-size_t len = nl_attr_get_size(attr);
-if (len) {
-const struct ovs_key_nsh *nsh_key = nl_attr_get(attr);
-format_nsh_key(ds, nsh_key);
+ds_put_cstr(ds, "encap_nsh(");
+format_uint8_masked(ds, &first, "flags", encap_nsh->flags, UINT8_MAX);
+format_uint8_masked(ds, &first, "mdtype", encap_nsh->
Re: [ovs-dev] [PATCH 5/6] Generic encap and decap support for NSH
Thanks Jan, I have folded it to my local branch and will include it in next
version.
-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Tuesday, July 18, 2017 12:34 AM
To: Yang, Yi Y ; d...@openvswitch.org
Subject: RE: [PATCH 5/6] Generic encap and decap support for NSH
Hi Yi,
The following incremental fills the gaps to support NSH TLV properties in
encap(nsh) for MD2 format
BR, Jan
Encap properties of type OFPPPT_PROP_NSH_TLV are mapped to structs
nsh_md2_tlv during translation and concatenated in a new struct ofpbuf
*encap_data in the translation ctx.
At generation of the encap_nsh action, the sequence of MD2 TLVs is
copied as byte array from *encap_data into the datapath action. In the
datapath, encap_nsh copies the TLV metadata verbatim into the NSH MD2
packet header.
The decap_nsh action already skipped any metadata behind the basic NSH
header based on the NSH header length attribute.
Note: There is no support yet for parsing, matching and manipulating
NSH MD2 TLVs as OXM fields. This will be added in a future contribution.
diff --git a/lib/odp-util.c b/lib/odp-util.c index 57c6ec8..1d8e24b 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -6704,7 +6704,8 @@ odp_put_decap_nsh_action(struct ofpbuf *odp_actions)
static void
odp_put_encap_nsh_action(struct ofpbuf *odp_actions,
- const struct flow *flow)
+ const struct flow *flow,
+ struct ofpbuf *encap_data)
{
struct ovs_action_encap_nsh encap_nsh;
@@ -6724,8 +6725,13 @@ odp_put_encap_nsh_action(struct ofpbuf *odp_actions,
break;
}
case NSH_M_TYPE2:
-/* TODO */
-encap_nsh.mdlen = 0;
+if (encap_data) {
+ovs_assert(encap_data->size < OVS_ENCAP_NSH_MAX_MD_LEN);
+encap_nsh.mdlen = encap_data->size;
+memcpy(encap_nsh.metadata, encap_data->data, encap_data->size);
+} else {
+encap_nsh.mdlen = 0;
+}
break;
default:
encap_nsh.mdlen = 0;
@@ -6740,7 +6746,8 @@ commit_packet_type_change(const struct flow *flow,
struct flow *base_flow,
struct ofpbuf *odp_actions,
struct flow_wildcards *wc,
- bool pending_encap)
+ bool pending_encap,
+ struct ofpbuf *encap_data)
{
if (flow->packet_type == base_flow->packet_type) {
return;
@@ -6759,7 +6766,7 @@ commit_packet_type_change(const struct flow *flow,
}
case PT_NSH:
/* encap_nsh */
-odp_put_encap_nsh_action(odp_actions, flow);
+odp_put_encap_nsh_action(odp_actions, flow, encap_data);
base_flow->packet_type = flow->packet_type;
memcpy(&base_flow->nsh, &flow->nsh, sizeof base_flow->nsh);
/* TODO: Do we need to copy all the other fields too? */ @@
-6808,12 +6815,14 @@ commit_packet_type_change(const struct flow *flow, enum
slow_path_reason commit_odp_actions(const struct flow *flow, struct flow *base,
struct ofpbuf *odp_actions, struct flow_wildcards *wc,
- bool use_masked, bool pending_encap)
+ bool use_masked, bool pending_encap,
+ struct ofpbuf *encap_data)
{
enum slow_path_reason slow1, slow2;
bool mpls_done = false;
-commit_packet_type_change(flow, base, odp_actions, wc, pending_encap);
+commit_packet_type_change(flow, base, odp_actions, wc,
+ pending_encap, encap_data);
commit_set_ether_action(flow, base, odp_actions, wc, use_masked);
/* Make packet a non-MPLS packet before committing L3/4 actions,
* which would otherwise do nothing. */ diff --git a/lib/odp-util.h
b/lib/odp-util.h index ed16f96..ef55501 100644
--- a/lib/odp-util.h
+++ b/lib/odp-util.h
@@ -275,7 +275,8 @@ enum slow_path_reason commit_odp_actions(const struct flow
*,
struct ofpbuf *odp_actions,
struct flow_wildcards *wc,
bool use_masked,
- bool pending_encap);
+ bool pending_encap,
+ struct ofpbuf *encap_data);
^L
/* ofproto-dpif interface.
*
diff --git a/lib/packets.c b/lib/packets.c index 45ddfee..ba4334a 100644
--- a/lib/packets.c
+++ b/lib/packets.c
@@ -433,11 +433,14 @@ encap_nsh(struct dp_packet *packet, const struct
ovs_action_encap_nsh *encap)
nsh->md_type = encap->mdtype;
switch (nsh->md_type) {
case NSH_M_TYPE1:
-nsh->md1 = *(struct nsh_md1_ctx *) encap->metadata;
+nsh->md1 = *ALIGNED_CAST
Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath
Jan, yes, we have patch to parse GTP-u as L7 protocol and implemented
corresponding match fields. This needn't any extra prerequisite, the parser
just parse the GTP-u header in UDP packet if its UDP destination port is 2152.
Here is our change against struct flow.
diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h
index 91966df..8078fa5 100644
--- a/include/openvswitch/flow.h
+++ b/include/openvswitch/flow.h
@@ -152,6 +152,10 @@ struct flow {
ovs_be32 igmp_group_ip4;/* IGMP group IPv4 address.
* Keep last for BUILD_ASSERT_DECL below. */
ovs_be32 pad3; /* Pad to 64 bits. */
+
+/* L5 (64-bit aligned) */
+union fields l5_fields;
};
BUILD_ASSERT_DECL(sizeof(struct flow) % sizeof(uint64_t) == 0);
BUILD_ASSERT_DECL(sizeof(struct flow_tnl) % sizeof(uint64_t) == 0);
union fields l5_fields is defined as below
/* L5 information used in flow key. */
struct gtp_u_mf {
uint8_t gtp_flag;
uint8_t gtp_msgtype;
ovs_be32 gtp_teid;
ovs_be32 ip_dst_in_gtp_u;
ovs_be32 ip_src_in_gtp_u;
uint8_t ip_proto_in_gtp_u;
ovs_be16 tp_src_in_gtp_u;
ovs_be16 tp_dst_in_gtp_u;
};
-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Tuesday, July 18, 2017 6:39 AM
To: Yang, Yi Y ; Amar Padmanabhan
; Joe Stringer ; Wieger IJntema
Cc: ovs dev ; Pablo Neira Ayuso ;
Harald Welte
Subject: RE: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath
Yi, so what you are saying is that for the third use case (GTP-u processing w/o
terminating UDP transport tunnel) you have patched OVS to parse GTP-u as L7
protocol and implemented corresponding match fields?
There is no Ethertype defined for GTP-u as it is only specified for UDP
transport. Supporting GTP-u as new packet type in OVS would require to
implement support for new packet type namespace OFPHTN_UDP_TCP_PORT (code point
3). So it's a bit more work than for a new packet type in namespace
OFPHTN_ETHERTYPE, but certainly doable.
The same GTP-u fields could be used as L7 fields (flow prerequisites udp,
tp_dst_port= 2152) and directly for new packet type (OFPHTN_UDP_TCP_PORT,2125).
Only in the latter case a decap() action could be used to remove the GTP-u
encapsulation. In the former case, processing would be limited to matching and
GTP-u header modification.
BR, Jan
> -Original Message-
> From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
> Sent: Monday, 17 July, 2017 11:18
> To: Jan Scheurich ; Amar Padmanabhan
> ; Joe Stringer ; Wieger IJntema
>
> Cc: ovs dev ; Pablo Neira Ayuso
> ; Harald Welte
> Subject: RE: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream
> datapath
>
> Jan, for the use case you mentioned, outer IP destination of the GPT-u
> packet must be IP address of generic UDP tunnel port, but in the
> actual use case (especially for ETSI MEC use case), the destination IP of the
> GTP-u packet isn't ovs host node's IP, so this kind of use case needn't
> tunnel port, we internally have implemented GTP-u header parsing and match as
> application layer data.
>
> But I do agree it is a good direction to implement tunnel port and
> tunnel encap & decap by using generic UDP tunnel port and generic encap &
> decap action.
>
> -Original Message-
> From: ovs-dev-boun...@openvswitch.org
> [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Jan Scheurich
> Sent: Monday, July 17, 2017 4:24 PM
> To: Amar Padmanabhan ; Joe Stringer
> ; Wieger IJntema
> Cc: ovs dev ; Pablo Neira Ayuso
> ; Harald Welte
> Subject: Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream
> datapath
>
> These are indeed two different use case. The pure termination of the
> GTP-u tunnel can be done by adding support for a GTP-u tunnel vport,
> which should be straightforward now that we have support for L3 tunneling
> fully upstreamed in in OVS and based on the GTP tunnel support in the Linux
> kernel.
>
> For more flexible use cases that match on GTP-u header fields and only
> conditionally decapsulate packets, we would like to have support for
> adding/removing the GTP-u header in the OpenFlow pipeline. This use case will
> be shortly be possible to implement based on the packet type-aware pipeline
> (PTAP) and generic encap/decap (EXT-382) infrastructure that we are currently
> upstreaming:
> PTAP: commit 3d4b2e6eb74 and following
> EXT-382:
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/335642.html
>
> For such use cases three things will have to be added on top:
> 1. A generic UDP tunnel vport (as already supported by the Linux
> kernel, I understand) to terminate the UDP transport tunnel and deliver a
> GTP-u packet to the PTAP OpenFlow pipeline. (There are also oth
Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath
Jan, for the use case you mentioned, outer IP destination of the GPT-u packet must be IP address of generic UDP tunnel port, but in the actual use case (especially for ETSI MEC use case), the destination IP of the GTP-u packet isn't ovs host node's IP, so this kind of use case needn't tunnel port, we internally have implemented GTP-u header parsing and match as application layer data. But I do agree it is a good direction to implement tunnel port and tunnel encap & decap by using generic UDP tunnel port and generic encap & decap action. -Original Message- From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Jan Scheurich Sent: Monday, July 17, 2017 4:24 PM To: Amar Padmanabhan ; Joe Stringer ; Wieger IJntema Cc: ovs dev ; Pablo Neira Ayuso ; Harald Welte Subject: Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath These are indeed two different use case. The pure termination of the GTP-u tunnel can be done by adding support for a GTP-u tunnel vport, which should be straightforward now that we have support for L3 tunneling fully upstreamed in in OVS and based on the GTP tunnel support in the Linux kernel. For more flexible use cases that match on GTP-u header fields and only conditionally decapsulate packets, we would like to have support for adding/removing the GTP-u header in the OpenFlow pipeline. This use case will be shortly be possible to implement based on the packet type-aware pipeline (PTAP) and generic encap/decap (EXT-382) infrastructure that we are currently upstreaming: PTAP: commit 3d4b2e6eb74 and following EXT-382: https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/335642.html For such use cases three things will have to be added on top: 1. A generic UDP tunnel vport (as already supported by the Linux kernel, I understand) to terminate the UDP transport tunnel and deliver a GTP-u packet to the PTAP OpenFlow pipeline. (There are also other interesting use cases for such a tunnel vport, e.g. MPLS over UDP.) 2. Support for GTP-u match fields in ofproto and datapaths 3. Support for generic encap and decap actions for the GTP-u packet type. The current work on support for NSH tunnels can be seen as an example for items 2. and 3. https://mail.openvswitch.org/pipermail/ovs-dev/2017-July/334872.html We would be very happy to see the PTAP and encap/decap infrastructure be applied to additional use cases. I currently don't see a possibility to match on GTP-u headers in OVS without first terminating the UDP transport tunnel. BR, Jan > -Original Message- > From: ovs-dev-boun...@openvswitch.org > [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Amar Padmanabhan > Sent: Friday, 14 July, 2017 19:23 > To: Joe Stringer ; Wieger IJntema > > Cc: ovs dev ; Harald Welte > ; Pablo Neira Ayuso > Subject: Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream > datapath > > Yeah, we are looking at tunnel termination in OVS, i.e. GGSN or PGW. I > think what you mention Weiger is about an on-path device that also does some > classification like some of the 5G proposals. I think Yi is also looking at > it but that is not directly related to this patch set. > - Amar > > On 7/14/17, 10:01 AM, "Joe Stringer" wrote: > > On 14 July 2017 at 04:53, Wieger IJntema > wrote: > >> ovs-vsctl add-port br0 gtp-vport -- set interface gtp-vport \ > >> ofport_request=2 type=gtp option:remote_ip=flow options:key=flow > >> > >> ovs-ofctl add-flow br0 > >> "in_port=2,tun_src=192.168.60.141,tun_id=123, \ > >> actions=set_field:02:00:00:00:00:00->eth_src, \ > >> set_field:ff:ff:ff:ff:ff:ff->eth_dst,LOCAL" > > > > > > I just want to be sure. But this implicates that the incomming packet is > > already decapusulated by the kernel and it has attached metadata like > the > > tunnel_id etc. > > a nicer solution would be that you can already match on tunnel_id > before it > > is getting encapsulated. Then you can chose later if it needa > decapsulation > > or just forward the packet. > > I'm not sure if it is a possibility? > > I wonder if we're actually discussing two different use cases? I think > that Jiannan & co are interested in GGSN functionality, whereas if my > understanding serves me right what you're proposing sounds more like > SGSN functionality. This approach is specifically for the edge of the > GTP-tunnelled network so it's always wanting to perform encap/decap. > For this particular use case, the proposed approach has a couple of > nice attributes. Firstly, the tunneling follows the same model as all > of the existing tunneling code so it fits quite well without needing > to solve new problems for a new tunnel protocol type. Secondly, the > kernel can deal with filtering GTP-C traffic out of the stream to > forward to the appropriate GTP daemon, which means th
Re: [ovs-dev] [PATCH 5/6] Generic encap and decap support for NSH
Thanks Jan, I have folded it to next version.
-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Monday, July 17, 2017 2:57 AM
To: Yang, Yi Y ; d...@openvswitch.org
Subject: RE: [PATCH 5/6] Generic encap and decap support for NSH
Hi Yi,
The following incremental patch unwildcards the NSH next proto field at
translation of a decap() action for an NSH packet. This ensures that a
datapath flow only decaps NSH packets of a known encapsulated packet type,
avoiding bad suprises when executing decap_nsh action in the datapath.
This implies updates to the NSH unit tests as the datapath flow now includes
the match on nsh_np.
For consistency we also unwildcard field dl_type when translating decap for an
Ethernet packet, even though the pop_eth datapath action works for any
Ethertype.
BR, Jan
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c index
f7e68c4..41a2dd1 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -5612,10 +5612,12 @@ xlate_generic_decap_action(struct xlate_ctx *ctx,
* Delay generating pop_eth to the next commit. */
flow->packet_type = htonl(PACKET_TYPE(OFPHTN_ETHERTYPE,
ntohs(flow->dl_type)));
+ctx->wc->masks.dl_type = OVS_BE16_MAX;
return false;
case PT_NSH:
-/* decap_nsh */
-/* Delay generating decap_nsh to the next commit. */
+/* The decap_nsh action is generated at the commit executed as
+ * part of freezing the ctx for recirculation. Here we just set
+ * the new packet type based on the NSH next protocol
+ field. */
switch (flow->nsh.np) {
case NSH_P_ETHERNET:
flow->packet_type = htonl(PT_ETH); @@ -5638,6 +5640,8 @@
xlate_generic_decap_action(struct xlate_ctx *ctx,
return false;
break;
}
+ctx->wc->masks.nsh.np = UINT8_MAX;
+/* Trigger recirculation. */
return true;
default:
xlate_report_debug(ctx, OFT_ACTION, diff --git a/tests/nsh.at
b/tests/nsh.at index 749e981..bbf3bbb 100644
--- a/tests/nsh.at
+++ b/tests/nsh.at
@@ -122,7 +122,7 @@ bridge("br0")
decap()
Final flow: unchanged
-Megaflow:
recirc_id=0,eth,in_port=4,dl_type=0x894f,nsh_mdtype=1,nsh_spi=4660,nsh_c1=0x11223344
+Megaflow:
+recirc_id=0,eth,in_port=4,dl_type=0x894f,nsh_mdtype=1,nsh_np=3,nsh_spi=
+4660,nsh_c1=0x11223344
Datapath actions: pop_eth,decap_nsh(),recirc(0x2)
])
@@ -456,7 +456,7 @@ AT_CHECK([
], [0], [flow-dump from non-dpdk interfaces:
recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:03),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10.0.0.3,proto=17,frag=no),udp(dst=4789),
packets:1, b
recirc_id(0),in_port(4),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=192.168.10.30,frag=no),
packets:1, bytes:98, used:0.0s, actions:pop_eth,encap_nsh(flags=0,mdty
-tunnel(tun_id=0x0,src=30.0.0.1,dst=30.0.0.3,flags(-df-csum+key)),recirc_id(0),in_port(4789),packet_type(ns=1,id=0x894f),nsh(spi=0x0bb8,si=255),
packets:1, bytes:10
+tunnel(tun_id=0x0,src=30.0.0.1,dst=30.0.0.3,flags(-df-csum+key)),recirc
+_id(0),in_port(4789),packet_type(ns=1,id=0x894f),nsh(np=1,spi=0x0bb
+8,si=255), packets:1, byt
tunnel(tun_id=0x0,src=30.0.0.1,dst=30.0.0.3,flags(-df-csum+key)),recirc_id(0x1),in_port(4789),packet_type(ns=1,id=0x800),ipv4(frag=no),
packets:1, bytes:84, used:0.0s,
])
@@ -513,7 +513,7 @@
recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:02),eth_ty
recirc_id(0),in_port(2),packet_type(ns=0,id=0),eth(dst=aa:55:00:00:00:03),eth_type(0x0800),ipv4(src=20.0.0.2,dst=20.0.0.3,proto=17,frag=no),udp(dst=4789),
packets:1, b
recirc_id(0),in_port(4),packet_type(ns=0,id=0),eth_type(0x0800),ipv4(dst=192.168.10.20/255.255.255.248,frag=no),
packets:1, bytes:98, used:0.0s, actions:pop_eth,encap_
tunnel(tun_id=0x0,src=20.0.0.1,dst=20.0.0.2,flags(-df-csum+key)),recirc_id(0),in_port(4789),packet_type(ns=1,id=0x894f),nsh(spi=0x0bcc,si=255),
packets:1, bytes:10
-tunnel(tun_id=0x0,src=30.0.0.2,dst=30.0.0.3,flags(-df-csum+key)),recirc_id(0),in_port(4789),packet_type(ns=1,id=0x894f),nsh(spi=0x0bcc,si=254),
packets:1, bytes:10
+tunnel(tun_id=0x0,src=30.0.0.2,dst=30.0.0.3,flags(-df-csum+key)),recirc
+_id(0),in_port(4789),packet_type(ns=1,id=0x894f),nsh(np=1,spi=0x0bc
+c,si=254), packets:1, byt
tunnel(tun_id=0x0,src=30.0.0.2,dst=30.0.0.3,flags(-df-csum+key)),recirc_id(0x2),in_port(4789),packet_type(ns=1,id=0x800),ipv4(frag=no),
packets:1, bytes:84, used:0.0s,
])
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 0/6] Generic Encap & Decap based NSH implementation
Thanks Jan, I have folded it to next version.
-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Monday, July 17, 2017 2:52 AM
To: Yang, Yi Y ; d...@openvswitch.org
Subject: RE: [ovs-dev] [PATCH 0/6] Generic Encap & Decap based NSH
implementation
Hi Yi,
The following incremental clarifies and cleans up the error handling during
translation of encap and decap actions for NSH:
- Rephrased the xlate_report_debug() messages when dropping packets during
translation of encap/decap actions.
- Encap and decap translation error handling should be complete. Removed any
TODO from the comments.
- As all encap/decap errors are checked during translation, the function
commit_packet_type_change() should throw an abort when it encounters
an unexpected combination of old and new packet types.
diff --git a/lib/odp-util.c b/lib/odp-util.c index 02c9859..57c6ec8 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -6765,24 +6765,31 @@ commit_packet_type_change(const struct flow *flow,
/* TODO: Do we need to copy all the other fields too? */
break;
default:
-/* Only the above protocols are supported for encap. The check
- * is done at action decoding. */
+/* Only the above protocols are supported for encap.
+ * The check is done at action translation. */
OVS_NOT_REACHED();
}
} else {
-/* This is a decap case. It can only happen after translation of a
- * decap action. */
+/* This is an explicit or implicit decap case. */
if (pt_ns(flow->packet_type) == OFPHTN_ETHERTYPE &&
base_flow->packet_type == htonl(PT_ETH)) {
-/* pop_eth */
+/* Generate pop_eth and continue without recirculation. */
odp_put_pop_eth_action(odp_actions);
base_flow->packet_type = flow->packet_type;
base_flow->dl_src = eth_addr_zero;
base_flow->dl_dst = eth_addr_zero;
-} else if (ntohl(base_flow->packet_type) == PT_NSH) {
+} else {
+/* All other decap cases require recirculation.
+ * No need to update the base flow here. */
+switch (ntohl(base_flow->packet_type)) {
+case PT_NSH:
+/* decap_nsh. */
odp_put_decap_nsh_action(odp_actions);
-base_flow->packet_type = flow->packet_type;
-memcpy(&base_flow->nsh, &flow->nsh, sizeof(base_flow->nsh));
+break;
+default:
+/* Checks are done during translation. */
+OVS_NOT_REACHED();
+}
}
}
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c index
41a2dd1..9ebfd30 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -5459,10 +5459,10 @@ rewrite_flow_encap_ethernet(struct xlate_ctx *ctx,
flow->dl_dst = eth_addr_zero;
flow->dl_type = ethertype;
} else {
+/* Error handling: drop packet. */
xlate_report_debug(ctx, OFT_ACTION,
- "encap(ethernet) unsupported for packet type "
- "ethernet");
-/* TODO: Error handling: drop packet. */
+ "Dropping packet as encap(ethernet) is not "
+ "supported for packet type ethernet.");
ctx->error = 1;
}
}
@@ -5532,9 +5532,11 @@ rewrite_flow_encap_nsh(struct xlate_ctx *ctx,
np = NSH_P_NSH;
break;
default:
+/* Error handling: drop packet. */
xlate_report_debug(ctx, OFT_ACTION,
- "encap(nsh) for unsupported packet type %x",
- ntohl(packet_type));
+ "Dropping packet as encap(nsh) is not "
+ "supported for packet type (%d,0x%x)",
+ pt_ns(packet_type),
+ pt_ns_type(packet_type));
ctx->error = 1;
return;
}
@@ -5584,6 +5586,7 @@ xlate_generic_encap_action(struct xlate_ctx *ctx,
rewrite_flow_encap_nsh(ctx, encap, flow, wc);
break;
default:
+/* New packet type was checked during decoding. */
OVS_NOT_REACHED();
break;
}
@@ -5632,10 +5635,10 @@ xlate_generic_decap_action(struct xlate_ctx *ctx,
flow->packet_type = htonl(PT_NSH);
break;
default:
+/* Error handling: drop packet. */
xlate_report_debug(ctx, OFT_ACTION,
- "decap() NSH Next Protocol not supported"
- &q
Re: [ovs-dev] [PATCH 5/6] Generic encap and decap support for NSH
Thanks Jan, I have folded it to next version.
-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com]
Sent: Monday, July 17, 2017 2:49 AM
To: Yang, Yi Y ; d...@openvswitch.org
Subject: RE: [PATCH 5/6] Generic encap and decap support for NSH
Hi Yi,
The following incremental patch drops a packet in the datapath at decap_nsh()
rather than aborting if the NSH next protocol field does not match any of the
supported values.
Normally this should not happen if the next proto field is checked in the
ofproto translation, but it feels safer to gracefully handle this case.
It also adds support for NSN in NSH encapsulation in in the encap_nsh and
decap_nsh Action in the datapath to match the translation logic in ofproto.
BR, Jan
diff --git a/lib/odp-execute.c b/lib/odp-execute.c index 12f517e..14978a7 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -828,11 +828,18 @@ odp_execute_actions(void *dp, struct dp_packet_batch
*batch, bool steal,
}
break;
}
-case OVS_ACTION_ATTR_DECAP_NSH:
-DP_PACKET_BATCH_FOR_EACH (packet, batch) {
-decap_nsh(packet);
+case OVS_ACTION_ATTR_DECAP_NSH: {
+size_t i, num = batch->count;
+
+DP_PACKET_BATCH_REFILL_FOR_EACH (i, num, packet, batch) {
+if (decap_nsh(packet)) {
+dp_packet_batch_refill(batch, packet, i);
+} else {
+dp_packet_delete(packet);
+}
}
break;
+}
case OVS_ACTION_ATTR_OUTPUT:
case OVS_ACTION_ATTR_TUNNEL_PUSH:
diff --git a/lib/packets.c b/lib/packets.c index f0ba027..45ddfee 100644
--- a/lib/packets.c
+++ b/lib/packets.c
@@ -419,6 +419,9 @@ encap_nsh(struct dp_packet *packet, const struct
ovs_action_encap_nsh *encap)
case PT_IPV6:
next_proto = NSH_P_IPV6;
break;
+case PT_NSH:
+next_proto = NSH_P_NSH;
+break;
default:
OVS_NOT_REACHED();
}
@@ -444,7 +447,7 @@ encap_nsh(struct dp_packet *packet, const struct
ovs_action_encap_nsh *encap)
packet->l3_ofs = 0;
}
-void
+bool
decap_nsh(struct dp_packet *packet)
{
struct nsh_hdr *nsh = (struct nsh_hdr *) dp_packet_l3(packet); @@ -462,8
+465,12 @@ decap_nsh(struct dp_packet *packet)
case NSH_P_IPV6:
next_pt = PT_IPV6;
break;
+case NSH_P_NSH:
+next_pt = PT_NSH;
+break;
default:
-OVS_NOT_REACHED();
+/* Unknown inner packet type. Drop packet. */
+return false;
}
length = nsh_hdr_len(nsh);
@@ -471,6 +478,7 @@ decap_nsh(struct dp_packet *packet)
packet->packet_type = htonl(next_pt);
/* Packet must be recirculated for further processing. */
}
+return true;
}
/* Converts hex digits in 'hex' to an Ethernet packet in '*packetp'. The diff
--git a/lib/packets.h b/lib/packets.h index 19571b1..ff0c4cc 100644
--- a/lib/packets.h
+++ b/lib/packets.h
@@ -409,7 +409,7 @@ void pop_eth(struct dp_packet *packet);
void encap_nsh(struct dp_packet *packet,
const struct ovs_action_encap_nsh *encap_nsh); -void
decap_nsh(struct dp_packet *packet);
+bool decap_nsh(struct dp_packet *packet);
#define LLC_DSAP_SNAP 0xaa
#define LLC_SSAP_SNAP 0xaa
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/4] Add OF actions for generic encap and decap
Jan, here is ALIGNED_CAST macro /* Given ATTR, and TYPE, cast the ATTR to TYPE by first casting ATTR to * (void *). This is to suppress the alignment warning issued by clang. */ #define ALIGNED_CAST(TYPE, ATTR) ((TYPE) (void *) (ATTR)) It is just for suppressing the error message Ben saw, so we can safely use it, the below patch is perfect solution to the issue :-) -Original Message- From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] Sent: Friday, July 14, 2017 1:34 AM To: Ben Pfaff ; Zoltán Balogh Cc: 'd...@openvswitch.org' ; Georg Schmuecking ; Jiri Benc (jb...@redhat.com) ; Yang, Yi Y Subject: RE: [PATCH 1/4] Add OF actions for generic encap and decap The simple way out is to use ALIGNED_CAST instead. diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c index 04dd048..cc19db4 100644 --- a/lib/ofp-actions.c +++ b/lib/ofp-actions.c @@ -4189,7 +4189,8 @@ parse_ENCAP(char *arg, return error; } /* ofbuf out may have been re-allocated. */ -encap = (struct ofpact_encap *) ((char *)out->data + start_ofs); +encap = ALIGNED_CAST(struct ofpact_encap *, (char *)out->data + + start_ofs); encap->n_props = n_props; ofpact_finish_ENCAP(out, &encap); return NULL; @@ -4224,7 +4225,7 @@ format_ed_props(struct ds *s, uint16_t n_props, format_ed_prop_value(s, prop); ds_put_cstr(s, ")"); p += ROUND_UP(prop->len, 8); -prop = (const struct ofpact_ed_prop *) p; +prop = ALIGNED_CAST(const struct ofpact_ed_prop *, p); } } While I'm sure this is correct for the second case, I don't understand enough of the ofpbuf implementation to be certain that the buffer has the same alignment after a re-allocation. If that was guaranteed, the ALIGNED_CAST should be safe as the start_ofs does not change. /Jan > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Thursday, 13 July, 2017 19:22 > To: Zoltán Balogh > Cc: 'd...@openvswitch.org' ; Jan Scheurich > ; Georg Schmuecking > ; Jiri Benc (jb...@redhat.com) > ; Yang, Yi Y > Subject: Re: [PATCH 1/4] Add OF actions for generic encap and decap > > On Thu, Jul 13, 2017 at 04:49:09PM +, Zoltán Balogh wrote: > > 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 'const struct ofpact_ed_prop > > > *' increases required alignment from 1 to 2 [-Werror,-Wcast-align] > > > > I cannot see these errors. I've tested with GCC 4.8.4 on Ubuntu 14.04.5 LTS > > and with GCC 6.3.0 on Ubuntu 17.04. > > Which version of GCC and Linux distro did you use? Did you pass any special > > args to make or to the configure script? > > It might be specific to 32-bit builds, since I build and test on i386. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/4] Add OF actions for generic encap and decap
I also tried it with 32 bit build on 64 bit machine by a simple c program with " -m32 -Werror -Wcast-align" options, but I can't reproduce this error information. The error message is saying char pointer or uint8 pointer may be any address (non-alignment to 4 or 8 bytes boundary), but struct ofpact_ed_prop pointer aligns to 4 or 8 bytes boundary, our code and variable struct results in that we can hardly handle this. A way is to remove "-Wcast-align" from ovs compiling option. -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Friday, July 14, 2017 1:22 AM To: Zoltán Balogh Cc: 'd...@openvswitch.org' ; Jan Scheurich ; Georg Schmuecking ; Jiri Benc (jb...@redhat.com) ; Yang, Yi Y Subject: Re: [PATCH 1/4] Add OF actions for generic encap and decap On Thu, Jul 13, 2017 at 04:49:09PM +, Zoltán Balogh wrote: > 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 'const struct ofpact_ed_prop *' > > increases required alignment from 1 to 2 [-Werror,-Wcast-align] > > I cannot see these errors. I've tested with GCC 4.8.4 on Ubuntu 14.04.5 LTS > and with GCC 6.3.0 on Ubuntu 17.04. > Which version of GCC and Linux distro did you use? Did you pass any special > args to make or to the configure script? It might be specific to 32-bit builds, since I build and test on i386. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 2/4] Translation of generic encap and decap actions
Zoltan will do that. -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Wednesday, July 12, 2017 11:59 AM To: Yang, Yi Y Cc: Zoltán Balogh ; 'd...@openvswitch.org' ; Jan Scheurich ; Georg Schmuecking ; Jiri Benc (jb...@redhat.com) Subject: Re: [PATCH 2/4] Translation of generic encap and decap actions OK. Are you willing to squash the first two patches for the next version? It looks to me like they form a single logical change. On Wed, Jul 12, 2017 at 12:41:10AM +0000, Yang, Yi Y wrote: > Ben, encap action is just adding an empty header, set_field action will set > the fields in the encapped header, so encap and set actions can be combined > if we defer encap action, this is an optimization. > > -Original Message- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Wednesday, July 12, 2017 8:28 AM > To: Zoltán Balogh > Cc: 'd...@openvswitch.org' ; Jan Scheurich > ; Georg Schmuecking > ; Yang, Yi Y ; > Jiri Benc (jb...@redhat.com) > Subject: Re: [PATCH 2/4] Translation of generic encap and decap > actions > > On Fri, Jun 30, 2017 at 03:29:32PM +, Zoltán Balogh wrote: > > 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 in accordance with the new packet type and > > header. In the case of encap(ethernet) it suffices to change the > > packet type from (1, Ethertype) to (0,0) and set the dl_type > > accordingly. A new pending_encap flag in xlate ctx is set to mark > > that an corresponding datapath encap action must be triggered at the > > next commit. In the case of encap(ethernet) ofproto generetas a push_eth > > action. > > > > The general case for translation of decap() is to emit a datapath > > action to decap the current outermost header and then recirculate > > the packet to reparse the inner headers. In the special case of an > > Ethernet packet, > > decap() just changes the packet type from (0,0) to (1, dl_type) > > without a need to recirculate. The emission of the pop_eth action > > for the datapath is postponed to the next commit. > > > > Hence encap(ethernet) and decap() on an Ethernet packet are OF > > octions that only incur a cost in the dataplane when a modifed > > packet is actually committed, e.g. because it is sent out. They can > > freely be used for normalizing the packet type in the OF pipeline > > without degrading performance. > > > > Signed-off-by: Jan Scheurich > > Signed-off-by: Yi Yang > > Thanks for posting this. > > It looks like a lot of the purpose of this commit is to fill in the blanks > with the first commit in the series, fixing some of the issues and > implementing bits that were missing. I think that it would be easier to > review if the two commits were squashed together. > > I am not sure that I understand the way of doing deferred encap actions. It > looks like, for example, one can chain a number of encap actions, but that > the result is just encapsulating once. Am I reading that right? > > Thanks, > > Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 2/4] Translation of generic encap and decap actions
Ben, encap action is just adding an empty header, set_field action will set the fields in the encapped header, so encap and set actions can be combined if we defer encap action, this is an optimization. -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Wednesday, July 12, 2017 8:28 AM To: Zoltán Balogh Cc: 'd...@openvswitch.org' ; Jan Scheurich ; Georg Schmuecking ; Yang, Yi Y ; Jiri Benc (jb...@redhat.com) Subject: Re: [PATCH 2/4] Translation of generic encap and decap actions On Fri, Jun 30, 2017 at 03:29:32PM +, Zoltán Balogh wrote: > 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 in accordance with the new packet type and > header. In the case of encap(ethernet) it suffices to change the > packet type from (1, Ethertype) to (0,0) and set the dl_type > accordingly. A new pending_encap flag in xlate ctx is set to mark that > an corresponding datapath encap action must be triggered at the next > commit. In the case of encap(ethernet) ofproto generetas a push_eth action. > > The general case for translation of decap() is to emit a datapath > action to decap the current outermost header and then recirculate the > packet to reparse the inner headers. In the special case of an > Ethernet packet, > decap() just changes the packet type from (0,0) to (1, dl_type) > without a need to recirculate. The emission of the pop_eth action for > the datapath is postponed to the next commit. > > Hence encap(ethernet) and decap() on an Ethernet packet are OF octions > that only incur a cost in the dataplane when a modifed packet is > actually committed, e.g. because it is sent out. They can freely be > used for normalizing the packet type in the OF pipeline without > degrading performance. > > Signed-off-by: Jan Scheurich > Signed-off-by: Yi Yang Thanks for posting this. It looks like a lot of the purpose of this commit is to fill in the blanks with the first commit in the series, fixing some of the issues and implementing bits that were missing. I think that it would be easier to review if the two commits were squashed together. I am not sure that I understand the way of doing deferred encap actions. It looks like, for example, one can chain a number of encap actions, but that the result is just encapsulating once. Am I reading that right? Thanks, Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/6] userspace: Add support for NSH MD1 match fields
Ok, will do. -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Wednesday, July 12, 2017 2:29 AM To: Yang, Yi Y Cc: ovs dev ; Li, Ricky ; Mengke Liu Subject: Re: [ovs-dev] [PATCH 1/6] userspace: Add support for NSH MD1 match fields On 7 July 2017 at 16:44, Yang, Yi Y wrote: > Joe, NSH for kernel datapath will be coming once this series is merged, do we > need to do so yet? Until the patch is merged upstream in the net-next tree, the enum is not officially dedicated to this particular feature and it's plausible that someone else comes along and proposes a different use for the same number; or alternatively it's plausible that upstream feedback leads to changing the enums for this new feature. For now, please keep them behind "#ifndef __KERNEL__" in the OVS tree. When the NSH for kernel datapath patches go through upstream, they will get long-term guaranteed values and we can subsequently fix up the values in the tree here to be consistent with the Linux tree. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/6] userspace: Add support for NSH MD1 match fields
Joe, NSH for kernel datapath will be coming once this series is merged, do we
need to do so yet?
-Original Message-
From: Joe Stringer [mailto:j...@ovn.org]
Sent: Friday, July 7, 2017 6:04 PM
To: Yang, Yi Y
Cc: ovs dev ; Li, Ricky ; Mengke Liu
Subject: Re: [ovs-dev] [PATCH 1/6] userspace: Add support for NSH MD1 match
fields
On 4 July 2017 at 20:45, Yi Yang wrote:
> From: Jan Scheurich
>
> This patch adds support for NSH packet header fields to the OVS
> control plane and the userspace datapath. Initially we support the
> fields of the NSH base header as defined in
> https://www.ietf.org/id/draft-ietf-sfc-nsh-12.txt
> and the fixed context headers specified for metadata format MD1.
> The variable length MD2 format is parsed but the TLV context headers
> are not yet available for matching.
>
> The NSH fields are modelled as OXM fields with the dedicated OXM class
> 0x8004 proposed for NSH in ONF. The following fields are defined:
>
> OXM codeofctl nameSize Comment
> --
> OXM_NSH_FLAGS nsh_flags 8 Bits 2-9 of 1st NSH word
> (0x8004,1)
> OXM_NSH_MDTYPE nsh_mdtype 8 Bits 16-23
> (0x8004,2)
> OXM_NSH_NEXTPROTO nsh_np 8 Bits 24-31
> (0x8004,3)
> OXM_NSH_SPI nsh_spi 24 Bits 0-23 of 2nd NSH word
> (0x8004,4)
> OXM_NSH_SI nsh_si 8 Bits 24-31
> (0x8004,5)
> OXM_NSH_C1 nsh_c1 32 Maskable, nsh_mdtype==1
> (0x8004,6)
> OXM_NSH_C2 nsh_c2 32 Maskable, nsh_mdtype==1
> (0x8004,7)
> OXM_NSH_C3 nsh_c3 32 Maskable, nsh_mdtype==1
> (0x8004,8)
> OXM_NSH_C4 nsh_c4 32 Maskable, nsh_mdtype==1
> (0x8004,9)
>
> Signed-off-by: Mengke Liu
> Signed-off-by: Ricky Li
> Signed-off-by: Johnson Li
> Signed-off-by: Yi Yang
> Signed-off-by: Jan Scheurich
> ---
Hi Yi, Jan,
Just relating to our other discussion on the GTP thread, I gave one minor
comment below. I don't have specific plans to review the rest of the series at
this stage.
Oh, and I see that there's no co-author tags in the commit message either.
> static const struct ovs_len_tbl
> ovs_vxlan_ext_key_lens[OVS_VXLAN_EXT_MAX + 1] = { diff --git
> a/datapath/linux/compat/include/linux/openvswitch.h
> b/datapath/linux/compat/include/linux/openvswitch.h
> index 91d3140..f5814c5 100644
> --- a/datapath/linux/compat/include/linux/openvswitch.h
> +++ b/datapath/linux/compat/include/linux/openvswitch.h
> @@ -359,6 +359,7 @@ enum ovs_key_attr {
> OVS_KEY_ATTR_CT_LABELS, /* 16-octet connection tracking labels */
> OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4, /* struct ovs_key_ct_tuple_ipv4 */
> OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV6, /* struct ovs_key_ct_tuple_ipv6 */
> + OVS_KEY_ATTR_NSH, /* struct ovs_key_nsh */
Until such changes are proposed upstream on netdev, we should put these under
the ifndef kernel a few lines below.
Same with all of the other enum changes in this file.
Cheers,
Joe
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink attribute
Eric, I verified this one, ptap unit tests and nsh tests passed without any
change, so it seems it is better than the original one you did.
-Original Message-
From: Eric Garver [mailto:e...@erig.me]
Sent: Friday, July 7, 2017 3:44 AM
To: Zoltán Balogh
Cc: Yang, Yi Y ; 'd...@openvswitch.org'
Subject: Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink
attribute
On Thu, Jul 06, 2017 at 01:14:31PM +, Zoltán Balogh wrote:
> Hi Eric,
>
> Thank you for clarifying.
>
> ...
> [OVS_FLOW_ATTR_KEY]
> ...
> [OVS_KEY_ATTR_IPV4] = ...
> ...
> [OVS_KEY_ATTR_ETHERTYPE] = ... <--- the one inserted
>
> I have not found any API that would extend a nested attribute.
> Maybe I'm wrong, but I thought 'buf' holds a single nested attribute. If this
> is true, isn't possible to add the ethertype to it and increase its size?
I gave it a try and realized it doesn't matter.
During the upcall we pass back the same key that the kernel gave us, with the
exception that we also fill in wildcard info. See
upcall_xlate() and ukey_create_from_upcall(). This is why my original patch
works. It caused odp_flow_key_from_mask() to fill the ETHERTYPE for the mask.
So I think this can only be solved in one of two places:
1) odp_flow_key_from_mask(), as my original patch did.
- This sets the wildcard for all dpifs, including userspace/netdev.
2) xlate_wc_init() and xlate_wc_finish().
- Here we can limit by dpif type.
Neither which is particularly pleasing. I gave #2 a try. see patch below. It
works for both check-kernel and check-system-userspace. It does not force
eth_type() for userspace.
What do you think?
Eric.
--->8---
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c index
1f4fe1dd6725..f3074c78c4b2 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -6129,7 +6129,10 @@ xlate_wc_init(struct xlate_ctx *ctx)
/* Some fields we consider to always be examined. */
WC_MASK_FIELD(ctx->wc, packet_type);
WC_MASK_FIELD(ctx->wc, in_port);
-if (is_ethernet(&ctx->xin->flow, NULL)) {
+if (is_ethernet(&ctx->xin->flow, NULL)
+|| (pt_ns(ctx->xin->flow.packet_type) == OFPHTN_ETHERTYPE
+&& !strcmp(dpif_normalize_type(dpif_type(ctx->xbridge->dpif)),
+ "system"))) {
WC_MASK_FIELD(ctx->wc, dl_type);
}
if (is_ip_any(&ctx->xin->flow)) {
@@ -6163,7 +6166,12 @@ xlate_wc_finish(struct xlate_ctx *ctx)
if (ctx->xin->upcall_flow->packet_type != htonl(PT_ETH)) {
ctx->wc->masks.dl_dst = eth_addr_zero;
ctx->wc->masks.dl_src = eth_addr_zero;
-ctx->wc->masks.dl_type = 0;
+/* Kernel uses ETHERTYPE to implicitly mean packet_type(1, x) */
+if (pt_ns(ctx->xin->upcall_flow->packet_type) != OFPHTN_ETHERTYPE
+|| strcmp(dpif_normalize_type(dpif_type(ctx->xbridge->dpif)),
+ "system")) {
+ctx->wc->masks.dl_type = 0;
+}
}
/* ICMPv4 and ICMPv6 have 8-bit "type" and "code" fields. struct flow
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline
I think it needs root privilege to run. -Original Message- From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Darrell Ball Sent: Friday, July 7, 2017 5:06 AM To: Eric Garver Cc: 'd...@openvswitch.org' ; simon.hor...@netronome.com; Jiri Benc Subject: Re: [ovs-dev] [PATCH v4 0/7] Packet type aware pipeline btw, I asked Andy to check on his Trusty system and he observes the same failure. On 7/6/17, 1:39 PM, "Darrell Ball" wrote: On 7/6/17, 1:22 PM, "Eric Garver" wrote: On Thu, Jul 06, 2017 at 03:59:51PM +, Darrell Ball wrote: > Patch 4 added unit tests > One test was added to system userspace. > I ran it many times and it has never passed. > Is something missing in the test or supporting code ? Works for me. Maybe there is a timing problem? Thanks There are races in the system tests, but those tests will pass on a second attempt. This is 100% failure. OVS: current master (fb16fec66498) Tip of master - same for me Kernel: 4.12.0-rc7+ I tried 2 kernels 4.2.0 and 3.19 – always fails in both. OS: RHEL 7.4-ish I really hope the distro is not relevant here If you have reason to think so, pls speak up > > ## -- ## > ## openvswitch 2.7.90 test suite. ## > ## -- ## > 94: ptap - triangle bridge setup with L2 and L3 GRE tunnels FAILED (system-userspace-packet-type-aware.at:344) > > ## - ## > ## Test results. ## > ## - ## > > ERROR: 1 test was run, > 1 failed unexpectedly. > ## --- ## > ## system-userspace-testsuite.log was created. ## > ## --- ## > > Please send `tests/system-userspace-testsuite.log' and all information you think might help: > >To: >Subject: [openvswitch 2.7.90] system-userspace-testsuite: 94 failed > > You may investigate any problem if you feel able to do so, in which > case the test suite provides a good starting point. Its output may > be found below `tests/system-userspace-testsuite.dir'. > > make: *** [check-system-userspace] Error 1 > make: Leaving directory `/home/dball/openvswitch/ovs/_gcc' > > > > > On 6/27/17, 2:29 PM, "ovs-dev-boun...@openvswitch.org on behalf of Ben Pfaff" wrote: > > On Fri, Jun 23, 2017 at 04:47:48PM +, Zoltán Balogh wrote: > > > > This series was started by Ben Pfaff, v3 can be found here: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778070_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=01fMZLg-sq_Rf_2X9TcxmtDN0Vx2hS2v4BABA77en0w&e= > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778071_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=5fpQZh33OQ_0AGjRuJNQqvS-1E6yhFoD5TxUoLayzwM&e= > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778076_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=rqnhEoIuJ9rECQaXZafZGrAW9us8y184GCexqK8VUxQ&e= > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778072_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=p5Fnh2SQ8fUrNF0V8ChNRQyQLmbjiuvKRd1UUwE93s8&e= > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778074_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=02CPoSKkiGGsFX4neL8TpGa75VUPaaeNYWz_2WbqBsQ&e= > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778073_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=eMl7m4NpJSD07nXTN_oOdQFvysmJnclSRw39GgGg9BQ&e= > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_778075_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6ND2me04&s=71zSrD_kcUjZwuKvjfeqam_rdCpeXuxtm4TW_SsZ_3w&e= > > > > Ben's series is based on this one: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_770490_&d=DwIFAw&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=YZOYZFR6QorkvkAZXXYPq7Z9SWuK0lZg9EH6N
Re: [ovs-dev] GTP support to OVS upstream
Joe, thank you for your clarification, it will significantly reduce ovs tunnel implementation dependency on Linux kernel if we just use udp tunnel in kernel, anyway userspace tunnel implementations are also some duplicates of kernel tunnel implementations less or more:-) I think it will simplify ovs tunnel implementation and maintenance if we use generic encap & decap framework to do tunnel encap & decap and move such processing into OpenFlow pipeline. -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Thursday, July 6, 2017 10:25 PM To: Yang, Yi Y Cc: Wieger IJntema ; d...@openvswitch.org Subject: Re: [ovs-dev] GTP support to OVS upstream On 5 July 2017 at 03:54, Yang, Yi Y wrote: > I remember OpenFlow 1.6 spec (not finalized) proposes to use OpenFlow actions > to do GTP-u encapsulation and decapsulation, current OvS tunnel > implementation can't support the third kind of use case (don't encap & decap, > just parse, match and forward), MEC (ETSI Molibe/Multi-access Edge Computing) > the third kind of use case. > > I'm wondering if it is feasible to implement a generic UDP tunnel in OvS, let > Openflow do encap /decap/parse&match, now ovs master has fully supported L3 > tunnel port and PTAP(Packet type aware pipeline), we have posted out generic > encap & decap actions implementation, once ovs officially merges them, ovs > can support generic encap & decap action, we can base on them to implement > GTP-u encap & decap, then it will be better if we can implement a generic UDP > tunnel, ovs can add UDP tunnel ports with different UDP port to handle > different tunnel protocol, I think this will be the best way to handle the > aforementioned three kinds of use cases. When it comes to the OVS userspace datapath, this seems like it maps pretty well to how things are already being done. When it comes to kernel APIs though there's a bunch of considerations around minimizing code duplication with the rest of the code, restricting scope/size creep of the module, and expectations of how long the API is supported. I think further discussion is necessary in that space to determine whether the OVS kernel module should really follow this model or not. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink attribute
I misunderstood Eric, he means we shouldn't have ETHERTYPE if packet_type is L3
type. I tried this one just now, it works.
diff --git a/lib/odp-util.c b/lib/odp-util.c
index 20373ec..2bf30bb 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -4883,7 +4883,9 @@ odp_flow_key_from_flow__(const struct odp_flow_key_parms
*parms,
goto unencap;
}
-nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, data->dl_type);
+if (flow->packet_type == htonl(PT_ETH)) {
+nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, data->dl_type);
+}
if (eth_type_vlan(flow->dl_type)) {
goto unencap;
-Original Message-
From: Zoltán Balogh [mailto:zoltan.bal...@ericsson.com]
Sent: Thursday, July 6, 2017 6:12 PM
To: Yang, Yi Y ; Eric Garver
Cc: 'd...@openvswitch.org' ; Jan Scheurich
Subject: RE: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink
attribute
Hello Yi,
I ran make check after applying your change and two tunnel tests did fail.
## -- ##
## openvswitch 2.7.90 test suite. ##
## -- ##
790: tunnel_push_pop_ipv6 - action FAILED
(tunnel-push-pop-ipv6.at:170)
787: tunnel_push_pop - actionFAILED
(tunnel-push-pop.at:221)
The error message from testsuite.log:
+2017-07-06T10:06:32.119Z|1|odp_util(revalidator37)|ERR|attribute
+eth has length 2 but should have length 12
Best regards,
Zoltan
> -Original Message-
> From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
> Sent: Thursday, July 06, 2017 11:10 AM
> To: Eric Garver ; Zoltán Balogh
>
> Cc: 'd...@openvswitch.org'
> Subject: RE: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type
> netlink attribute
>
> Eric, maybe the below patch can fix your issue, please give a try.
>
> diff --git a/lib/odp-util.c b/lib/odp-util.c index 20373ec..c5f714d
> 100644
> --- a/lib/odp-util.c
> +++ b/lib/odp-util.c
> @@ -4863,6 +4863,9 @@ odp_flow_key_from_flow__(const struct
> odp_flow_key_parms *parms,
> goto unencap;
> }
> }
> +} else {
> +if (export_mask) {
> +nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE,
> + OVS_BE16_MAX);
> }
>
> if (ntohs(flow->dl_type) < ETH_TYPE_MIN) {
>
> -Original Message-
> From: Eric Garver [mailto:e...@erig.me]
> Sent: Wednesday, July 5, 2017 11:14 PM
> To: Zoltán Balogh
> Cc: Yang, Yi Y ; 'd...@openvswitch.org'
>
> Subject: Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type
> netlink attribute
>
> Hi Zoltan,
>
> On Tue, Jul 04, 2017 at 09:23:17PM +, Zoltán Balogh wrote:
> > By introducing packet type-aware pipeline, match on ethertype was
> > removed when packet type is not Ethernet. As pointed out by Eric
> > Garver, this could have a side effect on the kernel datapath:
> > https://patchwork.ozlabs.org/patch/782991/
> >
> > This patch does approach the problem from a different perspective.
> > Instead of re-introducing the unconditional match on Ethernet type
> > in all megaflow entries, as suggested by Eric, mapping of
> > packet_type != PT_ETH to dl_type could be handled in the
> > put_exclude_packet_type() in dpif-netlink.c.
> >
> > Put_exclude_packet_type() filters the packet_type netlink 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
> > Reported-by: Eric Garver
> > ---
> > lib/dpif-netlink.c | 120
> > +++--
> > 1 file changed, 90 insertions(+), 30 deletions(-)
> >
> > diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c index
> > 562f613..cf4e98f 100644
> > --- a/lib/dpif-netlink.c
> > +++ b/lib/dpif-netlink.c
> > @@ -3433,34 +3433,101 @@ dpif_netlink_flow_from_ofpbuf(struct
> > dpif_netlink_flow *flow, }
> >
> >
> > +static bool
> > +put_exclude_packet_type(struct ofpbuf *buf, uint16_t type,
> > +const struct nlattr *data, uint16_t data_len,
> > +const struct nlattr *packet_type) {
> > +ovs_assert(NLA_ALIGN(packet_type->nla_len) == NL_A_U32_SIZE);
> > +size_t packet_type_len = NL_A_U32_SIZE;
> > +size_t first_chunk_size = (uint8_t *)packet_type - (uint8_t *)data;
> > +size_t second_chunk_size = data_len - first_chunk_size
> > + - packet_type_len;
> > +uint8_t
Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink attribute
Eric, maybe the below patch can fix your issue, please give a try.
diff --git a/lib/odp-util.c b/lib/odp-util.c
index 20373ec..c5f714d 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -4863,6 +4863,9 @@ odp_flow_key_from_flow__(const struct odp_flow_key_parms
*parms,
goto unencap;
}
}
+} else {
+if (export_mask) {
+nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, OVS_BE16_MAX);
}
if (ntohs(flow->dl_type) < ETH_TYPE_MIN) {
-Original Message-
From: Eric Garver [mailto:e...@erig.me]
Sent: Wednesday, July 5, 2017 11:14 PM
To: Zoltán Balogh
Cc: Yang, Yi Y ; 'd...@openvswitch.org'
Subject: Re: [ovs-dev] [PATCH v2] dpif-netlink: convert packet_type netlink
attribute
Hi Zoltan,
On Tue, Jul 04, 2017 at 09:23:17PM +, Zoltán Balogh wrote:
> By introducing packet type-aware pipeline, match on ethertype was
> removed when packet type is not Ethernet. As pointed out by Eric
> Garver, this could have a side effect on the kernel datapath:
> https://patchwork.ozlabs.org/patch/782991/
>
> This patch does approach the problem from a different perspective.
> Instead of re-introducing the unconditional match on Ethernet type in
> all megaflow entries, as suggested by Eric, mapping of packet_type !=
> PT_ETH to dl_type could be handled in the put_exclude_packet_type() in
> dpif-netlink.c.
>
> Put_exclude_packet_type() filters the packet_type netlink 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
> Reported-by: Eric Garver
> ---
> lib/dpif-netlink.c | 120
> +++--
> 1 file changed, 90 insertions(+), 30 deletions(-)
>
> diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c index
> 562f613..cf4e98f 100644
> --- a/lib/dpif-netlink.c
> +++ b/lib/dpif-netlink.c
> @@ -3433,34 +3433,101 @@ dpif_netlink_flow_from_ofpbuf(struct
> dpif_netlink_flow *flow, }
>
>
> +static bool
> +put_exclude_packet_type(struct ofpbuf *buf, uint16_t type,
> +const struct nlattr *data, uint16_t data_len,
> +const struct nlattr *packet_type) {
> +ovs_assert(NLA_ALIGN(packet_type->nla_len) == NL_A_U32_SIZE);
> +size_t packet_type_len = NL_A_U32_SIZE;
> +size_t first_chunk_size = (uint8_t *)packet_type - (uint8_t *)data;
> +size_t second_chunk_size = data_len - first_chunk_size
> + - packet_type_len;
> +uint8_t *first_attr = NULL;
> +struct nlattr *next_attr = nl_attr_next(packet_type);
> +
> +bool ethernet_present = nl_attr_find__(data, data_len,
> + OVS_KEY_ATTR_ETHERNET);
> +
> +first_attr = nl_msg_put_unspec_uninit(buf, type,
> + data_len - packet_type_len);
> +memcpy(first_attr, data, first_chunk_size);
> +memcpy(first_attr + first_chunk_size, next_attr,
> + second_chunk_size);
> +
> +return ethernet_present;
> +}
> +
> /*
> - * If PACKET_TYPE attribute is present in 'data', it filters
> PACKET_TYPE out,
> - * then puts 'data' to 'buf'.
> + * If PACKET_TYPE attribute is present in 'data', converts it to
> + ETHERNET and
> + * ETHERTYPE attributes, then puts 'data' to 'buf'.
> */
> static void
> -put_exclude_packet_type(struct ofpbuf *buf, uint16_t type,
> -const struct nlattr *data, uint16_t data_len)
> +put_convert_packet_type(struct ofpbuf *buf,
> +const struct dpif_netlink_flow *flow)
> {
> const struct nlattr *packet_type;
> +const struct nlattr *data = flow->key;
> +uint16_t data_len = flow->key_len;
> +const struct nlattr *mask_data = flow->mask;
> +uint16_t mask_len = flow->mask_len;
> +ovs_be32 value = htonl(PT_ETH);
> +bool ethernet_present = false;
> +
> +/* Verify KEY attributes. */
> +if (data_len) {
> +packet_type = nl_attr_find__(data, data_len,
> OVS_KEY_ATTR_PACKET_TYPE);
> +if (packet_type) {
> +/* Convert PACKET_TYPE Netlink attribute. */
> +value = nl_attr_get_be32(packet_type);
> +ethernet_present = put_exclude_packet_type(buf,
> OVS_FLOW_ATTR_KEY,
> + data, data_len,
> + packet_type);
> +/* Put OVS_KEY_ATTR_ETHERTYPE if needed.
Re: [ovs-dev] [PATCH] dpif-netilnk: convert packet_type netlink attribute
Hi, Zoltan
I checked odp_flow_key_from_flow__ in lib/odp-util.c, it has correctly handled
PACKET_TYPE and ETHERNET, ETHERTYPE has had correct value no matter packet_type
is PT_ETH or other L3 types, so I think the original put_exclude_packet_type
has done the right thing, the only one thing to be filtered is PACKET_TYPE. I
verified net-next and ovs compat mode with NSH patches, both of them can work
with the original put_exclude_packet_type.
The only issue as Eric mentioned is we should change odp_flow_key_from_flow__
to put mask for ETHERTYPE if packet_type is L3 type. But I didn't see
"match_validate complain" in my test.
nl_msg_put_be32(buf, OVS_KEY_ATTR_PACKET_TYPE, data->packet_type);
if (OVS_UNLIKELY(parms->probe)) {
max_vlans = FLOW_MAX_VLAN_HEADERS;
} else {
max_vlans = MIN(parms->support.max_vlan_headers, flow_vlan_limit);
}
/* Conditionally add L2 attributes for Ethernet packets */
if (flow->packet_type == htonl(PT_ETH)) {
eth_key = nl_msg_put_unspec_uninit(buf, OVS_KEY_ATTR_ETHERNET,
sizeof *eth_key);
get_ethernet_key(data, eth_key);
for (int encaps = 0; encaps < max_vlans; encaps++) {
ovs_be16 tpid = flow->vlans[encaps].tpid;
if (flow->vlans[encaps].tci == htons(0)) {
if (eth_type_vlan(flow->dl_type)) {
/* If VLAN was truncated the tpid is in dl_type */
tpid = flow->dl_type;
} else {
break;
}
}
if (export_mask) {
nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, OVS_BE16_MAX);
} else {
nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, tpid);
}
nl_msg_put_be16(buf, OVS_KEY_ATTR_VLAN, data->vlans[encaps].tci);
encap[encaps] = nl_msg_start_nested(buf, OVS_KEY_ATTR_ENCAP);
if (flow->vlans[encaps].tci == htons(0)) {
goto unencap;
}
}
}
if (ntohs(flow->dl_type) < ETH_TYPE_MIN) {
/* For backwards compatibility with kernels that don't support
* wildcarding, the following convention is used to encode the
* OVS_KEY_ATTR_ETHERTYPE for key and mask:
*
* key maskmatches
* ---
* >0x5ff 0x Specified Ethernet II Ethertype.
* >0x5ff 0 Any Ethernet II or non-Ethernet II frame.
* 0x Any non-Ethernet II frame (except valid
*802.3 SNAP packet with valid eth_type).
*/
if (export_mask) {
nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, OVS_BE16_MAX);
}
goto unencap;
}
nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE, data->dl_type);
-Original Message-
From: Zoltán Balogh [mailto:zoltan.bal...@ericsson.com]
Sent: Wednesday, July 5, 2017 5:25 AM
To: Yang, Yi Y ; Eric Garver
Cc: 'd...@openvswitch.org' ; Jan Scheurich
Subject: RE: [ovs-dev] [PATCH] dpif-netilnk: convert packet_type netlink
attribute
Hi Eric and Yi,
I tried to fix the issues. I posted v2 to the list. Could you have a look at it
and test it, please?
https://patchwork.ozlabs.org/patch/784317/
Best regards,
Zoltan
> -Original Message-
> From: Yang, Yi Y [mailto:yi.y.y...@intel.com]
> Sent: Tuesday, July 04, 2017 2:10 AM
> To: Eric Garver ; Zoltán Balogh
>
> Cc: 'd...@openvswitch.org'
> Subject: RE: [ovs-dev] [PATCH] dpif-netilnk: convert packet_type
> netlink attribute
>
> Zoltan, I tested this patch for net-next, it will result in failure by
> ovs_assert, in addition, we need to handle OVS_FLOW_ATTR_MASK and
> OVS_FLOW_ATTR_KEY differently, to be important, we need to verify it in
> kernel mode. From my test and verification, this patch can't work, instead,
> it can work without this patch.
>
> -Original Message-
> From: ovs-dev-boun...@openvswitch.org
> [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Eric Garver
> Sent: Tuesday, July 4, 2017 2:52 AM
> To: Zoltán Balogh
> Cc: 'd...@openvswitch.org'
> Subject: Re: [ovs-dev] [PATCH] dpif-netilnk: convert packet_type
> netlink attribute
>
> On Mon, Jul 03, 2017 at 02:27:18PM +, Zoltán Balogh wrote:
> > By introducing packet type-aware pipeline, match on ethertype was
> > removed when packet type is not Ethernet. As pointed out by Eric
> > Garver, this could have a side effect on the kernel datapath:
> > https://patchwork.ozlabs.org/patch/782991/
> >
> > This patch does approach the problem from a different perspective.
> > Instead of re-introducing the unconditional match on Ethernet type
> > in all megaflow ent
Re: [ovs-dev] GTP support to OVS upstream
You can register yourself in https://www.opennetworking.org/ then you can search any document. From: Wieger IJntema [mailto:wieger.ijntema@gmail.com] Sent: Wednesday, July 5, 2017 10:41 PM To: Yang, Yi Y ; d...@openvswitch.org Subject: Re: [ovs-dev] GTP support to OVS upstream Dear Yi, I'm not fully updated on the current OpenFlow 1.6 specification. I have now created a workaround with two bridge interfaces on one machine to forward normal traffic and only inspect GTP traffic. But indeed this requires full decapsulation of the packet before we have any knowledge of the packet inside. (IP and tun_id) I have to look deeper in the GTP code to be sure if we should proceed the way you describe. But i have looked in the PTAP and the generic encap & decap solutions described here: https://www.mail-archive.com/dev@openvswitch.org/msg71808.html and i think that is a solid basis to continue on. i'm new to the Openvswitch development is there a way i can view: EXT-382 Generic tunnel Encap and Decap issue? regards, Wieger IJntema On Wed, Jul 5, 2017 at 12:54 PM, Yang, Yi Y mailto:yi.y.y...@intel.com>> wrote: I remember OpenFlow 1.6 spec (not finalized) proposes to use OpenFlow actions to do GTP-u encapsulation and decapsulation, current OvS tunnel implementation can't support the third kind of use case (don't encap & decap, just parse, match and forward), MEC (ETSI Molibe/Multi-access Edge Computing) the third kind of use case. I'm wondering if it is feasible to implement a generic UDP tunnel in OvS, let Openflow do encap /decap/parse&match, now ovs master has fully supported L3 tunnel port and PTAP(Packet type aware pipeline), we have posted out generic encap & decap actions implementation, once ovs officially merges them, ovs can support generic encap & decap action, we can base on them to implement GTP-u encap & decap, then it will be better if we can implement a generic UDP tunnel, ovs can add UDP tunnel ports with different UDP port to handle different tunnel protocol, I think this will be the best way to handle the aforementioned three kinds of use cases. -Original Message- From: ovs-dev-boun...@openvswitch.org<mailto:ovs-dev-boun...@openvswitch.org> [mailto:ovs-dev-boun...@openvswitch.org<mailto:ovs-dev-boun...@openvswitch.org>] On Behalf Of Wieger IJntema Sent: Wednesday, July 5, 2017 5:37 PM To: d...@openvswitch.org<mailto:d...@openvswitch.org> Subject: [ovs-dev] GTP support to OVS upstream Dear Developers, I would like to start a discussion to actually get native GTP tunneling support in Openvswitch keeping it still compatible with the current OpenFlow standard. https://en.wikipedia.org/wiki/GPRS_Tunnelling_Protocol I the past there has been a patch for OVS to actually have GTP support. https://www.mail-archive.com/dev@openvswitch.org/msg56446.html, Feb 2016?, Niti Rohilla, OVS 2.5.0 Main concern was that there was no Linux upstream GTP support. This work is updated to work with version OVS 2.6.1 https://github.com/ashishkurian/ovs, Dec 2016, Ashish Kurian, OVS 2.6.1 I have tested it extensively if all nodes use the samen OVS version with GTP support it works good! It is just working like Lisp or GRE tunneling and you can set the key with the set "tunnel_id" command from openflow. I have used RYU as a controller to control multiple OVS switches with GTP tunneling. In mobile networks research there is a lot interest to get GTP support in OVS. Especially in development towards 5G mobile network, where Openflow is considered a protocol to be used there as switch-controller protocol. I'm currently testing this in "pre 5G" Core solution where GTP encapsulation is done by OVS. >From OSMOCOM.org there is now an GTP-U (GTP userplane) Linux upstream >implementation and it think we can use it together with the Openvswitch GTP >patch to get native GTP-U support in OVS. https://osmocom.org/projects/linux-kernel-gtp-u/wiki, Since linux kernel v4.7.0 https://www.kernel.org/doc/Documentation/networking/gtp.txt http://elixir.free-electrons.com/linux/v4.8.9/source/drivers/net/gtp.c I would like to start working on this, if you guys have suggestions or reservations please let me know. Regards, Wieger IJntema TNO ___ dev mailing list d...@openvswitch.org<mailto:d...@openvswitch.org> https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] GTP support to OVS upstream
I remember OpenFlow 1.6 spec (not finalized) proposes to use OpenFlow actions to do GTP-u encapsulation and decapsulation, current OvS tunnel implementation can't support the third kind of use case (don't encap & decap, just parse, match and forward), MEC (ETSI Molibe/Multi-access Edge Computing) the third kind of use case. I'm wondering if it is feasible to implement a generic UDP tunnel in OvS, let Openflow do encap /decap/parse&match, now ovs master has fully supported L3 tunnel port and PTAP(Packet type aware pipeline), we have posted out generic encap & decap actions implementation, once ovs officially merges them, ovs can support generic encap & decap action, we can base on them to implement GTP-u encap & decap, then it will be better if we can implement a generic UDP tunnel, ovs can add UDP tunnel ports with different UDP port to handle different tunnel protocol, I think this will be the best way to handle the aforementioned three kinds of use cases. -Original Message- From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Wieger IJntema Sent: Wednesday, July 5, 2017 5:37 PM To: d...@openvswitch.org Subject: [ovs-dev] GTP support to OVS upstream Dear Developers, I would like to start a discussion to actually get native GTP tunneling support in Openvswitch keeping it still compatible with the current OpenFlow standard. https://en.wikipedia.org/wiki/GPRS_Tunnelling_Protocol I the past there has been a patch for OVS to actually have GTP support. https://www.mail-archive.com/dev@openvswitch.org/msg56446.html, Feb 2016?, Niti Rohilla, OVS 2.5.0 Main concern was that there was no Linux upstream GTP support. This work is updated to work with version OVS 2.6.1 https://github.com/ashishkurian/ovs, Dec 2016, Ashish Kurian, OVS 2.6.1 I have tested it extensively if all nodes use the samen OVS version with GTP support it works good! It is just working like Lisp or GRE tunneling and you can set the key with the set "tunnel_id" command from openflow. I have used RYU as a controller to control multiple OVS switches with GTP tunneling. In mobile networks research there is a lot interest to get GTP support in OVS. Especially in development towards 5G mobile network, where Openflow is considered a protocol to be used there as switch-controller protocol. I'm currently testing this in "pre 5G" Core solution where GTP encapsulation is done by OVS. >From OSMOCOM.org there is now an GTP-U (GTP userplane) Linux upstream >implementation and it think we can use it together with the Openvswitch GTP >patch to get native GTP-U support in OVS. https://osmocom.org/projects/linux-kernel-gtp-u/wiki, Since linux kernel v4.7.0 https://www.kernel.org/doc/Documentation/networking/gtp.txt http://elixir.free-electrons.com/linux/v4.8.9/source/drivers/net/gtp.c I would like to start working on this, if you guys have suggestions or reservations please let me know. Regards, Wieger IJntema TNO ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] dpif-netilnk: convert packet_type netlink attribute
Zoltan, I tested this patch for net-next, it will result in failure by
ovs_assert, in addition, we need to handle OVS_FLOW_ATTR_MASK and
OVS_FLOW_ATTR_KEY differently, to be important, we need to verify it in kernel
mode. From my test and verification, this patch can't work, instead, it can
work without this patch.
-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org]
On Behalf Of Eric Garver
Sent: Tuesday, July 4, 2017 2:52 AM
To: Zoltán Balogh
Cc: 'd...@openvswitch.org'
Subject: Re: [ovs-dev] [PATCH] dpif-netilnk: convert packet_type netlink
attribute
On Mon, Jul 03, 2017 at 02:27:18PM +, Zoltán Balogh wrote:
> By introducing packet type-aware pipeline, match on ethertype was
> removed when packet type is not Ethernet. As pointed out by Eric
> Garver, this could have a side effect on the kernel datapath:
> https://patchwork.ozlabs.org/patch/782991/
>
> This patch does approach the problem from a different perspective.
> Instead of re-introducing the unconditional match on Ethernet type in
> all megaflow entries, as suggested by Eric, mapping of packet_type !=
> PT_ETH to dl_type could be handled in the put_exclude_packet_type() in
> dpif-netlink.c.
>
> Put_exclude_packet_type() filters the packet_type netlink 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
> Reported-by: Eric Garver
> ---
> lib/dpif-netlink.c | 34 --
> 1 file changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c index
> 562f6134c..d8051a09e 100644
> --- a/lib/dpif-netlink.c
> +++ b/lib/dpif-netlink.c
> @@ -3434,11 +3434,11 @@ dpif_netlink_flow_from_ofpbuf(struct
> dpif_netlink_flow *flow,
>
>
> /*
> - * If PACKET_TYPE attribute is present in 'data', it filters
> PACKET_TYPE out,
> - * then puts 'data' to 'buf'.
> + * If PACKET_TYPE attribute is present in 'data', converts it to
> + ETHERNET and
> + * ETHERTYPE attributes, then puts 'data' to 'buf'.
> */
> static void
> -put_exclude_packet_type(struct ofpbuf *buf, uint16_t type,
> +put_convert_packet_type(struct ofpbuf *buf, uint16_t type,
> const struct nlattr *data, uint16_t data_len)
> {
> const struct nlattr *packet_type; @@ -3446,8 +3446,9 @@
> put_exclude_packet_type(struct ofpbuf *buf, uint16_t type,
> packet_type = nl_attr_find__(data, data_len,
> OVS_KEY_ATTR_PACKET_TYPE);
>
> if (packet_type) {
> -/* exclude PACKET_TYPE Netlink attribute. */
> +/* Convert PACKET_TYPE Netlink attribute. */
> ovs_assert(NLA_ALIGN(packet_type->nla_len) == NL_A_U32_SIZE);
> +ovs_be32 value = nl_attr_get_be32(packet_type);
> size_t packet_type_len = NL_A_U32_SIZE;
> size_t first_chunk_size = (uint8_t *)packet_type - (uint8_t *)data;
> size_t second_chunk_size = data_len - first_chunk_size @@
> -3455,10 +3456,31 @@ put_exclude_packet_type(struct ofpbuf *buf, uint16_t
> type,
> uint8_t *first_attr = NULL;
> struct nlattr *next_attr = nl_attr_next(packet_type);
>
> +bool ethernet_present = nl_attr_find__(data, data_len,
> +
> + OVS_KEY_ATTR_ETHERNET);
> +
> first_attr = nl_msg_put_unspec_uninit(buf, type,
>data_len - packet_type_len);
> memcpy(first_attr, data, first_chunk_size);
> memcpy(first_attr + first_chunk_size, next_attr,
> second_chunk_size);
> +
> +/* Put OVS_KEY_ATTR_ETHERTYPE if needed. */
> +if (ntohl(value) == PT_ETH) {
I don't think this works for the mask case. I think value will be OVS_BE32_MAX.
> +ovs_assert(ethernet_present);
> +} else {
> +const struct nlattr *eth_type;
> +ovs_be16 ns_type = pt_ns_type_be(value);
> +
> +ovs_assert(ethernet_present == false);
> +
> +eth_type = nl_attr_find__(data, data_len,
> OVS_KEY_ATTR_ETHERTYPE);
> +if (eth_type) {
> +ovs_assert(nl_attr_get_be16(eth_type) == ns_type);
> +} else {
> +nl_msg_put_be16(buf, OVS_KEY_ATTR_ETHERTYPE,
> + ns_type);
This will have to put OVS_BE16_MAX for mask case.
> +}
> +}
> +
> } else {
> nl_msg_put_unspec(buf, type, data, data_len);
> }
> @@ -3489,11 +3511,11 @@ dpif_netlink_flow_to_ofpbuf(const struct
> dpif_netlink_flow *flow,
> }
> if (!flow->ufid_terse || !flow->ufid_present) {
> if (flow->key_len) {
> -put_exclude_packet_type(buf, OVS_FLOW_ATTR_KEY, flow->key,
> +put_convert_packet_type(buf, OVS_FLOW_ATTR_KEY,
> + flow->key,
>
Re: [ovs-dev] [PATCH v2 00/12] Packet type aware pipeline
Hi, guys
I'm working on NSH patches for kernel path, I think we can change it with new
NSH kernel patches together. You ovs guys have confirmed several times
userspace part can be merged before kernel part isn't there. So I propose we
review and merge userspace part first, kernel part will be posted in next
series, does it make sense?
-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org]
On Behalf Of Zoltán Balogh
Sent: Monday, June 19, 2017 6:27 PM
To: Ben Pfaff ; d...@openvswitch.org
Subject: 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 plan here?
Hi Ben,
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"
packet type is encoded in the OVS_KEY_ATTR_ETHERTYPE netlink attribute."
The plan was to do a conversion between OVS_KEY_ATTR_PACKET_TYPE and the pair
of OVS_KEY_ATTR_ETHERNET + OVS_KEY_ATTR_ETHERTYPE attributes before/after
transmission over netlink. Currently the PACKET_TYPE attribute is filtered out
in the put_exclude_packet_type() function in lib/dpif-netlink.c.
put_exclude_packet_type(struct ofpbuf *buf, uint16_t type,
const struct nlattr *data, uint16_t data_len) {
const struct nlattr *packet_type;
packet_type = nl_attr_find__(data, data_len, OVS_KEY_ATTR_PACKET_TYPE);
if (packet_type) {
/* exclude PACKET_TYPE Netlink attribute. */
ovs_assert(NLA_ALIGN(packet_type->nla_len) == NL_A_U32_SIZE);
size_t packet_type_len = NL_A_U32_SIZE;
size_t first_chunk_size = (uint8_t *)packet_type - (uint8_t *)data;
size_t second_chunk_size = data_len - first_chunk_size
- packet_type_len;
uint8_t *first_attr = NULL;
struct nlattr *next_attr = nl_attr_next(packet_type);
first_attr = nl_msg_put_unspec_uninit(buf, type,
data_len - packet_type_len);
memcpy(first_attr, data, first_chunk_size);
memcpy(first_attr + first_chunk_size, next_attr, second_chunk_size);
} else {
nl_msg_put_unspec(buf, type, data, data_len);
}
}
This could be modified to do more verification and put OVS_KEY_ATTR_ETHERTYPE
if needed:
---
diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c index 562f6134c..bdcc76c7b
100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -3434,11 +3434,11 @@ dpif_netlink_flow_from_ofpbuf(struct dpif_netlink_flow
*flow,
/*
- * If PACKET_TYPE attribute is present in 'data', it filters PACKET_TYPE out,
- * then puts 'data' to 'buf'.
+ * If PACKET_TYPE attribute is present in 'data', converts it to
+ ETHERNET and
+ * ETHERTYPE attributes, then puts 'data' to 'buf'.
*/
static void
-put_exclude_packet_type(struct ofpbuf *buf, uint16_t type,
+put_convert_packet_type(struct ofpbuf *buf, uint16_t type,
const struct nlattr *data, uint16_t data_len) {
const struct nlattr *packet_type;
@@ -3446,8 +3446,9 @@ put_exclude_packet_type(struct ofpbuf *buf, uint16_t type,
packet_type = nl_attr_find__(data, data_len, OVS_KEY_ATTR_PACKET_TYPE);
if (packet_type) {
-/* exclude PACKET_TYPE Netlink attribute. */
+/* convert PACKET_TYPE Netlink attribute. */
ovs_assert(NLA_ALIGN(packet_type->nla_len) == NL_A_U32_SIZE);
+ovs_be32 value = nl_attr_get_be32(packet_type);
size_t packet_type_len = NL_A_U32_SIZE;
size_t first_chunk_size = (uint8_t *)packet_type - (uint8_t *)data;
size_t second_chunk_size = data_len - first_chunk_size @@ -3455,10
+3456,31 @@ put_exclude_packet_type(struct ofpbuf *buf, uint16_t type,
uint8_t *first_attr = NULL;
struct nlattr *next_attr = nl_attr_next(packet_type);
+bool ethernet_present = nl_attr_find__(data, data_len,
+ OVS_KEY_ATTR_ETHERNET);
+
first_attr = nl_msg_put_unspec_uninit(buf, type,
data_len - packet_type_len);
memcpy(first_attr, data, first_chunk_size);
memcpy(first_attr + first_chunk_size, next_attr, second_chunk_size);
+
+/* Put OVS_KEY_ATTR_ETHERTYPE if needed. */
+if (ntohl(value) == PT_ETH) {
+ovs_assert(ethernet_present);
+} else {
+const struct nlattr *eth_type;
+ovs_be16 ns_type = pt_ns_type_be(value);
+
+ovs_assert(ethernet_present == false);
+
+
Re: [ovs-dev] [PATCH v1 0/5] NSH userspace support
Yes, Zoltan and I are working on this, please stay tuned, Jan should talk this in the coming sync meeting with you guys. -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Wednesday, June 7, 2017 2:13 AM To: Yang, Yi Y Cc: d...@openvswitch.org Subject: Re: [ovs-dev] [PATCH v1 0/5] NSH userspace support On Thu, Apr 20, 2017 at 10:42:06AM +0800, Yi Yang wrote: > This patchset adds NSH userspace support, it just covers parse, match > and set_field NSH fields, actions encap_nsh and decap_nsh will be > included in the following patchset. > > This patchset is based on top of Zoltan's Now that the base patches have been committed, would you mind rebasing and reposting? Thanks, Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC PATCH 0/2] Generic encap/decap actions implementation
Ben, we'll send out new patch series based on the recently merged patches and new PTAP series, sending this in the very early phase was just to get some general comments about implementation, Jan has reviewed them and changed many things per his full ovs experience, so next post will have high quality. -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Wednesday, June 7, 2017 2:17 AM To: Yang, Yi Y Cc: d...@openvswitch.org Subject: Re: [ovs-dev] [RFC PATCH 0/2] Generic encap/decap actions implementation On Thu, Apr 20, 2017 at 11:26:39AM +0800, Yi Yang wrote: > This patchset implements "Generic encap/decap actions" (EXT-382), it > is based on top of the below patchsets: > > [PATCH v1 0/5] NSH userspace support > https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/331158.html > > [PATCH 0/10] userspace: Packet type-aware pipeline > https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/331023.html > > [PATCH v3 0/8] userspace: Support for L3 tunnelin > https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330488.html Hi, thanks for posting this. It's difficult to deal with multiple dependent patch series. In practice, I don't usually even read patch series that depend on others, because it means that there are multiple steps to get to them. To get a better chance for review, I suggest putting all of the patches together into a single series. In case it is part of your concern, it's no problem to have RFC or experimental patches at the end of a series that is otherwise ready for review. Thanks, Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v6 5/5] userspace: add vxlan gpe support to vport
Zoltan has done that way. -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Friday, May 26, 2017 5:00 AM To: Jan Scheurich Cc: Yang, Yi Y ; Zoltán Balogh ; 'd...@openvswitch.org' Subject: Re: [ovs-dev] [PATCH v6 5/5] userspace: add vxlan gpe support to vport On Mon, May 22, 2017 at 03:10:56PM +, Jan Scheurich wrote: > I had a similar comment to avoid bit-fields in the nsh_hdr struct in the NSH > patch series. > @Yi: Have a look at the restructured nsh.h in my new branch. > > I suggest you just add any required vxlan-gpe specific items to the VXLAN > section in lib/packets.h rather than creating a new header file for vxlan-gpe. Yes, that is my preference too. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v6 5/5] userspace: add vxlan gpe support to vport
Ben, vxlangpe.h is from Linux kernel header file, so style is Linux but not
ovs, keeping these intact is to make sure there are same pieces in both
userspace and kernel, so code is also almost same. We'll change it to ovs style
per your comments. Zoltan, please let me know if you need any help from me.
-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org]
On Behalf Of Ben Pfaff
Sent: Friday, May 19, 2017 12:54 PM
To: Zoltán Balogh
Cc: 'd...@openvswitch.org'
Subject: Re: [ovs-dev] [PATCH v6 5/5] userspace: add vxlan gpe support to vport
On Fri, May 12, 2017 at 11:07:46AM +, Zoltán Balogh wrote:
> 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. Furthermore it introduces a new
> protocol header file vxlangpe.h in which the vxlan gpe protocoll is
> described. In the vxlan specific methods the different packet are introduced
> and handled.
>
> Added VXLAN GPE tunnel push test.
>
> Signed-off-by: Yi Yang
> Signed-off-by: Georg Schmuecking
checkpatch says:
ERROR: Inappropriate bracing around statement
#138 FILE: lib/netdev-native-tnl.c:519:
if (gpe->oam_flag)
WARNING: Line has non-spaces leading whitespace
#153 FILE: lib/netdev-native-tnl.c:534:
}
WARNING: Line length is >79-characters long
#188 FILE: lib/netdev-native-tnl.c:578:
put_16aligned_be32(&vxh->vx_vni,
htonl(ntohll(params->flow->tunnel.tun_id) << 8));
WARNING: Line length is >79-characters long
#206 FILE: lib/netdev-native-tnl.c:596:
put_16aligned_be32(&vxh->vx_vni,
htonl(ntohll(params->flow->tunnel.tun_id) << 8));
In netdev_vxlan_pop_header(), I don't see anything that verifies that the
packet is long enough when GPE is present.
The formatting of the switch statements look different from the usual OVS
style, which is like this:
switch (gpe->next_protocol) {
case VXLAN_GPE_NP_IPV4:
next_pt = PT_IPV4;
break;
case VXLAN_GPE_NP_IPV6:
next_pt = PT_IPV6;
break;
case VXLAN_GPE_NP_ETHERNET:
next_pt = PT_ETH;
break;
default:
goto err;
}
I suspect that struct vxlanhdr_gpe should use ovs_16aligned_be32 for the vx_vni
member.
I doubt that these #defines are a good idea, in vxlangpe.h:
#define u8 uint8_t
#define u32 uint8_t
#define __be32 ovs_be32
struct vxlanhdr in lib/packets.h is pretty different in philosophy from struct
vxlanhdr_gpe in vxlangpe.h. I'd suggest making the new structure more like the
existing one; OVS doesn't really use bit-fields much and in my experience they
do not make code much easier to deal with.
The new struct vxlan_metadata doesn't seem to be used anywhere and I wonder
whether it should be included.
Thanks,
Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 2/7] userspace: Support for push_eth and pop_eth actions
Zoltan, original l3 userspace patch set gets ether_type from packet->md.
eh->eth_type = packet->md.packet_ethertype;
I think we should keep struct ovs_action_push_eth consistent in both kernel and
userspace, we can use the way in original l3 userspace patch set to get
ether_type.
-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org]
On Behalf Of Zoltán Balogh
Sent: Thursday, May 4, 2017 6:02 PM
To: Ben Pfaff ; Jiri Benc (jb...@redhat.com)
Cc: 'd...@openvswitch.org'
Subject: Re: [ovs-dev] [PATCH v4 2/7] userspace: Support for push_eth and
pop_eth actions
> On Tue, Apr 25, 2017 at 04:30:23PM +, Zoltán Balogh wrote:
> > From: Jan Scheurich
> >
> > Add support for actions push_eth and pop_eth to the netdev datapath
> > and the supporting libraries. This patch relies on the support for
> > these actions in the kernel datapath to be present.
>
> Hi, can you help me to understand this part here? I believe that this
> will lead to userspace sending a OVS_ACTION_ATTR_PUSH_ETH action
> argument to the kernel that is different from what the kernel actually
> wants. What's the idea, and how is that problem avoided?
>
> struct ovs_action_push_eth {
> struct ovs_key_ethernet addresses;
> #ifndef __KERNEL__
> __be16 eth_type;
> #endif
> };
>
> Thanks,
>
> Ben.
Hi,
I'm afraid the kernel would not accept that OVS_ACTION_ATTR_PUSH_ETH action in
this case.
Jiri, could you confirm, please?
We could remove the eth_type from struct ovs_action_push_eth, then put an
additional "set action" after putting "push_eth" in the
odp_put_push_eth_action() function in order to set the ethertype of the packet.
void
odp_put_push_eth_action(struct ofpbuf *odp_actions,
const struct eth_addr *eth_src,
const struct eth_addr *eth_dst,
const ovs_be16 eth_type) {
struct ovs_action_push_eth eth;
memset(ð, 0, sizeof eth);
if (eth_src) {
eth.addresses.eth_src = *eth_src;
}
if (eth_dst) {
eth.addresses.eth_dst = *eth_dst;
}
nl_msg_put_unspec(odp_actions, OVS_ACTION_ATTR_PUSH_ETH,
ð, sizeof eth);
commit_set_action(odp_actions, OVS_KEY_ATTR_ETHERTYPE, eth_type); }
That way we would split the push_eth action into a simpler push_eth and a
set_field. However this would lead to modify odp_execute_set_action()as well,
since changing of ethertype with set_field is not allowed:
static void
odp_execute_set_action(struct dp_packet *packet, const struct nlattr *a) {
enum ovs_key_attr type = nl_attr_type(a);
const struct ovs_key_ipv4 *ipv4_key;
const struct ovs_key_ipv6 *ipv6_key;
struct pkt_metadata *md = &packet->md;
switch (type) {
...
case OVS_KEY_ATTR_ETHERTYPE:
case OVS_KEY_ATTR_IN_PORT:
case OVS_KEY_ATTR_VLAN:
case OVS_KEY_ATTR_TCP_FLAGS:
case OVS_KEY_ATTR_CT_STATE:
case OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV4:
case OVS_KEY_ATTR_CT_ORIG_TUPLE_IPV6:
case OVS_KEY_ATTR_CT_ZONE:
case OVS_KEY_ATTR_CT_MARK:
case OVS_KEY_ATTR_CT_LABELS:
case __OVS_KEY_ATTR_MAX:
default:
OVS_NOT_REACHED();
}
}
I guess something similar should be done at kernel side too, since the kernel
module would not accept set_field ethertype either.
Another option would be to convert OVS_ACTION_ATTR_PUSH_ETH action argument
between userspace and kernel.
Do you have any other proposal?
Btw, the original comment message of struct ovs_action_push_eth indicates
eth_type as a second member.
/*
* struct ovs_action_push_eth - %OVS_ACTION_ATTR_PUSH_ETH action argument.
* @addresses: Source and destination MAC addresses.
* @eth_type: Ethernet type
*/
struct ovs_action_push_eth {
struct ovs_key_ethernet addresses;
};
Best regards,
Zoltan
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS installation issue with NSH patch
Hi, Kiruthiga As I told you, please check your kernel version. https://github.com/yyang13/ovs_nsh_patches also included patches for ovs 2.6.1, if you have kernel version higher than v4.3, please use patches for 2.6.1. ovs 2.5 only can be built on kernel 3.10 to 4.3. -Original Message- From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Kiruthiga R Sent: Monday, April 24, 2017 11:50 AM To: Ben Pfaff Cc: ovs-dev@openvswitch.org Subject: Re: [ovs-dev] OVS installation issue with NSH patch Hi, Please find the attachment. Regards, Kiruthiga -Original Message- From: Ben Pfaff [mailto:b...@ovn.org] Sent: Friday, April 21, 2017 9:35 PM To: Kiruthiga R Cc: ovs-dev@openvswitch.org Subject: Re: [ovs-dev] OVS installation issue with NSH patch On Fri, Apr 21, 2017 at 05:40:57AM +, Kiruthiga R wrote: > Hi Team, > > I am trying to install OVS 2.5 with the NSH patch available in > https://github.com/yyang13/ovs_nsh_patches > I am facing error while doing "make". Attached the screenshot of error > message. I don't see any attachment. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] How do we set fields for selection_method=hash?
Thanks Simon, I know how I can use it correctly from tests/ofproto.at, but it requires OpenFlow 1.5. I tried a new field I added, it is ok. This is really a good feature:-) -Original Message- From: Simon Horman [mailto:simon.hor...@netronome.com] Sent: Monday, March 20, 2017 9:28 PM To: Yang, Yi Y Cc: ovs-dev@openvswitch.org Subject: Re: How do we set fields for selection_method=hash? On Tue, Mar 14, 2017 at 06:32:30AM +, Yang, Yi Y wrote: > Hi, Simon > > I notice you Netronome implemented selection_method support in ovs, > now I just want to use the specified match fields as hash input, I > checked ovs-ofctl man pages, for such use case, I must use > "selection_method=hash fields=...", I'm not sure how I set fields I > want, can you help give an example? We don't use IP 5 tuple for this, > because they are almost same for our use case, it will be great if we > can use a match field we can set as hash input. Thank you in advance. Hi, its a while since I have used the code in question but I believe you can use something like this: type=select,selection_method=hash,fields(eth_dst,ip_dst,tcp_dst) Where I believe fields can include any of the fields documented in ovs-fields(7). ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] How do we set fields for selection_method=hash?
Hi, Simon I notice you Netronome implemented selection_method support in ovs, now I just want to use the specified match fields as hash input, I checked ovs-ofctl man pages, for such use case, I must use "selection_method=hash fields=...", I'm not sure how I set fields I want, can you help give an example? We don't use IP 5 tuple for this, because they are almost same for our use case, it will be great if we can use a match field we can set as hash input. Thank you in advance. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Why "ovs-appctl dpif/dump-flows br-int" can't show match fields I add?
Joe, thank for your detailed explanation, now I know what I should do :-) -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Friday, March 10, 2017 1:19 AM To: Yang, Yi Y Cc: ovs-dev@openvswitch.org Subject: Re: [ovs-dev] Why "ovs-appctl dpif/dump-flows br-int" can't show match fields I add? On 9 March 2017 at 04:23, Yang, Yi Y wrote: > Hi, all > > I'm testing GTP-U header parsing by adding pure userspace support code, now I > can "ovs-ofctl -Oopenflow13 add-flows" and "ovs-ofctl -Oopenflow13 dump-flows" > > $ sudo ovs-ofctl -Oopenflow13 dump-flows br-int OFPST_FLOW reply > (OF1.3) (xid=0x2): > cookie=0x0, duration=2930.079s, table=0, n_packets=4, n_bytes=432, > udp,gtp_teid=1234 actions=drop cookie=0x0, duration=3028.156s, > table=0, n_packets=22, n_bytes=2376, priority=0 actions=NORMAL > > I can see some packets matched and dropped, but when I use "ovs-appctl > dpif/dump-flows br-int" to check this, I can't see key gtp_teid. > > $sudo ovs-appctl dpif/dump-flows br-int > recirc_id(0),in_port(2),eth_type(0x0800),ipv4(proto=17,frag=no), > packets:1, bytes:108, used:4.137s, actions:drop > > Anyboby knows how I add a new key/match field in order that "ovs-appctl > dpif/dump-flows" can show it correctly, I don't think I need to add netlink > key for this because this is pure userspace code, I don't use kernel > datapath. It'll be great if you can point out an existing match field example > which is just for pure userspace. Hi, ovs-appctl dpctl/dump-flows calls into the common library function dpctl_dump_flows(), which uses the dpif_flow_dump_next() API to fetch flows. These flows are dumped from the datapath in netlink format, no matter which datapath you use. Even if you are purely trying out a userspace implementation for now, then you'll still need to extend the datapath/linux/compat/include/linux/openvswitch.h header with the KEY_ATTR for your GTP field and handle all of the netlink marshalling to be able to dump the flows from the datapath layer via this mechanism. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Why "ovs-appctl dpif/dump-flows br-int" can't show match fields I add?
Hi, all I'm testing GTP-U header parsing by adding pure userspace support code, now I can "ovs-ofctl -Oopenflow13 add-flows" and "ovs-ofctl -Oopenflow13 dump-flows" $ sudo ovs-ofctl -Oopenflow13 dump-flows br-int OFPST_FLOW reply (OF1.3) (xid=0x2): cookie=0x0, duration=2930.079s, table=0, n_packets=4, n_bytes=432, udp,gtp_teid=1234 actions=drop cookie=0x0, duration=3028.156s, table=0, n_packets=22, n_bytes=2376, priority=0 actions=NORMAL I can see some packets matched and dropped, but when I use "ovs-appctl dpif/dump-flows br-int" to check this, I can't see key gtp_teid. $sudo ovs-appctl dpif/dump-flows br-int recirc_id(0),in_port(2),eth_type(0x0800),ipv4(proto=17,frag=no), packets:1, bytes:108, used:4.137s, actions:drop Anyboby knows how I add a new key/match field in order that "ovs-appctl dpif/dump-flows" can show it correctly, I don't think I need to add netlink key for this because this is pure userspace code, I don't use kernel datapath. It'll be great if you can point out an existing match field example which is just for pure userspace. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
Joe, I checked this tree https://github.com/joestringer/openvswitch/commits/dev/backport_review_v0.6 , it included all the 802.1ad patches and Jiri's l3 kernel data path patches, so I think this is the first step we should take, once they are officially merged, Jan and I will rework userspace l3 patches and vxlangpe patches and resubmit them based on your tree. -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Thursday, March 2, 2017 11:43 AM To: Yang, Yi Y Cc: ovs dev ; Jarno Rajahalme Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs On 6 February 2017 at 05:04, Yi Yang wrote: > This patch set just ports Jiri Benc's L3 8 support patches for layer 3 > encapsulated packets from net-next to current ovs, it also includes Jiri > Benc's 3 userspace patches, Jarno Rajahalme and Pravin Shelar's vlan fix > patches for L3 patchset as well as my 3 patches which enabled vxlangpe in > compat mode and dpdk netdev in both L2 and L3(layer3=true) mode. > > This patchset has been verified on Ubuntu 14.04 x86_64 with Linux kernel > 3.13.0-24-generic and 4.9.7, it also passed "make check" > and "sudo make check-kmod RECHECK=yes" in Fedora 23 with kernel > 4.2.3-300.fc23.x86_64 > > This patch set is based on > https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html > ([PATCH v2 0/4] Backport 802.1ad patches), please merge this one after > merging [PATCH v2 0/4] Backport 802.1ad patches. > > Yi Yang (16): > datapath: use hard_header_len instead of hardcoded ETH_HLEN > datapath: add mac_proto field to the flow key > datapath: pass mac_proto to ovs_vport_send > datapath: support MPLS push and pop for L3 packets > datapath: add processing of L3 packets > datapath: netlink: support L3 packets > datapath: add Ethernet push and pop actions > datapath: allow L3 netdev ports > userspace: add support for pop_eth and push_eth actions > userspace: add layer 3 flow and switching support > userspace: add non-tap (l3) support to GRE vports > datapath: Add a missing break statement > datapath: upcall: Fix vlan handling. > datapath: enable vxlangpe creation in compat mode > userspace: enable layer3 option for vxlan-gpe > userspace: add vxlan-gpe support for dpdk netdev Picking this thread back up, apologies for the delay.. Given that these backports + vlan + other series by Jarno may be interdependent on each other, I figured that I will assemble a single tree that brings them all together, run travis and local kmod testing on a variety of platforms, as well as per-commit compile checks with kernels 4.9 and 3.13. Here's the current tree I'm testing: https://github.com/joestringer/openvswitch/commits/dev/backport_review_v0.6 Travis looks good (build check against a range of kernels): https://travis-ci.org/joestringer/openvswitch/builds/206841787 My local system-kmod testing on a variety of platforms is coming out looking good so far. I dropped the userspace changes since they are decoupled and superseded. Where they were necessary to fix the build, I folded in the minimal changes necessary to fix the patch so that the tree successfully compiles on each individual commit. I'd appreciate if you could look over that tree once more, there's a couple of new patches that I backported but otherwise it's all series that have been out on the mailinglist over the past few weeks. I folded a few fixes together so that the tree should not break in between commits. I also updated the formatting of each commit message to unsure that, for example, attribution is retained from the original commits. Given they're building fine and testing looks good, I'd like to move towards pushing these patches, and then I can continue with the next series of backports review. New commits: https://github.com/joestringer/openvswitch/commit/8fa9841b9b06139f69f0138868ed9d6df730b748 https://github.com/joestringer/openvswitch/commit/c598981830e1274391fb80bae6ca9862e6c53fda Where I made changes to the posted patches, I updated the commit message to include [Committer notes]. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Can we use ovs to implement load balancer by openflow?
Han and Jarno, thank you all, I tried the below cmds, they can work. sudo ovs-ofctl -Oopenflow13 add-group br-sfc "group_id=100 type=select selection_method=dp_hash bucket=output:1 bucket=output:2" sudo ovs-ofctl -Oopenflow13 add-flow br-sfc "table=0,ip,nw_src=192.168.2.0/24,actions=group:100" -Original Message- From: Jarno Rajahalme [mailto:ja...@ovn.org] Sent: Wednesday, March 1, 2017 3:02 AM To: Han Zhou Cc: Yang, Yi Y ; ovs-dev@openvswitch.org Subject: Re: [ovs-dev] Can we use ovs to implement load balancer by openflow? > On Feb 27, 2017, at 10:42 PM, Han Zhou wrote: > > On Mon, Feb 27, 2017 at 7:42 PM, Yang, Yi Y wrote: >> >> Hi, all >> >> Can we use ovs to implement load balancer? Our target is to let ovs > distribute the traffic to different service VMs based on 5 tuple (src > ip, dst ip, src port, dst port, transport protocol). > > Yes. Try: man ovs-ofctl, look for keyword "group" for details. I would add that you’d want to use the “selection_method=dp_hash” option for the select group for performance reasons. Jarno ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Can we use ovs to implement load balancer by openflow?
Hi, all Can we use ovs to implement load balancer? Our target is to let ovs distribute the traffic to different service VMs based on 5 tuple (src ip, dst ip, src port, dst port, transport protocol). ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
Joe, got it, thanks a lot. -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Saturday, February 11, 2017 5:38 AM To: Yang, Yi Y Cc: Multanen, Eric W ; ovs dev ; Yi-Hung Wei Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs On 9 February 2017 at 17:45, Yang, Yi Y wrote: > Joe, thank you for explanation, let us push 802.1ad backport patches first, > Eric Garver has acked two of them, I'll rework another one patch he > commented. What Valentine mentioned has no business with 802.1 ad, it is what > we want to consider after Eric Garver's rtnetlink userspace patches are > merged, we have no way to use in-kernel data path to do it without rtnetlink > userspace patches. > > Can you point out which patches for 802.1ad are missing? I almost checked > all the 802.1 ad patches, ovs doesn't use most of them, most of them make > nonsense to ovs. Eric, please help point out if I missed something. I believe there's "net: mpls: Fixups for GSO" and one other more trivial one. I've been working with Yi-Hung to try to figure out those backports, so we should be able to proceed with those shortly, then I'll look at 802.1ad. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
Eric and Joe, thank you so much for your verification and fix, I'll resubmit a new version including this fix and missing part. -Original Message- From: Eric Garver [mailto:e...@erig.me] Sent: Saturday, February 11, 2017 9:22 PM To: Joe Stringer ; Yang, Yi Y Cc: ovs dev Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs On Fri, Feb 10, 2017 at 01:33:04PM -0800, Joe Stringer wrote: > On 10 February 2017 at 12:25, Eric Garver wrote: > > On Fri, Feb 10, 2017 at 11:24:58AM -0500, Eric Garver wrote: > >> On Tue, Feb 07, 2017 at 02:30:46PM -0800, Joe Stringer wrote: > >> > On 7 February 2017 at 09:44, Joe Stringer wrote: > >> > > On 6 February 2017 at 16:46, Yang, Yi Y wrote: > >> > >> Joe, I checked current ovs and net-next kernel, obviously some > >> > >> patches from net-next are selectively backported to ovs, but others > >> > >> are not, I'm not sure what the policy is for a new patch. It will be > >> > >> better that the person who did the patch backports it to ovs at the > >> > >> same time, but nobody did so. > >> > > > >> > > That's supposed to be the policy; However, depending on the > >> > > patch sometimes openvswitch isn't even the main target of the > >> > > change, so the contributor may not be aware they should do so. > >> > > There may be added difficulty if the previous contributor > >> > > didn't do their backport. I think that lately there hasn't been > >> > > particularly close co-ordination between the trees, but ideally > >> > > I think that as we approach an OVS release, we would try to sync them > >> > > up. > >> > > > >> > >> My 802.1ad backport has included all the things l3 patch set > >> > >> depends on, so I think you can give it a go :-) > >> > > > >> > > Kicking off a build on my local tester, I can at least report > >> > > back on that. I see you've tested on a few platforms as well, that's > >> > > great. > >> > > >> > Reporting back, I suspect that some of the older kernels don't > >> > treat the double-tagged vlans right with this series? > >> > > >> > I was using an Ubuntu trusty VM with kernel 3.13.0-92-generic > >> > plus this backport and it seems to be consistently failing this test: > >> > > >> > 4: datapath - ping between two ports on cvlan FAILED > >> > (system-traffic.at:88) > >> > > >> > The test output just shows that a ping tries about 10 times and > >> > fails all of the times. I didn't investigate further. > >> > >> Hi Joe, > >> > >> Thanks for testing those backports. > >> > >> I ran them on debian with 3.16 kernel. I see the same failures. > >> Interestingly, if when the test hangs (when waiting on the ping) I > >> ping in a different window namespace to namespace it will work as expected. > >> This ping should be equivalent to what the test is doing. I can't > >> explain this yet, but I'll keep investigating. > > > > I found the cause. The upcall re-inserts the VLAN back into the raw > > packet data, but the TPID is hard coded to 0x8100. > > This affects kernels for which HAVE_VLAN_INSERT_TAG_SET_PROTO is not > > set. > > > > The below patch allows the cvlan and 802.ad tests (not upstream yet) > > to pass on debian with 3.16 kernel. However, it may be better > > backport a modern version of vlan_insert_tag_set_proto(). > > Thanks for figuring this out. Will you or Yi submit this? I think it makes sense for it to be submitted with the 802.1ad series. Yi, Can you add the fix I suggest above to your 802.1ad series? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
Joe, thank you for explanation, let us push 802.1ad backport patches first, Eric Garver has acked two of them, I'll rework another one patch he commented. What Valentine mentioned has no business with 802.1 ad, it is what we want to consider after Eric Garver's rtnetlink userspace patches are merged, we have no way to use in-kernel data path to do it without rtnetlink userspace patches. Can you point out which patches for 802.1ad are missing? I almost checked all the 802.1 ad patches, ovs doesn't use most of them, most of them make nonsense to ovs. Eric, please help point out if I missed something. -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Friday, February 10, 2017 8:01 AM To: Yang, Yi Y Cc: ovs dev ; Yi-Hung Wei Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs On 8 February 2017 at 18:50, Yang, Yi Y wrote: > Then, are you merging > https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html or > do I need to do anything else for it? It looks like the backport breaks the existing kernel module tests on older kernels, without even using the new functionality. I've provided feedback on how you might further dig into that, and I don't believe I've seen confirmation that you observe the same thing, or any proposed solutions. I've mentioned previously a preference to see patches backported in the canonical order. I believe there's just a few patches missing from before 802.1ad, and discussions are ongoing to address those backports. I expect with time, those will be proposed and merged, and then we can look at 802.1ad. Finally, patches always need review before merging. Given that others in the community have previously looked into 802.1ad, I was looking to see that people with more detailed knowledge of these codepaths would take a first look. I see that Eric has now done so, and there is feedback to address. I also see that Valentine has provided some feedback. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
Ok, let me push 802.1 ad backport patches first. -Original Message- From: Jan Scheurich [mailto:jan.scheur...@web.de] Sent: Friday, February 10, 2017 7:04 AM To: Yang, Yi Y ; Jan Scheurich ; Joe Stringer ; Jiri Benc (jb...@redhat.com) ; Eric Garver ; 'ja...@ovn.org' Cc: d...@openvswitch.org Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs Hi Yi, I suggest we include (adapted versions of) your vxlan-gpe user space patches into the new L3 tunneling user-space series when we respin v2 with the review comments. Thus we get rid of one dependency. And you can focus on the datapath backports and NSH. Do you agree? @Jarno: It would be great if you could find the time to review the new series. Thanks, Jan On 2017-02-09 11:46, Yang, Yi Y wrote: > Jan, I'm ok, I will rebase those patches once ovs maintainers merge your > patches first. In my patches, I added vxlan-gpe user space support, that > needs those three user space patches, that is why I included those three user > space patches in my patch set. > > I don't know what order ovs maintainers will merge them in. I can only focus > on userspace support for vxlan-gpe if ovs maintainers really merge your > patches first. > > -Original Message- > From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] > Sent: Thursday, February 9, 2017 5:50 PM > To: Yang, Yi Y ; Joe Stringer ; Jiri > Benc (jb...@redhat.com) ; Eric Garver > Cc: d...@openvswitch.org; Jarno Rajahalme (ja...@ovn.org) > > Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset > to ovs > > Hi Yi, > > I very much doubt that it makes sense to first merge the obsolete user-space > patches and then override them with the target version. > > Jarno and Joe have in principle agreed to merge the new user-space patches > independently of the backport of the kernel datapath patches. So there is no > dependency in this direction. > > If it is not possible to merge the kernel datapath back-ports without test > cases, then I think the datapath merge should wait for the merge of the new > user-space patches and then add end-to-end test cases for the kernel datapath > as well. > > But perhaps such end-to-end tests are not strictly necessary. It appears to > me that Jiri's L3 tunneling datapath patches were merged into net-next > without such test cases (just based on code review). So why not in OVS tree? > > We can then add end-to-end kernel datapath tests when the Eric's outstanding > user-space patches for rtnetlink and compat tunnel configuration for L3 > tunnels are added. > > BR, Jan > > >> -Original Message- >> From: Yang, Yi Y [mailto:yi.y.y...@intel.com] >> Sent: Wednesday, 08 February, 2017 06:31 >> To: Jan Scheurich ; Joe Stringer >> ; Jiri Benc (jb...@redhat.com) ; Eric >> Garver >> Cc: d...@openvswitch.org >> Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset >> to ovs >> >> I'll check how we can rebase your changes against those three patches >> on top of my patches, our goals are same, that is to merge your >> changes and this patch set to ovs. I don't know what order Joe will merge >> them in. Obviously one patch set can't depend on another one which isn't >> nailed down to merge or not. >> >> Jan, let us have a sync by lync meeting. >> >> -Original Message- >> From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] >> Sent: Wednesday, February 8, 2017 7:19 AM >> To: Joe Stringer ; Yang, Yi Y ; >> Jiri Benc (jb...@redhat.com) ; Eric Garver >> >> Cc: d...@openvswitch.org >> Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset >> to ovs >> >> Hi Yi, >> >> Both Joe and Jarno have indicated there are no principle problems >> merging our self-contained user-space patches for L3 tunneling. May I >> suggest that you (together with Jiri and Eric) focus on the datapath >> back-ports and the user-space patches on top needed to configure L3 tunnels >> in the net-next and OVS tree kernel module. >> >> /Jan >> >>> -Original Message- >>> From: Joe Stringer [mailto:j...@ovn.org] >>> Sent: Tuesday, 07 February, 2017 18:55 >>> To: Yang, Yi Y >>> Cc: Jan Scheurich ; d...@openvswitch.org >>> Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset >>> to ovs >>> >>> On 7 February 2017 at 05:28, Yang, Yi Y wrote: >>>> Jan, I know that, but per Joe's comments, it seems he won't merge your >>>>
Re: [ovs-dev] [PATCH v2 3/4] datapath: backport: vlan: Check for vlan ethernet types for 8021.q or 802.1ad
Thanks Eric, I see, they were missing, I'll add them as you said.
-Original Message-
From: Eric Garver [mailto:e...@erig.me]
Sent: Thursday, February 9, 2017 11:37 PM
To: Yang, Yi Y
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v2 3/4] datapath: backport: vlan: Check for vlan
ethernet types for 8021.q or 802.1ad
On Mon, Feb 06, 2017 at 08:36:50PM +0800, Yi Yang wrote:
> commit fe19c4f971a55cea3be442d8032a5f6021702791
> Author: Eric Garver
> Date: Wed Sep 7 12:56:58 2016 -0400
>
> This is to simplify using double tagged vlans. This function allows all
> valid vlan ethertypes to be checked in a single function call.
> Also replace some instances that check for both ETH_P_8021Q and
> ETH_P_8021AD.
>
> Patch based on one originally by Thomas F Herbert.
>
> Signed-off-by: Thomas F Herbert
> Signed-off-by: Eric Garver
> Acked-by: Pravin B Shelar
> Signed-off-by: David S. Miller
>
> Signed-off-by: Yi Yang
> ---
> acinclude.m4 | 1 +
> datapath/linux/compat/include/linux/if_vlan.h | 24
> +---
> 2 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/acinclude.m4 b/acinclude.m4 index 9166da8..f219bec 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -664,6 +664,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
>OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [__vlan_insert_tag])
>OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [vlan_get_protocol])
>OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [skb_vlan_tagged])
> + OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [eth_type_vlan])
>
>OVS_GREP_IFELSE([$KSRC/include/linux/u64_stats_sync.h],
> [u64_stats_fetch_begin_irq])
>
> diff --git a/datapath/linux/compat/include/linux/if_vlan.h
> b/datapath/linux/compat/include/linux/if_vlan.h
> index c8ddef1..ff55fb8 100644
> --- a/datapath/linux/compat/include/linux/if_vlan.h
> +++ b/datapath/linux/compat/include/linux/if_vlan.h
> @@ -100,6 +100,25 @@ static inline struct sk_buff
> *rpl___vlan_hwaccel_put_tag(struct sk_buff *skb, #define
> __vlan_hwaccel_put_tag rpl___vlan_hwaccel_put_tag #endif
>
> +#ifndef HAVE_ETH_TYPE_VLAN
> +/**
> + * eth_type_vlan - check for valid vlan ether type.
> + * @ethertype: ether type to check
> + *
> + * Returns true if the ether type is a vlan ether type.
> + */
> +static inline bool eth_type_vlan(__be16 ethertype) {
> + switch (ethertype) {
> + case htons(ETH_P_8021Q):
> + case htons(ETH_P_8021AD):
> + return true;
> + default:
> + return false;
> + }
> +}
> +#endif
> +
> /* All of these were introduced in a single commit preceding 2.6.33, so
> * presumably all of them or none of them are present. */ #ifndef
> VLAN_PRIO_MASK @@ -188,7 +207,7 @@ static inline __be16
> __vlan_get_protocol(struct sk_buff *skb, __be16 type,
>* present at mac_len - VLAN_HLEN (if mac_len > 0), or at
>* ETH_HLEN otherwise
>*/
> - if (type == htons(ETH_P_8021Q) || type == htons(ETH_P_8021AD)) {
> + if (eth_type_vlan(type)) {
> if (vlan_depth) {
> if (WARN_ON(vlan_depth < VLAN_HLEN))
> return 0;
> @@ -206,8 +225,7 @@ static inline __be16 __vlan_get_protocol(struct sk_buff
> *skb, __be16 type,
> vh = (struct vlan_hdr *)(skb->data + vlan_depth);
> type = vh->h_vlan_encapsulated_proto;
> vlan_depth += VLAN_HLEN;
> - } while (type == htons(ETH_P_8021Q) ||
> - type == htons(ETH_P_8021AD));
> + } while (eth_type_vlan(type));
> }
>
> if (depth)
I think you can also take the hunks for skb_vlan_tagged() and
skb_vlan_tagged_multi() since you add them in the previous patch.
__vlan_get_tag() isn't in the OVS datapath, so that hunk can be omitted.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
If rtnetlink user space patches aren't merged, I don't think you can use in-kernel data path correctly, yes there are some work to do, but that has to been done after Eric Garver's rtnetlink user space patches are merged. Maybe you can try RFC patches Eric Garver posted https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327749.html, -Original Message- From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Valentine Sinitsyn Sent: Thursday, February 9, 2017 3:58 PM To: ovs-dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs Hi all, This L3 patchset looks similar to what we did internally with OVS 2.6 to add support for IPv6 tunnels. Could you please confirm that ovs-dpctl reports correct statistics with this patchset when one uses in-kernel Linux datapath? We had some issues with this (the counters were always zero). Largely, this was because userspace code (I refer to the tools and the daemon, not DPDK datapath here) assumes a plugged network interface is always L2, and I don't see this patch touching these files. Thanks for your co-operation. Best regards, Valentine Sinitsyn ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
Jan, I'm ok, I will rebase those patches once ovs maintainers merge your patches first. In my patches, I added vxlan-gpe user space support, that needs those three user space patches, that is why I included those three user space patches in my patch set. I don't know what order ovs maintainers will merge them in. I can only focus on userspace support for vxlan-gpe if ovs maintainers really merge your patches first. -Original Message- From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] Sent: Thursday, February 9, 2017 5:50 PM To: Yang, Yi Y ; Joe Stringer ; Jiri Benc (jb...@redhat.com) ; Eric Garver Cc: d...@openvswitch.org; Jarno Rajahalme (ja...@ovn.org) Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs Hi Yi, I very much doubt that it makes sense to first merge the obsolete user-space patches and then override them with the target version. Jarno and Joe have in principle agreed to merge the new user-space patches independently of the backport of the kernel datapath patches. So there is no dependency in this direction. If it is not possible to merge the kernel datapath back-ports without test cases, then I think the datapath merge should wait for the merge of the new user-space patches and then add end-to-end test cases for the kernel datapath as well. But perhaps such end-to-end tests are not strictly necessary. It appears to me that Jiri's L3 tunneling datapath patches were merged into net-next without such test cases (just based on code review). So why not in OVS tree? We can then add end-to-end kernel datapath tests when the Eric's outstanding user-space patches for rtnetlink and compat tunnel configuration for L3 tunnels are added. BR, Jan > -Original Message- > From: Yang, Yi Y [mailto:yi.y.y...@intel.com] > Sent: Wednesday, 08 February, 2017 06:31 > To: Jan Scheurich ; Joe Stringer > ; Jiri Benc (jb...@redhat.com) ; Eric > Garver > Cc: d...@openvswitch.org > Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset > to ovs > > I'll check how we can rebase your changes against those three patches > on top of my patches, our goals are same, that is to merge your > changes and this patch set to ovs. I don't know what order Joe will merge > them in. Obviously one patch set can't depend on another one which isn't > nailed down to merge or not. > > Jan, let us have a sync by lync meeting. > > -Original Message- > From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] > Sent: Wednesday, February 8, 2017 7:19 AM > To: Joe Stringer ; Yang, Yi Y ; Jiri > Benc (jb...@redhat.com) ; Eric Garver > Cc: d...@openvswitch.org > Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset > to ovs > > Hi Yi, > > Both Joe and Jarno have indicated there are no principle problems > merging our self-contained user-space patches for L3 tunneling. May I > suggest that you (together with Jiri and Eric) focus on the datapath > back-ports and the user-space patches on top needed to configure L3 tunnels > in the net-next and OVS tree kernel module. > > /Jan > > > -Original Message- > > From: Joe Stringer [mailto:j...@ovn.org] > > Sent: Tuesday, 07 February, 2017 18:55 > > To: Yang, Yi Y > > Cc: Jan Scheurich ; d...@openvswitch.org > > Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset > > to ovs > > > > On 7 February 2017 at 05:28, Yang, Yi Y wrote: > > > Jan, I know that, but per Joe's comments, it seems he won't merge your > > > patch set unless the part in kernel side is merged before them. > > It can't work without these three patches. > > > > I have primarily expressed concern about missing kernel patch > > backports due to inconsistent backporting order. If Jan's series is > > decoupled and still builds OK, tests OK, passes review, etc by > > itself then I'm not sure I understand the dependency on the kernel patches. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
Then, are you merging https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html or do I need to do anything else for it? -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Thursday, February 9, 2017 9:44 AM To: Yang, Yi Y Cc: ovs dev ; Yi-Hung Wei Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs On 7 February 2017 at 21:15, Yang, Yi Y wrote: > Joe, I investigated all the patches which changed > include/linux/if_vlan.h for 802.1ad in net-next again, I found ovs > compat mode doesn't need most of them at all, > datapath/linux/compat/include/linux/ only includes part of changes > which aren't in local $KSRC/include/linux/ but required in > datapath/linux/compat/*.c ^ required in datapath/linux/compat/*.c, or datapath/*.c. If a function doesn't exist in an older kernel, a backport is needed - whether in the headers or datapath/linux/compat/*.c. Also, if the behaviour of one of those functions changes on a newer kernel which requires changes to the users (such as datapath/*.c), then they may also need updating. > , so my conclusion is we needn't them at all, > https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html is > enough for 802.1ad backport for ovs. At a glance I think you're right. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
I'll check how we can rebase your changes against those three patches on top of my patches, our goals are same, that is to merge your changes and this patch set to ovs. I don't know what order Joe will merge them in. Obviously one patch set can't depend on another one which isn't nailed down to merge or not. Jan, let us have a sync by lync meeting. -Original Message- From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] Sent: Wednesday, February 8, 2017 7:19 AM To: Joe Stringer ; Yang, Yi Y ; Jiri Benc (jb...@redhat.com) ; Eric Garver Cc: d...@openvswitch.org Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs Hi Yi, Both Joe and Jarno have indicated there are no principle problems merging our self-contained user-space patches for L3 tunneling. May I suggest that you (together with Jiri and Eric) focus on the datapath back-ports and the user-space patches on top needed to configure L3 tunnels in the net-next and OVS tree kernel module. /Jan > -Original Message- > From: Joe Stringer [mailto:j...@ovn.org] > Sent: Tuesday, 07 February, 2017 18:55 > To: Yang, Yi Y > Cc: Jan Scheurich ; d...@openvswitch.org > Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset > to ovs > > On 7 February 2017 at 05:28, Yang, Yi Y wrote: > > Jan, I know that, but per Joe's comments, it seems he won't merge your > > patch set unless the part in kernel side is merged before them. > It can't work without these three patches. > > I have primarily expressed concern about missing kernel patch > backports due to inconsistent backporting order. If Jan's series is > decoupled and still builds OK, tests OK, passes review, etc by itself > then I'm not sure I understand the dependency on the kernel patches. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
Joe, I investigated all the patches which changed include/linux/if_vlan.h for 802.1ad in net-next again, I found ovs compat mode doesn't need most of them at all, datapath/linux/compat/include/linux/ only includes part of changes which aren't in local $KSRC/include/linux/ but required in datapath/linux/compat/*.c, so my conclusion is we needn't them at all, https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html is enough for 802.1ad backport for ovs. -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Wednesday, February 8, 2017 6:31 AM To: Yang, Yi Y Cc: ovs dev ; Yi-Hung Wei Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs On 7 February 2017 at 09:44, Joe Stringer wrote: > On 6 February 2017 at 16:46, Yang, Yi Y wrote: >> Joe, I checked current ovs and net-next kernel, obviously some patches from >> net-next are selectively backported to ovs, but others are not, I'm not sure >> what the policy is for a new patch. It will be better that the person who >> did the patch backports it to ovs at the same time, but nobody did so. > > That's supposed to be the policy; However, depending on the patch > sometimes openvswitch isn't even the main target of the change, so the > contributor may not be aware they should do so. There may be added > difficulty if the previous contributor didn't do their backport. I > think that lately there hasn't been particularly close co-ordination > between the trees, but ideally I think that as we approach an OVS > release, we would try to sync them up. > >> My 802.1ad backport has included all the things l3 patch set depends >> on, so I think you can give it a go :-) > > Kicking off a build on my local tester, I can at least report back on > that. I see you've tested on a few platforms as well, that's great. Reporting back, I suspect that some of the older kernels don't treat the double-tagged vlans right with this series? I was using an Ubuntu trusty VM with kernel 3.13.0-92-generic plus this backport and it seems to be consistently failing this test: 4: datapath - ping between two ports on cvlan FAILED (system-traffic.at:88) The test output just shows that a ping tries about 10 times and fails all of the times. I didn't investigate further. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
I mean these userspace patches are necessary to run l3 tunnel port in compat mode and dpdk netdev mode. Only jiri's 8 patches backport is not enough. One feasible way is we can rebase Jan's patches on top of this patch set. -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Wednesday, February 8, 2017 1:55 AM To: Yang, Yi Y Cc: Jan Scheurich ; d...@openvswitch.org Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs On 7 February 2017 at 05:28, Yang, Yi Y wrote: > Jan, I know that, but per Joe's comments, it seems he won't merge your patch > set unless the part in kernel side is merged before them. It can't work > without these three patches. I have primarily expressed concern about missing kernel patch backports due to inconsistent backporting order. If Jan's series is decoupled and still builds OK, tests OK, passes review, etc by itself then I'm not sure I understand the dependency on the kernel patches. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
Good point, I will add a following patch to do this. -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Wednesday, February 8, 2017 1:44 AM To: Yang, Yi Y Cc: ovs dev ; Yi-Hung Wei Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs On 6 February 2017 at 16:46, Yang, Yi Y wrote: > Joe, I checked current ovs and net-next kernel, obviously some patches from > net-next are selectively backported to ovs, but others are not, I'm not sure > what the policy is for a new patch. It will be better that the person who did > the patch backports it to ovs at the same time, but nobody did so. That's supposed to be the policy; However, depending on the patch sometimes openvswitch isn't even the main target of the change, so the contributor may not be aware they should do so. There may be added difficulty if the previous contributor didn't do their backport. I think that lately there hasn't been particularly close co-ordination between the trees, but ideally I think that as we approach an OVS release, we would try to sync them up. > My 802.1ad backport has included all the things l3 patch set depends > on, so I think you can give it a go :-) Kicking off a build on my local tester, I can at least report back on that. I see you've tested on a few platforms as well, that's great. If you were able to add even one or two basic tests to the system-kmod-testsuite for the new L3 bits (eg, set up a tunnel and send some packets through it), that would sure go some way towards knowing that this series does what it intends without bad side-effects, and also would help us to catch any potential regressions. > To make sure 802.1ad to work, there is still a userspace work to do, but as > Pravin said, this has no business with l3 patch set. Sure thing, userspace can be decoupled. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
Jan, I know that, but per Joe's comments, it seems he won't merge your patch set unless the part in kernel side is merged before them. It can't work without these three patches. -Original Message- From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] Sent: Tuesday, February 7, 2017 6:50 PM To: Yang, Yi Y ; d...@openvswitch.org Cc: Zoltán Balogh ; Jarno Rajahalme (ja...@ovn.org) Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs Hi Yi, Three of the user-space patches of your series have been superseded by our new patch series [PATCH 0/7] userspace: Support for L3 tunneling: https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html Please remove them from the next version. The user-space patches for VXLAN-GPE tunnels need adaptation to the above L3 tunneling patch set. BR, Jan > Yi Yang (16): > datapath: use hard_header_len instead of hardcoded ETH_HLEN > datapath: add mac_proto field to the flow key > datapath: pass mac_proto to ovs_vport_send > datapath: support MPLS push and pop for L3 packets > datapath: add processing of L3 packets > datapath: netlink: support L3 packets > datapath: add Ethernet push and pop actions > datapath: allow L3 netdev ports > userspace: add support for pop_eth and push_eth actions Jan: This is superseded > userspace: add layer 3 flow and switching support Jan: This is superseded > userspace: add non-tap (l3) support to GRE vports Jan: This is superseded > datapath: Add a missing break statement > datapath: upcall: Fix vlan handling. > datapath: enable vxlangpe creation in compat mode > userspace: enable layer3 option for vxlan-gpe Jan: To be adapted to https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html > userspace: add vxlan-gpe support for dpdk netdev Jan: To be adapted to https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
Joe, I checked current ovs and net-next kernel, obviously some patches from net-next are selectively backported to ovs, but others are not, I'm not sure what the policy is for a new patch. It will be better that the person who did the patch backports it to ovs at the same time, but nobody did so. My 802.1ad backport has included all the things l3 patch set depends on, so I think you can give it a go :-) To make sure 802.1ad to work, there is still a userspace work to do, but as Pravin said, this has no business with l3 patch set. -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Tuesday, February 7, 2017 8:34 AM To: Yang, Yi Y Cc: ovs dev ; Yi-Hung Wei Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs On 6 February 2017 at 05:04, Yi Yang wrote: > This patch set just ports Jiri Benc's L3 8 support patches for layer 3 > encapsulated packets from net-next to current ovs, it also includes Jiri > Benc's 3 userspace patches, Jarno Rajahalme and Pravin Shelar's vlan fix > patches for L3 patchset as well as my 3 patches which enabled vxlangpe in > compat mode and dpdk netdev in both L2 and L3(layer3=true) mode. > > This patchset has been verified on Ubuntu 14.04 x86_64 with Linux kernel > 3.13.0-24-generic and 4.9.7, it also passed "make check" > and "sudo make check-kmod RECHECK=yes" in Fedora 23 with kernel > 4.2.3-300.fc23.x86_64 > > This patch set is based on > https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html > ([PATCH v2 0/4] Backport 802.1ad patches), please merge this one after > merging [PATCH v2 0/4] Backport 802.1ad patches. Thanks for this work! I think that this comprises the majority of the remaining diff between the backport and the upstream tree, though there are still a bunch of other unrelated changes that are still missing. As we discussed earlier, it'd be good to ensure that we don't miss any of the small patches as well; to avoid this, my expectation would be that we can apply backports of all of the missing patches from net-next in the order they were applied to net-next. I believe that Yi-Hung is interested at looking at backporting those other missing patches up until the 802.1ad changes. From there we can review the 802.1ad backport series you have posted, then continue backporting up until the L3 tunnelling backport you've proposed. I'm not really sure how much work is involved in this at the moment, although I think that 802.1ad and L3 tunnelling were the largest features. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 0/3] Backport 802.1ad patches
I have found it can't be built on Ubuntu 14.04 because sbk_vlan_tagged isn't defined, I will send out a new patch set including this missing function (which was introduced by a patch in 2015). So please ignore this one and merge v2 I'll send out right now. -Original Message----- From: Yang, Yi Y Sent: Friday, February 3, 2017 11:12 PM To: d...@openvswitch.org Cc: pshe...@ovn.org; Yang, Yi Y Subject: [PATCH 0/3] Backport 802.1ad patches This patch set is to backport 802.1ad patches Eric Garver did to ovs, per discussion in ovs-dev mailing list, this fix patch "openvswitch: upcall: Fix vlan handling" depends on them, l3 patch set depends on this patch set and "openvswitch: upcall: Fix vlan handling". Once this patch set is merged, l3 patch set can be merged. Yi Yang (3): datapath: backport: openvswitch: 802.1ad uapi changes. datapath: backport: vlan: Check for vlan ethernet types for 8021.q or 802.1ad datapath: backport: openvswitch: 802.1AD Flow handling, actions, vlan parsing, netlink attributes datapath/actions.c| 16 +- datapath/flow.c | 65 +++-- datapath/flow.h | 8 +- datapath/flow_netlink.c | 311 +++--- datapath/linux/compat/include/linux/if_vlan.h | 24 +- datapath/linux/compat/include/linux/openvswitch.h | 17 +- datapath/vport.c | 7 +- 7 files changed, 312 insertions(+), 136 deletions(-) -- 2.1.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames
Thank you all, I'll try to backport 802.1ad patches. -Original Message- From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Eric Garver Sent: Friday, January 20, 2017 7:53 AM To: Joe Stringer Cc: ovs dev ; Jan Scheurich Subject: Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames On Thu, Jan 19, 2017 at 03:12:20PM -0800, Joe Stringer wrote: > On 19 January 2017 at 12:17, Pravin Shelar wrote: > > On Wed, Jan 18, 2017 at 4:53 PM, Yang, Yi wrote: > >> On Wed, Jan 18, 2017 at 01:29:14PM -0800, Joe Stringer wrote: > >>> On 18 January 2017 at 11:54, Eric Garver wrote: > >>> > On Tue, Jan 17, 2017 at 12:37:19AM +, Yang, Yi Y wrote: > >>> >> What userspace do "802.1ad patches" depend on? Per Pravin's statement, > >>> >> we just backport 802.1ad patches to ovs, then the below patch can be > >>> >> applied to ovs. > >>> > > >>> > Userspace does not yet have support for 802.1ad. I'm still > >>> > working on it. You can check the list archives for a recent RFC version. > >>> > > >>> > I don't know if it's acceptable to backport the datapath (kernel > >>> > module) support before the userspace support is accepted. If > >>> > not, you'll have to wait on the userspace. > >>> > Perhaps Pravin can answer. > >>> > >>> IMO the general method of: > >>> 1) Add support upstream > >>> 2) Add userspace support > >>> 3) Add backport > >>> > >>> ...works nicely because we get feedback for all interested parties > >>> for the APIs in (1), (2) can add tests and be easily tested > >>> against a version that works (upstream kernel) and a version that > >>> doesn't (version in tree) to ensure both cases are handled in a > >>> reasonable way, then (3) allows people on older kernels to gain > >>> access to the newer features. > >>> > >>> That said, if other people are blocking on (3) then I think that > >>> piece should be expedited. Let's say (2) and (3) were swapped, it > >>> just means we need to be a bit more careful when reviewing/testing > >>> to check that the newer userspace still handles old kernels (that > >>> lack support) fine. > >>> > >>> The nice thing about getting the backport earlier is, the closer > >>> to upstream we are, the sooner we may find issues that affect the > >>> latest code. > >> > >> If so, I think the below patch is the best solution to current > >> situation, it will be automatically overwritten once userspace part > >> and 802.1ad backport are ready to merge. > >> > > It is much easier to backport and review patches when it is done in > > same sequence as applied on upstream kernel. It is not just about > > this patch. by changing backport order the implementation and review > > of both L3 patch series and 802.1AD patch series becomes harder than > > necessary. > > Sorry, yes, my earlier explanation was regarding a particular feature > and ordering of userspace implementation vs. backport patches. > > With regards to the overall kernel backport, I agree the upstream > patches should be backported in sequence according to upstream. Then > we know we haven't missed anything. Also, dependencies from one patch > to the next are less likely to cause trouble while rebasing, so it > makes the backporter's life easier. Sounds good to me. Yi is welcome to try the 802.1ad datapath backport. Otherwise I'll get to when I can. Thanks everyone. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 15/17] datapath: enable vxlangpe creation in compat mode
Make sense, will change it in v3.
-Original Message-
From: Jiri Benc [mailto:jb...@redhat.com]
Sent: Wednesday, January 18, 2017 12:37 AM
To: Yang, Yi Y
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v2 15/17] datapath: enable vxlangpe creation in
compat mode
On Wed, 28 Dec 2016 20:26:28 +0800, Yi Yang wrote:
> --- a/datapath/linux/compat/include/linux/openvswitch.h
> +++ b/datapath/linux/compat/include/linux/openvswitch.h
> @@ -291,6 +291,7 @@ enum ovs_vport_attr { enum {
> OVS_VXLAN_EXT_UNSPEC,
> OVS_VXLAN_EXT_GBP, /* Flag or __u32 */
> + OVS_VXLAN_EXT_GPE, /* Flag or __u32 */
Please leave several free slots between OVS_VXLAN_EXT_GBP and
OVS_VXLAN_EXT_GPE. Although it's not expected that we add more values to this
enum upstream, we should not rule it out completely. Having a buffer here
allows to prevent nasty problems with attribute conflicts between the upstream
kernel and the compat code.
Jiri
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames
What userspace do "802.1ad patches" depend on? Per Pravin's statement, we just
backport 802.1ad patches to ovs, then the below patch can be applied to ovs.
commit df30f7408b187929dbde72661c7f7c615268f1d0
Author: pravin shelar
Date: Mon Dec 26 08:31:27 2016 -0800
openvswitch: upcall: Fix vlan handling.
-Original Message-
From: Eric Garver [mailto:e...@erig.me]
Sent: Monday, January 16, 2017 11:01 PM
To: Yang, Yi Y
Cc: Pravin Shelar ; Jan Scheurich ; ovs
dev
Subject: Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan
frames
On Mon, Jan 16, 2017 at 02:26:55PM +, Yang, Yi Y wrote:
> Hi, Eric
>
> We hope Jiri's L3 patchset can be applied into current ovs because we and
> Ericsson guys are enabling packet_type support and PTAP & non-PTAP based on
> L3 patchset, Pravin said you're backporting your 802.1ad patches from
> net-next to ovs, we don't know when your patches can be posted in ovs-dev, I
> can help with this if you have no time.
I had replied to Pravin earlier in this thread.
I do intend to backport the kernel changes to the ovs out-of-tree module. I was
waiting until userspace was ready. Unfortunately that's not likely to happen
this week or even next.
If you have the time feel free to give it a go.
> -Original Message-
> From: Pravin Shelar [mailto:pshe...@ovn.org]
> Sent: Monday, January 9, 2017 5:33 PM
> To: Yang, Yi Y ; Eric Garver
> Cc: ovs dev ; Jarno Rajahalme
> Subject: Re: [PATCH v2 14/17] datapath: Fix skb->protocol for vlan
> frames
>
> On Tue, Jan 3, 2017 at 6:47 AM, Yang, Yi Y wrote:
> > Pravin, the issue is current ovs has too many differences from net-next
> > tree, the best way is to apply all the patches before your patch, but it
> > seems a super huge work, it is out of my capability :-) Anybody of you is
> > working on this?
> >
>
> First we need to get 802.1ad patches merged in OVS out of tree module.
> Eric is working on 802.1ad support to OVS. I guess he will backport these
> patches to out of tree kernel module along with the userspace patches. That
> will cover majority of the remaining changes.
>
> Thanks,
> Pravin.
>
> > -Original Message-
> > From: Pravin Shelar [mailto:pshe...@ovn.org]
> > Sent: Sunday, January 1, 2017 3:45 PM
> > To: Yang, Yi Y
> > Cc: ovs dev ; Jarno Rajahalme
> > Subject: Re: [PATCH v2 14/17] datapath: Fix skb->protocol for vlan
> > frames
> >
> > On Wed, Dec 28, 2016 at 5:56 PM, Yi Yang wrote:
> >> Do not always set skb->protocol to be the ethertype of the L3 header.
> >> For a packet with non-accelerated VLAN tags skb->protocol needs to be the
> >> ethertype of the outermost non-accelerated VLAN ethertype.
> >>
> >> Any VLAN offloading is undone on the OVS netlink interface, and any VLAN
> >> tags added by userspace are non-accelerated, as are double tagged VLAN
> >> packets.
> >>
> >> Fixes: 018c1dda5f ("openvswitch: 802.1AD Flow handling, actions,
> >> vlan parsing, netlink attributes")
> >> Fixes: 5108bbaddc ("openvswitch: add processing of L3 packets")
> >> Signed-off-by: Jarno Rajahalme
> >> Signed-off-by: Yi Yang
> > This is not upstream patch. So even though it fixes the issue we can not
> > apply it to out of tree kernel module.
> >
> > Can you look at the net branch for the correct patch.
> >
> > Thanks.
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames
Hi, Eric
We hope Jiri's L3 patchset can be applied into current ovs because we and
Ericsson guys are enabling packet_type support and PTAP & non-PTAP based on L3
patchset, Pravin said you're backporting your 802.1ad patches from net-next to
ovs, we don't know when your patches can be posted in ovs-dev, I can help with
this if you have no time.
-Original Message-
From: Pravin Shelar [mailto:pshe...@ovn.org]
Sent: Monday, January 9, 2017 5:33 PM
To: Yang, Yi Y ; Eric Garver
Cc: ovs dev ; Jarno Rajahalme
Subject: Re: [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames
On Tue, Jan 3, 2017 at 6:47 AM, Yang, Yi Y wrote:
> Pravin, the issue is current ovs has too many differences from net-next tree,
> the best way is to apply all the patches before your patch, but it seems a
> super huge work, it is out of my capability :-) Anybody of you is working on
> this?
>
First we need to get 802.1ad patches merged in OVS out of tree module.
Eric is working on 802.1ad support to OVS. I guess he will backport these
patches to out of tree kernel module along with the userspace patches. That
will cover majority of the remaining changes.
Thanks,
Pravin.
> -Original Message-
> From: Pravin Shelar [mailto:pshe...@ovn.org]
> Sent: Sunday, January 1, 2017 3:45 PM
> To: Yang, Yi Y
> Cc: ovs dev ; Jarno Rajahalme
> Subject: Re: [PATCH v2 14/17] datapath: Fix skb->protocol for vlan
> frames
>
> On Wed, Dec 28, 2016 at 5:56 PM, Yi Yang wrote:
>> Do not always set skb->protocol to be the ethertype of the L3 header.
>> For a packet with non-accelerated VLAN tags skb->protocol needs to be the
>> ethertype of the outermost non-accelerated VLAN ethertype.
>>
>> Any VLAN offloading is undone on the OVS netlink interface, and any VLAN
>> tags added by userspace are non-accelerated, as are double tagged VLAN
>> packets.
>>
>> Fixes: 018c1dda5f ("openvswitch: 802.1AD Flow handling, actions, vlan
>> parsing, netlink attributes")
>> Fixes: 5108bbaddc ("openvswitch: add processing of L3 packets")
>> Signed-off-by: Jarno Rajahalme
>> Signed-off-by: Yi Yang
> This is not upstream patch. So even though it fixes the issue we can not
> apply it to out of tree kernel module.
>
> Can you look at the net branch for the correct patch.
>
> Thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH
Jan, do you think when your proposal can be merged into ovs? The old NSH implementation and new proposal aren't contradictory, they can coexist, your new proposal isn't just for NSH, new proposal won't have push_nsh & pop_nsh, so we can let them coexist, let users decide which one is better. We need to let users have one NSH version available before your proposal is implemented. I support your proposal, but I have no way to do anything helpful before your implementation for generic encap/decap and packet_type are available. I don't know what other guys are thinking about this, it seems only you and I are caring this :) From: Jan Scheurich [mailto:jan.scheur...@web.de] Sent: Monday, January 9, 2017 8:23 AM To: Yang, Yi Y ; Jan Scheurich ; Zoltán Balogh ; Jiri Benc (jb...@redhat.com) ; Pravin Shelar ; Simon Horman (simon.hor...@netronome.com) ; 'jpet...@ovn.org' ; 'ja...@ovn.org' ; 'Ben Pfaff' ; 'ben.mackcr...@corsa.com' ; d...@openvswitch.org; Zhou, Danny Subject: Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH Hi Yi, I fully agree that support for NSH has been dragging along for to long. The prime reason for this (in addition to the dependency on the L3 tunneling) have been the mentioned conceptual problems with the current patches. Our initiative is the attempt to put NSH on a solid basis in OF/OVS and make faster progress by bundling all forces that agree on the solution documented in the Google doc. We wouldn't pursue this if we saw a chance of upstreaming the NSH patches as they are now. We still hope that you can agree on the proposed approach and help making NSH happen soon. Please find some more answers below. BR, Jan On 2017-01-03 01:59, Yang, Yi Y wrote: Jan, we can't always be waiting endlessly, L3 patchset has been in Linux kernel no matter you like it or not, we're just to make sure ovs can work with it, VxLAN-gpe is not only for NSH. If you think L3 patchset in Linux kernel has any issue, please send out your fix patches as soon as possible, it can be ported to ovs, this isn't an excuse we wait endlessly. I don't think we need to wait it. About several NSH-related issues you mentioned, I don't think they are big issues, Jan: "The NXM fields for NSH are used both as packet match fields and as packet metadata fields (after decap). This ambiguity leads to problems, latest when dealing with NSH in NSH packets." Yi: VxLAN tunnel metadata used the same way, isn't it? What problems do you mean? I believe we can fix them even if they are really so-called "problems". Tunnel metadata do not have that issue. They are only valid after the tunnel packet has been decapsulated or before it is encapsulated, but never when it is encapsulated. However, if you use OXM fields both for matching present packet headers and for keeping their content as packet metadata after decapsulation, both the meaning of matching on them and manipulating them is essentially undefined. This is most obvious for a packet with two NSH headers in a row (hierarchical SFC). Jan: "They introduce push/pop_nsh OpenFlow actions without dealing with the resulting non-Ethernet packets in the pipeline. The behavior is not at all well defined." Yi: L3 patchset is just for this, isn't it? Your new proposal will also depend on L3 patchset, right? No, the L3 patch set merely allows to connect L3 ports to an Ethernet only (non-PTAP) OF pipeline. The packets in the OF pipeline are logically always L2 packets, even though the representation inside ofproto-dpif may temporarily omit the Ethernet header from the packet. But the L2 fields dl_src, dl_dst and dl_type can be matched on and manipulated by the OF controller at any time. When a packet is sent to an Ethernet port, the L2 header containing these fields is always present. There is nothing in the L3 tunneling patch set that would allow an OF controller to modify the packet type in the pipeline. For this we need the concept of packet-type aware pipeline and the packet_type match field. The new proposal based on PTAP does indeed depend on "versatile" tunnel ports, as e.g. already implemented in the kernel datapath. Zoltan and I are very close to having the user-space parts of the L3 tunneling patch sets adapted to the packet_type concept. These replace the user-space patches in your latest L3 tunneling patch set. Then we'd have work packages 1,2,3 and 6 of the document in place and we could focus in parallel on 4 (PTAP), 5 (EXT-382) and NSH MD1 (7 and 8). Jan: "The re-use of the Geneve tunnel metada fields for NSH MD2 TLVs is problematic because a) it again mixes packet metadata and header fields and b) it couldn't handle NSH MD2 in Geneve tunnels." Yi: You have to admit this is the existing best solution for MD type 2, it is not perfect, but it is ready for use.
Re: [ovs-dev] [PATCH v2 11/17] userspace: add non-tap (l3) support to GRE vports
Jan, which patch is the final solution you mentioned? Has It been merged into
net-next? Or it isn't ready at all? From my understanding, the final solution
you mentioned will also wait for long time to merge, it is just to add
packet_type match field, this won't have any big impact on current patchset
from user perspective.
-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@web.de]
Sent: Friday, December 30, 2016 6:59 PM
To: Yang, Yi Y ; d...@openvswitch.org
Cc: Simon Horman ; Jiri Benc
Subject: Re: [ovs-dev] [PATCH v2 11/17] userspace: add non-tap (l3) support to
GRE vports
This patch is not in line with the ongoing work to support L3 tunnels on legacy
(non packet type-aware) OVS bridges as specified in
https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit?usp=sharing
To avoid extensive rework, we suggest to replace the patch with the final
solution based on explicit packet_type fields in dp_packet and struct flow.
Regards, Jan
On 2016-12-28 13:26, Yi Yang wrote:
> Add support for layer 3 GRE vports (non-tap aka non-VTEP).
>
> This makes use of a vport mode configuration for the existing
> (tap/VTEP) GRE vports.
>
> In order to differentiate packets for two different types of GRE
> vports a new flow key attribute, OVS_KEY_ATTR_NEXT_BASE_LAYER, is
> used. It is intended that this attribute is only used in userspace as
> there appears to be no need for it to be used in the kernel datapath.
>
> It is envisaged that this attribute may be used for other
> encapsulation protocols that support both layer3 and layer2 inner-packets.
>
> Signed-off-by: Simon Horman
> Signed-off-by: Jiri Benc
> Signed-off-by: Yi Yang
> ---
> datapath/linux/compat/include/linux/openvswitch.h | 3 ++
> include/openvswitch/flow.h| 12 --
> lib/flow.c| 34
> lib/match.c | 6 ++-
> lib/netdev-linux.c| 3 +-
> lib/netdev-native-tnl.c | 26 +---
> lib/netdev-vport.c| 22 --
> lib/netdev.h | 1 +
> lib/nx-match.c| 2 +-
> lib/odp-execute.c | 2 +
> lib/odp-util.c| 22 ++
> lib/odp-util.h| 4 +-
> lib/ofp-util.c| 2 +-
> lib/tnl-ports.c | 49
> +--
> lib/tnl-ports.h | 3 +-
> ofproto/ofproto-dpif-rid.h| 2 +-
> ofproto/ofproto-dpif-sflow.c | 1 +
> ofproto/ofproto-dpif-xlate.c | 2 +-
> ofproto/ofproto-dpif.c| 2 +
> ofproto/tunnel.c | 4 +-
> tests/tunnel-push-pop-ipv6.at | 12 --
> tests/tunnel-push-pop.at | 26 ++--
> vswitchd/vswitch.xml | 13 ++
> 23 files changed, 202 insertions(+), 51 deletions(-)
>
> diff --git a/datapath/linux/compat/include/linux/openvswitch.h
> b/datapath/linux/compat/include/linux/openvswitch.h
> index af4ee5c..e477d35 100644
> --- a/datapath/linux/compat/include/linux/openvswitch.h
> +++ b/datapath/linux/compat/include/linux/openvswitch.h
> @@ -360,6 +360,9 @@ enum ovs_key_attr {
> #ifdef __KERNEL__
> /* Only used within kernel data path. */
> OVS_KEY_ATTR_TUNNEL_INFO, /* struct ovs_tunnel_info */
> +#else
> + /* Only used within user-space data path. */
> + OVS_KEY_ATTR_NEXT_BASE_LAYER, /* base layer of encapsulated packet
> +*/
> #endif
> __OVS_KEY_ATTR_MAX
> };
> diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h
> index 93ed37e..46ef87e 100644
> --- a/include/openvswitch/flow.h
> +++ b/include/openvswitch/flow.h
> @@ -23,7 +23,7 @@
> /* This sequence number should be incremented whenever anything involving
> flows
>* or the wildcarding of flows changes. This will cause build assertion
>* failures in places which likely need to be updated. */ -#define
> FLOW_WC_SEQ 37
> +#define FLOW_WC_SEQ 38
>
> /* Number of Open vSwitch extension 32-bit registers. */
> #define FLOW_N_REGS 16
> @@ -138,6 +138,10 @@ struct flow {
> ovs_be16 tp_dst;/* TCP/UDP/SCTP destination port/ICMP code.
> */
> ovs_be32 igmp_group_ip4;/* IGMP group IPv4 address.
>* Keep last for BUILD_ASSERT_DECL
> b
Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH
Jan, we can't always be waiting endlessly, L3 patchset has been in Linux kernel no matter you like it or not, we're just to make sure ovs can work with it, VxLAN-gpe is not only for NSH. If you think L3 patchset in Linux kernel has any issue, please send out your fix patches as soon as possible, it can be ported to ovs, this isn't an excuse we wait endlessly. I don't think we need to wait it. About several NSH-related issues you mentioned, I don't think they are big issues, Jan: "The NXM fields for NSH are used both as packet match fields and as packet metadata fields (after decap). This ambiguity leads to problems, latest when dealing with NSH in NSH packets." Yi: VxLAN tunnel metadata used the same way, isn't it? What problems do you mean? I believe we can fix them even if they are really so-called "problems". Jan: "They introduce push/pop_nsh OpenFlow actions without dealing with the resulting non-Ethernet packets in the pipeline. The behavior is not at all well defined." Yi: L3 patchset is just for this, isn't it? Your new proposal will also depend on L3 patchset, right? Jan: "The re-use of the Geneve tunnel metada fields for NSH MD2 TLVs is problematic because a) it again mixes packet metadata and header fields and b) it couldn't handle NSH MD2 in Geneve tunnels." Yi: You have to admit this is the existing best solution for MD type 2, it is not perfect, but it is ready for use. I don't think people will use GENEVE for NSH now, we can modify it to adapt to such use case if people really would like to do that way. Jan, I don't think the new proposal fixed the above issues you mentioned, on the contrary, it will make things more complicated. Why don't we go fats path instead take a from-a-scratch way? From: Jan Scheurich [mailto:jan.scheur...@web.de] Sent: Friday, December 30, 2016 6:34 PM To: Yang, Yi Y ; Jan Scheurich ; Zoltán Balogh ; Jiri Benc (jb...@redhat.com) ; Pravin Shelar ; Simon Horman (simon.hor...@netronome.com) ; 'jpet...@ovn.org' ; 'ja...@ovn.org' ; 'Ben Pfaff' ; 'ben.mackcr...@corsa.com' ; d...@openvswitch.org; Zhou, Danny Subject: Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH Hi Yi, Thanks for the confirmation and for rebasing the existing L3 tunneling patches to include VXLAN-GPE. Unfortunately, Simon's original user-space implementation in patches 9/17 through 11/17 using base_layer and offset fields in dp_packet is not compatible to our ongoing implementation of versatile tunnel ports in PTAP and non-PTAP bridges, which is based on an explicit packet_type field. To avoid extensive rework, I would rather not merge these changes into master now but substitute them with the final implementation. This is work-package "3 - L3 ports in non-PTAP pipeline" in our Google doc and Zoltan and I will have that ready soon. Regarding the implementation of NSH support, we should work together to implement what is described in the Google doc: https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit#heading=h.wp4o2op1lp9z In our opinion the earlier NSH patches cannot be upstreamed because of a couple of fundamental conceptual problems: 1. The NXM fields for NSH are used both as packet match fields and as packet metadata fields (after decap). This ambiguity leads to problems, latest when dealing with NSH in NSH packets. 2. They introduce push/pop_nsh OpenFlow actions without dealing with the resulting non-Ethernet packets in the pipeline. The behavior is not at all well defined. 3. The re-use of the Geneve tunnel metada fields for NSH MD2 TLVs is problematic because a) it again mixes packet metadata and header fields and b) it couldn't handle NSH MD2 in Geneve tunnels. All these issues are addressed in the proposed new solution built on PTAP and EXT-382. The fundamentals are aligned with ONF (OXM classes already assigned), so that there is a good chance that we can feed the OVS implementation of NSH into the next OpenFlow standard. The first phase covering the fixed MD1 NSH header should also be possible to upstream in Q1/17, quite soon after the basic patches for PTAP and EXT-382. Let's have a direct talk when I'm back in office after New Year. Regards, Jan On 2016-12-23 01:51, Yang, Yi Y wrote: Hi, Jan I confirm I can take VxLAN-gpe and NSH related work, now I'm pushing Jiri's L3 patches ot ovs in order that it can be ported into ovs as early as possible, Pravin, Joe and Jarno found some vlan-related issues in Jiri's L3 patches in net-next and worked out several patches for net-next, but they are not merged yet. But I have had a workable local ovs version with Jiri's l3 patches and Jarno's fix patches merged, I have worked out several patches to make sure VxLAN-gpe can work in layer3 and layer 2 mo
Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames
Pravin, the issue is current ovs has too many differences from net-next tree,
the best way is to apply all the patches before your patch, but it seems a
super huge work, it is out of my capability :-) Anybody of you is working on
this?
-Original Message-
From: Pravin Shelar [mailto:pshe...@ovn.org]
Sent: Sunday, January 1, 2017 3:45 PM
To: Yang, Yi Y
Cc: ovs dev ; Jarno Rajahalme
Subject: Re: [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames
On Wed, Dec 28, 2016 at 5:56 PM, Yi Yang wrote:
> Do not always set skb->protocol to be the ethertype of the L3 header.
> For a packet with non-accelerated VLAN tags skb->protocol needs to be the
> ethertype of the outermost non-accelerated VLAN ethertype.
>
> Any VLAN offloading is undone on the OVS netlink interface, and any VLAN tags
> added by userspace are non-accelerated, as are double tagged VLAN packets.
>
> Fixes: 018c1dda5f ("openvswitch: 802.1AD Flow handling, actions, vlan
> parsing, netlink attributes")
> Fixes: 5108bbaddc ("openvswitch: add processing of L3 packets")
> Signed-off-by: Jarno Rajahalme
> Signed-off-by: Yi Yang
This is not upstream patch. So even though it fixes the issue we can not apply
it to out of tree kernel module.
Can you look at the net branch for the correct patch.
Thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Sync on PTAP, EXT-382 and NSH
Hi, Jan I confirm I can take VxLAN-gpe and NSH related work, now I'm pushing Jiri's L3 patches ot ovs in order that it can be ported into ovs as early as possible, Pravin, Joe and Jarno found some vlan-related issues in Jiri's L3 patches in net-next and worked out several patches for net-next, but they are not merged yet. But I have had a workable local ovs version with Jiri's l3 patches and Jarno's fix patches merged, I have worked out several patches to make sure VxLAN-gpe can work in layer3 and layer 2 mode, now they are ready except DPDK userspace has some issues which I'm debugging. So I think L3 patches and VxLAN-gpe will be ready very soon. I remember every guys agreed our old NSH implementation with MD type 2 support, I think that will be the fastest path we can take for NSH support, I dare to guarantee it can be ready to merge about one month after (including kernel patches and ovs patches) I'm wondering if you guys can make a form to list pros and cons for the old implementation way and this new one in order that every people can clearly know what the advantages and disadvantages for them are. From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] Sent: Thursday, December 22, 2016 6:51 PM To: Zoltán Balogh ; Yang, Yi Y ; Jiri Benc (jb...@redhat.com) ; Pravin Shelar ; Simon Horman (simon.hor...@netronome.com) ; 'jpet...@ovn.org' ; 'ja...@ovn.org' ; 'Ben Pfaff' ; 'ben.mackcr...@corsa.com' ; d...@openvswitch.org Subject: RE: Sync on PTAP, EXT-382 and NSH Thanks for the good meeting. Here are my notes: Date: 2016-12-21, 17-18:30 CET Participants: Jarno R, Ben P, Ben M-C, Jiri B, Simon H, Zoltan B, Jan S Summary: ·Discussed making PTAP, EXT-382 and NSH available as extensions to OF 1.3. ·No big deal for the match fields and the encap/decap actions ·Potential problem could be the missing packet_type information in OF 1.3 Packet In, Packet Out and Table Features (Note: Closer inspection of OF 1.5.1 spec reveals that OXM packet_type is part of struct ofp_match in Packet In and Packet Out. It should be OK for an OF 1.3 controller extended with PTAP support) ·Is it simpler for the controllers to upgrade to OF 1.5? ·Deferred the decision ·Agreed to use the (to be assigned) OXM field code points for packet_type and NSH in OVS for all OF versions ·Agreed to allow all NS=1 packet types received from/sent to a tunnel port that uses the Ethertype name space in its protocol field (like GRE). Other versatile tunnel ports (like VXLAN-GPE) which have their own code points require explicit mapping and must drop packets for which no such mapping exists. ·Discussed introduction of a new OXM class for the proposed GEN_TLV fields ·No problem to reserve an OXM class even before those fields are standardized ·For standardization we also need to specify a dynamic binding mechanism between protocol TLVs and GEN_TLV fields. We can submit the mechanism to be developed in OVS for standardization when its stable. ·Walk-through of division into work packages: ·Some follow up needed for the L3 packet support kernel datapath patches ·Rest OK ·Technical discussion around GEN_TLV and use for NSH MD2 in conjunction with encap(NSH) to be continued in the Google doc. ·Time line: ·The entire work should be targeting OVS 2.8 with feature freeze around July ·OVS 2.7 is having feature freeze already in early January ·Work packages can be upstreamed individually. NSH MD1 support doesn't have to wait for MD2 ·Basically agreed to the work split proposed in the document: ·RedHat is taking the patches for L3 tunnel configuration (including use of RTNETLINK for config) ·Ericsson take the infrastructure components (L3-tunnels, PTAP, Basic EXT-382) ·Jarno (VMware) will handle the GEN_TLV infrastructure ·Confirm with Yi Yang (Intel): Can they take VXLAN-GPE and the NSH-specific WPs? Or do they need help? ·Way of working ·Continue the meeting series for coordination of effort ·Can use a feature integration branch to ease the joint development and test ·Review of patches mainly through the ovs-dev mailing list ·Use tools like git citool to break up larger patches into a series of smaller patches for review -Original Appointment- From: Jan Scheurich Sent: Sunday, 18 December, 2016 15:34 To: Jan Scheurich; Zoltán Balogh; Yang, Yi Y (yi.y.y...@intel.com<mailto:yi.y.y...@intel.com>); Jiri Benc (jb...@redhat.com<mailto:jb...@redhat.com>); Pravin Shelar; Simon Horman (simon.hor...@netronome.com<mailto:simon.hor...@netronome.com>); jpet...@ovn.org<mailto:jpet...@ovn.org>; ja...@ovn.org<mailto:ja...@ovn.org>; Ben Pfaff; 'ben.mackcr...@corsa.com'; d...@o
Re: [ovs-dev] [PATCH 0/8] port Jiri's 8 support patches for layer 3 encapsulated packets from net-next
Hi, Joe and Pravin I checked " make check-kernel" against current ovs master (I don't add any change) on Ubuntu 14.04, but it failed ## -- ## ## openvswitch 2.6.90 test suite. ## ## -- ## datapath-sanity 1: datapath - ping between two ports FAILED (system-traffic.at:13) 2: datapath - http between two ports FAILED (system-traffic.at:36) I don't know what we need to prepare in order that it can be run correctly. " make check-kmod" has the same result. Notice, I didn't add a line code, I just cloned ovs master and tried it after build. ## -- ## ## openvswitch 2.6.90 test suite. ## ## -- ## datapath-sanity 1: datapath - ping between two ports FAILED (system-traffic.at:13) 2: datapath - http between two ports FAILED (system-traffic.at:36) 3: datapath - ping between two ports on vlan FAILED (system-traffic.at:59) -Original Message- From: Pravin Shelar [mailto:pshe...@ovn.org] Sent: Friday, December 16, 2016 3:30 PM To: Joe Stringer Cc: Yang, Yi Y ; ovs dev Subject: Re: [ovs-dev] [PATCH 0/8] port Jiri's 8 support patches for layer 3 encapsulated packets from net-next On Thu, Dec 15, 2016 at 5:23 PM, Joe Stringer wrote: > On 15 December 2016 at 05:27, Yi Yang wrote: >> This patch set just ports Jiri's 8 support patches for layer 3 encapsulated >> packets from net-next to current ovs, this is a cornerstone for L3 tunnel >> port support in ovs. > > Please follow the directions for submitting patches: > http://docs.openvswitch.org/en/latest/internals/contributing/submittin > g-patches/ > > In particular, I see a variety of complaints from the compiler with > this series, some of them may apply to upstream as well [I didn't get > as far as to check that yet], some are just warnings but we should > certainly fix them anyway; some are userspace compilation failures > with the newer headers. > > It would also provide further validation of the series if A) you can > point to a good full travis-ci run with this series; and B) if you > could run the kernel module testsuite to confirm things don't break. I > believe that Jarno had some pending patches for breakage introduced by > this series. > I agree, we need to sort out those issues upstream before merging it to out of tree kernel module. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC PATCH] datapath: allow tunnels to be created with rtnetlink
Hi, guys
This patch isn't updated from June on, Cascardo said he/Eric is still working
on this, but six months passed, we don't see any following patch for this, now
I have time to revisit it, for case 3 Pravin mentioned, I can make it work by
applying the below patch [1] against
https://mail.openvswitch.org/pipermail/ovs-dev/2016-June/316881.html, but it
only can create vxlan port, it will also create vxlan port even if I create
vxlan-gpe port by cmd "sudo ovs-vsctl add-port br-int vxlan_gpe1 -- set
interface vxlan_gpe1 type=vxlan options:remote_ip=flow options:key=flow
options:dst_port=4790 options:exts=gpe", the reason is very simple,
vxlan_configure_exts in datapath/vport-vxlan.c will be called to set vxlan
configuration, but it can't recognize vxlangpe extension and flags, you guys
told me datapath/vport-vxlan.c and
datapath/linux/compat/include/linux/openvswitch.h are compatibility code, we
can't change them, but for case 3, we have to change them like patch [2], I
know we shoul
d change them on Linux net-next kernel first, here I just show you we have to
do so for case 3 Pravin mentioned, I'm happy to hear you have better way for
this.
So my advice about this is we can push patch [2] to Linux net-next first, then
apply patch series
https://mail.openvswitch.org/pipermail/ovs-dev/2016-June/316879.html from
Cascardo and apply [1], that can cover all the cases Pravin mentioned.
This patch has blocked us too long, we look forward to seeing progress on this.
[1]:
>From f40b6fec09e1f9ad14e50ba224f46b1b9657399c Mon Sep 17 00:00:00 2001
From: Yi Yang
Date: Tue, 6 Dec 2016 12:39:41 +0800
Subject: [PATCH] Use ovs compat modules if USE_UPSTREAM_TUNNEL is defined
Signed-off-by: Yi Yang
---
lib/dpif-netlink.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 0d03334..2286c3e 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -1062,6 +1062,9 @@ dpif_netlink_port_query__(const struct dpif_netlink
*dpif, odp_port_t port_no,
static int
dpif_netlink_port_create(struct netdev *netdev)
{
+#ifndef USE_UPSTREAM_TUNNEL
+return EOPNOTSUPP;
+#else
switch (netdev_to_ovs_vport_type(netdev_get_type(netdev))) {
case OVS_VPORT_TYPE_VXLAN:
return netdev_vxlan_create(netdev);
@@ -1077,6 +1080,7 @@ dpif_netlink_port_create(struct netdev *netdev)
return EOPNOTSUPP;
}
return 0;
+#endif
}
static int
--
2.1.0
[2]:
diff --git a/datapath/linux/compat/include/linux/openvswitch.h
b/datapath/linux/compat/include/linux/openvswitch.h
index 12260d8..17e21cb 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -291,6 +291,7 @@ enum ovs_vport_attr {
enum {
OVS_VXLAN_EXT_UNSPEC,
OVS_VXLAN_EXT_GBP, /* Flag or __u32 */
+ OVS_VXLAN_EXT_GPE, /* Flag or __u32 */
__OVS_VXLAN_EXT_MAX,
};
diff --git a/datapath/vport-vxlan.c b/datapath/vport-vxlan.c
index 11965c0..a5882ed 100644
--- a/datapath/vport-vxlan.c
+++ b/datapath/vport-vxlan.c
@@ -54,11 +54,26 @@ static int vxlan_get_options(const struct vport *vport,
struct sk_buff *skb)
nla_nest_end(skb, exts);
}
+ if (vxlan->flags & VXLAN_F_GPE) {
+ struct nlattr *exts;
+
+ exts = nla_nest_start(skb, OVS_TUNNEL_ATTR_EXTENSION);
+ if (!exts)
+ return -EMSGSIZE;
+
+ if (vxlan->flags & VXLAN_F_GPE &&
+ nla_put_flag(skb, OVS_VXLAN_EXT_GPE))
+ return -EMSGSIZE;
+
+ nla_nest_end(skb, exts);
+ }
+
return 0;
}
static const struct nla_policy exts_policy[OVS_VXLAN_EXT_MAX + 1] = {
[OVS_VXLAN_EXT_GBP] = { .type = NLA_FLAG, },
+ [OVS_VXLAN_EXT_GPE] = { .type = NLA_FLAG, },
};
static int vxlan_configure_exts(struct vport *vport, struct nlattr *attr,
@@ -76,6 +91,8 @@ static int vxlan_configure_exts(struct vport *vport, struct
nlattr *attr,
if (exts[OVS_VXLAN_EXT_GBP])
conf->flags |= VXLAN_F_GBP;
+ if (exts[OVS_VXLAN_EXT_GPE])
+ conf->flags |= VXLAN_F_GPE;
return 0;
}
-Original Message-
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Pravin Shelar
Sent: Friday, October 21, 2016 1:31 AM
To: Thadeu Lima de Souza Cascardo
Cc: ovs dev ; Eric Garver
Subject: Re: [ovs-dev] [RFC PATCH] datapath: allow tunnels to be created with
rtnetlink
On Tue, Sep 20, 2016 at 7:01 AM, Thadeu Lima de Souza Cascardo
wrote:
> In order to use rtnetlink to create new tunnel vports, the backported
> tunnels require some code that was removed from their upstream
> version, mainly the necessary code for newlink and for start_xmit.
>
> This patch adds back the necessary code for VXLAN, GRE and Geneve
> tunnels.
>
> Signed-off-by: Eric Garver
> Signed-off-by: Thadeu Lima de Souza Cascardo
> ---
> datapath/linux/Modu
