Re: [ovs-dev] [PATCH v2 1/2] userspace datapath: Add GTP-U tunnel support

[Yang, Yi]

On Thu, May 17, 2018 at 05:11:24AM +0800, Aaron Conole wrote:
> Yi Yang  writes:
> 
> Hi Yi,
> 
> Thanks for the patch!  Just a brief review.
> 

Aaron, thank you so much for your quick review.

> >
> > Signed-off-by: Feng Yang 
> > Signed-off-by: Jiannan Ouyang 
> > Signed-off-by: Yi Yang 
> 
> Needs Co-author tags.

Ok, will add it in v3.

> >  OXM_CLASSES = {"NXM_OF_":(0,  0x),
> > "NXM_NX_":(0,  0x0001),
> > "NXOXM_NSH_": (0x005ad650, 0x),
> > +   "NXOXM_GTPU_":(0x005ad651, 0x),
> > "OXM_OF_":(0,  0x8000),
> > "OXM_OF_PKT_REG": (0,  0x8001),
> > "ONFOXM_ET_": (0x4f4e4600, 0x),
> > diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
> > b/datapath/linux/compat/include/linux/openvswitch.h
> > index 84ebcaf..ad6ea64 100644
> > --- a/datapath/linux/compat/include/linux/openvswitch.h
> > +++ b/datapath/linux/compat/include/linux/openvswitch.h
> 
> I don't see this in the upstream code.  This is introducing another
> place for kernel and ovs to diverge.  Please get this type accepted
> upstream first.

You're partially right :-), there was the case OVS accepted first, then
kernel did so. I think OVS community is very open for this.

> > diff --git a/lib/dpif-netlink-rtnl.c b/lib/dpif-netlink-rtnl.c
> > index 40c4569..a628b72 100644
> > --- a/lib/dpif-netlink-rtnl.c
> > +++ b/lib/dpif-netlink-rtnl.c
> 
> Again, you'll need to get the netlink datapath changes through kernel
> process.  At least try.

Yeah, I will, because Facebook guy Jiannan Ouyang did that before, they
won't push this, so I'll try pushing this, but you know this is a slow
process.

> >  break;
> > @@ -814,6 +817,8 @@ netdev_to_ovs_vport_type(const char *type)
> >  return OVS_VPORT_TYPE_VXLAN;
> >  } else if (!strcmp(type, "lisp")) {
> >  return OVS_VPORT_TYPE_LISP;
> > +} else if (strstr(type, "gtpu")) {
> 
> Why isn't this using "!strcmp"?

good catch, it should be "!strcmp", I'll change it in v3.

> >  
> > +/* It won't be parsed if the packet contains application layer data 
> > only.
> > + * These include, but not limited to GTP-U messages, GTP-C packets.
> > + */
> 
> Why treat GTP-U and C separate here?

GTP-C is very complicated and it is for control plane, so it won't be
helpful to have it in OVS datapath, Joe mentioned this in v1 comments, we 
discussed
this, GTP-U is what we care in real user scenarios.

In addition, GPT-C and GTP-U use different UDP port, GTP-U tunnel can't
handle GTP-C, here the comment may be misleading you. It means ovs won't
parse the packet if it is GTP-U signaling message but not normal GTP-U
PDU.
___
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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>; 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 <jan.scheur...@ericsson.com>; 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 <yi.y.y...@intel.com>; Jan Scheurich 
> <jan.scheur...@ericsson.com>
> 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 <jan.scheur...@ericsson.com>
> 
> ---
> 
> 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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>; Jan Scheurich <jan.scheur...@ericsson.com>
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 <jan.scheur...@ericsson.com>

---

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

[Yang, Yi]

I tried the below fix patch you mentioned, it did fix this issue.

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();

On Mon, Mar 26, 2018 at 12:45:46AM +, Yang, Yi Y wrote:
> 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 <yi.y.y...@intel.com>
> Cc: d...@openvswitch.org; Zoltán Balogh <zoltan.bal...@ericsson.com>
> 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 wit

Re: [ovs-dev] OVS will hit an assert if encap(nsh) is done in bucket of group

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
Cc: d...@openvswitch.org; Zoltán Balogh <zoltan.bal...@ericsson.com>
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 
> <jan.scheur...@ericsson.com<mailto:jan.scheur...@ericsson.com>>

> Cc: d...@openvswitch.org<mailto:d...@openvswitch.org>; Zoltán Balogh 
> <zoltan.bal...@ericsson.com<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:

Re: [ovs-dev] OVS will hit an assert if encap(nsh) is done in bucket of group

[Yang, Yi]

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
 3(vxlan1): addr:da:1e:fb:2b:c8:63
 config: 0
 state:  LIVE
 speed: 0 Mbps now, 0 Mbps max
 4(veth-br): addr:92:3d:e0:ab:c2:85
 config: 0
 state:  LIVE
 current:10GB-FD COPPER
 speed: 1 Mbps now, 0 Mbps max
 LOCAL(br-int): addr:08:00:27:c6:9f:ff
 config: 0
 state:  LIVE
 current:10MB-FD COPPER
 speed: 10 Mbps now, 0 Mbps max

Here are group and flow

${OFCTL} -Oopenflow13 add-group br-int
group_id=111,type=all,bucket="load:0xc0a83249->NXM_NX_TUN_IPV4_DST[],load:0x9->NXM_NX_TUN_ID[0..31],output:3",bucket="encap(nsh(md_type=1)),set_field:0x80->nsh_flags,set_field:0x3456->nsh_spi,set_field:253->nsh_si,set_field:0x->nsh_c1,set_field:0x->nsh_c2,set_field:0x->nsh_c3,set_field:0x->nsh_c4,load:0xc0a83249->NXM_NX_TUN_IPV4_DST[],load:0x9->NXM_NX_TUN_ID[0..31],output:2"
${OFCTL} -Oopenflow13 add-flow br-int in_port=4,icmp,actions=group:111

Then I run ping by this cmd "sudo ip netns exec app ping -c 1 192.168.2.2", it 
will hit flow "in_port=4,icmp,actions=group:111", then result in this assert.

> 
> > -Original Message-
> > From: Yang, Yi [mailto:yi.y.y...@intel.com]
> > Sent: Friday, 23 March, 2018 04:53
> > To: d...@openvswitch.org
> > Cc: Jan Scheurich <jan.scheur...@ericsson.com>; Zoltán Balogh 
> > <zoltan.bal...@ericsson.com>
> > Subject: OVS will hit an assert if encap(nsh) is done in bucket of group
> > 
> > Hi, guys
> > 
> > A NSH user found OVS will hit the below assert in function
> > commit_set_nsh_action in file lib/odp-util.c if encap(nsh) is done in
> > bucket of group
> > 
> > ovs_assert(flow->nsh.mdtype == base_flow->nsh.mdtype &&
> >flow->nsh.np == base_flow->nsh.np);
> > 
> > But it isn't an issue if encap(nsh) in actions=.
> > 
> > I debugged this issue but can't find the root cause, basically
> > xlate_generic_encap_action is called twice for a packet in different
> > code path in group bucket use case. one is upcall process, another one
> > is normal process in two code paths, gdb call stack dump is as followed.
> > 
> > The second call is obviously based on the result of the first call which
> > has been committed by xlate_commit_actions in first call
> > xlate_generic_encap_action, so flow->nsh.np will be set to NSH_P_NSH,
> > this is wrong, but it can work normally if I comment out the above
> > assert. I really don't know why xlate_generic_encap_action is called
> > twice in group bucket use case, so look forward to your insights,
> > appriciate your feedback heartfeltly.
> > 
> > (gdb) bt
> > #0  xlate_generic_encap_action (encap=0x7ffd9458f460,
> > ctx=0x7ffd94590f30)
> > at ofproto/ofproto-dpif-xlate.c:5913
> > #1  do_xlate_actions (ofpacts=, ofpacts_len= > out>,
> > ctx=ctx@entry=0x7ffd94590f30,
> > is_last_action=is_last_action@entry=false)
> > at ofproto/ofproto-dpif-xlate.c:6499
> > #2  0x0074add0 in xlate_group_bucket
> > (ctx=ctx@entry=0x7ffd94590f30,
> > is_last_action=, bucket=0x2214f90, bucket=0x2214f90)
> > at ofproto/ofproto-dpif-xlate.c:4090
> > #3  0x00749ee4 in xlate_all_group (is_last_action=false,
> > group=0x2214bc0, ctx=0x7ffd94590f30) at
> > ofproto/ofproto-dpif-xlate.c:4150
> > #4  xlate_group_action__ (is_last_action=,
> > group=0x2214bc0,
> > ctx=0x7ffd94590f30) at ofproto/ofproto-dpif-xlate.c:4304
> > #5  xlate_group_action (is_last_action=,
> > group_id=, ctx=0x7ffd94590f30)
> > at ofproto/ofproto-dpif-xlate.c:4335
> > #6  do_xlate_actions (ofpacts=ofpacts@entry=0x2212558,
> > ofpacts_len=ofpacts_len@entry=8, ctx=ctx@entry=0x7ffd94590f30,
> > is_last_action=is_last_action@entry=true)
> > at ofproto/ofproto-dpif-xlate.c:6177
> > #7  0x00750041 in xlate_actions (xin=xin@entry=0x7ffd945919d0,
> > xout=xout@entry=0x7ffd94591dd0) at ofproto/ofproto-dpif-xlate.c:7090
> > #8  0x00741f00 in upcall_xlate (wc=0x7ffd94592ff8,
> > ---Type  to continue,

[ovs-dev] OVS will hit an assert if encap(nsh) is done in bucket of group

[Yang, Yi]

Hi, guys

A NSH user found OVS will hit the below assert in function
commit_set_nsh_action in file lib/odp-util.c if encap(nsh) is done in
bucket of group

ovs_assert(flow->nsh.mdtype == base_flow->nsh.mdtype &&
   flow->nsh.np == base_flow->nsh.np);

But it isn't an issue if encap(nsh) in actions=.

I debugged this issue but can't find the root cause, basically
xlate_generic_encap_action is called twice for a packet in different
code path in group bucket use case. one is upcall process, another one
is normal process in two code paths, gdb call stack dump is as followed.

The second call is obviously based on the result of the first call which
has been committed by xlate_commit_actions in first call
xlate_generic_encap_action, so flow->nsh.np will be set to NSH_P_NSH,
this is wrong, but it can work normally if I comment out the above
assert. I really don't know why xlate_generic_encap_action is called
twice in group bucket use case, so look forward to your insights,
appriciate your feedback heartfeltly.

(gdb) bt
#0  xlate_generic_encap_action (encap=0x7ffd9458f460,
ctx=0x7ffd94590f30)
at ofproto/ofproto-dpif-xlate.c:5913
#1  do_xlate_actions (ofpacts=, ofpacts_len=,
ctx=ctx@entry=0x7ffd94590f30,
is_last_action=is_last_action@entry=false)
at ofproto/ofproto-dpif-xlate.c:6499
#2  0x0074add0 in xlate_group_bucket
(ctx=ctx@entry=0x7ffd94590f30,
is_last_action=, bucket=0x2214f90, bucket=0x2214f90)
at ofproto/ofproto-dpif-xlate.c:4090
#3  0x00749ee4 in xlate_all_group (is_last_action=false,
group=0x2214bc0, ctx=0x7ffd94590f30) at
ofproto/ofproto-dpif-xlate.c:4150
#4  xlate_group_action__ (is_last_action=,
group=0x2214bc0,
ctx=0x7ffd94590f30) at ofproto/ofproto-dpif-xlate.c:4304
#5  xlate_group_action (is_last_action=,
group_id=, ctx=0x7ffd94590f30)
at ofproto/ofproto-dpif-xlate.c:4335
#6  do_xlate_actions (ofpacts=ofpacts@entry=0x2212558,
ofpacts_len=ofpacts_len@entry=8, ctx=ctx@entry=0x7ffd94590f30,
is_last_action=is_last_action@entry=true)
at ofproto/ofproto-dpif-xlate.c:6177
#7  0x00750041 in xlate_actions (xin=xin@entry=0x7ffd945919d0,
xout=xout@entry=0x7ffd94591dd0) at ofproto/ofproto-dpif-xlate.c:7090
#8  0x00741f00 in upcall_xlate (wc=0x7ffd94592ff8,
---Type  to continue, or q  to quit---
odp_actions=0x7ffd945927d0, upcall=0x7ffd94591d70, udpif=0x1805440)
at ofproto/ofproto-dpif-upcall.c:1162
#9  process_upcall (udpif=udpif@entry=0x1805440,
upcall=upcall@entry=0x7ffd94591d70,
odp_actions=odp_actions@entry=0x7ffd945927d0,
wc=wc@entry=0x7ffd94592ff8)
at ofproto/ofproto-dpif-upcall.c:1361
#10 0x0074244b in upcall_cb (packet=,
flow=0x7ffd94592d60, ufid=, pmd_id=,
type=, userdata=,
actions=0x7ffd945927d0,
wc=0x7ffd94592ff8, put_actions=0x7ffd94592810, aux=0x1805440)
at ofproto/ofproto-dpif-upcall.c:1263
#11 0x0076b2d6 in dp_netdev_upcall
(packet_=packet_@entry=0x2211680,
flow=flow@entry=0x7ffd94592d60, wc=wc@entry=0x7ffd94592ff8,
ufid=ufid@entry=0x7ffd945927b0, type=type@entry=DPIF_UC_MISS,
userdata=userdata@entry=0x0, actions=actions@entry=0x7ffd945927d0,
put_actions=put_actions@entry=0x7ffd94592810, pmd=,
pmd=) at lib/dpif-netdev.c:4868
#12 0x007725fd in handle_packet_upcall
(put_actions=0x7ffd94592810,
actions=0x7ffd945927d0, key=0x7ffd94593c40, packet=0x2211680,
pmd=0x18a3e90) at lib/dpif-netdev.c:5079
#13 fast_path_processing (pmd=pmd@entry=0x18a3e90,
packets_=packets_@entry=0x7ffd94593fa0,
keys=keys@entry=0x7ffd94593c40,
---Type  to continue, or q  to quit---
batches=batches@entry=0x7ffd94593ae0,
n_batches=n_batches@entry=0x7ffd94593f28, in_port=)
at lib/dpif-netdev.c:5187
#14 0x00772ea8 in dp_netdev_input__ (pmd=pmd@entry=0x18a3e90,
packets=packets@entry=0x7ffd94593fa0,
md_is_valid=md_is_valid@entry=false, port_no=port_no@entry=5)
at lib/dpif-netdev.c:5259
#15 0x0077310d in dp_netdev_input (port_no=5,
packets=0x7ffd94593fa0,
pmd=0x18a3e90) at lib/dpif-netdev.c:5287
#16 dp_netdev_process_rxq_port (pmd=pmd@entry=0x18a3e90, rxq=0x1d4f2a0,
port_no=5) at lib/dpif-netdev.c:3286
#17 0x00773b02 in dpif_netdev_run (dpif=)
at lib/dpif-netdev.c:3940
#18 0x00733a18 in type_run (type=)
at ofproto/ofproto-dpif.c:342
#19 0x0071f9cf in ofproto_type_run (datapath_type=,
datapath_type@entry=0x1d50ab0 "netdev") at ofproto/ofproto.c:1707
#20 0x0070f955 in bridge_run__ () at vswitchd/bridge.c:2931
#21 0x007153c8 in bridge_run () at vswitchd/bridge.c:2995
#22 0x00415485 in main (argc=5, argv=0x7ffd94594568)
at vswitchd/ovs-vswitchd.c:120
(gdb) bt
#0  xlate_generic_encap_action (encap=0x7ffd9458f478,
ctx=0x7ffd94590f30)
at ofproto/ofproto-dpif-xlate.c:5913
#1  do_xlate_actions (ofpacts=, ofpacts_len=,
ctx=ctx@entry=0x7ffd94590f30,
is_last_action=is_last_action@entry=false)
at ofproto/ofproto-dpif-xlate.c:6499
#2  

Re: [ovs-dev] when the physical compute receive vxlan-gpe-nsh packet whose size>256, the ovs flow table not match and ovs crash.

[Yang, Yi Y]

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 1/2] userspace datapath: Add GTP-U tunnel support

[Yang, Yi]

On Mon, Mar 05, 2018 at 04:19:58AM +0800, Joe Stringer wrote:
> ?On 2 March 2018 at 04:32, Yi Yang  wrote:
> > From: Feng Yang 
> >
> > +
> > +csum = csum_continue(csum, udp, ip_tot_size);
> > +udp->udp_csum = csum_finish(csum);
> > +
> > +if (!udp->udp_csum) {
> > +udp->udp_csum = htons(0x);
> 
> What's the motivation behind this?

More comments, this is from the existing ovs code, Feng checked why.

[Feng] According to the standard RFC768,
https://tools.ietf.org/html/rfc768, I quote, "if the computed  checksum
is zero,  it is transmitted  as all ones (the equivalent  in one's
complement  arithmetic)". Actually, netdev_tnl_udp_push_header( ) did
the same.

> 
> > +}
> > +}
> > +
> > +packet->packet_type = htonl(PT_ETH);
> > +}
> > +
> > +
> > +int
> > +netdev_gtpu_build_header(const struct netdev *netdev,
> > +  struct ovs_action_push_tnl *data,
> > +  const struct netdev_tnl_build_header_params 
> > *params)
> > +{
> > +struct netdev_vport *dev = netdev_vport_cast(netdev);
> > +struct netdev_tunnel_config *tnl_cfg;
> > +struct gtpuhdr *gtph;
> > +struct udp_header *udp;
> > +
> > +/* XXX: RCUfy tnl_cfg. */
> > +ovs_mutex_lock(>mutex);
> > +
> > +tnl_cfg = >tnl_cfg;
> > +udp = netdev_tnl_ip_build_header(data, params, IPPROTO_UDP);
> > +udp->udp_dst = tnl_cfg->dst_port;
> > +udp->udp_src = htons(GTPU_DST_PORT);
> > +
> > +if (params->is_ipv6 || params->flow->tunnel.flags & FLOW_TNL_F_CSUM) {
> > +/* Write a value in now to mark that we should compute the checksum
> > + * later. 0x is handy because it is transparent to the
> > + * calculation. */
> > +udp->udp_csum = htons(0x);
> 
> Maybe I missed it, but I didn't see where in this patch that it is
> computed later due to this value.
> 

This is also from the existing code. udp_build_header is doing same
thing.

[Feng]  udp_csum is calculated in netdev_gtpu_push_header( ). In
principle, udp_csum can be arbitrarily set to any two octets except all
zero, which means transmitter generated no checksum, according to the
standard, https://tools.ietf.org/html/rfc768.
We followed what udp_build_header( ) did, by setting udp_csum to 0x. 

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

Re: [ovs-dev] [PATCH v1 1/2] userspace datapath: Add GTP-U tunnel support

[Yang, Yi]

On Sun, Mar 04, 2018 at 09:59:18PM -0800, Joe Stringer wrote:
> On 4 March 2018 at 19:58, Yang, Yi <yi.y.y...@intel.com> wrote:
> > On Sun, Mar 04, 2018 at 07:40:49PM -0800, Joe Stringer wrote:
> >> On 4 March 2018 at 18:48, Yang, Yi <yi.y.y...@intel.com> wrote:
> >> > On Mon, Mar 05, 2018 at 04:19:58AM +0800, Joe Stringer wrote:
> >> >> ?On 2 March 2018 at 04:32, Yi Yang <yi.y.y...@intel.com> wrote:
> 
> > By the way, Feng said the existing GTP kernel implementation also didn't
> > implement GTP-C and didn't handle other optional flag bits.
> 
> Ah, okay. The thing I was thinking of was the way to configure a GTP
> socket to forward signalling traffic to a userspace process for
> handling:
> 
> https://www.kernel.org/doc/Documentation/networking/gtp.txt
>

Yeah, this is just why we are to handle signaling message here, we can
add Openflow rule to forward such message to local or remote userspace
process, per Feng's explanation, this signaling message will be output
to the GTP-U tunnel with different destination IP.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v1 1/2] userspace datapath: Add GTP-U tunnel support

[Yang, Yi]

On Sun, Mar 04, 2018 at 07:40:49PM -0800, Joe Stringer wrote:
> On 4 March 2018 at 18:48, Yang, Yi <yi.y.y...@intel.com> wrote:
> > On Mon, Mar 05, 2018 at 04:19:58AM +0800, Joe Stringer wrote:
> >> ?On 2 March 2018 at 04:32, Yi Yang <yi.y.y...@intel.com> wrote:
> >> > +goto err;
> >> > +}
> >> > +} else {
> >> > +/* tnl->gtpu_msgtype can identify if it is GTP-U message,
> >> > + * miniflow_extract won't parse it if tnl->gtpu_msgtype
> >> > + * isn't equal to GTPU_MSGTYPE_GPDU.
> >> > + */
> >> > +packet->packet_type = htonl(PT_UNKNOWN);
> >>
> >> This is where the limits of my GTP understanding will show, I was
> >> under the impression that GTP-U provides encapsulation for user
> >> traffic, so would commonly encapsulate IPv4/IPv6 inside. Whereas for
> >> GTP-C, it's signalling traffic so would not have such inner headers -
> >> it's supposed to be handled by a GTP implementation. Why is it
> >> important to be able to decapsulate GTP-C? Furthermore, what's
> >> ensuring that we don't end up spitting inner GTP-C packet data onto
> >> the wire without headers post-translation?
> >>
> > GTP-C is for control path, so I don't think it makes sense for OVS to
> > handle this, in addition GTP-C used different UDP port from GTP-U's, so
> > we must have different tunnel ports to handle them respectively.
> 
> Re: GTP-C in OVS, I'm inclined to agree that it doesn't make sense to
> be in OVS. There's a lot of complexity there and existing FOSS
> projects already attempt to support this, such as those under Osmocom.
> 
> The thing I was trying to highlight with the above comment is that
> this function appears to be attempting to handle both GTP-U and GTP-C,
> but if it doesn't make sense for OVS to handle it then I'm not sure
> why this code attempts to do so. I don't think that expecting people
> to just send the right kind of traffic on the designated ports (eg,
> GTP-U on the GTP-U port) is enough, these paths need to be resilient
> to unexpected input. Perhaps it's enough to restrict installation of
> flows with pop GTP actions based on presence of the appropriate GTP
> msgtype in the flow key.

GTP-U has two kinds of message types, normal GTP-U PDU and signaling
messages, so we have to handle signaling messages here, it isn't GTP-C,
http://www.3gpp.org/ftp/Specs/archive/29_series/29.281/29281-f10.zip
has detailed description.

By the way, Feng said the existing GTP kernel implementation also didn't
implement GTP-C and didn't handle other optional flag bits.

> 
> > I don't know if Jiannan has implemented GTP-C support in kernel data
> > path, we can add GTP-C support if it is really needed, but I think it is
> > a nice-to-have thing.
> 
> I believe there is some kind of implementation already in the kernel,
> but you'd have to take a look to see whether its design fits with what
> you're trying to do.
> 
> Cheers,
> Joe
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v1 1/2] userspace datapath: Add GTP-U tunnel support

[Yang, Yi]

On Mon, Mar 05, 2018 at 04:19:58AM +0800, Joe Stringer wrote:
> ?On 2 March 2018 at 04:32, Yi Yang  wrote:
> >
> > Signed-off-by: Feng Yang 
> > Signed-off-by: Yi Yang 
> > ---
> 
> Hi Yi, thanks for this work. Some minor comments below, but this is
> just a "drive-by" review. I hope that others with more experience with
> GTP will take a look as well.
> 
> I see the comment that there is locking on the device whenever a GTP
> header is built, I assume you intend to address that in a followup
> iteration.

Joe, thank for your comments, can you elaborate "there is locking on the
device whenever a GTP  header is built" with more details? I don't know
this, or there is any existing document for this? We'll fix it in next
iteration.

> 
> If you haven't already, it may be interesting to sync with Jiannan
> (CC'd) who has previously done some work on GTP support in OVS for
> kernel, to see whether the API (OpenFlow, OVSDB) makes sense for a
> cross-datapath (ie kernel AND userspace) implementation perspective.

Yes, sync is necessary, we contacted Jiannan before, I'll ping him to
check the status of his kernel patch, we'll make sure they can work well
together.

> 
> > diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
> > b/datapath/linux/compat/include/linux/openvswitch.h
> > index 84ebcaf..ad6ea64 100644
> > --- a/datapath/linux/compat/include/linux/openvswitch.h
> > +++ b/datapath/linux/compat/include/linux/openvswitch.h
> > @@ -236,6 +236,7 @@ enum ovs_vport_type {
> > OVS_VPORT_TYPE_GRE,  /* GRE tunnel. */
> > OVS_VPORT_TYPE_VXLAN,/* VXLAN tunnel. */
> > OVS_VPORT_TYPE_GENEVE,   /* Geneve tunnel. */
> > +   OVS_VPORT_TYPE_GTPU, /* GTPU tunnel. */
> > OVS_VPORT_TYPE_LISP = 105,  /* LISP tunnel */
> > OVS_VPORT_TYPE_STT = 106, /* STT tunnel */
> > __OVS_VPORT_TYPE_MAX
> > @@ -394,6 +395,8 @@ enum ovs_tunnel_key_attr {
> > OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS, /* Nested OVS_VXLAN_EXT_* */
> > OVS_TUNNEL_KEY_ATTR_IPV6_SRC,   /* struct in6_addr src IPv6 
> > address. */
> > OVS_TUNNEL_KEY_ATTR_IPV6_DST,   /* struct in6_addr dst IPv6 
> > address. */
> > +   OVS_TUNNEL_KEY_ATTR_GTPU_FLAGS, /* u8 GTP-U FLAGS. */
> > +   OVS_TUNNEL_KEY_ATTR_GTPU_MSGTYPE,   /* u8 GTP-U MSGTYPE. */
> > OVS_TUNNEL_KEY_ATTR_PAD,
> > __OVS_TUNNEL_KEY_ATTR_MAX
> >  };
> 
> The above changes have not been added to upstream linux header file,
> and the kernel uapi headers are the source of truth for these values.
> Please define them in such a way that they only apply to userspace so
> that we can prevent any potential conflict between expectations of
> meaning of these enums. I see common ways to achieve this have been to
> use `#ifndef __KERNEL__` conditional and by defining them as higher
> numbers that are less likely to conflict like the existing tunnel
> types.

Ok, will put them inside of `#ifndef __KERNEL__`.

> > +csum = packet_csum_pseudoheader6(
> > +   netdev_tnl_ipv6_hdr(dp_packet_data(packet)));
> > +} else {
> > +csum = packet_csum_pseudoheader(
> > +   netdev_tnl_ip_hdr(dp_packet_data(packet)));
> > +}
> > +
> > +csum = csum_continue(csum, udp, ip_tot_size);
> > +udp->udp_csum = csum_finish(csum);
> > +
> > +if (!udp->udp_csum) {
> > +udp->udp_csum = htons(0x);
> 
> What's the motivation behind this?

Feng, does this mean indicating protocol stack to ignore UDP checksum check?

> 
> > +}
> > +}
> > +
> > +packet->packet_type = htonl(PT_ETH);
> > +}
> > +
> > +
> > +int
> > +netdev_gtpu_build_header(const struct netdev *netdev,
> > +  struct ovs_action_push_tnl *data,
> > +  const struct netdev_tnl_build_header_params 
> > *params)
> > +{
> > +struct netdev_vport *dev = netdev_vport_cast(netdev);
> > +struct netdev_tunnel_config *tnl_cfg;
> > +struct gtpuhdr *gtph;
> > +struct udp_header *udp;
> > +
> > +/* XXX: RCUfy tnl_cfg. */
> > +ovs_mutex_lock(>mutex);
> > +
> > +tnl_cfg = >tnl_cfg;
> > +udp = netdev_tnl_ip_build_header(data, params, IPPROTO_UDP);
> > +udp->udp_dst = tnl_cfg->dst_port;
> > +udp->udp_src = htons(GTPU_DST_PORT);
> > +
> > +if (params->is_ipv6 || params->flow->tunnel.flags & FLOW_TNL_F_CSUM) {
> > +/* Write a value in now to mark that we should compute the checksum
> > + * later. 0x is handy because it is transparent to the
> > + * calculation. */
> > +udp->udp_csum = htons(0x);
> 
> Maybe I missed it, but I didn't see where in this patch that it is
> computed later due to this value.

Feng will check this.

> 
> > +}
> > +
> > +ovs_mutex_unlock(>mutex);
> > +data->header_len += sizeof *udp;
> > +
> > +gtph = 

Re: [ovs-dev] [PATCH v2 0/5] datapath: enable NSH support in kernel compat mode

[Yang, Yi]

On Thu, Feb 08, 2018 at 05:17:56AM +0800, Gregory Rose wrote:
> On 2/7/2018 10:46 AM, Ben Pfaff wrote:
> > On Fri, Feb 02, 2018 at 10:23:04AM -0800, Gregory Rose wrote:
> >> On 1/31/2018 5:53 AM, Yi Yang wrote:
> >>> v1->v2
> >>>   - Fix compilation error in linux-3.10.107
> >>>
> >>> 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.
> >>>
> >> Reviewed-by: Greg Rose 
> > Thanks Yi and Greg, I applied this to master.
> >
> > Should I backport to branch-2.9?
> We should get Yi's opinion as well but from my perspective I think just 
> applying to master is fine for now.
> Unless maybe there is some specific request from the community or a 
> partner.  It's only just present
> in the 4.15 kernel release which just came out.  I checked with the 
> lexer and it is not present in 4.14.
> 
> My two cents anyway...
> 
> Thanks,
> 
> - Greg

These kernel data path patches are just for old kernels, so I strongly
suggest they can be applied to branch-2.9, I saw NSH update patches have
been in branch-2.9, OVS 2.9 will be the first release which can
completely support NSH both in userspace and kernel datapath if this
patch series can be applied, many people are expecting this :-),
especially Opendaylight guys.

Please let me know if you have any problem on applying them to
branch-2.9.
___
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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
Cc: Gregory Rose <gvrose8...@gmail.com>; 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 +0000, 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 <yi.y.y...@intel.com>; 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
> 
> 
>

Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode

[Yang, Yi Y]

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 <yi.y.y...@intel.com>; 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 

Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode

[Yang, Yi Y]

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 <yi.y.y...@intel.com>; 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

[Yang, Yi Y]

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 v9 1/3] nsh: add new flow key 'ttl'

[Yang, Yi]

On Fri, Jan 12, 2018 at 03:50:17AM +0800, Ben Pfaff wrote:
> On Thu, Jan 11, 2018 at 01:24:01PM +0800, Yi Yang wrote:
> > IETF NSH draft added a new filed ttl in NSH header, this patch
> > is to add new nsh key 'ttl' for it.
> > 
> > Signed-off-by: Yi Yang 
> 
> Thanks, I applied this to master.
> 
> (Special thanks for the documentation update.)

Thanks Ben, I also posted NSH kernel modules patches, it will be perfect
if we can have them in OVS 2.9.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v8 3/3] nsh: add dec_nsh_ttl action

[Yang, Yi]

On Thu, Jan 11, 2018 at 07:02:29AM +0800, Ben Pfaff wrote:
> On Wed, Jan 10, 2018 at 02:52:00PM -0800, Ben Pfaff wrote:
> > On Tue, Jan 09, 2018 at 09:56:18PM +0800, Yi Yang wrote:
> > > NSH ttl is a 6-bit field ranged from 0 to 63, it should be
> > > decremented by 1 every hop, if it is 0 or it is so after
> > > decremented, the packet should be dropped and a packet-in
> > > message is sent to main controller.
> > > 
> > > Signed-off-by: Yi Yang 
> > 
> > This change is user-visible so it should add a NEWS item.
> 
> Oh, and I get several failures with the patches applied:
> 
> ## -- ##
> ## openvswitch 2.8.90 test suite. ##
> ## -- ##
> 
> 454: learning action - satisfied prerequisites   FAILED (learn.at:74)
> 452: learning action - parsing and formatting - OXM  FAILED (learn.at:42)
> 453: learning action - examples  FAILED (learn.at:58)
> 455: learning action - invalid prerequisites FAILED (learn.at:86)
> 450: learning action - parsing and formattingFAILED (learn.at:14)
> 456: learning action - too-long immediate value  FAILED (learn.at:106)
> 457: learning action - standard VLAN+MAC learningFAILED (learn.at:122)
> 460: learning action - TCPv6 port learning   FAILED (learn.at:277)
> 458: learning action - learn refreshes hard_age  FAILED (learn.at:191)
> 459: learning action - TCPv4 port learning   FAILED (learn.at:250)
> 461: learning action - self-modifying flow   FAILED (learn.at:306)
> 463: learning action - self-modifying flow with hard_timeout FAILED 
> (learn.at:406)
> 466: learning action - limit FAILED (learn.at:635)
> 465: learning action - delete_learned featureFAILED (learn.at:522)
> 464: learning action - fin_timeout feature   FAILED (learn.at:502)
> 462: learning action - self-modifying flow with idle_timeout FAILED 
> (learn.at:348)
> 467: learning action - limit result_dst  FAILED (learn.at:674)
> 468: learning action - different limits  FAILED (learn.at:721)
> 1187: ofproto-dpif megaflow - learningFAILED 
> (ofproto-dpif.at:7974)
> 1077: ofproto-dpif - MPLS handlingFAILED 
> (ofproto-dpif.at:1760)
> 1094: ofproto-dpif - fragment handling - actions  FAILED 
> (ofproto-dpif.at:4118)
> 999: ofproto - flow mod with tunnel metadata FAILED (ofproto.at:5987)
> 786: tunnel - Geneve metadataFAILED (tunnel.at:582)
> 939: ofproto - table features (OpenFlow 1.3) FAILED (ofproto.at:2607)
> 2326: ovn -- vtep: 3 HVs, 1 VIFs/HV, 1 GW, 1 LS   FAILED (ovn.at:2031)
> 
> ## - ##
> ## Test results. ##
> ## - ##
> 
> ERROR: All 25 tests were run,
> 25 failed unexpectedly.
> ## -- ##
> ## testsuite.log was created. ##
> ## -- ##
> 
> Please send `tests/testsuite.log' and all information you think might help:
> 
>To: 
>Subject: [openvswitch 2.8.90] testsuite: 450 452 453 454 455 456 457 458 
> 459 460 461 462 463 464 465 466 467 468 786 939 999 1077 1094 1187 2326 failed

All these unit tests failures are led by "939: ofproto - table features
(OpenFlow 1.3)", the first patch in v9 has fixed it.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v8 3/3] nsh: add dec_nsh_ttl action

[Yang, Yi]

On Thu, Jan 11, 2018 at 06:52:00AM +0800, Ben Pfaff wrote:
> On Tue, Jan 09, 2018 at 09:56:18PM +0800, Yi Yang wrote:
> > NSH ttl is a 6-bit field ranged from 0 to 63, it should be
> > decremented by 1 every hop, if it is 0 or it is so after
> > decremented, the packet should be dropped and a packet-in
> > message is sent to main controller.
> > 
> > Signed-off-by: Yi Yang 
> 
> This change is user-visible so it should add a NEWS item.

Added NEWS item in v9, thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v8 1/3] nsh: add new flow key 'ttl'

[Yang, Yi]

On Thu, Jan 11, 2018 at 06:50:35AM +0800, Ben Pfaff wrote:
> On Tue, Jan 09, 2018 at 09:56:16PM +0800, Yi Yang wrote:
> > IETF NSH draft added a new filed ttl in NSH header, this patch
> > is to add new nsh key 'ttl' for it.
> > 
> > Signed-off-by: Yi Yang 
> 
> Thanks for the revision!
> 
> This breaks a test:
> 
> 939: ofproto - table features (OpenFlow 1.3) FAILED (ofproto.at:2607)
> 
> This change is user-visible so it should have a NEWS item.
> 
> I'm appending some suggested minor improvements.

Fixed them and applied it in v7 and sent out v7 to ovs mailing list, thanks a 
lot.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v7 4/4] nsh: add dec_nsh_ttl action

[Yang, Yi]

On Tue, Jan 09, 2018 at 08:14:07AM +0800, Ben Pfaff wrote:
> On Sat, Jan 06, 2018 at 01:47:54PM +0800, Yi Yang wrote:
> > NSH ttl is a 6-bit field ranged from 0 to 63, it should be
> > decremented by 1 every hop, if it is 0 or it is so after
> > decremented, the packet should be dropped and a packet-in
> > message is sent to main controller.
> > 
> > Signed-off-by: Yi Yang 
> 
> This introduces lots of sparse warnings:
> 
> ../include/openvswitch/nsh.h:314:14: warning: cast to restricted ovs_be32
> ../include/openvswitch/nsh.h:314:14: warning: cast from restricted ovs_be16
> ../include/openvswitch/nsh.h:314:14: warning: restricted ovs_be32 degrades to 
> integer
> ../include/openvswitch/nsh.h:314:40: warning: cast to restricted ovs_be32
> ../include/openvswitch/nsh.h:314:40: warning: cast from restricted ovs_be16
> ../include/openvswitch/nsh.h:314:40: warning: restricted ovs_be32 degrades to 
> integer
> ../include/openvswitch/nsh.h:314:37: warning: incorrect type in return 
> expression (different base types)
> ../include/openvswitch/nsh.h:314:37:expected restricted ovs_be32
> ../include/openvswitch/nsh.h:314:37:got unsigned int
> ../include/openvswitch/nsh.h:327:30: warning: incorrect type in initializer 
> (different base types)
> ../include/openvswitch/nsh.h:327:30:expected restricted ovs_be32 
> [usertype] path_hdr
> ../include/openvswitch/nsh.h:327:30:got unsigned int
> ../include/openvswitch/nsh.h:328:19: warning: restricted ovs_be32 degrades to 
> integer
> ../include/openvswitch/nsh.h:314:14: warning: cast to restricted ovs_be32
> ../include/openvswitch/nsh.h:314:14: warning: cast from restricted ovs_be16
> ../include/openvswitch/nsh.h:314:14: warning: restricted ovs_be32 degrades to 
> integer
> ../include/openvswitch/nsh.h:314:40: warning: cast to restricted ovs_be32
> ../include/openvswitch/nsh.h:314:40: warning: cast from restricted ovs_be16
> ../include/openvswitch/nsh.h:314:40: warning: restricted ovs_be32 degrades to 
> integer
> ../include/openvswitch/nsh.h:314:37: warning: incorrect type in return 
> expression (different base types)
> ../include/openvswitch/nsh.h:314:37:expected restricted ovs_be32
> ../include/openvswitch/nsh.h:314:37:got unsigned int
> ../include/openvswitch/nsh.h:334:30: warning: incorrect type in initializer 
> (different base types)
> ../include/openvswitch/nsh.h:334:30:expected restricted ovs_be32 
> [usertype] path_hdr
> ../include/openvswitch/nsh.h:334:30:got unsigned int
> ../include/openvswitch/nsh.h:335:13: warning: restricted ovs_be32 degrades to 
> integer
> ../include/openvswitch/nsh.h:314:14: warning: cast to restricted ovs_be32
> ../include/openvswitch/nsh.h:314:14: warning: cast from restricted ovs_be16
> ../include/openvswitch/nsh.h:314:14: warning: restricted ovs_be32 degrades to 
> integer
> ../include/openvswitch/nsh.h:314:40: warning: cast to restricted ovs_be32
> ../include/openvswitch/nsh.h:314:40: warning: cast from restricted ovs_be16
> ../include/openvswitch/nsh.h:314:40: warning: restricted ovs_be32 degrades to 
> integer
> ../include/openvswitch/nsh.h:314:37: warning: incorrect type in return 
> expression (different base types)
> ../include/openvswitch/nsh.h:314:37:expected restricted ovs_be32
> ../include/openvswitch/nsh.h:314:37:got unsigned int

They are introduced in patch #2, v8 has fixed them and posted in mailing
list, please review new ones, thanks.

> 
> Thanks,
> 
> Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v7 2/4] nsh: add new flow key 'ttl'

[Yang, Yi]

On Tue, Jan 09, 2018 at 08:11:15AM +0800, Ben Pfaff wrote:
> On Sat, Jan 06, 2018 at 01:47:52PM +0800, Yi Yang wrote:
> > IETF NSH draft added a new filed ttl in NSH header, this patch
> > is to add new nsh key 'ttl' for it.
> > 
> > Signed-off-by: Yi Yang 
> 
> Thanks for v7!
> 
> The field assignments in meta-flow.h seem wrong to me:
> 
> - The TTL field is new in v2.9, so it shouldn't say v2.8.
> 
> - The existing fields should not be renumbered because that
>   breaks OpenFlow wire format compatibility with anything that
>   already knows how to talk to OVS 2.8.  Please keep the
>   existing numbering.
> 
> Why does nsh_16aligned_be32 exist?  Please use get_16aligned_be32, which
> is identical.

I want to keep include/openvswitch/nsh.h consistent as possible as nsh.h in
kernel, it is not good to depend on lib/unaligned.h because it is only used
in lib/*, I have fixed sparse warnings.

> 
> In meta-flow.xml, please properly document the NSH fields, following the
> pattern set by the other documentation in the file.
> 
> I see several uses of memcpy() for copying a struct.  Please use an
> assignment to copy structs.
> 
> This statement looks suspicious, since the target and the "sizeof" are
> different:
> memset(nsh, 0, sizeof(nsh->context));
> 
> I'm concerned about how this patch introduces different structs with
> identical layouts and then uses memcpy() to copy between them.  This is
> a trap for unsuspecting developers who change one structure or the other
> (even by reordering fields).  It would probably be better to figure out
> a way to either use the same struct in each case, or to do
> member-by-member copies.  Another way would be to use assertions to make
> sure that the structures really are identical.

Your concerns make sense, I use assignments for them. v8 has been
posted, please review new ones. Thanks a lot.

> 
> Thanks,
> 
> Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v6 1/4] nsh: rework NSH netlink keys and actions

[Yang, Yi]

On Fri, Jan 05, 2018 at 04:42:00AM +0800, Ben Pfaff wrote:
> On Fri, Dec 08, 2017 at 10:04:22PM +0800, Yi Yang wrote:
> > 
> > Signed-off-by: Yi Yang 
> 
> 
> In odp_execute_actions(), this looks bogus: there is nothing to
> guarantee that 'buffer' is properly aligned for struct nsh_hdr.
> +uint8_t buffer[NSH_HDR_MAX_LEN];
> +struct nsh_hdr *nsh_hdr = ALIGNED_CAST(struct nsh_hdr *, buffer);
> 
> Similarly in format_odp_action().
> 

Ben, do you mean buffer isn't 4 bytes aligned? I redefine it as
"uint32_t buffer[NSH_HDR_MAX_LEN / 4];", it is enough for struct nsh_hdr to
align to 4 bytes boundary.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v6 1/4] nsh: rework NSH netlink keys and actions

[Yang, Yi]

On Fri, Jan 05, 2018 at 04:42:00AM +0800, Ben Pfaff wrote:
> On Fri, Dec 08, 2017 at 10:04:22PM +0800, Yi Yang wrote:
> > Signed-off-by: Yi Yang 
> 
> This fails to build with Clang (and, I would guess, MSVC):
> ../lib/odp-execute.c:497:21: error: fields must have a constant size: 
> 'variable length array in structure' extension will never be supported
> 
> "sparse" issues some warnings.  This one is probably sensible:
> ../lib/odp-util.c:1884:32: warning: incorrect type in argument 1 
> (different base types)
> ../lib/odp-util.c:1884:32:expected unsigned int [unsigned] [usertype] 
> x
> ../lib/odp-util.c:1884:32:got restricted ovs_be32 [assigned] 
> [usertype] spi
> 
> These I don't understand.
> https://marc.info/?l=linux-sparse=110218288411207 suggests that they
> might be a sparse bug:
> 
> ../lib/odp-util.c:7123:32: warning: crazy programmer
> ../lib/odp-util.c:7123:43: warning: crazy programmer
> ../lib/odp-util.c:7123:22: warning: crazy programmer
> 
> In odp_execute_actions(), this looks bogus: there is nothing to
> guarantee that 'buffer' is properly aligned for struct nsh_hdr.
> +uint8_t buffer[NSH_HDR_MAX_LEN];
> +struct nsh_hdr *nsh_hdr = ALIGNED_CAST(struct nsh_hdr *, buffer);
> 
> Similarly in format_odp_action().
> 
> In nsh_key_to_attr(), can this:
> +for (int i = 0; i < 4; i++) {
> +md1.context[i] = nsh->context[i];
> +}
> +nl_msg_put_unspec(buf, OVS_NSH_KEY_ATTR_MD1, , sizeof md1);
> be written as just this?
> +nl_msg_put_unspec(buf, OVS_NSH_KEY_ATTR_MD1, nsh->context,
> +  sizeof nsh->context);
> and similarly in a second place.
> 
> In parse_odp_push_nsh_action(), the idea of xmalloc()'ing a stub is
> weird.  A stub should be a local array.  There are many examples in the
> tree.
> 
> Please don't check a pointer for null before calling free():
> +if (metadata != NULL) {
> +free(metadata);
>  }

Thanks, Ben, I have posted v7
https://mail.openvswitch.org/pipermail/ovs-dev/2018-January/342698.html
to fix the above issues.

By the way, what command do you run to do static code analysis by sparse?
"make clang-analyze" will have too much warnings. I can't get sparse
warnings, it will be better if I can run it locally.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v6 0/4] nsh: add new nsh key ttl and action dec_nsh_ttl

[Yang, Yi]

On Tue, Dec 12, 2017 at 03:15:49AM +0800, Gregory Rose wrote:
> On 12/11/2017 10:55 AM, Ben Pfaff wrote:
> > On Mon, Dec 11, 2017 at 10:25:54AM -0800, Gregory Rose wrote:
> >> On 12/10/2017 4:39 PM, Yang, Yi wrote:
> >>> On Sat, Dec 09, 2017 at 12:42:32AM +0800, Gregory Rose wrote:
> >>>> On 12/8/2017 6:04 AM, Yi Yang wrote:
> >>>>> v5->v6
> >>>>> - Rebase v5 to master
> >>>>> - Refactor netlink message format to align to NSH kernel
> >>>>>   implementation
> >>>>> - Add dec_nsh_ttl unit test into tests/nsh.at
> >>>>> - Fix unit test unstable issue
> >>>>>
> >>>> I don't see any backport of the upstream kernel datapath changes? I'm
> >>>> working on catching our out of tree datapath code with the upstream
> >>>> Linux kernel datapath and your patch (commit
> >>>> b2d0f5d5dc53532e6f07bc546a476a55ebdfe0f3 " openvswitch: enable NSH
> >>>> support") needs the backport as well as compat layer changes.
> >>>>
> >>>> Do you plan on doing that work?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> - Greg
> >>> Greg, yes, I'll backport kernel datapath patches once this patch series
> >>> is merged. BTW this doesn't depend on the kernel datapath patches.
> >> Understood that this series of patches  you sent does not require the 
> >> kernel
> >> datapath backport
> >> but I found that the kernel datapath patches do modify the openvswitch uapi
> >> header and adds
> >> new switch cases.  These need to be handled eventually which can be done
> >> when you do the
> >> backport.
> > Greg and Yi, can you help me understand the compatibility and patch
> > workflow implications of accepting this series now instead of after the
> > kernel datapath backport?  In your opinions, is it important to apply
> > them in a particular order?
> 
> Ben,
> 
> I started backporting the upstream NSH patch from Yi and found that I 
> had to make some
> related user space changes to make it compile correctly.  So it would 
> appear that the upstream
> kernel patch would require this set of patches first.
> 
> That said, let's get Yi's response since he is far more familiar with 
> the NSH work than I am.
> 
> Thanks,
> 
> - Greg
>

We need to apply this patch series first, we do need to change some
header files when we backport NSH kernel patch, this is inevitable
, we only can support NSH userspace in current OVS. After applying
this patch series, NSH kernel backport patches will make sure both
userspace and kernel data path can work.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v6 0/4] nsh: add new nsh key ttl and action dec_nsh_ttl

[Yang, Yi]

On Sat, Dec 09, 2017 at 12:42:32AM +0800, Gregory Rose wrote:
> On 12/8/2017 6:04 AM, Yi Yang wrote:
> > v5->v6
> >- Rebase v5 to master
> >- Refactor netlink message format to align to NSH kernel
> >  implementation
> >- Add dec_nsh_ttl unit test into tests/nsh.at
> >- Fix unit test unstable issue
> >
> 
> I don't see any backport of the upstream kernel datapath changes? I'm 
> working on catching our out of tree datapath code with the upstream 
> Linux kernel datapath and your patch (commit 
> b2d0f5d5dc53532e6f07bc546a476a55ebdfe0f3 " openvswitch: enable NSH 
> support") needs the backport as well as compat layer changes.
> 
> Do you plan on doing that work?
> 
> Thanks,
> 
> - Greg

Greg, yes, I'll backport kernel datapath patches once this patch series
is merged. BTW this doesn't depend on the kernel datapath patches.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v15] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Nov 07, 2017 at 05:01:28AM -0800, Pravin Shelar wrote:
> On Tue, Nov 7, 2017 at 3:55 AM, Yang, Yi <yi.y.y...@intel.com> wrote:
> > On Tue, Nov 07, 2017 at 03:58:35AM -0800, Pravin Shelar wrote:
> >> On Tue, Nov 7, 2017 at 3:28 AM, Yang, Yi <yi.y.y...@intel.com> wrote:
> >> > On Tue, Nov 07, 2017 at 06:57:30PM +0800, Pravin Shelar wrote:
> >> >> On Mon, Nov 6, 2017 at 4:22 AM, Jiri Benc <jb...@redhat.com> wrote:
> >> >> > On Sat, 4 Nov 2017 07:29:46 -0700, Pravin Shelar wrote:
> >> >> >> > +   if (skb->mac_len) {
> >> >> >> > +   next_proto = TUN_P_ETHERNET;
> >> >> >> > +   } else {
> >> >> >> > +   next_proto = tun_p_from_eth_p(skb->protocol);
> >> >> >> > +   if (!next_proto)
> >> >> >> > +   return -EAFNOSUPPORT;
> >> >> >> check for supported protocols can be moved to flow install validation
> >> >> >> in __ovs_nla_copy_actions().
> >> >> >
> >> >> > You mean the check for !next_proto? It needs to be present for
> >> >> > correctness of nsh_push. This function has to be self contained, it
> >> >> > will be used by more callers than opevswitch, namely tc.
> >> >> >
> >> >> > It's actually not so much a check for "supported protocols", it's
> >> >> > rather a check of return value of a function that converts ethertype 
> >> >> > to
> >> >> > a 1 byte tunnel type. Blindly using a result of a function that may
> >> >> > return error would be wrong. Openvswitch is free to perform additional
> >> >> > checks but this needs to stay.
> >> >> >
> >> >> I am not disputing validity of the checks, but it could be done at
> >> >> flow install phase.
> >> >> For other use case we could refactor code. If it is too complex, I am
> >> >> fine with duplicate code that check the protocol in flow install for
> >> >> now.
> >> >
> >> > Ok, I'll add check code in __ovs_nla_copy_actions for both nsh_push and
> >> > nsh_pop, but how can we get value of skb->protocol in
> >> > __ovs_nla_copy_actions? Is it argument eth_type of
> >> > __ovs_nla_copy_actions?
> >> >
> >> Yes.
> >
> > So here is newly-added check code, is it ok?
> >
> > diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> > index fa07a17..b64b754 100644
> > --- a/net/openvswitch/flow_netlink.c
> > +++ b/net/openvswitch/flow_netlink.c
> > @@ -3001,20 +3001,34 @@ static int __ovs_nla_copy_actions(struct net *net, 
> > const struct nlattr *attr,
> > mac_proto = MAC_PROTO_ETHERNET;
> > break;
> >
> > -   case OVS_ACTION_ATTR_PUSH_NSH:
> > +   case OVS_ACTION_ATTR_PUSH_NSH: {
> > +   u8 next_proto;
> > +
> next_proto can be moved to the if () block, otherwise, I am fine with
> this change.

Thanks, fixed it and sent out v17.

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

Re: [ovs-dev] [PATCH net-next v15] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Nov 07, 2017 at 03:58:35AM -0800, Pravin Shelar wrote:
> On Tue, Nov 7, 2017 at 3:28 AM, Yang, Yi <yi.y.y...@intel.com> wrote:
> > On Tue, Nov 07, 2017 at 06:57:30PM +0800, Pravin Shelar wrote:
> >> On Mon, Nov 6, 2017 at 4:22 AM, Jiri Benc <jb...@redhat.com> wrote:
> >> > On Sat, 4 Nov 2017 07:29:46 -0700, Pravin Shelar wrote:
> >> >> > +int nsh_push(struct sk_buff *skb, const struct nshhdr *pushed_nh)
> >> >> > +{
> >> >> > +   struct nshhdr *nh;
> >> >> > +   size_t length = nsh_hdr_len(pushed_nh);
> >> >> > +   u8 next_proto;
> >> >> > +
> >> >> > +   if (skb->mac_len) {
> >> >> > +   next_proto = TUN_P_ETHERNET;
> >> >> > +   } else {
> >> >> > +   next_proto = tun_p_from_eth_p(skb->protocol);
> >> >> > +   if (!next_proto)
> >> >> > +   return -EAFNOSUPPORT;
> >> >> check for supported protocols can be moved to flow install validation
> >> >> in __ovs_nla_copy_actions().
> >> >
> >> > You mean the check for !next_proto? It needs to be present for
> >> > correctness of nsh_push. This function has to be self contained, it
> >> > will be used by more callers than opevswitch, namely tc.
> >> >
> >> > It's actually not so much a check for "supported protocols", it's
> >> > rather a check of return value of a function that converts ethertype to
> >> > a 1 byte tunnel type. Blindly using a result of a function that may
> >> > return error would be wrong. Openvswitch is free to perform additional
> >> > checks but this needs to stay.
> >> >
> >> I am not disputing validity of the checks, but it could be done at
> >> flow install phase.
> >> For other use case we could refactor code. If it is too complex, I am
> >> fine with duplicate code that check the protocol in flow install for
> >> now.
> >
> > Ok, I'll add check code in __ovs_nla_copy_actions for both nsh_push and
> > nsh_pop, but how can we get value of skb->protocol in
> > __ovs_nla_copy_actions? Is it argument eth_type of
> > __ovs_nla_copy_actions?
> >
> Yes.

So here is newly-added check code, is it ok?

diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index fa07a17..b64b754 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -3001,20 +3001,34 @@ static int __ovs_nla_copy_actions(struct net *net, 
const struct nlattr *attr,
mac_proto = MAC_PROTO_ETHERNET;
break;
 
-   case OVS_ACTION_ATTR_PUSH_NSH:
+   case OVS_ACTION_ATTR_PUSH_NSH: {
+   u8 next_proto;
+
+   if (mac_proto != MAC_PROTO_ETHERNET) {
+   next_proto = tun_p_from_eth_p(eth_type);
+   if (!next_proto)
+   return -EINVAL;
+   }
mac_proto = MAC_PROTO_NONE;
if (!validate_nsh(nla_data(a), false, true, true))
return -EINVAL;
break;
+   }
+
+   case OVS_ACTION_ATTR_POP_NSH: {
+   __be16 inner_proto;
 
-   case OVS_ACTION_ATTR_POP_NSH:
if (eth_type != htons(ETH_P_NSH))
return -EINVAL;
+   inner_proto = tun_p_to_eth_p(key->nsh.base.np);
+   if (!inner_proto)
+   return -EINVAL;
if (key->nsh.base.np == TUN_P_ETHERNET)
mac_proto = MAC_PROTO_ETHERNET;
else
mac_proto = MAC_PROTO_NONE;
break;
+   }
 
default:
OVS_NLERR(log, "Unknown Action type %d", type);
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v15] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Nov 07, 2017 at 06:57:30PM +0800, Pravin Shelar wrote:
> On Mon, Nov 6, 2017 at 4:22 AM, Jiri Benc  wrote:
> > On Sat, 4 Nov 2017 07:29:46 -0700, Pravin Shelar wrote:
> >> > +int nsh_push(struct sk_buff *skb, const struct nshhdr *pushed_nh)
> >> > +{
> >> > +   struct nshhdr *nh;
> >> > +   size_t length = nsh_hdr_len(pushed_nh);
> >> > +   u8 next_proto;
> >> > +
> >> > +   if (skb->mac_len) {
> >> > +   next_proto = TUN_P_ETHERNET;
> >> > +   } else {
> >> > +   next_proto = tun_p_from_eth_p(skb->protocol);
> >> > +   if (!next_proto)
> >> > +   return -EAFNOSUPPORT;
> >> check for supported protocols can be moved to flow install validation
> >> in __ovs_nla_copy_actions().
> >
> > You mean the check for !next_proto? It needs to be present for
> > correctness of nsh_push. This function has to be self contained, it
> > will be used by more callers than opevswitch, namely tc.
> >
> > It's actually not so much a check for "supported protocols", it's
> > rather a check of return value of a function that converts ethertype to
> > a 1 byte tunnel type. Blindly using a result of a function that may
> > return error would be wrong. Openvswitch is free to perform additional
> > checks but this needs to stay.
> >
> I am not disputing validity of the checks, but it could be done at
> flow install phase.
> For other use case we could refactor code. If it is too complex, I am
> fine with duplicate code that check the protocol in flow install for
> now.

Ok, I'll add check code in __ovs_nla_copy_actions for both nsh_push and
nsh_pop, but how can we get value of skb->protocol in
__ovs_nla_copy_actions? Is it argument eth_type of
__ovs_nla_copy_actions?
 
> 
> >> > +int nsh_pop(struct sk_buff *skb)
> >> > +{
> >> > +   struct nshhdr *nh;
> >> > +   size_t length;
> >> > +   __be16 inner_proto;
> >> > +
> >> > +   if (!pskb_may_pull(skb, NSH_BASE_HDR_LEN))
> >> > +   return -ENOMEM;
> >> > +   nh = (struct nshhdr *)(skb->data);
> >> > +   length = nsh_hdr_len(nh);
> >> > +   inner_proto = tun_p_to_eth_p(nh->np);
> >> same as above, this check can be moved to flow install 
> >> __ovs_nla_copy_actions().
> >
> > There's no check here.
> >
> >> > +   if (!pskb_may_pull(skb, length))
> >> > +   return -ENOMEM;
> >> > +
> >> > +   if (!inner_proto)
> >> > +   return -EAFNOSUPPORT;
> >
> > Did you mean this one instead? Then see above, this has to stay.
> >
> >  Jiri
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] nsh: Fix packet format to match IETF NSH draft.

[Yang, Yi]

On Thu, Nov 02, 2017 at 04:51:52AM +0800, Ben Pfaff wrote:
> The NSH draft added a TTL field.  This adds basic support.
> 
> CC: Yi Yang 
> CC: Jan Scheurich 
> Signed-off-by: Ben Pfaff 
> ---
>  include/openvswitch/nsh.h | 11 +++
>  lib/flow.c|  2 +-
>  lib/odp-execute.c | 10 +-
>  lib/packets.c |  4 +++-
>  4 files changed, 16 insertions(+), 11 deletions(-)
> 
> diff --git a/include/openvswitch/nsh.h b/include/openvswitch/nsh.h
> index a3611d0896b2..4d83bad1af81 100644
> --- a/include/openvswitch/nsh.h
> +++ b/include/openvswitch/nsh.h
> @@ -62,7 +62,7 @@ struct nsh_md2_tlv {
>  };
>  
>  struct nsh_hdr {
> -ovs_be16 ver_flags_len;
> +ovs_be16 ver_flags_ttl_len;
>  uint8_t md_type;
>  uint8_t next_proto;
>  ovs_16aligned_be32 path_hdr;
> @@ -75,8 +75,10 @@ struct nsh_hdr {
>  /* Masking NSH header fields. */
>  #define NSH_VER_MASK   0xc000
>  #define NSH_VER_SHIFT  14
> -#define NSH_FLAGS_MASK 0x3fc0
> -#define NSH_FLAGS_SHIFT6
> +#define NSH_FLAGS_MASK 0x3000
> +#define NSH_FLAGS_SHIFT12
> +#define NSH_TTL_MASK   0x0fc0
> +#define NSH_TTL_SHIFT  6
>  #define NSH_LEN_MASK   0x003f
>  #define NSH_LEN_SHIFT  0
>  
> @@ -113,7 +115,8 @@ struct nsh_hdr {
>  static inline uint16_t
>  nsh_hdr_len(const struct nsh_hdr *nsh)
>  {
> -return ((ntohs(nsh->ver_flags_len) & NSH_LEN_MASK) >> NSH_LEN_SHIFT) << 
> 2;
> +return ((ntohs(nsh->ver_flags_ttl_len) & NSH_LEN_MASK)
> +>> NSH_LEN_SHIFT) << 2;
>  }
>  
>  static inline struct nsh_md1_ctx *
> diff --git a/lib/flow.c b/lib/flow.c
> index 4d2b7747a124..57b6c597d207 100644
> --- a/lib/flow.c
> +++ b/lib/flow.c
> @@ -546,7 +546,7 @@ parse_nsh(const void **datap, size_t *sizep, struct 
> flow_nsh *key)
>  
>  memset(key, 0, sizeof(struct flow_nsh));
>  
> -ver_flags_len = ntohs(nsh->ver_flags_len);

Rename ver_flags_len to ver_flags_ttl_len.

Do we need to consider new ttl key in this patch?

> +ver_flags_len = ntohs(nsh->ver_flags_ttl_len);
>  version = (ver_flags_len & NSH_VER_MASK) >> NSH_VER_SHIFT;
>  flags = (ver_flags_len & NSH_FLAGS_MASK) >> NSH_FLAGS_SHIFT;
>  
> diff --git a/lib/odp-execute.c b/lib/odp-execute.c
> index 5f4d23a91a3e..d5542bde8b02 100644
> --- a/lib/odp-execute.c
> +++ b/lib/odp-execute.c
> @@ -279,8 +279,8 @@ odp_set_nsh(struct dp_packet *packet, const struct 
> ovs_key_nsh *key,
>  struct nsh_hdr *nsh = dp_packet_l3(packet);
>  
>  if (!mask) {
> -nsh->ver_flags_len = htons(key->flags << NSH_FLAGS_SHIFT) |
> - (nsh->ver_flags_len & ~htons(NSH_FLAGS_MASK));
> +nsh->ver_flags_ttl_len = htons(key->flags << NSH_FLAGS_SHIFT) |
> +(nsh->ver_flags_ttl_len & ~htons(NSH_FLAGS_MASK));
>  put_16aligned_be32(>path_hdr, key->path_hdr);
>  switch (nsh->md_type) {
>  case NSH_M_TYPE1:
> @@ -294,11 +294,11 @@ odp_set_nsh(struct dp_packet *packet, const struct 
> ovs_key_nsh *key,
>  break;
>  }
>  } else {
> -uint8_t flags = (ntohs(nsh->ver_flags_len) & NSH_FLAGS_MASK) >>
> +uint8_t flags = (ntohs(nsh->ver_flags_ttl_len) & NSH_FLAGS_MASK) >>
>  NSH_FLAGS_SHIFT;
>  flags = key->flags | (flags & ~mask->flags);
> -nsh->ver_flags_len = htons(flags << NSH_FLAGS_SHIFT) |
> - (nsh->ver_flags_len & ~htons(NSH_FLAGS_MASK));
> +nsh->ver_flags_ttl_len = htons(flags << NSH_FLAGS_SHIFT) |
> +(nsh->ver_flags_ttl_len & ~htons(NSH_FLAGS_MASK));
>  
>  ovs_be32 path_hdr = get_16aligned_be32(>path_hdr);
>  path_hdr = key->path_hdr | (path_hdr & ~mask->path_hdr);
> diff --git a/lib/packets.c b/lib/packets.c
> index 74d87eda89e1..a26b6c33e41c 100644
> --- a/lib/packets.c
> +++ b/lib/packets.c
> @@ -427,7 +427,9 @@ encap_nsh(struct dp_packet *packet, const struct 
> ovs_action_encap_nsh *encap)
>  }
>  
>  nsh = (struct nsh_hdr *) dp_packet_push_uninit(packet, length);
> -nsh->ver_flags_len = htons(encap->flags << NSH_FLAGS_SHIFT | length >> 
> 2);
> +nsh->ver_flags_ttl_len = htons((encap->flags << NSH_FLAGS_SHIFT)
> +   | (63 << NSH_TTL_SHIFT)
> +   | ((length >> 2) << NSH_LEN_SHIFT));
>  nsh->next_proto = next_proto;
>  put_16aligned_be32(>path_hdr, encap->path_hdr);
>  nsh->md_type = encap->mdtype;
> -- 
> 2.10.2
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v5 1/2] nsh: add new flow key 'ttl'

[Yang, Yi]

On Thu, Nov 02, 2017 at 04:53:15AM +0800, Ben Pfaff wrote:
> On Wed, Aug 30, 2017 at 02:21:01AM +0800, Yi Yang wrote:
> > IETF NSH draft will be approved by end of August, NSH header
> > format has been finalized and won't be change anymore, so we
> > need to follow this final spec to implement nsh.
> > 
> > kernel data path also needs finalized uAPIs, they can't be
> > changed once they are merged.
> > 
> > This patch adds new nsh key 'ttl', bits of flags and mdtype
> > fields are also changed to follow the final spec.
> > 
> > A new action dec_nsh_ttl will be added in the following patch.
> > 
> > Signed-off-by: Yi Yang 
> 
> It's time to take another look at NSH, by adding support for the latest
> draft.  I posted a patch to kick this off:
> 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-November/340365.html
> 
> This is the sort of patch that could be backported to 2.8 if that is
> desirable.
> 
> After we get the protocol format fixed, I suggest rebasing and reposting
> these patches so that we can get enhanced support into 2.9.
> 
> Thanks,

Ben, no problem, NSH kernel patch will be merged very soon, after that
I'll rework this patch series, netlink message format for OVS_KEY_ATTR_NSH
has big change per kernel requirement, so userspace part will have some
big change for push_nsh and set. action names for data path also need
to be changed.

We also can start backporting NSH kernel patches to OVS to support
compat mode, this requires to backport many kernel patches before NSH
kernel patch, it will be great if OVS 2.9 can support both userspace and
kernel data path.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v15] openvswitch: enable NSH support

[Yang, Yi]

On Sat, Nov 04, 2017 at 10:29:46PM +0800, Pravin Shelar wrote:
> On Tue, Oct 31, 2017 at 9:03 PM, Yi Yang  wrote:
> > +int nsh_push(struct sk_buff *skb, const struct nshhdr *pushed_nh)
> > +{
> > +   struct nshhdr *nh;
> > +   size_t length = nsh_hdr_len(pushed_nh);
> > +   u8 next_proto;
> > +
> > +   if (skb->mac_len) {
> > +   next_proto = TUN_P_ETHERNET;
> > +   } else {
> > +   next_proto = tun_p_from_eth_p(skb->protocol);
> > +   if (!next_proto)
> > +   return -EAFNOSUPPORT;
> check for supported protocols can be moved to flow install validation
> in __ovs_nla_copy_actions().
> 
> > +   }
> > +
> > +   /* Add the NSH header */
> > +   if (skb_cow_head(skb, length) < 0)
> > +   return -ENOMEM;
> > +
> > +   skb_push(skb, length);
> > +   nh = (struct nshhdr *)(skb->data);
> > +   memcpy(nh, pushed_nh, length);
> > +   nh->np = next_proto;
> > +
> > +   skb->protocol = htons(ETH_P_NSH);
> > +   skb_reset_mac_header(skb);
> > +   skb_reset_network_header(skb);
> > +   skb_reset_mac_len(skb);
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(nsh_push);
> > +
> > +int nsh_pop(struct sk_buff *skb)
> > +{
> > +   struct nshhdr *nh;
> > +   size_t length;
> > +   __be16 inner_proto;
> > +
> > +   if (!pskb_may_pull(skb, NSH_BASE_HDR_LEN))
> > +   return -ENOMEM;
> > +   nh = (struct nshhdr *)(skb->data);
> > +   length = nsh_hdr_len(nh);
> > +   inner_proto = tun_p_to_eth_p(nh->np);
> same as above, this check can be moved to flow install 
> __ovs_nla_copy_actions().

Pravin, these two functions are not only for OVS, you can see it is
net/nsh/nsh.c, Jiri and Eric mentioned they also could be used by TC.

I understand you expect some checks should be moved to slow path, but
for there two cases, we can't remove them into __ovs_nla_copy_actions.

> 
> > +   if (!pskb_may_pull(skb, length))
> > +   return -ENOMEM;
> > +
> > +   if (!inner_proto)
> > +   return -EAFNOSUPPORT;
> > +
> > +   skb_pull(skb, length);
> > +   skb_reset_mac_header(skb);
> > +   skb_reset_network_header(skb);
> > +   skb_reset_mac_len(skb);
> > +   skb->protocol = inner_proto;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(nsh_pop);
> > +
> ...
> > diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> > index a551232..dd1449d 100644
> > --- a/net/openvswitch/actions.c
> > +++ b/net/openvswitch/actions.c
> ...
> > +static int pop_nsh(struct sk_buff *skb, struct sw_flow_key *key)
> > +{
> > +   int err;
> > +
> > +   if (ovs_key_mac_proto(key) != MAC_PROTO_NONE ||
> > +   skb->protocol != htons(ETH_P_NSH)) {
> > +   return -EINVAL;
> > +   }
> > +
> These checks can be moved to flow install.

Done in v16, here is incremental patch. I have sent out v16.

diff -u b/net/openvswitch/actions.c b/net/openvswitch/actions.c
--- b/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -400,11 +400,6 @@
 {
int err;
 
-   if (ovs_key_mac_proto(key) != MAC_PROTO_NONE ||
-   skb->protocol != htons(ETH_P_NSH)) {
-   return -EINVAL;
-   }
-
err = nsh_pop(skb);
if (err)
return err;
diff -u b/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
--- b/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -2737,6 +2737,8 @@
break;
 
case OVS_KEY_ATTR_NSH:
+   if (eth_type != htons(ETH_P_NSH))
+   return -EINVAL;
if (!validate_nsh(nla_data(a), masked, false, log))
return -EINVAL;
break;
@@ -3006,6 +3008,8 @@
break;
 
case OVS_ACTION_ATTR_POP_NSH:
+   if (eth_type != htons(ETH_P_NSH))
+   return -EINVAL;
if (key->nsh.base.np == TUN_P_ETHERNET)
mac_proto = MAC_PROTO_ETHERNET;
else
> 
> > +   err = nsh_pop(skb);
> > +   if (err)
> > +   return err;
> > +
> > +   /* safe right before invalidate_flow_key */
> > +   if (skb->protocol == htons(ETH_P_TEB))
> > +   key->mac_proto = MAC_PROTO_ETHERNET;
> > +   else
> > +   key->mac_proto = MAC_PROTO_NONE;
> > +   invalidate_flow_key(key);
> > +   return 0;
> > +}
> > +
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v15] openvswitch: enable NSH support

[Yang, Yi]

On Thu, Nov 02, 2017 at 05:06:47AM -0700, Pravin Shelar wrote:
> On Wed, Nov 1, 2017 at 7:50 PM, Yang, Yi <yi.y.y...@intel.com> wrote:
> > On Thu, Nov 02, 2017 at 08:52:40AM +0800, Pravin Shelar wrote:
> >> On Tue, Oct 31, 2017 at 9:03 PM, Yi Yang <yi.y.y...@intel.com> wrote:
> >> >
> >> > OVS master and 2.8 branch has merged NSH userspace
> >> > patch series, this patch is to enable NSH support
> >> > in kernel data path in order that OVS can support
> >> > NSH in compat mode by porting this.
> >> >
> >> > Signed-off-by: Yi Yang <yi.y.y...@intel.com>
> >> > ---
> >> I have comment related to checksum, otherwise patch looks good to me.
> >
> > Pravin, thank you for your comments, the below part is incremental patch
> > for checksum, please help check it, I'll send out v16 with this after
> > you confirm.
> >
> This change looks good to me.
> I noticed couple of more issues.
> 1. Can you move the ovs_key_nsh to the union of ipv4 an ipv6?
> ipv4/ipv6/nsh key data is mutually exclusive so there is no need for
> separate space for nsh key in the ovs key.
> 2. We need to fix match_validate() with nsh check. Datapath can not
> allow any l3 or l4 match if the flow key contains nsh match and
> vice-versa. such flow key should be rejected.

Pravin, the below incremental patch should fix the issues you pionted
out, please help confirm/ack, then I'll send out v16 with all acks
from you all for merge. BTW, it has been verified in my sfc test
environment.

diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index 8eeae749..c670dd2 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -149,8 +149,8 @@ struct sw_flow_key {
} nd;
};
} ipv6;
+   struct ovs_key_nsh nsh; /* network service header */
};
-   struct ovs_key_nsh nsh; /* network service header */
struct {
/* Connection tracking fields not packed above. */
struct {
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 0d7d4ae..090103c 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -178,7 +178,8 @@ static bool match_validate(const struct sw_flow_match 
*match,
| (1 << OVS_KEY_ATTR_ICMPV6)
| (1 << OVS_KEY_ATTR_ARP)
| (1 << OVS_KEY_ATTR_ND)
-   | (1 << OVS_KEY_ATTR_MPLS));
+   | (1 << OVS_KEY_ATTR_MPLS)
+   | (1 << OVS_KEY_ATTR_NSH));
 
/* Always allowed mask fields. */
mask_allowed |= ((1 << OVS_KEY_ATTR_TUNNEL)
@@ -287,6 +288,14 @@ static bool match_validate(const struct sw_flow_match 
*match,
}
}
 
+   if (match->key->eth.type == htons(ETH_P_NSH)) {
+   key_expected |= 1 << OVS_KEY_ATTR_NSH;
+   if (match->mask &&
+   match->mask->key.eth.type == htons(0x)) {
+   mask_allowed |= 1 << OVS_KEY_ATTR_NSH;
+   }
+   }
+
if ((key_attrs & key_expected) != key_expected) {
/* Key attributes check failed. */
OVS_NLERR(log, "Missing key (keys=%llx, expected=%llx)",
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v15] openvswitch: enable NSH support

[Yang, Yi]

On Thu, Nov 02, 2017 at 05:06:47AM -0700, Pravin Shelar wrote:
> On Wed, Nov 1, 2017 at 7:50 PM, Yang, Yi <yi.y.y...@intel.com> wrote:
> > On Thu, Nov 02, 2017 at 08:52:40AM +0800, Pravin Shelar wrote:
> >> On Tue, Oct 31, 2017 at 9:03 PM, Yi Yang <yi.y.y...@intel.com> wrote:
> >> >
> >> > OVS master and 2.8 branch has merged NSH userspace
> >> > patch series, this patch is to enable NSH support
> >> > in kernel data path in order that OVS can support
> >> > NSH in compat mode by porting this.
> >> >
> >> > Signed-off-by: Yi Yang <yi.y.y...@intel.com>
> >> > ---
> >> I have comment related to checksum, otherwise patch looks good to me.
> >
> > Pravin, thank you for your comments, the below part is incremental patch
> > for checksum, please help check it, I'll send out v16 with this after
> > you confirm.
> >
> This change looks good to me.
> I noticed couple of more issues.
> 1. Can you move the ovs_key_nsh to the union of ipv4 an ipv6?
> ipv4/ipv6/nsh key data is mutually exclusive so there is no need for
> separate space for nsh key in the ovs key.
> 2. We need to fix match_validate() with nsh check. Datapath can not
> allow any l3 or l4 match if the flow key contains nsh match and
> vice-versa. such flow key should be rejected.

Ok, I'll fix them ASAP.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v15] openvswitch: enable NSH support

[Yang, Yi]

On Thu, Nov 02, 2017 at 08:52:40AM +0800, Pravin Shelar wrote:
> On Tue, Oct 31, 2017 at 9:03 PM, Yi Yang  wrote:
> >
> > OVS master and 2.8 branch has merged NSH userspace
> > patch series, this patch is to enable NSH support
> > in kernel data path in order that OVS can support
> > NSH in compat mode by porting this.
> >
> > Signed-off-by: Yi Yang 
> > ---
> I have comment related to checksum, otherwise patch looks good to me.

Pravin, thank you for your comments, the below part is incremental patch
for checksum, please help check it, I'll send out v16 with this after
you confirm.

diff --git a/net/nsh/nsh.c b/net/nsh/nsh.c
index 2764682..d7da99a 100644
--- a/net/nsh/nsh.c
+++ b/net/nsh/nsh.c
@@ -36,6 +36,7 @@ int nsh_push(struct sk_buff *skb, const struct nshhdr 
*pushed_nh)
nh = (struct nshhdr *)(skb->data);
memcpy(nh, pushed_nh, length);
nh->np = next_proto;
+   skb_postpush_rcsum(skb, nh, length);
 
skb->protocol = htons(ETH_P_NSH);
skb_reset_mac_header(skb);
@@ -63,7 +64,7 @@ int nsh_pop(struct sk_buff *skb)
if (!inner_proto)
return -EAFNOSUPPORT;
 
-   skb_pull(skb, length);
+   skb_pull_rcsum(skb, length);
skb_reset_mac_header(skb);
skb_reset_network_header(skb);
skb_reset_mac_len(skb);
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index dd1449d..5ba0e35 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -671,6 +671,7 @@ static int set_nsh(struct sk_buff *skb, struct sw_flow_key 
*flow_key,
return err;
 
nh = nsh_hdr(skb);
+   skb_postpull_rcsum(skb, nh, length);
flags = nsh_get_flags(nh);
flags = OVS_MASKED(flags, key.base.flags, mask.base.flags);
flow_key->nsh.base.flags = flags;
@@ -698,6 +699,7 @@ static int set_nsh(struct sk_buff *skb, struct sw_flow_key 
*flow_key,
default:
return -EINVAL;
}
+   skb_postpush_rcsum(skb, nh, length);
return 0;
 }
 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v14] openvswitch: enable NSH support

[Yang, Yi]

On Wed, Nov 01, 2017 at 04:08:22AM +0800, Jiri Benc wrote:
> On Mon, 30 Oct 2017 09:29:34 +0800, Yi Yang wrote:
> > +static int set_nsh(struct sk_buff *skb, struct sw_flow_key *flow_key,
> > +  const struct nlattr *a)
> > +{
> > +   struct nshhdr *nh;
> > +   size_t length;
> > +   int err;
> > +   u8 flags;
> > +   u8 ttl;
> > +   int i;
> > +
> > +   struct ovs_key_nsh key;
> > +   struct ovs_key_nsh mask;
> > +
> > +   err = nsh_key_from_nlattr(a, , );
> > +   if (err)
> > +   return err;
> > +
> > +   /* Make sure the NSH base header is there */
> > +   if (!pskb_may_pull(skb, NSH_BASE_HDR_LEN))
> 
> This should be skb_network_offset(skb) + NSH_BASE_HDR_LEN.
> 

Fixed in v15.

> > +size_t ovs_nsh_key_attr_size(void)
> > +{
> > +   /* Whenever adding new OVS_NSH_KEY_ FIELDS, we should consider
> > +* updating this function.
> > +*/
> > +   return  nla_total_size(NSH_BASE_HDR_LEN) /* OVS_NSH_KEY_ATTR_BASE */
> > +   /* OVS_NSH_KEY_ATTR_MD1 and OVS_NSH_KEY_ATTR_MD2 are
> > +* mutually exclusive, so the bigger one can cover
> > +* the small one.
> > +*
> > +* OVS_NSH_KEY_ATTR_MD2
> > +*/
> 
> A nit, not important but since you'll need to respin anyway: the last
> line in the comment above seems to be a left over from some previous
> version of the comment. This should be enough:
> 
>   /* OVS_NSH_KEY_ATTR_MD1 and OVS_NSH_KEY_ATTR_MD2 are
>* mutually exclusive, so the bigger one can cover
>* the small one.
>*/
> 
> Or maybe I misunderstood what you meant.
> 
Fixed it per the above one.

> > +int nsh_hdr_from_nlattr(const struct nlattr *attr,
> > +   struct nshhdr *nh, size_t size)
> > +{
> > +   struct nlattr *a;
> > +   int rem;
> > +   u8 flags = 0;
> > +   u8 ttl = 0;
> > +   int mdlen = 0;
> > +
> > +   /* validate_nsh has check this, so we needn't do duplicate check here
> > +*/
> > +   nla_for_each_nested(a, attr, rem) {
> > +   int type = nla_type(a);
> > +
> > +   switch (type) {
> > +   case OVS_NSH_KEY_ATTR_BASE: {
> > +   const struct ovs_nsh_key_base *base = nla_data(a);
> > +
> > +   flags = base->flags;
> > +   ttl = base->ttl;
> > +   nh->np = base->np;
> > +   nh->mdtype = base->mdtype;
> > +   nh->path_hdr = base->path_hdr;
> > +   break;
> > +   }
> > +   case OVS_NSH_KEY_ATTR_MD1:
> > +   mdlen = nla_len(a);
> > +   memcpy(>md1, nla_data(a), mdlen);
> 
> The check for 'size' disappeared from here somehow.
> 
> > +   break;
> > +
> > +   case OVS_NSH_KEY_ATTR_MD2:
> > +   mdlen = nla_len(a);
> > +   memcpy(>md2, nla_data(a), mdlen);
> 
> And here.

validate_nsh checked netlink attributes but can't check size, yes, we
should add size check for mdlen, v15 has had them. Please check v15,
thanks a lot.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v14] openvswitch: enable NSH support

[Yang, Yi]

On Wed, Nov 01, 2017 at 03:57:41AM +0800, Eric Garver wrote:
> On Mon, Oct 30, 2017 at 09:29:34AM +0800, Yi Yang wrote:
> [...]
> > +int nsh_pop(struct sk_buff *skb)
> > +{
> > +   struct nshhdr *nh;
> > +   size_t length;
> > +   __be16 inner_proto;
> > +
> > +   if (!pskb_may_pull(skb, NSH_BASE_HDR_LEN))
> > +   return -ENOMEM;
> > +   nh = (struct nshhdr *)(skb->data);
> > +   length = nsh_hdr_len(nh);
> > +   if (!pskb_may_pull(skb, length))
> > +   return -ENOMEM;
> > +
> > +   nh = (struct nshhdr *)(skb->data);
> > +   inner_proto = tun_p_to_eth_p(nh->np);
> 
> If you fetch inner_proto before the second pskb_may_pull then there is
> no need to reload the nh pointer as you won't use it later.
> 
> > +   if (!inner_proto)
> > +   return -EAFNOSUPPORT;
> > +
> > +   length = nsh_hdr_len(nh);
> 
> You already have the length from above. No need to get it again.

Good catch, fixed in v15.

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

Re: [ovs-dev] [PATCH net-next v13] openvswitch: enable NSH support

[Yang, Yi]

On Mon, Oct 30, 2017 at 10:01:34AM +0900, David Miller wrote:
> From: Yi Yang 
> Date: Thu, 26 Oct 2017 15:45:16 +0800
> 
> > OVS master and 2.8 branch has merged NSH userspace
> > patch series, this patch is to enable NSH support
> > in kernel data path in order that OVS can support
> > NSH in compat mode by porting this.
> > 
> > Signed-off-by: Yi Yang 
> 
> One small request for function naming:
> 
> > diff --git a/include/net/nsh.h b/include/net/nsh.h
> > index a1eaea2..7dcf377 100644
> > --- a/include/net/nsh.h
> > +++ b/include/net/nsh.h
> > @@ -304,4 +304,7 @@ static inline void nsh_set_flags_ttl_len(struct nshhdr 
> > *nsh, u8 flags,
> > NSH_FLAGS_MASK | NSH_TTL_MASK | NSH_LEN_MASK);
> >  }
> >  
> > +int skb_push_nsh(struct sk_buff *skb, const struct nshhdr *pushed_nh);
> > +int skb_pop_nsh(struct sk_buff *skb);
> > +
> >  #endif /* __NET_NSH_H */
> 
> All functions named "skb_*" should be core SKB handling functions found
> and implemented in include/linux/skbuff.h and net/core/skbuff.c
> 
> Protocol specific helpers like this should be named "$PROTOCOL_NAME_*"
> so please renamed these something like "nsh_header_push()" and
> "nsh_header_pop()".

Dave, thank for your comments, I have changed skb_push_nsh to nsh_push and
changed skb_pop_nsh to nsh_pop, posted v14, please review, thanks.

> 
> Thank you.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v12] openvswitch: enable NSH support

[Yang, Yi]

On Fri, Oct 20, 2017 at 04:05:35PM +0800, Jiri Benc wrote:
> On Fri, 20 Oct 2017 05:53:12 +0800, Yang, Yi wrote:
> > For push_nsh, my typical use scinario is push_nsh then set then output
> > to vxlangpe port.
> 
> Okay.

Then I just need to do the below change against v12.

diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 1ab3c51..a3a663c 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -658,10 +658,8 @@ static int set_nsh(struct sk_buff *skb, struct
sw_flow_key *flow_key,
return err;

/* Make sure the NSH base header is there */
-   err = skb_ensure_writable(skb, skb_network_offset(skb) +
-  NSH_BASE_HDR_LEN);
-   if (unlikely(err))
-   return err;
+   if (!pskb_may_pull(skb, NSH_BASE_HDR_LEN))
+   return -ENOMEM;

nh = nsh_hdr(skb);
length = nsh_hdr_len(nh);

I'll send out v13 with this if you're ok.

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

Re: [ovs-dev] [PATCH net-next v12] openvswitch: enable NSH support

[Yang, Yi]

On Thu, Oct 19, 2017 at 03:41:18PM +0200, Jiri Benc wrote:
> On Thu, 19 Oct 2017 21:12:15 +0800, Yang, Yi wrote:
> > flow_key in set_nsh is got from netlink message which is set by
> > commit_nsh in user space, here is code.
> 
> Isn't this the 'key' local variable that you're talking about, while I'm
> referring to the 'flow_key' parameter?

Oh, my mistake, but it is possible not to polulate nsh key in flow_key
for push_nsh then set, as Jan and I explained before, we don't
recirculate the packet after push_nsh for performance, so parse function
isn't called for NSH header, mdtype can't be gotten from flow_key yet.
Only one case is true, i.e. an ingress NSH packet is parsed then set by 
changing si and ttl.

For push_nsh, my typical use scinario is push_nsh then set then output
to vxlangpe port.

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

Re: [ovs-dev] [PATCH net-next v12] openvswitch: enable NSH support

[Yang, Yi]

On Thu, Oct 19, 2017 at 02:43:47PM +0200, Jiri Benc wrote:
> On Thu, 19 Oct 2017 19:40:53 +0800, Yang, Yi wrote:
> > Actually mdtype can't be set, only push_nsh can set mdtype, so set_nsh
> > won't have mdtype flow key, we can't get it from flow_key in set_nsh,
> > only ttl, flags and path_hdr can be set in set_nsh as you can see in code.
> > I understand your concern is calling skb_ensure_writable twice, so
> > changing the first one to pskb_may_pull is more appropriate for set_nsh.
> 
> Isn't set_nsh called only after the packet was already dissected (i.e.
> parse_nsh called)? The dissected fields should be available in flow_key.

flow_key in set_nsh is got from netlink message which is set by
commit_nsh in user space, here is code.

mask.mdtype = 0; /* Not writable. */
mask.np = 0; /* Not writable. */

if (commit_nsh(_flow->nsh, use_masked, , , ,
sizeof key, odp_actions)) {
put_nsh_key(, base_flow, false);
if (mask.mdtype != 0) { /* Mask was changed by commit(). */
put_nsh_key(, >masks, true);
}
}

Here set is set with mask, so key value is masked by mask.mdtype

/* OVS_KEY_ATTR_NSH keys */
nsh_key_ofs = nl_msg_start_nested(odp_actions,
OVS_KEY_ATTR_NSH);

/* put value and mask for OVS_NSH_KEY_ATTR_BASE */
char *data = nl_msg_put_unspec_uninit(odp_actions,
  OVS_NSH_KEY_ATTR_BASE,
  2 * sizeof(nsh_base));
const char *lkey = (char *)_base, *lmask = (char
*)_base_mask;
size_t lkey_size = sizeof(nsh_base);

while (lkey_size--) {
*data++ = *lkey++ & *lmask++;
}
lmask = (char *)_base_mask;
memcpy(data, lmask, sizeof(nsh_base_mask));

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

Re: [ovs-dev] [PATCH net-next v12] openvswitch: enable NSH support

[Yang, Yi]

On Thu, Oct 19, 2017 at 05:19:55AM +0800, Jiri Benc wrote:
> On Mon, 16 Oct 2017 21:53:29 +0800, Yi Yang wrote:
> > +static int set_nsh(struct sk_buff *skb, struct sw_flow_key *flow_key,
> > +  const struct nlattr *a)
> > +{
> > +   struct nshhdr *nh;
> > +   size_t length;
> > +   int err;
> > +   u8 flags;
> > +   u8 ttl;
> > +   int i;
> > +
> > +   struct ovs_key_nsh key;
> > +   struct ovs_key_nsh mask;
> > +
> > +   err = nsh_key_from_nlattr(a, , );
> > +   if (err)
> > +   return err;
> > +
> > +   /* Make sure the NSH base header is there */
> > +   err = skb_ensure_writable(skb, skb_network_offset(skb) +
> > +  NSH_BASE_HDR_LEN);
> > +   if (unlikely(err))
> > +   return err;
> > +
> > +   nh = nsh_hdr(skb);
> > +   length = nsh_hdr_len(nh);
> > +
> > +   /* Make sure the whole NSH header is there */
> > +   err = skb_ensure_writable(skb, skb_network_offset(skb) +
> > +  length);
> 
> Calling skb_ensure_writable twice is an unnecessary waste in the fast
> path. If anything, the first call should be changed to pskb_may_pull.
> 
> But what we really should do here is to move the header only once. We
> know how much data we're going to write, we have everything stored in
> the key and can calculate it from there.

Actually mdtype can't be set, only push_nsh can set mdtype, so set_nsh
won't have mdtype flow key, we can't get it from flow_key in set_nsh,
only ttl, flags and path_hdr can be set in set_nsh as you can see in code.
I understand your concern is calling skb_ensure_writable twice, so
changing the first one to pskb_may_pull is more appropriate for set_nsh.

> 
>   length = NSH_BASE_HDR_LEN;
>   switch (flow_key->nsh.base.mdtype) {
>   case NSH_MD_TYPE1:
>   length += sizeof(struct ovs_nsh_key_md1);
>   break;
>   case NSH_MD_TYPE2:
>   length += whatever_way_we_store_the_tlvs_in_flow_key;
>   break;
>   }
>   err = skb_ensure_writable(skb, skb_network_offset(skb) + length);
> 
> However, set_nsh does not support MD type 2, thus the second case is a
> dead code. In both switches in this function. As such, it should be
> removed and added only when MD type 2 is introduced. I'd still keep the
> overall logic to ease the future addition, though. This boils down to:
> 
>   length = NSH_BASE_HDR_LEN;
>   /* Assume MD type 1. This function cannot be called for anything
>* else currently. When MD type 2 is added, the line below will
>* have to be turned into a switch on flow_key->nsh.base.mdtype.
>*/
>   length += sizeof(struct ovs_nsh_key_md1);
>   err = skb_ensure_writable(skb, skb_network_offset(skb) + length);
>   ...
>   flow_key->nsh.base.path_hdr = nh->path_hdr;
>   /* Only MD type 1, see the comment above. */
>   for (i = 0; i < NSH_MD1_CONTEXT_SIZE; i++) {
>   ...
> 
> Please verify I'm not missing something.
> 
> It seems we also rely on the user space checking first whether the
> packet is indeed compatible with the pushed key/mask. Most importantly,
> that it's of the same mdtype and (in the future) that the MD type 2
> TLVs being written actually fit. Seems this is done the same way in the
> other set_* actions, thus fine with me.
> 
>  Jiri
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v9] openvswitch: enable NSH support

[Yang, Yi]

On Fri, Sep 29, 2017 at 07:10:52AM +, Jan Scheurich wrote:
> > From: Yang, Yi [mailto:yi.y.y...@intel.com]
> > Sent: Friday, 29 September, 2017 08:41
> > To: Pravin Shelar <pshe...@ovn.org>
> > Cc: Jiri Benc <jb...@redhat.com>; net...@vger.kernel.org; 
> > d...@openvswitch.org; e...@erig.me; da...@davemloft.net; Jan Scheurich
> > <jan.scheur...@ericsson.com>
> > Subject: Re: [PATCH net-next v9] openvswitch: enable NSH support
> > 
> > On Fri, Sep 29, 2017 at 02:28:38AM +0800, Pravin Shelar wrote:
> > > On Tue, Sep 26, 2017 at 6:39 PM, Yang, Yi <yi.y.y...@intel.com> wrote:
> > > > On Tue, Sep 26, 2017 at 06:49:14PM +0800, Jiri Benc wrote:
> > > >> On Tue, 26 Sep 2017 12:55:39 +0800, Yang, Yi wrote:
> > > >> > After push_nsh, the packet won't be recirculated to flow pipeline, so
> > > >> > key->eth.type must be set explicitly here, but for pop_nsh, the 
> > > >> > packet
> > > >> > will be recirculated to flow pipeline, it will be reparsed, so
> > > >> > key->eth.type will be set in packet parse function, we needn't 
> > > >> > handle it
> > > >> > in pop_nsh.
> > > >>
> > > >> This seems to be a very different approach than what we currently have.
> > > >> Looking at the code, the requirement after "destructive" actions such
> > > >> as pushing or popping headers is to recirculate.
> > > >
> > > > This is optimization proposed by Jan Scheurich, recurculating after 
> > > > push_nsh
> > > > will impact on performance, recurculating after pop_nsh is unavoidable, 
> > > > So
> > > > also cc jan.scheur...@ericsson.com.
> > > >
> > > > Actucally all the keys before push_nsh are still there after push_nsh,
> > > > push_nsh has updated all the nsh keys, so recirculating remains 
> > > > avoidable.
> > > >
> > >
> > >
> > > We should keep existing model for this patch. Later you can submit
> > > optimization patch with specific use cases and performance
> > > improvement. So that we can evaluate code complexity and benefits.
> > 
> > Ok, I'll remove the below line in push_nsh and send out v11, thanks.
> > 
> > key->eth.type = htons(ETH_P_NSH);
> 
> The optimization Yi refers to only affects the slow path translation. 
> 
> OVS 2.8 does not immediately trigger an immediate recirculation after 
> translating 
> encap(nsh,...). There is no need to do so as the flow key of the resulting 
> packet 
> can be determined from the encap() action and its properties. Translation 
> continues with the rewritten flow key and subsequent OpenFlow actions will 
> typically set the new fields in the new NSH header. The push_nsh datapath 
> action 
> (including all NSH header fields) is only generated at the next commit, e.g. 
> for 
> output, cloning, recirculation, encap/decap or another destructive change of 
> the flow key.
> 
> The implementation of push_nsh in the user-space datapath does not update
> the miniflow (key) of the packet, only the packet data and some metadata. 
> If the packet needs to be looked up again the slow path triggers recirculation
> to re-parse the packet. There should be no need for the datapath push_nsh 
> action to try to update the flow key.

Thanks Jan for clarification, it can still work after removing that
line, our flows didn't match it after push_nsh, it is output to
VxLAN-gpe port after push_nsh, I'm not sure if we can match dl_type and NSH
fields if we don't output and don't recirculate.

> 
> BR, Jan
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v9] openvswitch: enable NSH support

[Yang, Yi]

On Fri, Sep 29, 2017 at 02:28:38AM +0800, Pravin Shelar wrote:
> On Tue, Sep 26, 2017 at 6:39 PM, Yang, Yi <yi.y.y...@intel.com> wrote:
> > On Tue, Sep 26, 2017 at 06:49:14PM +0800, Jiri Benc wrote:
> >> On Tue, 26 Sep 2017 12:55:39 +0800, Yang, Yi wrote:
> >> > After push_nsh, the packet won't be recirculated to flow pipeline, so
> >> > key->eth.type must be set explicitly here, but for pop_nsh, the packet
> >> > will be recirculated to flow pipeline, it will be reparsed, so
> >> > key->eth.type will be set in packet parse function, we needn't handle it
> >> > in pop_nsh.
> >>
> >> This seems to be a very different approach than what we currently have.
> >> Looking at the code, the requirement after "destructive" actions such
> >> as pushing or popping headers is to recirculate.
> >
> > This is optimization proposed by Jan Scheurich, recurculating after push_nsh
> > will impact on performance, recurculating after pop_nsh is unavoidable, So
> > also cc jan.scheur...@ericsson.com.
> >
> > Actucally all the keys before push_nsh are still there after push_nsh,
> > push_nsh has updated all the nsh keys, so recirculating remains avoidable.
> >
> 
> 
> We should keep existing model for this patch. Later you can submit
> optimization patch with specific use cases and performance
> improvement. So that we can evaluate code complexity and benefits.

Ok, I'll remove the below line in push_nsh and send out v11, thanks.

key->eth.type = htons(ETH_P_NSH);

> 
> >>
> >> Setting key->eth.type to satisfy conditions in the output path without
> >> updating the rest of the key looks very hacky and fragile to me. There
> >> might be other conditions and dependencies that are not obvious.
> >> I don't think the code was written with such code path in mind.
> >>
> >> I'd like to hear what Pravin thinks about this.
> >>
> >>  Jiri
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v9] openvswitch: enable NSH support

[Yang, Yi]

On Wed, Sep 27, 2017 at 04:59:36AM +0800, Eric Garver wrote:
> On Tue, Sep 26, 2017 at 01:02:15PM +0800, Yang, Yi wrote:
> > On Tue, Sep 26, 2017 at 03:28:42AM +0800, Eric Garver wrote:
> > > On Mon, Sep 25, 2017 at 10:16:09PM +0800, Yi Yang wrote:
> > > > +
> > > > +   length = nsh_hdr_len(nsh_hdr);
> > > > +   skb_pull(skb, length);
> > > 
> > > Do you need to verify you can actually pull length bytes? I don't see
> > > any guarantee.
> > 
> > I have added skb length check in pop_nsh, so that can verify this.
> 
> That doesn't help other code that may call skb_pop_nsh(). skb_vlan_pop()
> calls skb_ensure_writable() which seems like the right thing to do.

Make sense, I will move it to skp_pop_nsh, thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v10] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Sep 26, 2017 at 10:42:40PM +0800, Jiri Benc wrote:
> On Tue, 26 Sep 2017 21:52:41 +0800, Yang, Yi wrote:
> > > + return ((ret != 0) ? false : true);
> > 
> > But I don't think this is a problematic line from my understanding,
> 
> Why not:
> 
>   return ((ret != 0 == true) ? false : true) == true;
> 
> ?
> 
> Sigh. This is equal to:
> 
>   return !ret;
> 
> which you should use.

Ok, got it, I'll use "return !ret;", real programming art :-), I also saw
!!(condition), personally its readability is not good, typical kernel
style :-)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v10] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Sep 26, 2017 at 07:05:34PM +0800, Jiri Benc wrote:
> On Tue, 26 Sep 2017 12:47:16 +0800, Yi Yang wrote:
> > +   return ((ret != 0) ? false : true);

Jiri, I appriciate your review very carefully and professionally from my
heart for 10 versions, that is really very very big effort.

I carefully thought this comment:

"""
> + return ((ret != 0) ? false : true);

Too little coffee or too late in the night, right? ;-)
"""

But I don't think this is a problematic line from my understanding,
because validate_nsh is declared to return bool. I had thought you were
saying "it was late, it was time for you to leave office, so no more
comments", this is my readout :-)

So the best comment you can give out here is one line you prefer :-)

I'm not a kernel developer full time, I'm adapting to several coding
style at the time in kernel, OVS and Opendaylight.

> 
> I'm not going to review this version but this caught my eye - I pointed
> out this silly construct in my review of v9. I can understand that
> working late in the night and rewriting the code back and forth, one
> could end up with such construct and overlook it at the final
> self-review before submission. Happens to everyone.
> 
> But leaving this after a review pointed it out means you're not paying
> enough attention to your work. Even the fact that you sent v10 so
> shortly after v9 means you did not spend the needed time on reflecting
> on the review and that you did not properly test the new version. And
> I told you exactly this before.
> 
> Honestly, I'm starting to be tired with reviewing your patch again and
> again and pointing out silly mistakes like this one and repeating basic
> things to you again and again.

I did test it in my sfc test environment, I don't see any warning, error
during build and runtime, it can work well.

Sorry if missing your comments, that is understanding issue in most
cases but not I don't take your comments seriously. You know English
isn't my native language, it is a big challenge for me to understand
your comments very well. Neverthless, code is our common language, I can
understand code better than your descriptive words :-)

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

Re: [ovs-dev] [PATCH net-next v9] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Sep 26, 2017 at 03:28:42AM +0800, Eric Garver wrote:
> On Mon, Sep 25, 2017 at 10:16:09PM +0800, Yi Yang wrote:
> > +
> > +   length = nsh_hdr_len(nsh_hdr);
> > +   skb_pull(skb, length);
> 
> Do you need to verify you can actually pull length bytes? I don't see
> any guarantee.

I have added skb length check in pop_nsh, so that can verify this.

> > +   err = skb_ensure_writable(skb, skb_network_offset(skb) +
> > + sizeof(struct nshhdr));
> 
> This calls pskb_may_pull(), but you're not pulling any data here.

set_ipv4 and set_ipv6 also used skb_ensure_writable to check if skb
has enough header length, they didn't call skb_pull in the following
part, so I think this is ok.

I have sent out v10 to fix all of your comments for v9, please help
review v10, thanks a lot.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v9] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Sep 26, 2017 at 02:14:39AM +0800, Jiri Benc wrote:
> On Mon, 25 Sep 2017 22:16:09 +0800, Yi Yang wrote:
> > +   return err;
> > +
> > +   key->eth.type = htons(ETH_P_NSH);
> 
> I wonder why you have this assignment here. The key is invalidated,
> thus nothing should rely on key->eth.type. However, looking at the code
> and ovs_fragment in particular, I'm not sure that's the case. Could you
> please explain why it is needed? And why the reverse of it is not
> needed in pop_nsh?

After push_nsh, the packet won't be recirculated to flow pipeline, so
key->eth.type must be set explicitly here, but for pop_nsh, the packet
will be recirculated to flow pipeline, it will be reparsed, so
key->eth.type will be set in packet parse function, we needn't handle it
in pop_nsh.

I have sent out v10 to fix all the comments for v9, please review v10,
thanks a lot.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v9] openvswitch: enable NSH support

[Yang, Yi]

On Thu, Sep 14, 2017 at 05:09:02PM +0800, Jiri Benc wrote:
> On Thu, 14 Sep 2017 16:37:59 +0800, Yi Yang wrote:
> > OVS master and 2.8 branch has merged NSH userspace
> > patch series, this patch is to enable NSH support
> > in kernel data path in order that OVS can support
> > NSH in compat mode by porting this.
> 
> http://vger.kernel.org/~davem/net-next.html

I see it has been open now, v9 this patch series is still ok to
current net-next without any hunk, so please help review v9, thanks a
lot.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

[Yang, Yi]

On Thu, Aug 31, 2017 at 06:45:16PM +0800, Jiri Benc wrote:
> On Wed, 30 Aug 2017 20:39:12 +0800, Yi Yang wrote:
> > +   nsh->md1.context[i] =
> > +   OVS_MASKED(nsh->md1.context[i], key->context[i],
> > +  mask->context[i]);
> > +   }
> > +   memcpy(flow_key->nsh.context, nsh->md1.context,
> > +  sizeof(nsh->md1.context));
> 
> Do you follow the discussion that Hannes Sowa started on the ovs list
> regarding matching on the context fields? It would be better to hold on this
> until there's a conclusion reached.

We had several back-and-forth discussions, Jan was also involved, the
conslusion is current way is still the best way we can have, we need
set and match for context fields.

> > +   type,
> > +   nla_len(a),
> > +   ovs_nsh_key_attr_lens[type].len
> > +   );
> > +   return -EINVAL;
> > +   }
> 
> These checks should be done only once when the action is configured, not for
> each packet.

in v8, nsh_key_put_from_nlattr is only one check point, validate_nsh calls it
for set and push_nsh, nsh_hdr_from_nlattr and nsh_key_from_nlattr
haven't these checked anymore because validate_nsh has done them.

> > +   if (unlikely(!has_md1 && !has_md2)) {
> > +   OVS_NLERR(1, "neither nsh md1 nor md2 attribute is there");
> > +   return -EINVAL;
> > +   }
> 
> Ditto. Plus I don't see a check that the OVS_NSH_KEY_ATTR_BASE attribute is
> present. Seems that the compiler warned you about possibly unitialized flags
> and ttl variables and you just silenced the warning without considering
> whether it's not actually justified.

nsh_key_put_from_nlattr is used for both set and push_nsh, so
OVS_NSH_KEY_ATTR_BASE check is valid only for push_nsh, it is possible
for set not to have OVS_NSH_KEY_ATTR_BASE. v8 has been successfully built
without any warnings, it is also verified in sfc test environment.

I think v8 has fixed all the comments for v7, I have sent out v8 to
mailing list, please help review it, thanks a lot.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH support

[Yang, Yi]

On Wed, Sep 06, 2017 at 04:03:29PM +0800, Hannes Frederic Sowa wrote:
> "Yang, Yi" <yi.y.y...@intel.com> writes:
> >> 
> >> > If you check GENEVE implementation, tun_metadata* can be set or matched
> >> > as any other match field.
> >> 
> >> Yes, I wrote that in my previous mail. I wonder why NSH context metadata
> >> is not in tun_metadata as well?
> >
> > tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is
> > not so, NSH can't directly use tun_metadata, for MD type 2, we need to a
> > lot of rework on tun_metadata to make it shared between GENEVE and NSH,
> > I don't think this can happen in near term. So tun_metadata isn't option
> > for this now.
> 
> Sorry, I couldn't follow you. Why can't you store the context headers in
> tun_metadata exactly?

tun_metadata can work only if in_port and out_port are GENEVE tunnel
port, it is designed specially for GENEVE, Eth+NSH can work without
any tunnel port involved, context headers for NSH are not tunnel
metadata, they aren't tunnel-specific, you can't treat them as same
thing. In addtition, tun_metadata also can be matched and set, they have
the same issue as you concern.

> 
> [...]
> 
> Bye,
> Hannes
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Sep 05, 2017 at 09:12:09PM +0800, Hannes Frederic Sowa wrote:
> "Yang, Yi" <yi.y.y...@intel.com> writes:
> 
> > We can change this later if we really find a better way to handle this
> > because it isn't defined in include/uapi/linux/openvswitch.h, so I still
> > have backdoor to do this if needed :-)
> 
> Sorry, I can't follow you.
> 
> It doesn't matter if something is defined in uapi headers, the
> observable behavior matters. If you allow users to configure flows with
> specific fields, it should not stop working at a future point in time.

Anyway this can be changed if it is really needed, so far current way is
the best one we can come up with, we would like to use it if you can
have better proposal. We have explained repeatedly context headers must
be matched and set, this is bottom line.

> 
> > For our sfc use case in Opendaylight, we use context[0] for tunnel ID,
> > context[1] for destination IP for reverse RSP, they are used to match
> > and set in OpenFlow table, you can't limit users to use them in such
> > ways.
> 
> So in your specific case you expect the masks to be completely stable
> because you defined a protocol on top of NSH, understood. And that is
> stable accross all possible paths. Understood as well.
> 
> > If you check GENEVE implementation, tun_metadata* can be set or matched
> > as any other match field.
> 
> Yes, I wrote that in my previous mail. I wonder why NSH context metadata
> is not in tun_metadata as well?

tun_metadata is tunnel metadata, GENEVE needs tunnel port, but NSH is
not so, NSH can't directly use tun_metadata, for MD type 2, we need to a
lot of rework on tun_metadata to make it shared between GENEVE and NSH,
I don't think this can happen in near term. So tun_metadata isn't option
for this now.

> 
> > Actually the most important information in NSH are just these context
> > headers, you can't limit imagination of users by removing them from flow
> > keys.
> >
> > My point is to bring miniflow into kernel data path to fix your concern,
> > this will benefit your employer directly :-)
> 
> Okay, interesting. It will probably not help if you still have a hash of
> a packet inside the flow table and use that for load balancing.
> 
> [...]
> 
> BTW I don't want to stop this patch, I am merely interested in how the
> bigger picture will look like in the end.
> 
> Bye,
> Hannes
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Sep 05, 2017 at 12:30:09PM +0200, Hannes Frederic Sowa wrote:
> "Yang, Yi" <yi.y.y...@intel.com> writes:
> 
> > I'm not sure what new action you expect to bring here, I think group
> > action is just for this, as you said it isn't only bound to NSH, you can
> > start a new thread to discuss this. I don't think it is in scope of NSH.
> 
> It is in scope of this discussion as you will provide a user space API
> that makes the NSH context fields accessible from user space in a
> certain way. If you commit to this, there is no way going back.

We can change this later if we really find a better way to handle this
because it isn't defined in include/uapi/linux/openvswitch.h, so I still
have backdoor to do this if needed :-)

> 
> I haven't yet grasped the idea on how those fields will be used in OVS
> besides load balancing. Even for load balancing the tunnel itself
> (vxlan-gpe + UDP source port or ipv6 flowlabel) already provides enough
> entropy to do per-flow load balancing. What else is needed?  Why a
> context header for that? You just need multiple action chains and pick
> one randomly.

For our sfc use case in Opendaylight, we use context[0] for tunnel ID,
context[1] for destination IP for reverse RSP, they are used to match
and set in OpenFlow table, you can't limit users to use them in such
ways.

If you check GENEVE implementation, tun_metadata* can be set or matched
as any other match field.

Actually the most important information in NSH are just these context
headers, you can't limit imagination of users by removing them from flow
keys.

My point is to bring miniflow into kernel data path to fix your concern,
this will benefit your employer directly :-)

I'm just curious your company has hardware to offload NSH? Which
company are you from?

> 
> The only protocol that I can compare that to is geneve with TLVs, but
> the TLVs are global and uniquie and a property of the networking
> forwarding backplane and not a property of the path inside a tenant. So
> I expect this actually to be the first case where I think that matters.
> 
> Why are context labels that special that they are not part of tun_ops?
> 
> Thanks,
> Hannes
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Sep 05, 2017 at 11:46:45AM +0200, Jiri Benc wrote:
> On Tue, 5 Sep 2017 13:51:45 +0800, Yang, Yi wrote:
> > But if we follow your way, how does nla_for_each_nested handle such
> > pattern?
> > 
> > attribute1
> > attribute1_mask
> > attribute2
> > attribute2_mask
> > attribute3
> > attribute3_mask
> 
> Uh? That will just work. Note that nla len contains the size of the
> whole attribute, i.e. includes both fields.
> 
> > I don't think this can increase performance and readability.
>

I got the point, actually value and mask are data of one attribute, so
they are three attributes but not six. 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Sep 05, 2017 at 11:47:41AM +0200, Jiri Benc wrote:
> On Tue, 5 Sep 2017 14:37:05 +0800, Yang, Yi wrote:
> > I checked source code but can't find where we can prepopulate it and how
> > we can deliver the prepopulated header to push_nsh, can you expand it in
> > order that I can know how to do this in code level?
> 
> I already said that it's not implemented yet and can be done as a
> future performance enhancement.

Got it, thanks.

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

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

[Yang, Yi]

On Mon, Sep 04, 2017 at 06:42:16PM +0800, Jiri Benc wrote:
> On Mon, 4 Sep 2017 16:00:05 +0800, Yang, Yi wrote:
> > how can we know next push_nsh uses the same nsh header as previous
> > one?
> 
> We store the prepopulated header together with the action.
>

I checked source code but can't find where we can prepopulate it and how
we can deliver the prepopulated header to push_nsh, can you expand it in
order that I can know how to do this in code level?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

[Yang, Yi]

On Mon, Sep 04, 2017 at 08:57:44PM +0800, Jiri Benc wrote:
> On Mon, 4 Sep 2017 20:09:07 +0800, Yang, Yi wrote:
> > So we must do many changes if we want to break this assumption.
> 
> We may do as many changes as we want to. This is uAPI we're talking
> about and we need to get it right since the beginning. Sure, it may
> mean that some user space programs need some changes in order to make
> use of the new features. That happens every day.
> 
> I also don't understand where's the problem. It's very easy to check
> for NLA_F_NESTED and generically act based on that in the function you
> quoted. Just call a different function than format_odp_key_attr to
> handle ovs_nsh_key_attr attributes in case the nested flag is set and
> the attribute is OVS_KEY_ATTR_NSH and you're done. You'll need such
> function anyway, it's not much different code size wise to call it from
> format_odp_key_attr or from format_odp_action.

But if we follow your way, how does nla_for_each_nested handle such
pattern?

attribute1
attribute1_mask
attribute2
attribute2_mask
attribute3
attribute3_mask

I don't think this can increase performance and readability.

In current way, we just call nla_for_each_nested twice

one is for

attribute1
attribute2
attribute3

another is for

attribute1_mask
attribute2_mask
attribute3_mask

if we use one function to handle both attributes and masks, I can't
see any substantial difference between two ways as far as the
performance is concerned.

So my proposal is we needn't introduce special handling case for
OVS_KEY_ATTR_NSH in OVS_ACTION_ATTR_SET_MASKED, that will open Pandora's
box.

If we consider OVS_KEY_ATTR_NSH as a big attribute, current way is
precisely following current design pattern

attribute
mask

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

Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH support

[Yang, Yi]

On Mon, Sep 04, 2017 at 07:22:26PM +0800, Hannes Frederic Sowa wrote:
> Hello,
> 
> "Yang, Yi" <yi.y.y...@intel.com> writes:
> 
> > On Wed, Aug 30, 2017 at 05:53:27PM +0800, Hannes Frederic Sowa wrote:
> >> Hello,
> >> 
> >> Yi Yang <yi.y.y...@intel.com> writes:
> >> 
> >> [...]
> >> 
> >> > +struct ovs_key_nsh {
> >> > +u8 flags;
> >> > +u8 ttl;
> >> > +u8 mdtype;
> >> > +u8 np;
> >> > +__be32 path_hdr;
> >> > +__be32 context[NSH_MD1_CONTEXT_SIZE];
> >> > +};
> >> > +
> >> >  struct sw_flow_key {
> >> >  u8 tun_opts[IP_TUNNEL_OPTS_MAX];
> >> >  u8 tun_opts_len;
> >> > @@ -144,6 +154,7 @@ struct sw_flow_key {
> >> >  };
> >> >  } ipv6;
> >> >  };
> >> > +struct ovs_key_nsh nsh; /* network service header */
> >> >  struct {
> >> >  /* Connection tracking fields not packed above. */
> >> >  struct {
> >> 
> >> Does it makes sense to keep the context headers as part of the flow?
> >> What is the reasoning behind it? With mdtype 2 headers this might either
> >> not work very well or will increase sw_flow_key size causing slowdowns
> >> for all protocols.
> >
> > For userspace, miniflow can handle such issue, but kernel data path
> > didn't provide such mechanism, so I don't think we can think of a better
> > way to fix this.
> 
> I do think that both, kernel and dpdk dp, are fine if you don't match on
> context fields, which I think is the common case.
> 
> As soon as a few paths start to match on contexts at different offsets I
> am not sure if miniflow will actually help. I don't know enough about
> that. Set cover is a NP hard problem, so constructing plain simple flows
> will be an approximation somewhere anyway at some point.
> 
> If the context values are in some way discrete it might make sense, but
> for load balancing purposes your ingress router might fill out one
> context field with a flow hash of the inner flow to allow ECMP or
> loadbalancing. You might want to treat that separately. Otherwise the
> different paths might always need to context[3] & 0x3 (bits as number of
> possible next hops) and put that into the flow state. Because every hop
> and every path might have different numbers of nexthops etc., I don't
> think this is easy unifiable anymore.

Anyway, this is a common issue but not NSH-implemention-specific issue.
In my perspective, kernel data path won't have better perfromance than
userspace DPDK data path, maybe you're considering hardware offload, but
so far there isn't an infrastructure in OVS to offload NSH.

> 
> > We have to have context headers in flow for match and set, every hop in
> > service function chaining can put its metedata into context headers on
> > demand, MD type 2 is much more complicated than you can imagine, it is
> > impossible to use an uniform way to handle MD type 1 and MD type 2, our
> > way is to keep MD type 1 keys in struct ovs_key_nsh and to reuse struct
> > flow_tnl for MD type 2 metadata, in case of MD type 2, we can set
> > context headers to 0 in struct ovs_key_nsh.
> 
> Understood and agreed.
> 
> > I beleive every newly-added key will result in similiar issue you
> > concern, maybe it will be better to introduce miniflow in kernel data
> > path, but it isn't in scope of this patch series.
> 
> You will see the same problem with offloading flows e.g. to network
> cards very soon. Flow explosion here will cause your 100Gbit/s NIC
> suddenly to go to software slow path.

Do you mean the whole OVS data path offload? As I said, this is a common
issue, it isn't NSH-specific.

> 
> > It will be great if you can have a better proposal to fix your concern.
> 
> I do think that something alike miniflow might make sense, but I don't
> know enough about miniflow.
> 
> New ACTIONS, that are not only bound to NSH, seem appealing to me at the
> moment. E.g. have a subtable match in the kernel dp or allowing for some
> OXM % modulo -> select action or neighbor alike thing would probably
> cover a lot of cases in the beginning. The submatch would probably very
> much reassemble the miniflow in dpdk dp.

I'm not sure what new action you expect to bring here, I think group
action is just for this, as you said it isn't only bound to NSH, you can
start a new thread to discuss this. I don't think it is in scope of NSH.

> 
> Thanks,
> Hannes
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

[Yang, Yi]

On Mon, Sep 04, 2017 at 12:42:16PM +0200, Jiri Benc wrote:
> On Mon, 4 Sep 2017 16:00:05 +0800, Yang, Yi wrote:
> > I think we have had similiar discussion about this, the issue is we have
> > no way to handle both MD type 1 and MD type 2 by using a common flow key 
> > struct.
> > 
> > So we have to do so, there is miniflow to handle such issue in
> > userspace, but kernel data path didn't provide such mechanism. I think
> > every newly-added key will result in the same space-wasting issue for
> > kernel data path, isn't it?
> 
> Yes. And it would be surprising if it didn't have an effect on
> performance.
> 
> I don't care that much as this is a result of openvswitch module design
> decisions but it still would be good to reach a consensus before
> implementing uAPI that might not be needed in the end.
> 
> > OVS_ATTR_KEY_NSH is the first case to use nested attributes for set
> > action, so no reference code for this, set action has two use cases, one
> > has mask but the other hasn't, so it will be easier an nested attribute is
> > handled as a whole, in user space, nsh_key_from_nlattr is used in
> > several places.
> 
> I very much disagree. What you're doing is very poor design as can be
> seen from the code where you have to do weird gymnastics to implement
> that. Compare that to a much simple case where each attribute carries
> its own value and mask.
> 
> > If we change it per your proposal, there will be a lot
> > of rework,
> 
> That's not an argument. We care about doing things right, we don't do
> things hastily and with as little effort as possible.

Jiri, I check OVS source code carefully, if you check OVS code in
format_odp_action in lib/odp-util.c, it has a strong assumption for set
action, mask is following value no matter it is simple attribute or
nested attribute, I copy source code here for your reference,

case OVS_ACTION_ATTR_SET_MASKED:
a = nl_attr_get(a);
size = nl_attr_get_size(a) / 2;
ds_put_cstr(ds, "set(");

/* Masked set action not supported for tunnel key, which is
 * bigger. */
if (size <= sizeof(struct ovs_key_ipv6)) {
struct nlattr attr[1 + DIV_ROUND_UP(sizeof(struct
ovs_key_ipv6),
sizeof(struct nlattr))];
struct nlattr mask[1 + DIV_ROUND_UP(sizeof(struct
ovs_key_ipv6),
sizeof(struct nlattr))];

mask->nla_type = attr->nla_type = nl_attr_type(a);
mask->nla_len = attr->nla_len = NLA_HDRLEN + size;
memcpy(attr + 1, (char *)(a + 1), size);
memcpy(mask + 1, (char *)(a + 1) + size, size);
format_odp_key_attr(attr, mask, NULL, ds, false);
} else {
format_odp_key_attr(a, NULL, NULL, ds, false);
}
ds_put_cstr(ds, ")");
break;

So we must do many changes if we want to break this assumption.

> 
> > we have to provide two functions to handle this, one is for
> > the case with mask, the other is for the case without mask.
> 
> I don't see that. The function is called from a single place only.
> 
> > How can we do so? I see batch process code in user space implementation,
> > but kernel data path didn't such infrastructure,
> 
> You're right that there's no infrastructure. I somewhat agree that it
> might be out of scope of this patch and it can be optimized later.
> That's why I also included other suggestions to speed this up until we
> implement better parsing: namely, verify correctness once (at the time
> it is set from user space) and just expect things to be correct in the
> fast path.
> 
> > how can we know next push_nsh uses the same nsh header as previous
> > one?
> 
> We store the prepopulated header together with the action.
> 
> > > Shouldn't we reject the packet, then? Pretending that something was parsed
> > > correctly while in fact it was not, does not look correct.
> > 
> > For MD type 2, we don't implement metadata parsing, but it can still
> > work. I'm not sure what you mean here, how do we reject a packet here?
> 
> Okay, we can match on mdtype and thus can find out about this type of
> packets. No problem, then.
> 
> > > These checks should be done only once when the action is configured, not 
> > > for
> > > each packet.
> > 
> > I don't know how to implement a batch processing in kernel data path, it
> > seems there isn't such code for reference.
> 
> The checks should be done somewhere in __ovs_nla_copy_action. Which
> seems to be done even in your patch by nsh_key_put_from_nlattr
> (I didn't get that far during the review last week. 

Re: [ovs-dev] [PATCH net-next v7] openvswitch: enable NSH support

[Yang, Yi]

On Thu, Aug 31, 2017 at 06:45:16PM +0800, Jiri Benc wrote:
> > +  mask->context[i]);
> > +   }
> > +   memcpy(flow_key->nsh.context, nsh->md1.context,
> > +  sizeof(nsh->md1.context));
> 
> Do you follow the discussion that Hannes Sowa started on the ovs list
> regarding matching on the context fields? It would be better to hold on this
> until there's a conclusion reached.
>

I think we have had similiar discussion about this, the issue is we have
no way to handle both MD type 1 and MD type 2 by using a common flow key struct.

So we have to do so, there is miniflow to handle such issue in
userspace, but kernel data path didn't provide such mechanism. I think
every newly-added key will result in the same space-wasting issue for
kernel data path, isn't it?

> > +   err = nsh_key_from_nlattr(, );
> > +   if (err)
> > +   break;
> > +   err = nsh_key_from_nlattr(, _mask);
> > +   if (err)
> > +   break;
> 
> This is a lot of copying to just be able to use nla_for_each_nested. While
> I'm not a fan of how ovs uses the attributes to store both value and mask,
> it's not completely irrational. However, I don't think that the intent was
> to store a copy of the whole nested group. It's quite obvious that it does
> not fit the pattern from the gymnastics you need to do.
> 
> Instead, store the mask in each of the nested attributes individually. There
> will be no need for the copying above and the code will get cleaner and
> faster. It's not that the nsh_key_from_nlattr function needs to be able to
> work separately for the key and mask. Nothing else than the line above uses
> this function. Just move the logic inside.
> 
> Actually, it seems it can be moved directly to set_nsh.

OVS_ATTR_KEY_NSH is the first case to use nested attributes for set
action, so no reference code for this, set action has two use cases, one
has mask but the other hasn't, so it will be easier an nested attribute is
handled as a whole, in user space, nsh_key_from_nlattr is used in
several places. If we change it per your proposal, there will be a lot
of rework, we have to provide two functions to handle this, one is for
the case with mask, the other is for the case without mask.

> 
> > +   err = set_nsh(skb, flow_key, , _mask);
> > +   break;
> > +   }
> > +
> > case OVS_KEY_ATTR_IPV4:
> > err = set_ipv4(skb, flow_key, nla_data(a),
> >get_mask(a, struct ovs_key_ipv4 *));
> > @@ -1210,6 +1336,21 @@ static int do_execute_actions(struct datapath *dp, 
> > struct sk_buff *skb,
> > case OVS_ACTION_ATTR_POP_ETH:
> > err = pop_eth(skb, key);
> > break;
> > +
> > +   case OVS_ACTION_ATTR_PUSH_NSH: {
> > +   u8 buffer[NSH_HDR_MAX_LEN];
> > +   struct nshhdr *nsh_hdr = (struct nshhdr *)buffer;
> > +   const struct nshhdr *nsh_src = nsh_hdr;
> > +
> > +   nsh_hdr_from_nlattr(nla_data(a), nsh_hdr,
> > +   NSH_HDR_MAX_LEN);
> 
> This is costly. This is called for every packet in the fast path. We should
> precompute and store the header instead.

How can we do so? I see batch process code in user space implementation,
but kernel data path didn't such infrastructure, how can we know next
push_nsh uses the same nsh header as previous one?

> > +   case NSH_M_TYPE2:
> > +   /* Don't support MD type 2 metedata parsing yet */
> > +   if (length < NSH_BASE_HDR_LEN)
> > +   return -EINVAL;
> 
> Shouldn't we reject the packet, then? Pretending that something was parsed
> correctly while in fact it was not, does not look correct.

For MD type 2, we don't implement metadata parsing, but it can still
work. I'm not sure what you mean here, how do we reject a packet here?

> 
> These checks should be done only once when the action is configured, not for
> each packet.

I don't know how to implement a batch processing in kernel data path, it
seems there isn't such code for reference.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH support

[Yang, Yi]

On Wed, Aug 30, 2017 at 05:53:27PM +0800, Hannes Frederic Sowa wrote:
> Hello,
> 
> Yi Yang  writes:
> 
> [...]
> 
> > +struct ovs_key_nsh {
> > +   u8 flags;
> > +   u8 ttl;
> > +   u8 mdtype;
> > +   u8 np;
> > +   __be32 path_hdr;
> > +   __be32 context[NSH_MD1_CONTEXT_SIZE];
> > +};
> > +
> >  struct sw_flow_key {
> > u8 tun_opts[IP_TUNNEL_OPTS_MAX];
> > u8 tun_opts_len;
> > @@ -144,6 +154,7 @@ struct sw_flow_key {
> > };
> > } ipv6;
> > };
> > +   struct ovs_key_nsh nsh; /* network service header */
> > struct {
> > /* Connection tracking fields not packed above. */
> > struct {
> 
> Does it makes sense to keep the context headers as part of the flow?
> What is the reasoning behind it? With mdtype 2 headers this might either
> not work very well or will increase sw_flow_key size causing slowdowns
> for all protocols.

For userspace, miniflow can handle such issue, but kernel data path
didn't provide such mechanism, so I don't think we can think of a better
way to fix this.

We have to have context headers in flow for match and set, every hop in
service function chaining can put its metedata into context headers on
demand, MD type 2 is much more complicated than you can imagine, it is
impossible to use an uniform way to handle MD type 1 and MD type 2, our
way is to keep MD type 1 keys in struct ovs_key_nsh and to reuse struct
flow_tnl for MD type 2 metadata, in case of MD type 2, we can set
context headers to 0 in struct ovs_key_nsh.

I beleive every newly-added key will result in similiar issue you
concern, maybe it will be better to introduce miniflow in kernel data
path, but it isn't in scope of this patch series.

It will be great if you can have a better proposal to fix your concern.

> 
> [...]
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v5 1/2] nsh: add new flow key 'ttl'

[Yang, Yi]

On Thu, Aug 31, 2017 at 09:27:36AM -0700, Ben Pfaff wrote:
> On Thu, Aug 31, 2017 at 09:23:34AM -0700, Ben Pfaff wrote:
> > On Wed, Aug 30, 2017 at 02:21:01AM +0800, Yi Yang wrote:
> > > IETF NSH draft will be approved by end of August, NSH header
> > > format has been finalized and won't be change anymore, so we
> > > need to follow this final spec to implement nsh.
> > > 
> > > kernel data path also needs finalized uAPIs, they can't be
> > > changed once they are merged.
> > > 
> > > This patch adds new nsh key 'ttl', bits of flags and mdtype
> > > fields are also changed to follow the final spec.
> > > 
> > > A new action dec_nsh_ttl will be added in the following patch.
> > > 
> > > Signed-off-by: Yi Yang 
> > 
> > This is a large change to just update the wire format.  Can you make it
> > more minimal?
> 
> Actually, let's skip it.  I think that we should release OVS 2.8 as is.
> We delayed the release mostly to get NSH in, because Jan said that it
> was important to them, but then it turns out that the NSH protocol is
> still changing?  What a waste.  I will not make that mistake again.

Ben, the confirmation I got from one of NSH draft authors is it won't be
changed except some text description, moreover it will be approved as
IETF RFC very soon. So I think you can consider this again. Maybe OVS
master can apply them if it is too late for OVS 2.8.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4 2/3] nsh: add new flow key 'ttl'

[Yang, Yi]

On Wed, Aug 30, 2017 at 01:02:07AM +0800, Jan Scheurich wrote:
> Hi Yi,
> 
> Some more comments below.
> 
> /Jan
> 
> > -Original Message-
> > From: Yang, Yi [mailto:yi.y.y...@intel.com]
> > Sent: Tuesday, 29 August, 2017 08:31
> > To: Jan Scheurich <jan.scheur...@ericsson.com>
> > Cc: d...@openvswitch.org; b...@ovn.org
> > Subject: Re: [PATCH v4 2/3] nsh: add new flow key 'ttl'
> > 
> > 
> > > > diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h
> > > > index a658a58..cd61fff 100644
> > > > --- a/include/openvswitch/flow.h
> > > > +++ b/include/openvswitch/flow.h
> > > > @@ -146,7 +146,7 @@ struct flow {
> > > >  struct eth_addr arp_tha;/* ARP/ND target hardware address. */
> > > >  ovs_be16 tcp_flags; /* TCP flags. With L3 to avoid 
> > > > matching L4.
> > */
> > > >  ovs_be16 pad2;  /* Pad to 64 bits. */
> > > > -struct flow_nsh nsh;/* Network Service Header keys */
> > > > +struct ovs_key_nsh nsh; /* Network Service Header keys */
> > >
> > > Why rename this type to struct ovs_key_nsh?
> > 
> > I have explained it in previous review, new ttl field results in it isn't 
> > 64 bit
> > aligned, moreover, we musnt't do some unnecessary conversion if we use
> > struct ovs_key_nsh, netlink also used struct ovs_key_nsh, it is very
> > reasonable to use struct ovs_key_nsh for this, why don't we use it?
> 
> Not arguing alignment here. That resulted in merging spi and si into path_hdr
> and is OK.
> 
> All structs ovs_key_xxx are defined in datapath/linux/.../openvswitch.h, 
> while all 
> structs flow_xxx are defined in lib/packets.h. You have defined struct 
> ovs_key_nsh in lib/packets.h and refer to it both in struct flow and in the 
> netlink attribute. This violates the standard practices. Even if they are
> isomorphic, I think we should have independent type definitions and a 
> (trivial)
> conversion function.

Jan, this is just a way we can aviod breaking kernel uAPI, I also
defined struct ovs_key_nsh in net/openvswitch/flow.h not in
datapath/linux/.../openvswitch.h in kernel datapath patch.

> 
> > >
> > > > +static inline void
> > > > +__nsh_set_xflag(struct nsh_hdr *nsh, uint16_t xflag, uint16_t
> > > > +xmask) {
> > > > +nsh->ver_flags_ttl_len
> > > > += (nsh->ver_flags_ttl_len & ~htons(xmask)) | htons(xflag);
> > > > +}
> > >
> > > Avoid __* prefix. Better call it nsh_set_base_hdr_masked().
> > 
> > We just use __ to mark it as an internal function which will not be used
> > outside of nsh.h, this is C coding convention.
> 
> The use of __* prefix is reserved for the C compiler. In OVS we typically 
> use *__ postfix for internal functions.

Ok, let me move __ as suffix.

> 
> > > > +static inline void nsh_set_flags_and_ttl(struct nsh_hdr *nsh, uint8_t
> > flags,
> > > > + uint8_t ttl) {
> > > > +__nsh_set_xflag(nsh, ((flags << NSH_FLAGS_SHIFT) &
> > > > NSH_FLAGS_MASK) |
> > > > + ((ttl << NSH_TTL_SHIFT) & NSH_TTL_MASK),
> > > > +NSH_FLAGS_MASK | NSH_TTL_MASK); }
> > > > +
> > > > +static inline void nsh_set_flags_ttl_len(struct nsh_hdr *nsh, uint8_t
> > flags,
> > > > + uint8_t ttl, uint8_t len)
> > > > +{
> > > > +len = len >> 2;
> > > > +__nsh_set_xflag(nsh, ((flags << NSH_FLAGS_SHIFT) &
> > > > NSH_FLAGS_MASK) |
> > > > + ((ttl << NSH_TTL_SHIFT) & NSH_TTL_MASK) |
> > > > + ((len << NSH_LEN_SHIFT) & NSH_LEN_MASK),
> > > > +NSH_FLAGS_MASK | NSH_TTL_MASK | NSH_LEN_MASK);
> > > > +}
> > >
> > > Do you really need to these hybrid functions? Why not use modular
> > functions nsh_set_flags(), nsh_set_ttl() and nsh_set_len()? I believe the 
> > run-
> > time overhead is negligible with an optimizing compiler.
> > 
> > Basically these three functions will be executed together, so one is better.
> 
> They are set in different combinations. I'd say it is better not have a 
> dedicated
> setter function for every required combination. Only a significant run-time 
> overhead might tempt one to introduce collapsed functions.
> 
> >

Re: [ovs-dev] [PATCH v4 2/3] nsh: add new flow key 'ttl'

[Yang, Yi]

On Tue, Aug 29, 2017 at 07:31:22AM +0800, Jan Scheurich wrote:
> Hi Yi,
> 
> Thanks for the fixes. Please find my individual comments inline.
> 
> BR, Jan
> 
> > -Original Message-
> > -#define OVS_ENCAP_NSH_MAX_MD_LEN 16
> >  /*
> >   * struct ovs_action_encap_nsh - %OVS_ACTION_ATTR_ENCAP_NSH
> >   * @flags: NSH header flags.
> > + * @ttl: NSH header TTL.
> >   * @mdtype: NSH metadata type.
> >   * @mdlen: Length of NSH metadata in bytes.
> >   * @np: NSH next_protocol: Inner packet type.
> > @@ -805,11 +796,13 @@ struct ovs_action_push_eth {
> >   */
> >  struct ovs_action_encap_nsh {
> >  uint8_t flags;
> > +uint8_t ttl;
> >  uint8_t mdtype;
> > -uint8_t mdlen;
> >  uint8_t np;
> >  __be32 path_hdr;
> > -uint8_t metadata[OVS_ENCAP_NSH_MAX_MD_LEN];
> > +uint8_t mdlen;
> > +uint8_t pad[7]; /* Aligned to 64 bit boundary for metadata */
> > +uint8_t metadata[];
> >  };
> 
> Alignment of metadata to 32 bits should suffice here. Netlink attrs are only 
> 4-byte aligned anyhow. The same goes for the MD1 context headers inside 
> metadata.
>

Ok, I will change it to pad[3].

> > diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h
> > index a658a58..cd61fff 100644
> > --- a/include/openvswitch/flow.h
> > +++ b/include/openvswitch/flow.h
> > @@ -146,7 +146,7 @@ struct flow {
> >  struct eth_addr arp_tha;/* ARP/ND target hardware address. */
> >  ovs_be16 tcp_flags; /* TCP flags. With L3 to avoid matching 
> > L4. */
> >  ovs_be16 pad2;  /* Pad to 64 bits. */
> > -struct flow_nsh nsh;/* Network Service Header keys */
> > +struct ovs_key_nsh nsh; /* Network Service Header keys */
> 
> Why rename this type to struct ovs_key_nsh?

I have explained it in previous review, new ttl field results in it
isn't 64 bit aligned, moreover, we musnt't do some unnecessary
conversion if we use struct ovs_key_nsh, netlink also used struct
ovs_key_nsh, it is very reasonable to use struct ovs_key_nsh for this,
why don't we use it?

> 
> > diff --git a/include/openvswitch/nsh.h b/include/openvswitch/nsh.h
> [...]
> > @@ -62,7 +210,7 @@ struct nsh_md2_tlv {
> >  };
> > 
> >  struct nsh_hdr {
> > -ovs_be16 ver_flags_len;
> > +ovs_be16 ver_flags_ttl_len;
> >  uint8_t md_type;
> >  uint8_t next_proto;
> >  ovs_16aligned_be32 path_hdr;
> > @@ -75,11 +223,16 @@ struct nsh_hdr {
> >  /* Masking NSH header fields. */
> >  #define NSH_VER_MASK   0xc000
> >  #define NSH_VER_SHIFT  14
> > -#define NSH_FLAGS_MASK 0x3fc0
> > -#define NSH_FLAGS_SHIFT6
> > +#define NSH_FLAGS_MASK 0x3000
> > +#define NSH_FLAGS_SHIFT12
> 
> With this definition of NSH FLAGS the match field NSH_FLAGS covers
> only the two bits between Version and TTL field. Bit 1 is the OaM flag, 
> bit 0 is currently unused. The remaining 4 unused bits between Length
> and MD Type fields are excluded. That is perhaps OK as we cannot be
> sure the these 4 bits will be used as "flags" in the future. But it needs
> to be documented clearly that NSH_FLAGS has only two bits and which
> bits in the NSH header it covers.

Make sense, we can add more information for this in lib/meta-flow.xml.

> 
> > +static inline void
> > +__nsh_set_xflag(struct nsh_hdr *nsh, uint16_t xflag, uint16_t xmask)
> > +{
> > +nsh->ver_flags_ttl_len
> > += (nsh->ver_flags_ttl_len & ~htons(xmask)) | htons(xflag);
> > +}
> 
> Avoid __* prefix. Better call it nsh_set_base_hdr_masked(). 

We just use __ to mark it as an internal function which will not be used
outside of nsh.h, this is C coding convention.

> 
> > +
> > +static inline void nsh_set_flags_and_ttl(struct nsh_hdr *nsh, uint8_t 
> > flags,
> > + uint8_t ttl)
> > +{
> > +__nsh_set_xflag(nsh, ((flags << NSH_FLAGS_SHIFT) &
> > NSH_FLAGS_MASK) |
> > + ((ttl << NSH_TTL_SHIFT) & NSH_TTL_MASK),
> > +NSH_FLAGS_MASK | NSH_TTL_MASK);
> > +}
> > +
> > +static inline void nsh_set_flags_ttl_len(struct nsh_hdr *nsh, uint8_t 
> > flags,
> > + uint8_t ttl, uint8_t len)
> > +{
> > +len = len >> 2;
> > +__nsh_set_xflag(nsh, ((flags << NSH_FLAGS_SHIFT) &
> > NSH_FLAGS_MASK) |
> > + ((ttl << NSH_TTL_SHIFT) & NSH_TTL_MASK) |
> > + ((len << NSH_LEN_SHIFT) & NSH_LEN_MASK),
> > +NSH_FLAGS_MASK | NSH_TTL_MASK | NSH_LEN_MASK);
> > +}
> 
> Do you really need to these hybrid functions? Why not use modular functions 
> nsh_set_flags(), nsh_set_ttl() and nsh_set_len()? I believe the run-time 
> overhead is negligible with an optimizing compiler.

Basically these three functions will be executed together, so one is
better.

> 
> For symmetry you should also add a function setter function for path_hdr:

I think put_16aligned_be32(>path_hdr, path_hdr) is better than
nsh_set_path_hdr, here isn't C++ programming :-)

Re: [ovs-dev] [PATCH v2 0/2] nsh: rework NSH netlink keys and actions

[Yang, Yi]

On Thu, Aug 24, 2017 at 04:24:07PM -0700, Ben Pfaff wrote:
> > 
> > Ok, I'll send patch 1 without datapath actions name change and netlink
> > change, but it isn't a good result if people see encap_nsh and decep_nsh
> > in 2.8 and see they are changed to push_nsh and pop_nsh in 2.9 and
> > later.
> 
> It doesn't look to me like these names are changing for OpenFlow
> actions.  Datapath actions are an implementation detail and keeping them
> 100% stable is not a priority.
> 
> > > Making 2.8 compliant with the NSH draft makes sense.
> > 
> > I have finished dec_nsh_ttl action patch, does it make sense for 2.8?
> 
> You can add that as a patch 3 in the next version and we'll take a look.
> 
> We want to release 2.8 next week.

I have sent them out as v4 and included patch 3 which is just for new
action dec_nsh_ttl, please review v4.

https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337877.html

> 
> Thanks,
> 
> Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 0/2] nsh: rework NSH netlink keys and actions

[Yang, Yi]

On Fri, Aug 25, 2017 at 01:39:29AM +0800, Ben Pfaff wrote:
> > do the below changes:
> > 
> > 1. change ecanp_nsh and decap_nsh to push_nsh and pop_nsh
> > 2. Use nested OVS_KEY_ATTR_NSH to handle push_nsh.
> > 
> > Patch 1 is precisely doing this way.
> 
> Since this is targeted at 2.8, I'm only planning to take actual bug
> fixes, or changes that affect Open vSwitch external interfaces where we
> historically maintain a high degree of backward compatibility.
> 
> In patch 1, it looks like the change to nsh_hdr_len() is a bug fix.  At
> a glance, I am not sure whether any of the other changes in patch 1 are
> bug fixes.
> 
> Also in patch 1, renaming and Netlink restructuring isn't a bug fix,
> doesn't appear to affect, say, OpenFlow action names, and it doesn't
> affect any ABIs, so it's not appropriate for 2.8.

Ok, I'll send patch 1 without datapath actions name change and netlink
change, but it isn't a good result if people see encap_nsh and decep_nsh
in 2.8 and see they are changed to push_nsh and pop_nsh in 2.9 and
later.

> 
> Making 2.8 compliant with the NSH draft makes sense.

I have finished dec_nsh_ttl action patch, does it make sense for 2.8?

> 
> Can you edit this series so that patch 1 is just bug fixes, and then
> re-send it?
> 
> Thanks,
> 
> Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v4] openvswitch: enable NSH support

[Yang, Yi]

On Mon, Aug 21, 2017 at 05:47:13PM +0800, Jiri Benc wrote:
> 
> > I don't know how we can support this, is it a must-have thing?
> 
> What would happen if you get a GSO packet? Ports of an ovs bridge claim
> GSO support, thus they may get a GSO packet. You have to handle it one
> way or the other: either software segment the packet before pushing the
> header, or implement proper GSO support for NSH.
> 

I checked GSO support code, we have two cases to handle, one case is to
output NSH packet to VxLAN-gpe port, the other case is to output NSH packet
to Ethernet port (tap, veth, vhost, physical eth, etc.), I don't think
it is a good way to do GSO support in OVS module, because we can't know
the final output port at this point, if the final output port is
VxLAN-gpe port, it will still face GSO issue, but I didn't see vxlan
module handles this, maybe udp tunnel did this. I think a NSH packet can
be split into two packets, one has NSH header, another one doesn't, so I'm not 
sure how vxlan module can avoid this situation.

For the second case, we can add a nsh GSO module in net/nsh/nsh_gso.c (as MPLS 
did in net/mpls/mpls_gso.c), that is the best way to handle this, what do you
think about it?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v4] openvswitch: enable NSH support

[Yang, Yi]

On Mon, Aug 21, 2017 at 05:47:13PM +0800, Jiri Benc wrote:
> On Mon, 21 Aug 2017 17:15:42 +0800, Yang, Yi wrote:
> > The issue is it is used union in
> > 
> > struct nsh_hdr {
> > ovs_be16 ver_flags_ttl_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;
> > };
> > };
> 
> This should work (modulo the non-kernel type names, of course). Did you
> mean to put [] after md2?

Yes, the original version has [] after md2.

> 
> > in Linux kernel build, it complained it, I changed it to
> 
> What was the error message?

./include/net/nsh.h:213:25: error: flexible array member in union
  struct nsh_md2_tlv md2[];
 ^

> 
> > struct nsh_hdr {
> > ovs_be16 ver_flags_ttl_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];
> > };
> > };
> 
> I wouldn't use this. First, zero length array is a GCC extension. It
> would indeed be better not to use that in uAPI. Second, I wouldn't even
> use a flexible array member here, see my reply to Jan for the reasons.
> 
> Note that I commented on struct nsh_md2_tlv having __u8[] as the last
> member which IMHO makes good sense. I'm not entirely sure what C99 says
> about flexible array member being part of a struct inside union inside
> a struct, though. GCC seems to cope with that just fine but AFAIK it
> has some extension over the C standard wrt. flexible array members.

Yes, if struct nsh_md2_tlv has  __u8[] as last field, 

struct nsh_md2_tlv {
__be16 md_class;
u8 type;
u8 length;
u8 md_value[];
};

struct nsh_hdr {
__be16 ver_flags_ttl_len;
u8 md_type;
u8 next_proto;
__be32 path_hdr;
union {
struct nsh_md1_ctx md1;
struct nsh_md2_tlv md2;
};
};

it is ok, so let us use this one.

> 
> > I don't know how we can support this, is it a must-have thing?
> 
> What would happen if you get a GSO packet? Ports of an ovs bridge claim
> GSO support, thus they may get a GSO packet. You have to handle it one
> way or the other: either software segment the packet before pushing the
> header, or implement proper GSO support for NSH.

This is an issue, I'll investigate it and find a way to handle this.

> 
> > But struct nsh_hdr had different struct from struct ovs_key_nsh, we
> > have no way to make them completely same, do you mean we should use the
> > same name if they are same fields and represent the same thing?
> 
> Yes.
> 
> Thanks,
> 
>  Jiri
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v4] openvswitch: enable NSH support

[Yang, Yi]

On Fri, Aug 18, 2017 at 09:26:01PM +0800, Jiri Benc wrote:
> On Fri, 18 Aug 2017 15:24:31 +0800, Yi Yang wrote:
> > +struct nsh_md2_tlv {
> > +   __be16 md_class;
> > +   u8 type;
> > +   u8 length;
> > +   /* Followed by variable-length data. */
> > +};
> 
> What was wrong with the u8[] field that was present at the end of the
> struct in the previous version of the patch?

In OVS code, it has been removed because of Microsoft compiler issue.

> 
> > +#define NSH_M_TYPE2_MAX_LEN 256
> 
> This is defined twice, please delete this define and keep the one lower
> in the file.

Removed duplicate one in v5.

> 
> > +#define NSH_DST_PORT4790 /* UDP Port for NSH on VXLAN. */
> 
> This is a VXLAN-GPE port, it has nothing to do with NSH (except that
> VXLAN-GPE can contain a NSH packet). It's also unused. Please remove it.
> 

Removed in v5.

> > +/* NSH Metadata Length. */
> > +#define NSH_M_TYPE1_MDLEN 16
> 
> This is unused and it seems it's not much useful anyway,
> sizeof(struct nsh_md1_ctx) provides the same value. Please remove this
> define.

Removed in v5.

> 
> > +#define NSH_MD1_CTX(nsh_hdr_ptr) (&(nsh_hdr_ptr)->md1)
> > +
> > +#define NSH_MD2_CTX(nsh_hdr_ptr) (&(nsh_hdr_ptr)->md2)
> 
> Please remove these two. They are unused and would just obscure things
> anyway.
> 
> > +static inline struct nsh_md1_ctx *nsh_md1_ctx(struct nsh_hdr *nsh)
> > +{
> > +   return >md1;
> > +}
> > +
> > +static inline struct nsh_md2_tlv *nsh_md2_ctx(struct nsh_hdr *nsh)
> > +{
> > +   return >md2;
> > +}
> 
> And remove these too, for the same reason. Just use nsh->md1 when you
> need the metadata, there's no reason for these helper functions. They
> just obscure things.
> 

Removed them in v5

> > +static inline void nsh_set_flags_and_ttl(struct nsh_hdr *nsh, u8 flags, u8 
> > ttl)
> > +{
> > +   nsh->ver_flags_ttl_len
> > +   = htons((ntohs(nsh->ver_flags_ttl_len)
> > +   & ~(NSH_FLAGS_MASK | NSH_TTL_MASK))
> > +   | ((flags << NSH_FLAGS_SHIFT) & NSH_FLAGS_MASK)
> > +   | ((ttl << NSH_TTL_SHIFT) & NSH_TTL_MASK));
> > +}
> > +
> > +static inline void nsh_set_flags_ttl_len(struct nsh_hdr *nsh, u8 flags,
> > +u8 ttl, u8 len)
> > +{
> > +   nsh->ver_flags_ttl_len
> > +   = htons((ntohs(nsh->ver_flags_ttl_len)
> > +   & ~(NSH_FLAGS_MASK | NSH_TTL_MASK | NSH_LEN_MASK))
> > +   | ((flags << NSH_FLAGS_SHIFT) & NSH_FLAGS_MASK)
> > +   | ((ttl << NSH_TTL_SHIFT) & NSH_TTL_MASK)
> > +   | ((len << NSH_LEN_SHIFT) & NSH_LEN_MASK));
> > +}
> 
> Okay. Could those two perhaps use a common function?
> 
> static inline void __nsh_set_flags(struct nsh_hdr *nsh, u16 value, u16 mask)
> {
>   nsh->ver_flags_ttl_len = nsh->ver_flags_ttl_len & ~htons(mask)
>   | htons(value);
> }
> 
> static inline void nsh_set_flags_and_ttl(struct nsh_hdr *nsh, u8 flags, u8 
> ttl)
> {
>   __nsh_set_flags(nsh, flags << NSH_FLAGS_SHIFT | ttl << NSH_TTL_SHIFT,
>   NSH_FLAGS_MASK | NSH_TTL_MASK);
> }
> 
> etc.

Thanks for this good suggestion, applied in v5 with small change.

> 
> > +static int push_nsh(struct sk_buff *skb, struct sw_flow_key *key,
> > +   const struct nsh_hdr *nsh_src)
> > +{
> [...]
> > +   if (!skb->inner_protocol)
> > +   skb_set_inner_protocol(skb, skb->protocol);
> 
> I was wondering about this during the reviews of the previous versions.
> Now I've given this more thought but I still don't see it - why is the
> inner_protocol set here?

I saw push_mpls has it, so also set it.

> 
> > +   case OVS_KEY_ATTR_NSH: {
> > +   struct ovs_key_nsh nsh;
> > +   struct ovs_key_nsh nsh_mask;
> > +   size_t size = nla_len(a) / 2;
> > +   struct nlattr attr[1 + size / sizeof(struct nlattr) + 1];
> > +   struct nlattr mask[1 + size / sizeof(struct nlattr) + 1];
> > +
> > +   attr->nla_type = nla_type(a);
> > +   mask->nla_type = attr->nla_type;
> > +   attr->nla_len = NLA_HDRLEN + size;
> > +   mask->nla_len = attr->nla_len;
> > +   memcpy(attr + 1, (char *)(a + 1), size);
> > +   memcpy(mask + 1, (char *)(a + 1) + size, size);
> 
> No, please. See my reply to the previous version for how to do this in
> a less hacky way.

I have used your proposal in previous comments and have it in v5.

> 
> > +   case OVS_ACTION_ATTR_PUSH_NSH: {
> > +   u8 buffer[256];
> > +   struct nsh_hdr *nsh_hdr = (struct nsh_hdr *)buffer;
> > +   const struct nsh_hdr *nsh_src = nsh_hdr;
> > +
> > +   nsh_hdr_from_nlattr(nla_data(a), nsh_hdr);
> 
> This is very dangerous security wise. You have to protect against
> buffer overflow, one way or other. The current code may not overflow
> (I have not checked that, though) but a future addition may break the
> 

Re: [ovs-dev] [PATCH v2 1/2] nsh: rework NSH netlink keys and actions

[Yang, Yi]

On Fri, Aug 18, 2017 at 11:02:35PM +0800, Jan Scheurich wrote:
> > diff --git a/datapath/linux/compat/include/linux/openvswitch.h
> > b/datapath/linux/compat/include/linux/openvswitch.h
> > index bc6c94b..d7f9029 100644
> > --- a/datapath/linux/compat/include/linux/openvswitch.h
> > +++ b/datapath/linux/compat/include/linux/openvswitch.h
>  
> > +#define NSH_MD1_CONTEXT_SIZE 4
> [Jan] This shouldn’t be needed here and replaced by a macro defined in nsh.h

Jan, this is indeed needed here, context[4] won't work because ovs
script will convert array[4] in

datapath/linux/compat/include/linux/openvswitch.h

To a special type, so we have to hack this. In addition,
datapath/linux/compat/include/linux/openvswitch.h shouldn't include
nsh.h anyway.

>  
> > +#define OVS_PUSH_NSH_MAX_MD_LEN 248
> [Jan] This shouldn’t be needed here and replaced by a macro defined in nsh.h
>

ok, I'll remove it from here.
  
> > diff --git a/include/openvswitch/nsh.h b/include/openvswitch/nsh.h
> > index f4ccadc..ed9054e 100644
> > --- a/include/openvswitch/nsh.h
> > +++ b/include/openvswitch/nsh.h
>  
>  
> >  struct nsh_md2_tlv {
> > @@ -72,6 +72,8 @@ struct nsh_hdr {
> >  };
> >  };
> >
> > +#define NSH_M_TYPE2_MAX_LEN 256
> [Jan] This is a duplicate definition (see below)
>

Noted, will remove it.
  
>  
> > +/* NSH MD Type 2 header maximum Length. */
> > +#define NSH_M_TYPE2_MAX_LEN 256
> [Jan] I suggest to rename this to NSH_HEADER_MAX_LEN as it is generic limit 
> for
> any MD type, not only MD2, resulting from the fact that the length in 4 byte
> words is encoded in 6 bits.
>  
> Add a macro NSH_CONTEXT_HDRS_MAX_LEN 248 and use that instead of
> OVS_PUSH_NSH_MAX_MD_LEN.
>  

Ok, will use macros you suggest to replace them.

> >  static inline uint16_t
> >  nsh_hdr_len(const struct nsh_hdr *nsh)
> >  {
> > -return 4 * (ntohs(nsh->ver_flags_len) & NSH_LEN_MASK) >>
> > NSH_LEN_SHIFT;
> > +return ((ntohs(nsh->ver_flags_len) & NSH_LEN_MASK) >>
> > NSH_LEN_SHIFT) << 2;
> [Jan] I personally find 4 * X clearer than X << 2 when the purpose really is 
> to
> multiply by 4 rather than to shift left by two bits. The compiler should
> generate similar code with -O2 anyhow.
>

The issue is it is incorrect, Eric Garver told me operator ">>" will be
done before operator "*", it can run correctly just because
NSH_LEN_SHIFT is zero, so the new one is right.

"* 4" and "<< 2" have same readability, we mustn't argue such issue
here.

> > diff --git a/include/openvswitch/packets.h b/include/openvswitch/packets.h
> > index be91e02..5ee3099 100644
> > --- a/include/openvswitch/packets.h
> > +++ b/include/openvswitch/packets.h
> > @@ -84,7 +84,16 @@ struct flow_nsh {
> >  uint8_t np;
> >  uint8_t si;
> >  ovs_be32 spi;
> > -ovs_be32 c[4];
> > +ovs_be32 context[4];
> > +};
> > +
> > +struct ovs_key_nsh {
> > +uint8_t flags;
> > +uint8_t mdtype;
> > +uint8_t np;
> > +uint8_t pad;
> > +ovs_be32 path_hdr;
> > +ovs_be32 context[4];
> >  };
> 
> [Jan] I see in the second patch that you use this new struct as replacement 
> for
> struct flow_nsh in struct flow. The main difference being that the new struct
> combines spi and si fields into the path_hdr. That is of course possible
> provided that the necessary conversions are made where needed, but I doubt 
> that
> it improves readability in the code overall.
>  
> Was the main motivation to use the same data type both in struct flow as well
> as in the datapath for set(nsh) operations? Or did you want to prevent struct
> flow_nsh spilling over into 25 bytes as the spare octet used for the si field
> is now needed for the new ttl field?
>  
> I believe in the datapath the NSH key attributes could be parsed into an NSH
> header struct directly, no need to have an struct ovs_key_nsh.

Jan, struct flow_nsh must be 64 bits aligned, new key ttl broke this.
struct ovs_key_nsh is the stuff we transfer by netlink, kernel data path 
struct sw_flow_key also uses it. struct ovs_key_nsh is very appropriate
to do this in struct flow, it is very natural way to do right thing.

A field corresponding to multiple keys is noraml if you check ovs code,
mpls_lse is a typical case.

> > @@ -572,11 +574,12 @@ parse_nsh(const void **datap, size_t *sizep,
> > struct flow_nsh *key)
> >  switch (key->mdtype) {
> >  case NSH_M_TYPE1:
> >  for (size_t i = 0; i < 4; i++) {
> > -key->c[i] = get_16aligned_be32(>md1.c[i]);
> > +key->context[i] = get_16aligned_be32(>md1.context[i]);
> >  }
> >  break;
> >  case NSH_M_TYPE2:
> > -/* Don't support MD type 2 yet, so return false */
> > +/* Don't support MD type 2 metedata parsing yet */
> > +break;
> >  default:
> >  return false;
>  
> [Jan] There is no need to return false here. If the md_type is unknown we 
> don’t
> parse the context headers, but we can still continue processing the NSH 

Re: [ovs-dev] [PATCH v2 0/2] nsh: rework NSH netlink keys and actions

[Yang, Yi]

On Sat, Aug 19, 2017 at 01:36:57AM +0800, Ben Pfaff wrote:
> On Fri, Aug 18, 2017 at 07:38:56AM +0800, Yi Yang wrote:
> > v1->v2
> >   - Rework per kernel datapath review comments
> >   - Add new NSH key ttl
> >   - Add many helpers in nsh.h and replace much code
> > with these helpers
> >   - nsh.h includes the lasted NSH spec
> >   - bits of flags and mdtype have a change
> > 
> > This patch seires reworks NSH netlink keys and actions
> > per kernel datapath requirments. OVS_KEY_ATTR_NSH is
> > changed as a nested key, encap_nsh and decap_nsh are
> > renamed as push_nsh and pop_nsh. PUSH_NSH used nested
> > OVS_KEY_ATTR_NSH keys to transfer NSH header data.
> > 
> > It also adds new NSH key 'ttl' to follow the lasted
> > IETF NSH draft:
> > 
> > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
> > 
> > I have double confirmed from one of its authors, this
> > is a final version which will be approved as IETF RFC,
> > the NSH header format won't be change anymore.
> 
> I think it's very wise to make 2.8 compliant with the latest NSH draft.
> It looks like that's patch 2.
> 
> It seems less valuable to me to rework the internals other than to gain
> this compliance, since as far as I can tell the kernel-side details are
> still under review and have not been applied to net-next.  I don't think
> it's worth closely tracking the proposals there.
> 
> Would you mind sending a patch that just makes the NSH implementation
> compliant with the latest Internet-Draft, without irrelevant changes?
> That is more suitable for a stable branch.
> 
> Thanks,

Forgot addressing patch 1, I think all the people have agreed we need to
do the below changes:

1. change ecanp_nsh and decap_nsh to push_nsh and pop_nsh
2. Use nested OVS_KEY_ATTR_NSH to handle push_nsh.

Patch 1 is precisely doing this way.
> 
> Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 0/2] nsh: rework NSH netlink keys and actions

[Yang, Yi]

On Sat, Aug 19, 2017 at 01:36:57AM +0800, Ben Pfaff wrote:
> On Fri, Aug 18, 2017 at 07:38:56AM +0800, Yi Yang wrote:
> > v1->v2
> >   - Rework per kernel datapath review comments
> >   - Add new NSH key ttl
> >   - Add many helpers in nsh.h and replace much code
> > with these helpers
> >   - nsh.h includes the lasted NSH spec
> >   - bits of flags and mdtype have a change
> > 
> > This patch seires reworks NSH netlink keys and actions
> > per kernel datapath requirments. OVS_KEY_ATTR_NSH is
> > changed as a nested key, encap_nsh and decap_nsh are
> > renamed as push_nsh and pop_nsh. PUSH_NSH used nested
> > OVS_KEY_ATTR_NSH keys to transfer NSH header data.
> > 
> > It also adds new NSH key 'ttl' to follow the lasted
> > IETF NSH draft:
> > 
> > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
> > 
> > I have double confirmed from one of its authors, this
> > is a final version which will be approved as IETF RFC,
> > the NSH header format won't be change anymore.
> 
> I think it's very wise to make 2.8 compliant with the latest NSH draft.
> It looks like that's patch 2.
> 
> It seems less valuable to me to rework the internals other than to gain
> this compliance, since as far as I can tell the kernel-side details are
> still under review and have not been applied to net-next.  I don't think
> it's worth closely tracking the proposals there.
> 
> Would you mind sending a patch that just makes the NSH implementation
> compliant with the latest Internet-Draft, without irrelevant changes?
> That is more suitable for a stable branch.

Ben, I'm not sure what part you mean is irreleant change. I remove
struct flow_nsh and use struct ovs_key_nsh because a new field ttl
result in struct flow_nsh isn't 64 bits aligned, I think it is better
to use struct ovs_key_nsh, path_hdr corresponds to two keys spi and si
this isn't my invention, mpls_lse is just such case, it even
corresponds n keys :-)

Most part is optimization because the same struct in struct flow and in
netlink, so we can use memcpy to replace multiple assignment statements.

In my perspective, this version is clearer. I do test them before I send
them, so don't worry stability issue, my real sfc test environment can
make sure this.

So please do let me know what parts I have to keep intact.

> 
> Thanks,
> 
> Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3] openvswitch: enable NSH support

[Yang, Yi]

On Wed, Aug 16, 2017 at 11:15:28PM +0800, Eric Garver wrote:
> On Wed, Aug 16, 2017 at 01:35:30PM +0800, Yi Yang wrote:
> > +
> > +#define NSH_DST_PORT4790 /* UDP Port for NSH on VXLAN. */
> > +#define ETH_P_NSH   0x894F   /* Ethertype for NSH. */
> 
> ETH_P_NSH probably belongs in include/uapi/linux/if_ether.h with all the
> other ETH_P_* defines.
> 

Ok, I'll move it to include/uapi/linux/if_ether.h, but in userspace, we
still need to keep it in nsh.h.

> >  
> > +struct ovs_key_nsh {
> > +   __u8 flags;
> > +   __u8 mdtype;
> > +   __u8 np;
> > +   __u8 pad;
> > +   __be32 path_hdr;
> > +   __be32 context[NSH_MD1_CONTEXT_SIZE];
> > +};
> > +
> >  struct sw_flow_key {
> > u8 tun_opts[IP_TUNNEL_OPTS_MAX];
> > u8 tun_opts_len;
> > @@ -144,6 +154,7 @@ struct sw_flow_key {
> > };
> > } ipv6;
> > };
> > +   struct ovs_key_nsh nsh; /* network service header */
> 
> Are you intentionally not reserving space in the flow key for
> OVS_NSH_KEY_ATTR_MD2? I know it's not supported yet, but much of the
> code is stubbed out for it - just making sure this wasn't an oversight.
> 

For MD type 2, we'll reuse tun_metedata keys in struct flow_tnl which
will be reworked and it will be shared by NSH and GENEVE, so we won't
have new keys in "struct ovs_key_nsh" for MD type 2.

> > struct {
> > /* Connection tracking fields not packed above. */
> > struct {
> > diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> > index f07d10a..79059db 100644
> > --- a/net/openvswitch/flow_netlink.c
> > +++ b/net/openvswitch/flow_netlink.c
> > @@ -78,9 +78,11 @@ static bool actions_may_change_flow(const struct nlattr 
> > *actions)
> > case OVS_ACTION_ATTR_HASH:
> > case OVS_ACTION_ATTR_POP_ETH:
> > case OVS_ACTION_ATTR_POP_MPLS:
> > +   case OVS_ACTION_ATTR_POP_NSH:
> > case OVS_ACTION_ATTR_POP_VLAN:
> > case OVS_ACTION_ATTR_PUSH_ETH:
> > case OVS_ACTION_ATTR_PUSH_MPLS:
> > +   case OVS_ACTION_ATTR_PUSH_NSH:
> > case OVS_ACTION_ATTR_PUSH_VLAN:
> > case OVS_ACTION_ATTR_SAMPLE:
> > case OVS_ACTION_ATTR_SET:
> > @@ -322,12 +324,22 @@ size_t ovs_tun_key_attr_size(void)
> > + nla_total_size(2);   /* OVS_TUNNEL_KEY_ATTR_TP_DST */
> >  }
> >  
> > +size_t ovs_nsh_key_attr_size(void)
> > +{
> > +   /* Whenever adding new OVS_NSH_KEY_ FIELDS, we should consider
> > +* updating this function.
> > +*/
> > +   return  nla_total_size(8)  /* OVS_NSH_KEY_ATTR_BASE */
> > +   + nla_total_size(16)   /* OVS_NSH_KEY_ATTR_MD1 */
> > +   + nla_total_size(248); /* OVS_NSH_KEY_ATTR_MD2 */
> 
> _MD1 and _MD2 are mutually exclusive. You only need the larger of the
> two.
> 
> Maybe use OVS_PUSH_NSH_MAX_MD_LEN instead of 248.

Got it, will use nla_total_size(NSH_M_TYPE2_MAX_LEN - NSH_BASE_HDR_LEN)

> > +
> > +   switch (type) {
> > +   case OVS_NSH_KEY_ATTR_BASE: {
> > +   const struct ovs_nsh_key_base *base =
> > +   (struct ovs_nsh_key_base *)nla_data(a);
> > +   nsh->flags = base->flags;
> > +   nsh->mdtype = base->mdtype;
> > +   nsh->np = base->np;
> > +   nsh->path_hdr = base->path_hdr;
> > +   break;
> > +   }
> > +   case OVS_NSH_KEY_ATTR_MD1: {
> > +   const struct ovs_nsh_key_md1 *md1 =
> > +   (struct ovs_nsh_key_md1 *)nla_data(a);
> > +   memcpy(nsh->context, md1->context, sizeof(*md1));
> > +   break;
> > +   }
> > +   case OVS_NSH_KEY_ATTR_MD2:
> > +   /* Not supported yet */
> > +   break;
> 
> When we encounter these metadata attributes do we need to verify that
> nsh->mdtype is set correctly? Keep in mind we may parse ATTR_MD{1,2}
> before ATTR_BASE.

Good point, will add check code for this.

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

Re: [ovs-dev] [PATCH v3] openvswitch: enable NSH support

[Yang, Yi]

On Wed, Aug 16, 2017 at 10:03:22PM +0800, Jiri Benc wrote:
> On Wed, 16 Aug 2017 17:31:30 +0800, Yang, Yi wrote:
> > On Wed, Aug 16, 2017 at 11:19:21AM +0200, Jiri Benc wrote:
> > > > --- a/include/uapi/linux/openvswitch.h
> > > > +++ b/include/uapi/linux/openvswitch.h
> > > [...]
> > > > +#define NSH_MD1_CONTEXT_SIZE 4
> > > 
> > > Please move this to nsh.h and use it there, too, instead of the open
> > > coded 4.
> > 
> > ovs code is very ugly, it will convert array[4] in
> > datapath/linux/compat/include/linux/openvswitch.h to other struct, I
> > have to change context[4] to such format :-), we can use 4 here for
> > Linux kernel.
> 
> Oh, right, this is uAPI and nsh.h is kernel internal. My suggestion was
> nonsense, let's keep it as it was in your patch.
> 
> > > > +   case OVS_KEY_ATTR_NSH: {
> > > > +   struct ovs_key_nsh nsh;
> > > > +   struct ovs_key_nsh nsh_mask;
> > > > +   size_t size = nla_len(a) / 2;
> > > > +   struct nlattr attr[1 + DIV_ROUND_UP(sizeof(struct 
> > > > ovs_key_ipv6)
> > > > +   , sizeof(struct 
> > > > nlattr))];
> > > > +   struct nlattr mask[1 + DIV_ROUND_UP(sizeof(struct 
> > > > ovs_key_ipv6)
> > > > +   , sizeof(struct 
> > > > nlattr))];
> > > > +
> > > > +   attr->nla_type = nla_type(a);
> > > > +   mask->nla_type = attr->nla_type;
> > > > +   attr->nla_len = NLA_HDRLEN + size;
> > > > +   mask->nla_len = attr->nla_len;
> > > > +   memcpy(attr + 1, (char *)(a + 1), size);
> > > > +   memcpy(mask + 1, (char *)(a + 1) + size, size);
> > > 
> > > This is too hacky. Please find a better way to handle this.
> > > 
> > > One option is to create a struct with struct nlattr as the first member
> > > followed by a char buffer. Still not nice but at least it's clear
> > > what's the intent.
> > 
> > The issue is nested attributes only can use this way, nested attribute
> > for SET_MASKED is very special, we have to handle it specially.
> 
> I'm not sure you understood what I meant. Let me explain in code:
> 
>   struct {
>   struct nlattr attr;
>   struct ovs_key_ipv6 data;
>   } attr, mask;
> 
>   attr->attr.nla_type = nla_type(a);
>   attr->attr.nl_len = NLA_HDRLEN + size;
>   memcpy(>data, a + 1, size);
> 
> It's much less hacky and doing the same thing.
> 
> I'm not sure we don't need verification of size not overflowing the
> available buffer. Is it checked beforehand elsewhere?
> 
> I also spotted one more bug: the 'mask' variable is not used anywhere.
> The second call of nsh_key_from_nlattr should use mask, not attr.
>

I have verified it in my real sfc test environment, but it is indeed
a bug, because mask and attr are same, so the result is still attr.

But here attr and mask shoud be of "struct nlattr attr", I'll polish it.
 
> > > > +   key->nsh.path_hdr = nsh->path_hdr;
> > > > +   switch (key->nsh.mdtype) {
> > > > +   case NSH_M_TYPE1:
> > > > +   if ((length << 2) != NSH_M_TYPE1_LEN)
> > > 
> > > Why length << 2?
> > 
> > len in NSH header is number of 4 octets, so need to multiply 4.
> 
> Should nsh_get_len take care of that, then?
> 

There are two helpers for this, nsh_hdr_len gets actual length,
nsh_get_len gets "len" field in nsh header.

> Thanks,
> 
>  Jiri
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3] openvswitch: enable NSH support

[Yang, Yi]

On Wed, Aug 16, 2017 at 11:19:21AM +0200, Jiri Benc wrote:
> Please always CC reviewers of the previous versions, thanks.

Jiri, thank you for quick review. Sorry, I made a mistake on
sending and missed all the CCs, will indeed do this in next version.

> > +   __be16 ver_flags_len;
> > +   u8 md_type;
> > +   u8 next_proto;
> > +   __be32 path_hdr;
> > +   u8 metadata[NSH_M_TYPE2_MAX_LEN-8];
> > +};
> 
> Please get rid of this struct. It's a copy of struct nsh_hdr with some
> space added to the bottom.
> 
> One of the options (though maybe not the best one, feel free to come up
> with something better) is to change struct nsh_md1_ctx to:
> 
> struct nsh_md1_ctx {
>   __be32 context[];
> };
> 
> and change struct push_nsh_para:
> 
> struct push_nsh_para {
>   struct nsh_hdr hdr;
>   u8 metadata[NSH_M_TYPE2_MAX_LEN-8];
> };
> 
> Another option (a better one, though a bit more work) is to get rid of
> push_nsh_para completely and just pass a properly allocated nsh_hdr
> around. Introduce macros and/or functions to help with the allocation.
>

Yeah, good point, we can use dynamic allocation and struct nsh_hdr * to
handle this.

> > +static inline struct nsh_md1_ctx *nsh_md1_ctx(struct nsh_hdr *nsh)
> > +{
> > +   return >md1;
> > +}
> > +
> > +static inline struct nsh_md2_tlv *nsh_md2_ctx(struct nsh_hdr *nsh)
> > +{
> > +   return nsh->md2;
> > +}
> 
> These are unused, please remove them.

Will remove them, userspace does use them.

> 
> > --- a/include/uapi/linux/openvswitch.h
> > +++ b/include/uapi/linux/openvswitch.h
> [...]
> > +#define NSH_MD1_CONTEXT_SIZE 4
> 
> Please move this to nsh.h and use it there, too, instead of the open
> coded 4.

ovs code is very ugly, it will convert array[4] in
datapath/linux/compat/include/linux/openvswitch.h to other struct, I
have to change context[4] to such format :-), we can use 4 here for
Linux kernel.

> 
> > +static int push_nsh(struct sk_buff *skb, struct sw_flow_key *key,
> > +   const struct push_nsh_para *pnp)
> > +{
> > +   struct nsh_hdr *nsh;
> > +   size_t length = ((ntohs(pnp->ver_flags_len) & NSH_LEN_MASK)
> > +>> NSH_LEN_SHIFT) << 2;
> 
> Once push_nsh_para is removed/changed, this can be changed to a call to
> nsh_hdr_len.

Yes, will do that way.

> 
> > +   flags = (ntohs(nsh->ver_flags_len) & NSH_FLAGS_MASK) >>
> > +   NSH_FLAGS_SHIFT;
> 
> nsh_get_flags

Missed this one :-)

> 
> > +   case OVS_KEY_ATTR_NSH: {
> > +   struct ovs_key_nsh nsh;
> > +   struct ovs_key_nsh nsh_mask;
> > +   size_t size = nla_len(a) / 2;
> > +   struct nlattr attr[1 + DIV_ROUND_UP(sizeof(struct ovs_key_ipv6)
> > +   , sizeof(struct nlattr))];
> > +   struct nlattr mask[1 + DIV_ROUND_UP(sizeof(struct ovs_key_ipv6)
> > +   , sizeof(struct nlattr))];
> > +
> > +   attr->nla_type = nla_type(a);
> > +   mask->nla_type = attr->nla_type;
> > +   attr->nla_len = NLA_HDRLEN + size;
> > +   mask->nla_len = attr->nla_len;
> > +   memcpy(attr + 1, (char *)(a + 1), size);
> > +   memcpy(mask + 1, (char *)(a + 1) + size, size);
> 
> This is too hacky. Please find a better way to handle this.
> 
> One option is to create a struct with struct nlattr as the first member
> followed by a char buffer. Still not nice but at least it's clear
> what's the intent.

The issue is nested attributes only can use this way, nested attribute
for SET_MASKED is very special, we have to handle it specially.

> 
> > +static int parse_nsh(struct sk_buff *skb, struct sw_flow_key *key)
> > +{
> > +   struct nsh_hdr *nsh = (struct nsh_hdr *)skb_network_header(skb);
> > +   u8 version, length;
> > +   u32 path_hdr;
> > +   int i;
> > +
> > +   memset(>nsh, 0, sizeof(struct ovs_key_nsh));
> > +   version = nsh_get_ver(nsh);
> > +   length = nsh_get_len(nsh);
> > +
> > +   key->nsh.flags = nsh_get_flags(nsh);
> > +   key->nsh.mdtype = nsh->md_type;
> > +   key->nsh.np = nsh->next_proto;
> > +   path_hdr = ntohl(nsh->path_hdr);
> 
> The path_hdr variable is unused.

Will remove it.

> 
> > +   key->nsh.path_hdr = nsh->path_hdr;
> > +   switch (key->nsh.mdtype) {
> > +   case NSH_M_TYPE1:
> > +   if ((length << 2) != NSH_M_TYPE1_LEN)
> 
> Why length << 2?

len in NSH header is number of 4 octets, so need to multiply 4.

> 
> > +   return -EINVAL;
> > +
> > +   for (i = 0; i < 4; i++)
> 
> NSH_MD1_CONTEXT_SIZE

Ok

> 
> > +   key->nsh.context[i] = nsh->md1.context[i];
> > +
> > +   break;
> 
> Will go through the rest later. Feel free to send a new version
> meanwhile.
> 
> Thanks,
> 
>  Jiri

Thank you so much for your comments, will work out new version ASAP.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v2] openvswitch: enable NSH support

[Yang, Yi]

On Tue, Aug 15, 2017 at 12:09:14AM +0800, Eric Garver wrote:
> On Thu, Aug 10, 2017 at 09:21:15PM +0800, Yi Yang wrote:
> 
> Hi Yi,
> 
> In general I'd like to echo Jiri's comments on the netlink attributes.
> I'd like to see the metadata separate.
> 
> I have a few other comments below.
> 
> Thanks.
> Eric.
> 
> [..]

Thanks Eric, I'm doing this and it is almost done, there is still an
issue to fix.

> > +{
> > +   return 4 * (ntohs(nsh->ver_flags_len) & NSH_LEN_MASK) >> NSH_LEN_SHIFT;
> 
> This is doing the multiplication before the shift. It works only because
> the shift is 0.
> 

Thank you for catching this, the right one:

((ntohs(nsh->ver_flags_len) & NSH_LEN_MASK) >> NSH_LEN_SHIFT) << 2

> > +static int push_nsh(struct sk_buff *skb, struct sw_flow_key *key,
> > +   const struct ovs_action_push_nsh *oapn)
> > +{
> > +   struct nsh_hdr *nsh;
> > +   size_t length = NSH_BASE_HDR_LEN + oapn->mdlen;
> > +   u8 next_proto;
> > +
> > +   if (key->mac_proto == MAC_PROTO_ETHERNET) {
> > +   next_proto = NSH_P_ETHERNET;
> > +   } else {
> > +   switch (ntohs(skb->protocol)) {
> > +   case ETH_P_IP:
> > +   next_proto = NSH_P_IPV4;
> > +   break;
> > +   case ETH_P_IPV6:
> > +   next_proto = NSH_P_IPV6;
> > +   break;
> > +   case ETH_P_NSH:
> > +   next_proto = NSH_P_NSH;
> > +   break;
> > +   default:
> > +   return -ENOTSUPP;
> > +   }
> > +   }
> > +
> >
> 
> I believe you need to validate that oapn->mdlen is a multiple of 4.
>

I'll add this check.

> > +   switch (nsh->md_type) {
> > +   case NSH_M_TYPE1:
> > +   nsh->md1 = *(struct nsh_md1_ctx *)oapn->metadata;
> > +   break;
> > +   case NSH_M_TYPE2: {
> > +   /* The MD2 metadata in oapn is already padded to 4 bytes. */
> > +   size_t len = DIV_ROUND_UP(oapn->mdlen, 4) * 4;
> > +
> > +   memcpy(nsh->md2, oapn->metadata, len);
> 
> I don't see any validation of oapn->mdlen. Normally this happens in
> __ovs_nla_copy_actions(). It will be made easier if you add a separate
> MD attribute as Jiri has suggested.
>

Got it, will include this in next version.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v2] openvswitch: enable NSH support

[Yang, Yi]

On Fri, Aug 11, 2017 at 11:44:49AM +0200, Jiri Benc wrote:
> On Fri, 11 Aug 2017 09:24:25 +0000, Yang, Yi Y wrote:
> > 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.
> 
> Please do not top post.

Sorry for this inconvenience, I'm using outlook. But now I have to use
mutt to address your concern :-)

> 
> The context field does not apply to MD type 2. It looks wrong for the
> context field to be included in netlink attribute for anything other
> than MD type 1. Perhaps it needs to be put into a separate attribute,
> too?
> 
> Note that I'm talking only about the uAPI. Internally, ovs can use
> struct ovs_key_nsh that is MD type 1 only, there's no problem changing
> that later. But for the user space interface, this needs to be clean.
> This can be solved for example this way:
> 
> In include/uapi/linux/openvswitch.h:
> 
> struct ovs_key_nsh_base {
>   __u8 flags;
>   __u8 mdtype;
>   __u8 np;
>   __u8 pad;
>   __be32 path_hdr;
> };
> 
> + one more netlink attribute carrying MD type 1 info. Will probably
> require to change OVS_KEY_ATTR_NSH to a nested attribute etc.
> 
> In net/openvswitch/flow.h (or perhaps a different header would be more
> appropriate?):
> 
> struct ovs_key_nsh {
>   struct ovs_key_nsh_base base;
>   __be32 context[4];
> };
> 
> Plus needed conversions between OVS_KEY_ATTR_NSH and struct ovs_key_nsh
> when interfacing between the kernel and user space.
> 
> That way, we can have MD type 1 support only for now while still being
> allowed to redesign things in whatever way later.

Yeah, good suggestion, will try to do that way.

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

Re: [ovs-dev] [PATCH net-next v2] openvswitch: enable NSH support

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
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 v2] openvswitch: enable NSH support

[Yang, Yi]

On Fri, Aug 11, 2017 at 10:24:18AM +0200, Jiri Benc wrote:
> On Thu, 10 Aug 2017 21:21:15 +0800, Yi Yang wrote:
> > OVS master and 2.8 branch has merged NSH userspace
> > patch series, this patch is to enable NSH support
> > in kernel data path in order that OVS can support
> > NSH in 2.8 release in compat mode by porting this.
> 
> Please include changelog when posting a new version of a patch.
> 
> > +static inline u16
> > +nsh_hdr_len(const struct nsh_hdr *nsh)
> 
> Single line, please. And all other instances of this in nsh.h, too.

Thanks Jiri, I'll change these in next version.

> 
> > --- a/include/uapi/linux/openvswitch.h
> > +++ b/include/uapi/linux/openvswitch.h
> > @@ -333,6 +333,7 @@ enum ovs_key_attr {
> > OVS_KEY_ATTR_CT_LABELS, /* 16-octet connection tracking label */
> > 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 */
> >  
> >  #ifdef __KERNEL__
> > OVS_KEY_ATTR_TUNNEL_INFO,  /* struct ip_tunnel_info */
> > @@ -491,6 +492,15 @@ struct ovs_key_ct_tuple_ipv6 {
> > __u8   ipv6_proto;
> >  };
> >  
> > +struct ovs_key_nsh {
> > +   __u8 flags;
> > +   __u8 mdtype;
> > +   __u8 np;
> > +   __u8 pad;
> > +   __be32 path_hdr;
> > +   __be32 c[4];
> 
> I still don't like the "c" name. Please change it to something
> descriptive. This is uAPI and can't be changed later.

is "__be32 context[4]" ok?

> 
> And I still don't see my comment about this not being extensible for
> MD type 2 addressed. Please understand this is uAPI and it is set in
> stone once it is merged into the kernel. It's very important we get
> this right since the beginning.

I understood it, but I don't know how I can do this per your comments,

Per Ben's comments,

PUSH_NSH message looks like

PUSH_NSH begin
nsh base header
MD type 1
PUSH_NSH end

or 

PUSH_NSH begin
nsh base header
MD type 2
PUSH_NSH end

If so, I think we don't need struct ovs_action_push_nsh at all, just as
_CT action did, treat it as a variable data buffer.

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?

> 
> > +struct ovs_action_push_nsh {
> > +   __u8 flags;
> > +   __u8 mdtype;
> > +   __u8 mdlen;
> > +   __u8 np;
> > +   __be32 path_hdr;
> > +   __u8 metadata[];
> > +};
> 
> This is not how netlink attributes work. Please reread Ben Pfaff's
> explanation on how this needs to be structured (Message-ID:
> <20170809180912.gu6...@ovn.org>) and rework the patch. I 100% agree
> with what he wrote, his proposal is very clean and matches how netlink
> is designed.
> 
> > @@ -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_PUSH_NSH, /* struct ovs_action_push_nsh. */
> > +   OVS_ACTION_ATTR_POP_NSH,  /* No argument. */
> 
> Thank you for changing this to push/pop, it looks much cleaner now.
> 
> > +static int parse_nsh(struct sk_buff *skb, struct sw_flow_key *key)
> > +{
> > +   struct nsh_hdr *nsh = (struct nsh_hdr *)skb_network_header(skb);
> > +   u16 ver_flags_len;
> > +   u8 version, length;
> > +   u32 path_hdr;
> > +   int i;
> > +
> > +   memset(>nsh, 0, sizeof(struct ovs_key_nsh));
> > +   ver_flags_len = ntohs(nsh->ver_flags_len);
> > +   version = (ver_flags_len & NSH_VER_MASK) >> NSH_VER_SHIFT;
> > +   length = (ver_flags_len & NSH_LEN_MASK) >> NSH_LEN_SHIFT;
> 
> A nit: the operation to get/set version, length and flags from the NSH
> header seems to be repeated enough to warrant helper functions in
> include/net/nsh.h. Something like:
> 
> static inline u8 nsh_get_version(const struct nsh_hdr *nsh)
> {
>   return (ntohs(nsh->ver_flags_len) & NSH_VER_MASK) >> NSH_VER_SHIFT;
> }
> 
> etc.
> 
> Not a blocker, though, it may be done later if needed.

Ok, will change it.

> 
> > @@ -76,9 +77,11 @@ static bool actions_may_change_flow(const struct nlattr 
> > *actions)
> >  
> > case OVS_ACTION_ATTR_CT:
> > case OVS_ACTION_ATTR_HASH:
> > +   case OVS_ACTION_ATTR_POP_NSH:
> > case OVS_ACTION_ATTR_POP_ETH:
> > case OVS_ACTION_ATTR_POP_MPLS:
> > case OVS_ACTION_ATTR_POP_VLAN:
> > +   case OVS_ACTION_ATTR_PUSH_NSH:
> > case OVS_ACTION_ATTR_PUSH_ETH:
> > case OVS_ACTION_ATTR_PUSH_MPLS:
> > case OVS_ACTION_ATTR_PUSH_VLAN:
> 
> Alphabetical order, 

Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
Cc: Jan Scheurich <jan.scheur...@ericsson.com>; d...@openvswitch.org; 
net...@vger.kernel.org; Jiri Benc <jb...@redhat.com>; da...@davemloft.net; 
Zoltán Balogh <zoltan.bal...@ericsson.com>
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 <yi.y.y...@intel.com>
> Cc: Jan Scheurich <jan.scheur...@ericsson.com>; d...@openvswitch.org; 
> net...@vger.kernel.org; Jiri Benc <jb...@redhat.com>; 
> da...@davemloft.net; Zoltán Balogh <zoltan.bal...@ericsson.com>
> 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 
> > _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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
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 <yi.y.y...@intel.com>
> 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 <yi.y.y...@intel.com>
> 
> 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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
Cc: Jan Scheurich <jan.scheur...@ericsson.com>; d...@openvswitch.org; 
net...@vger.kernel.org; Jiri Benc <jb...@redhat.com>; da...@davemloft.net; 
Zoltán Balogh <zoltan.bal...@ericsson.com>
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 _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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
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 <yi.y.y...@intel.com>

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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
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 <yi.y.y...@intel.com>
---
 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, , "flags=%"SCNi8, _nsh.flags)) {
+if (ovs_scan_len(s, , "flags=%"SCNi8, _nsh->flags)) {
 continue;
 }
-if (ovs_scan_len(s, , "mdtype=%"SCNi8, _nsh.mdtype)) {
-switch (encap_nsh.mdtype) {
+if (ovs_scan_len(s, , "mdtype=%"SCNi8, _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, , "np=%"SCNi8, _nsh.np)) {
+if (ovs_scan_len(s, , "np=%"SCNi8, _nsh->np)) {
 continue;
 }
 if (ovs_scan_len(s, , "spi=0x%"SCNx32, )) {
-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, , "si=%"SCNi8, )) {
-encap_nsh.path_hdr =
+encap_nsh->path_hdr =
 htonl((si << NSH_SI_SHIFT) |
-(ntohl(encap_nsh.path_hdr) & ~NSH_SI_MASK));
+(ntohl(encap_nsh->path_hdr) & 
+ ~NSH_SI_MASK))

Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support

[Yang, Yi Y]

OVS_ENCAP_NSH_MAX_MD_LEN);
 ofpbuf_put_hex(, buf, );
-encap_nsh.mdlen = mdlen;
+encap_nsh->mdlen = mdlen;
 ofpbuf_uninit();
 }
 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,
-  _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(>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,
-  _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 <b...@ovn.org>; Yang, Yi Y <yi.y.y...@intel.com>
Cc: d...@openvswitch.org; net...@vger.kernel.org; Jiri Benc <jb...@redhat.com>; 
da...@davemloft.net; Zoltán Balogh <zoltan.bal...@ericsson.com>
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() operation. They are 
translated by the ofproto layer and forwarded as opaque byte sequence in the 
encap

Re: [ovs-dev] [PATCH net-next] openvswitch: add NSH support

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
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 v2 0/6] Generic Encap & Decap based NSH implementation

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
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] [PATCH v4 1/2] OF support and translation of generic encap and decap

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
Cc: d...@openvswitch.org; Jan Scheurich <jan.scheur...@ericsson.com>; Zoltan 
Balogh <zoltan.bal...@ericsson.com>
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 <yi.y.y...@intel.com>
> Cc: d...@openvswitch.org; Jan Scheurich <jan.scheur...@ericsson.com>; 
> Zoltan Balogh <zoltan.bal...@ericsson.com>
> 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 <jan.scheur...@ericsson.com>
> > 
> > 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 <jan.scheur...@ericsson.com>
> > Signed-off-by: Yi Yang <yi.y.y...@intel.com>
> > Signed-off-by: Zoltan Balogh <zoltan.bal...@ericsson.com>
> > Co-authored-by: Zoltan Balogh <zoltan.bal...@ericsson.com>
> 
> 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

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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
Cc: d...@openvswitch.org; Jan Scheurich <jan.scheur...@ericsson.com>; Zoltan 
Balogh <zoltan.bal...@ericsson.com>
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 <jan.scheur...@ericsson.com>
> 
> 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 <jan.scheur...@ericsson.com>
> Signed-off-by: Yi Yang <yi.y.y...@intel.com>
> Signed-off-by: Zoltan Balogh <zoltan.bal...@ericsson.com>
> Co-authored-by: Zoltan Balogh <zoltan.bal...@ericsson.com>

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..6bb

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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
Cc: d...@openvswitch.org; Jan Scheurich <jan.scheur...@ericsson.com>; Zoltan 
Balogh <zoltan.bal...@ericsson.com>
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 <jan.scheur...@ericsson.com>
> 
> 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 <jan.scheur...@ericsson.com>
> Signed-off-by: Yi Yang <yi.y.y...@intel.com>
> Signed-off-by: Zoltan Balogh <zoltan.bal...@ericsson.com>
> Co-authored-by: Zoltan Balogh <zoltan.bal...@ericsson.com>

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 = of

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

[Yang, Yi Y]

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 
> 

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

[Yang, Yi Y]

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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>
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

[Yang, Yi Y]

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 <yi.y.y...@intel.com>; d...@openvswitch.org
Cc: Mengke Liu <mengke@intel.com>; Li, Ricky <ricky...@intel.com>; Li, 
Johnson <johnson...@intel.com>
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, , "flags", encap_nsh->flags, UINT8_MAX);
+format_u

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

[Yang, Yi Y]

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 <yi.y.y...@intel.com>; Amar Padmanabhan 
<amarpadmanab...@fb.com>; Joe Stringer <j...@ovn.org>; Wieger IJntema 
<wieger.ijntema@gmail.com>
Cc: ovs dev <d...@openvswitch.org>; Pablo Neira Ayuso <pa...@netfilter.org>; 
Harald Welte <lafo...@gnumonks.org>
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 <jan.scheur...@ericsson.com>; Amar Padmanabhan 
> <amarpadmanab...@fb.com>; Joe Stringer <j...@ovn.org>; Wieger IJntema 
> <wieger.ijntema@gmail.com>
> Cc: ovs dev <d...@openvswitch.org>; Pablo Neira Ayuso 
> <pa...@netfilter.org>; Harald Welte <lafo...@gnumonks.org>
> 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 <amarpadmanab...@fb.com>; Joe Stringer 
> <j...@ovn.org>; Wieger IJntema <wieger.ijntema@gmail.com>
> Cc: ovs dev <d...@openvswitch.org>; Pablo Neira Ayuso 
> <pa...@netfilter.org>; Harald Welte <lafo...@gnumonks.org>
> 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 t

Re: [ovs-dev] [PATCH v1 0/2] Add GTP vport based on upstream datapath

[Yang, Yi Y]

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 

Re: [ovs-dev] [PATCH 5/6] Generic encap and decap support for NSH

[Yang, Yi Y]

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 <yi.y.y...@intel.com>; 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