Re: [ovs-dev] [PATCH v8 1/2] OVN: Enable E-W Traffic, Vlan backed DVR

2019-05-10 Thread 0-day Robot
Bleep bloop.  Greetings Ankur Sharma, I am a robot and I have tried out your 
patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


checkpatch:
WARNING: Line lacks whitespace around operator
#627 FILE: ovn/utilities/ovn-nbctl.c:575:
  ls-add [SWITCH] [TYPE]create a logical switch named SWITCH of TYPE \n\

Lines checked: 1063, Warnings: 1, Errors: 0


Please check this out.  If you feel there has been an error, please email 
acon...@bytheb.org

Thanks,
0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH v8 2/2] OVN: Enable N-S Traffic, Vlan backed DVR

2019-05-10 Thread Ankur Sharma
Background:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
[2] 
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing

This Series:
Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
backed distributed logical router.

This patch:
For North-South traffic, we need a chassis which will respond to
ARP requests for router port coming from outside. For this purpose,
we will reply upon gateway-chassis construct in OVN, on a logical
router port, we will associate one or more chassis as gateway chassis.

One of these chassis would be active at a point and will become
entry point to traffic, bound for end points behind logical router
coming from outside network (North to South).

This patch make some enhancements to gateway chassis implementation
to manage above used case.

A.
Do not replace router port mac with chassis mac on gateway
chassis.
This is done, because:
i. Chassisredirect port is NOT a distributed port, hence
   we need not replace its mac address
  (which same as router port mac).

   ii. ARP cache will be consistent everywhere, i.e just like
   endpoints on OVN chassis will see configured router port
   mac as resolved mac for router port ip, outside endpoints
   will see that as well.

  iii. For implementing Network Address Translation. Although
   not a part of this series. But, follow up series would
   be having this feature and approach would rely upon
   sending packets to redirect chassis using chassis redirect
   router port mac as dest mac.

B.
Advertise router port GARP on gateway chassis.
This is needed, especially if a failover happens and
chassisredirect port moves to a new gateway chassis.
Otherwise, there would be packet drops till outside
router ARPs for router port ip again.

Intention of this GARP is to update top of the rack (TOR)
to direct router port mac to new hypervisor.

Hence, we could have done the same using RARP as well, but
because ovn-controller has implementation for GARP already,
hence it did not look like worthy to add a RARP implementation
just for this.

C.
For South to North traffic, we need not pass through gateway
chassis, if there is no address transalation needed.

For overlay networks, NATing is a must to talk to outside networks.
However, for vlan backed networks, NATing is not a must, and hence
in the absence of NATing configuration we need redirect the packet
to gateway chassis.

Signed-off-by: Ankur Sharma 
---
 ovn/controller/physical.c  |  24 +++-
 ovn/controller/pinctrl.c   | 205 ++
 ovn/controller/pinctrl.h   |   6 +
 ovn/lib/ovn-util.c |  31 +
 ovn/lib/ovn-util.h |   6 +
 ovn/northd/ovn-northd.c|  43 +--
 ovn/ovn-architecture.7.xml |  87 -
 tests/ovn.at   | 307 -
 8 files changed, 665 insertions(+), 44 deletions(-)

diff --git a/ovn/controller/physical.c b/ovn/controller/physical.c
index fb4aaa0..2aad279 100644
--- a/ovn/controller/physical.c
+++ b/ovn/controller/physical.c
@@ -21,6 +21,7 @@
 #include "lflow.h"
 #include "lport.h"
 #include "chassis.h"
+#include "pinctrl.h"
 #include "lib/bundle.h"
 #include "openvswitch/poll-loop.h"
 #include "lib/uuid.h"
@@ -235,9 +236,12 @@ get_zone_ids(const struct sbrec_port_binding *binding,
 }
 
 static void
-put_replace_router_port_mac_flows(const struct
+put_replace_router_port_mac_flows(struct ovsdb_idl_index
+  *sbrec_port_binding_by_name,
+  const struct
   sbrec_port_binding *localnet_port,
   const struct sbrec_chassis *chassis,
+  const struct sset *active_tunnels,
   const struct hmap *local_datapaths,
   struct ofpbuf *ofpacts_p,
   ofp_port_t ofport,
@@ -278,8 +282,21 @@ put_replace_router_port_mac_flows(const struct
 char *err_str = NULL;
 struct match match;
 struct ofpact_mac *replace_mac;
+char *cr_peer_name = xasprintf("cr-%s", rport_binding->logical_port);
 
-/* Table 65, priority 150.
+
+if (pinctrl_is_chassis_resident(sbrec_port_binding_by_name,
+chassis, active_tunnels,
+cr_peer_name)) {
+/* If a router port's chassisredirect port is
+ * resident on this chassis, then we need not do mac replace. */
+free(cr_peer_name);
+continue;
+}
+
+free(cr_peer_name);
+
+   /* Table 65, priority 150.
  * ===
  *
  * Implements output to localnet port.
@@ -791,7 +808,8 @@ consider_port_binding(struct ovsdb_idl_index 
*sbrec_port_binding_by_name,
 , 

[ovs-dev] [PATCH v8 0/2] OVN: Distributed Virtual Router for Vlan Backed Networks

2019-05-10 Thread Ankur Sharma
This series is about enhancing the logical router functionality in OVN to work
with vlan backed logical switches.

Intial proposal was discused here:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
[2] 
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing

This series covers following:
a. L2:
   Associate a type with logical switches. Type value could be vlan or bridged.

b. L3 E-W:
   In the absence of encapsulation, we cannot use router port mac as source mac
   (since it is distributed), hence replace the same with a chassis unique mac.

c. L3 N-S:
   Use gateway-chassis construct to respond to ARP requests for router port,
   so that it becomes entry point for all chassis bound traffic coming from
   "external" network.
   Some additional changes, like no need to redirect south to north traffic
   in the absence of NAT etc.

This series does not cover following:
(will be sent out for review in follow up series once this series is 
reviewed/committed)
a. Network Address Translation.
b. Ensuring VMs mac is learnt in underlay network to avoid flooding of L3 flows.

v7 -> v8

  * Handled Numan's review comments.

v6 -> v7

  * Added packet flow details in ovn-architecture.

v5 -> v6

  * Handled Numan's review comments.


v4 -> v5

  * Changed the network_type value to "bridged" instead of "vlan".

v3 -> v4

  * Improved documentation and commit message.
  * Converted the patchset to 2 patches.
  * Changes in nbctl to NOT set to network_type during logical switch create.
  * Fixed 3 space indentation.

v2 -> v3
-
  * Rebased with TOT.

v1 -> v2
--
  * Fixed unit tests and review comments.

Ankur Sharma (2):
  OVN: Enable E-W Traffic, Vlan backed DVR
  OVN: Enable N-S Traffic, Vlan backed DVR

 ovn/controller/binding.c|  12 +-
 ovn/controller/chassis.c|  64 -
 ovn/controller/chassis.h|   4 +
 ovn/controller/ovn-controller.8.xml |  10 +
 ovn/controller/ovn-controller.c |   2 +-
 ovn/controller/ovn-controller.h |   5 +-
 ovn/controller/physical.c   | 113 
 ovn/controller/pinctrl.c| 205 +--
 ovn/controller/pinctrl.h|   6 +
 ovn/lib/ovn-util.c  |  31 +++
 ovn/lib/ovn-util.h  |   6 +
 ovn/northd/ovn-northd.c |  81 +-
 ovn/ovn-architecture.7.xml  | 111 +++-
 ovn/ovn-nb.ovsschema|  10 +-
 ovn/ovn-nb.xml  |  18 ++
 ovn/ovn-sb.xml  |  15 ++
 ovn/utilities/ovn-nbctl.c   |  49 +++-
 tests/ovn-nbctl.at  |  48 +++-
 tests/ovn-northd.at |  22 ++
 tests/ovn.at| 502 
 20 files changed, 1242 insertions(+), 72 deletions(-)

-- 
1.8.3.1

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


[ovs-dev] [PATCH v8 1/2] OVN: Enable E-W Traffic, Vlan backed DVR

2019-05-10 Thread Ankur Sharma
Background:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
[2] 
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing

This Series:
Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
backed distributed logical router.

This patch:

A.
Key difference between an overlay logical switch and
vlan backed logical switch is that for vlan logical switches
packets are not encapsulated.

Hence, if a distributed router port is connected to vlan type
logical switch, then router port mac as source mac could be
seen from multiple hypervisors. Same  pairs coming
from multiple ports from a top of the rack switch (TOR) perspective
could be seen as a security threat and it could send alarms, drop
the packets or block the ports etc.

This patch addresses the same by introducing the concept of chassis mac.
A chassis mac is CMS provisioned unique mac per chassis. For any routed packet
(i.e source mac is router port mac) going on the wire on a vlan type
logical switch, we will replace its source mac with chassis mac.

This replacing of source mac with chassis mac will happen in table=65
of the logical switch datapath. A flow is added at priority 150, which
matches the source mac and replaces it with chassis mac if the value
is a router port mac.

Example flow:
cookie=0x0, duration=67765.830s, table=65, n_packets=0, n_bytes=0,
idle_age=65534, hard_age=65534, priority=150,reg15=0x1,metadata=0x4,
dl_src=00:00:01:01:02:03 actions=mod_dl_src:aa:bb:cc:dd:ee:ff,
mod_vlan_vid:1000,output:16

Here, 00:00:01:01:02:03 is router port mac and aa:bb:cc:dd:ee:ff
is chassis mac.

B.
This patch adds one more change of associating "types" with logical
switches. i.e a logical switch could be of type "overlay" or "bridged".
This is done to explicitly call out that on a bridged logical
switch there will no encapsulation.
Just a localnet port's presence is not sufficient, as we do
encap while redirecting the packet to gateway chassis.
By marking the logical switch as bridged, we can either
avoid redirection totally (if there is no NAT) or do redirection
based on router port mac, rather than encap over a tunnel.

Signed-off-by: Ankur Sharma 
---
 ovn/controller/binding.c|  12 +--
 ovn/controller/chassis.c|  64 +++-
 ovn/controller/chassis.h|   4 +
 ovn/controller/ovn-controller.8.xml |  10 ++
 ovn/controller/ovn-controller.c |   2 +-
 ovn/controller/ovn-controller.h |   5 +-
 ovn/controller/physical.c   |  95 +
 ovn/northd/ovn-northd.c |  38 +++
 ovn/ovn-architecture.7.xml  |  24 +
 ovn/ovn-nb.ovsschema|  10 +-
 ovn/ovn-nb.xml  |  19 
 ovn/ovn-sb.xml  |  15 +++
 ovn/utilities/ovn-nbctl.c   |  49 +++--
 tests/ovn-nbctl.at  |  48 ++---
 tests/ovn-northd.at |  22 
 tests/ovn.at| 197 
 16 files changed, 582 insertions(+), 32 deletions(-)

diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
index 404f0e7..e9461ef 100644
--- a/ovn/controller/binding.c
+++ b/ovn/controller/binding.c
@@ -159,13 +159,11 @@ add_local_datapath__(struct ovsdb_idl_index 
*sbrec_datapath_binding_by_key,
  sbrec_port_binding_by_name,
  peer->datapath, false,
  depth + 1, local_datapaths);
-ld->n_peer_dps++;
-ld->peer_dps = xrealloc(
-ld->peer_dps,
-ld->n_peer_dps * sizeof *ld->peer_dps);
-ld->peer_dps[ld->n_peer_dps - 1] = datapath_lookup_by_key(
-sbrec_datapath_binding_by_key,
-peer->datapath->tunnel_key);
+ld->n_peer_ports++;
+ld->peer_ports = xrealloc(ld->peer_ports,
+  ld->n_peer_ports *
+  sizeof *ld->peer_ports);
+ld->peer_ports[ld->n_peer_ports - 1] = peer;
 }
 }
 }
diff --git a/ovn/controller/chassis.c b/ovn/controller/chassis.c
index 0f537f1..8403212 100644
--- a/ovn/controller/chassis.c
+++ b/ovn/controller/chassis.c
@@ -23,6 +23,7 @@
 #include "lib/vswitch-idl.h"
 #include "openvswitch/dynamic-string.h"
 #include "openvswitch/vlog.h"
+#include "openvswitch/ofp-parse.h"
 #include "ovn/lib/chassis-index.h"
 #include "ovn/lib/ovn-sb-idl.h"
 #include "ovn-controller.h"
@@ -69,6 +70,12 @@ get_bridge_mappings(const struct smap *ext_ids)
 }
 
 static const char *
+get_chassis_mac_mappings(const struct smap *ext_ids)
+{
+return smap_get_def(ext_ids, "ovn-chassis-mac-mappings", "");
+}
+
+static const char *
 get_cms_options(const struct smap *ext_ids)
 {
 

Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan backed DVR

2019-05-10 Thread Ankur Sharma
Hi Numan,

Thanks for trying out the patch.
Please find my comments inline.

Regards,
Ankur

From: Numan Siddique 
Sent: Friday, May 10, 2019 5:44 AM
To: Ankur Sharma 
Cc: ovs-dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan backed DVR



On Thu, May 9, 2019 at 4:29 AM Ankur Sharma 
mailto:ankur.sha...@nutanix.com>> wrote:
Background:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html 
[mail.openvswitch.org]
[2] 
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
 
[docs.google.com]

This Series:
Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
backed distributed logical router.

This patch:
For North-South traffic, we need a chassis which will respond to
ARP requests for router port coming from outside. For this purpose,
we will reply upon gateway-chassis construct in OVN, on a logical
router port, we will associate one or more chassis as gateway chassis.

One of these chassis would be active at a point and will become
entry point to traffic, bound for end points behind logical router
coming from outside network (North to South).

This patch make some enhancements to gateway chassis implementation
to manage above used case.

A.
Do not replace router port mac with chassis mac on gateway
chassis.
This is done, because:
i. Chassisredirect port is NOT a distributed port, hence
   we need not replace its mac address
  (which same as router port mac).

   ii. ARP cache will be consistent everywhere, i.e just like
   endpoints on OVN chassis will see configured router port
   mac as resolved mac for router port ip, outside endpoints
   will see that as well.

  iii. For implementing Network Address Translation. Although
   not a part of this series. But, follow up series would
   be having this feature and approach would rely upon
   sending packets to redirect chassis using chassis redirect
   router port mac as dest mac.

B.
Advertise router port GARP on gateway chassis.
This is needed, especially if a failover happens and
chassisredirect port moves to a new gateway chassis.
Otherwise, there would be packet drops till outside
router ARPs for router port ip again.

Intention of this GARP is to update top of the rack (TOR)
to direct router port mac to new hypervisor.

Hence, we could have done the same using RARP as well, but
because ovn-controller has implementation for GARP already,
hence it did not look like worthy to add a RARP implementation
just for this.

C.
For South to North traffic, we need not pass through gateway
chassis, if there is no address transalation needed.

For overlay networks, NATing is a must to talk to outside networks.
However, for vlan backed networks, NATing is not a must, and hence
in the absence of NATing configuration we need redirect the packet
to gateway chassis.

Signed-off-by: Ankur Sharma 
mailto:ankur.sha...@nutanix.com>>
---


Hi Ankur,

I am little confused with the approach taken here. I ran the tests added in 
this patch.
I see below logical flows in the router pipeline

***
 table=1 (lr_in_ip_input ), priority=90   , match=(inport == 
"router-to-ls1" && arp.spa == 192.168.1.0/24 
[192.168.1.0]
 && arp.tpa == 192.168.1.3 && arp.op == 1), action=(put_arp(inport, arp.spa, 
arp.sha); eth.dst = eth.src; eth.src = 00:00:01:01:02:03; arp.op = 2; /* ARP 
reply */ arp.tha = arp.sha; arp.sha = 00:00:01:01:02:03; arp.tpa = arp.spa; 
arp.spa = 192.168.1.3; outport = "router-to-ls1"; flags.loopback = 1; output;)
  table=1 (lr_in_ip_input ), priority=90   , match=(inport == 
"router-to-ls1" && nd_ns && ip6.dst == {fe80::200:1ff:fe01:203, 
ff02::1:ff01:203} && nd.target == fe80::200:1ff:fe01:203 && 
is_chassis_resident("cr-router-to-ls1")), action=(put_nd(inport, ip6.src, 
nd.sll); nd_na_router { eth.src = 00:00:01:01:02:03; ip6.src = 
fe80::200:1ff:fe01:203; nd.target = fe80::200:1ff:fe01:203; nd.tll = 
00:00:01:01:02:03; outport = inport; flags.loopback = 1; output; };)
  table=1 (lr_in_ip_input ), priority=90   , match=(inport == 
"router-to-ls2" && arp.spa == 192.168.2.0/24 

Re: [ovs-dev] [PATCH v7 1/2] OVN: Enable E-W Traffic, Vlan backed DVR

2019-05-10 Thread Ankur Sharma
Hi Numan,

Glad to see your comments.
I have handled all the comments in the code, v8 will have the same.

Regarding your comments on backward compatibility:
“
Hi Ankur,

For most part the patch looks fine to me. Please see some additional comments.

I still have few questions about the type added to the logical switch. How 
would you handle
the case for upgrades ? i.e if the deployment already have a logical switch 
with a localnet port.

What if the user sets the type as - bridged, but doesn't create the localnet 
port ?
“

Changes are backward compatible, i.e upgrades would not be an issue.
a. Flow for replacing router port mac with chassis mac happens based on 
localnet port configuration.
b. If chassis_mac is not configured, then router port mac will be used as is.

If localnet port is not created, then connectivity to vlan backed physical 
network cannot be established,
like for a regular logical switch. Adding a validation for this looked tricky, 
because a single transaction
will not have both network_types and localnet port creation. I added a line in 
documentation to
indicate that bridged types MUST have a localnet port configured. I will be 
happy to make more
changes in this regard, let me know if i can take it as a follow up activity, 
we can have  a more thorough
discussion on it.


Thanks

Regards,
Ankur

From: Numan Siddique 
Sent: Friday, May 10, 2019 5:39 AM
To: Ankur Sharma 
Cc: ovs-dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v7 1/2] OVN: Enable E-W Traffic, Vlan backed DVR




On Thu, May 9, 2019 at 4:28 AM Ankur Sharma 
mailto:ankur.sha...@nutanix.com>> wrote:
Background:
[1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html 
[mail.openvswitch.org]
[2] 
https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
 
[docs.google.com]

This Series:
Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
backed distributed logical router.

This patch:

A.
Key difference between an overlay logical switch and
vlan backed logical switch is that for vlan logical switches
packets are not encapsulated.

Hence, if a distributed router port is connected to vlan type
logical switch, then router port mac as source mac could be
seen from multiple hypervisors. Same  pairs coming
from multiple ports from a top of the rack switch (TOR) perspective
could be seen as a security threat and it could send alarms, drop
the packets or block the ports etc.

This patch addresses the same by introducing the concept of chassis mac.
A chassis mac is CMS provisioned unique mac per chassis. For any routed packet
(i.e source mac is router port mac) going on the wire on a vlan type
logical switch, we will replace its source mac with chassis mac.

This replacing of source mac with chassis mac will happen in table=65
of the logical switch datapath. A flow is added at priority 150, which
matches the source mac and replaces it with chassis mac if the value
is a router port mac.

Example flow:
cookie=0x0, duration=67765.830s, table=65, n_packets=0, n_bytes=0,
idle_age=65534, hard_age=65534, priority=150,reg15=0x1,metadata=0x4,
dl_src=00:00:01:01:02:03 actions=mod_dl_src:aa:bb:cc:dd:ee:ff,
mod_vlan_vid:1000,output:16

Here, 00:00:01:01:02:03 is router port mac and aa:bb:cc:dd:ee:ff
is chassis mac.

B.
This patch adds one more change of associating "types" with logical
switches. i.e a logical switch could be of type "overlay" or "bridged".
This is done to explicitly call out that on a bridged logical
switch there will no encapsulation.
Just a localnet port's presence is not sufficient, as we do
encap while redirecting the packet to gateway chassis.
By marking the logical switch as bridged, we can either
avoid redirection totally (if there is no NAT) or do redirection
based on router port mac, rather than encap over a tunnel.

Hi Ankur,

For most part the patch looks fine to me. Please see some additional comments.

I still have few questions about the type added to the logical switch. How 
would you handle
the case for upgrades ? i.e if the deployment already have a logical switch 
with a localnet port.

What if the user sets the type as - bridged, but doesn't create the localnet 
port ?

Thanks
Numan


Signed-off-by: Ankur Sharma 
mailto:ankur.sha...@nutanix.com>>
---
 ovn/controller/binding.c|  12 +--
 ovn/controller/chassis.c|  64 +++-
 

Re: [ovs-dev] [PATCH v1] OVN: Fix the ovn-controller 100% usage issue with put_mac_bindings

2019-05-10 Thread Ankur Sharma
Hi Han,

Thanks for review.

Yup, looks like it, although I did not try the scenario myself, but yes entry 
are not getting removed once added,
hence, new mac bindings will not be added after some time (as existing count 
reaches 1000).

Regards,
Ankur

From: Han Zhou 
Sent: Friday, May 10, 2019 4:47 PM
To: Ankur Sharma 
Cc: ovs-dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v1] OVN: Fix the ovn-controller 100% usage issue 
with put_mac_bindings



On Fri, May 10, 2019 at 2:46 PM Ankur Sharma 
mailto:ankur.sha...@nutanix.com>> wrote:
>
> ISSUE:
> a. As soon as entries get added to put_mac_bindings in pinctrl.c,
>ovn-controller CPU consumption reached 100%.
>
> b. This happens because in wait_put_mac_bindings,
>if !hmap_is_empty(_mac_bindings) succeeds and
>calls poll_immediat_wake().
>
>ovn-controller.log:
>"2019-05-10T19:43:28.035Z|00035|poll_loop|INFO|wakeup due to
> 0-ms timeout at ovn/controller/pinctrl.c:2520 (99% CPU usage)"
>
> ROOT_CAUSE:
> a. Earlier it used to work fine, because in run_put_mac_bindings
>all the bindings in put_mac_bindings would be flushed.
>
> b. Looks like, as a part of adding a new thread in pinctrl, this
>line got replaced with calling buffer_put_mac_bindings.
>
> "
> .
> .
> .
>/* Move the mac bindings from 'put_mac_bindings' hmap to
>  * 'buffered_mac_bindings' and notify the pinctrl_handler.
>  * pinctrl_handler will reinject the buffered packets. */
> if (!hmap_is_empty(_mac_bindings)) {
> buffer_put_mac_bindings();
> notify_pinctrl_handler();
> }
> "
>
> c. Because of which put_mac_bindings is never emptied and 
> wait_put_mac_bindings
>ends up doing poll_immediate_wake.
>
> FIX:
> a. Added call to flush_put_mac_bindings back in
>run_put_mac_bindings.
>
> b. Additioanlly, logic mentioned in ROOT_CAUSE.b has been changed
>in 1c24b2f490ba002bbfeb23006965188a7c5b9747, hence updated
>the documentation in pinctrl.c accordingly.
>
> Signed-off-by: Ankur Sharma 
> mailto:ankur.sha...@nutanix.com>>
> ---
>  ovn/controller/pinctrl.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
> index 8ae1f9b..b7bb4c9 100644
> --- a/ovn/controller/pinctrl.c
> +++ b/ovn/controller/pinctrl.c
> @@ -91,11 +91,13 @@ VLOG_DEFINE_THIS_MODULE(pinctrl);
>   *
>   *   - arp/nd_ns  - These actions generate an ARP/IPv6 Neighbor solicit
>   *  requests. The original packets are buffered and
> - *  injected back when put_arp/put_nd actions are called.
> + *  injected back when put_arp/put_nd resolves
> + *  corresponding ARP/IPv6 Neighbor solicit requests.
>   *  When pinctrl_run(), writes the mac bindings from the
>   *  'put_mac_bindings' hmap to the MAC_Binding table in
> - *  SB DB, it moves these mac bindings to another hmap -
> - *  'buffered_mac_bindings'.
> + *  SB DB, run_buffered_binding will add the buffered
> + *  packets to buffered_mac_bindings and notify
> + *  pinctrl_handler.
>   *
>   *  The pinctrl_handler thread calls the function -
>   *  send_mac_binding_buffered_pkts(), which uses
> @@ -2468,6 +2470,7 @@ run_put_mac_bindings(struct ovsdb_idl_txn 
> *ovnsb_idl_txn,
>  sbrec_mac_binding_by_lport_ip,
>  pmb);
>  }
> +flush_put_mac_bindings();
>  }
>
>  static void
> --
> 1.8.3.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev 
> [mail.openvswitch.org]

Thanks for the fix. Does it mean the the mac-binding will not work after some 
time since it is never flushed, and the check "hmap_count(_mac_bindings) >= 
1000" in pinctrl_handle_put_mac_binding() will prevent any new mac-binding 
being handled?

The fix looks good to me.

Acked-by: Han Zhou mailto:hzh...@ebay.com>>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v1] OVN: Fix the ovn-controller 100% usage issue with put_mac_bindings

2019-05-10 Thread Han Zhou
On Fri, May 10, 2019 at 2:46 PM Ankur Sharma 
wrote:
>
> ISSUE:
> a. As soon as entries get added to put_mac_bindings in pinctrl.c,
>ovn-controller CPU consumption reached 100%.
>
> b. This happens because in wait_put_mac_bindings,
>if !hmap_is_empty(_mac_bindings) succeeds and
>calls poll_immediat_wake().
>
>ovn-controller.log:
>"2019-05-10T19:43:28.035Z|00035|poll_loop|INFO|wakeup due to
> 0-ms timeout at ovn/controller/pinctrl.c:2520 (99% CPU usage)"
>
> ROOT_CAUSE:
> a. Earlier it used to work fine, because in run_put_mac_bindings
>all the bindings in put_mac_bindings would be flushed.
>
> b. Looks like, as a part of adding a new thread in pinctrl, this
>line got replaced with calling buffer_put_mac_bindings.
>
> "
> .
> .
> .
>/* Move the mac bindings from 'put_mac_bindings' hmap to
>  * 'buffered_mac_bindings' and notify the pinctrl_handler.
>  * pinctrl_handler will reinject the buffered packets. */
> if (!hmap_is_empty(_mac_bindings)) {
> buffer_put_mac_bindings();
> notify_pinctrl_handler();
> }
> "
>
> c. Because of which put_mac_bindings is never emptied and
wait_put_mac_bindings
>ends up doing poll_immediate_wake.
>
> FIX:
> a. Added call to flush_put_mac_bindings back in
>run_put_mac_bindings.
>
> b. Additioanlly, logic mentioned in ROOT_CAUSE.b has been changed
>in 1c24b2f490ba002bbfeb23006965188a7c5b9747, hence updated
>the documentation in pinctrl.c accordingly.
>
> Signed-off-by: Ankur Sharma 
> ---
>  ovn/controller/pinctrl.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
> index 8ae1f9b..b7bb4c9 100644
> --- a/ovn/controller/pinctrl.c
> +++ b/ovn/controller/pinctrl.c
> @@ -91,11 +91,13 @@ VLOG_DEFINE_THIS_MODULE(pinctrl);
>   *
>   *   - arp/nd_ns  - These actions generate an ARP/IPv6 Neighbor
solicit
>   *  requests. The original packets are buffered and
> - *  injected back when put_arp/put_nd actions are
called.
> + *  injected back when put_arp/put_nd resolves
> + *  corresponding ARP/IPv6 Neighbor solicit requests.
>   *  When pinctrl_run(), writes the mac bindings from
the
>   *  'put_mac_bindings' hmap to the MAC_Binding table
in
> - *  SB DB, it moves these mac bindings to another
hmap -
> - *  'buffered_mac_bindings'.
> + *  SB DB, run_buffered_binding will add the buffered
> + *  packets to buffered_mac_bindings and notify
> + *  pinctrl_handler.
>   *
>   *  The pinctrl_handler thread calls the function -
>   *  send_mac_binding_buffered_pkts(), which uses
> @@ -2468,6 +2470,7 @@ run_put_mac_bindings(struct ovsdb_idl_txn
*ovnsb_idl_txn,
>  sbrec_mac_binding_by_lport_ip,
>  pmb);
>  }
> +flush_put_mac_bindings();
>  }
>
>  static void
> --
> 1.8.3.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Thanks for the fix. Does it mean the the mac-binding will not work after
some time since it is never flushed, and the check
"hmap_count(_mac_bindings) >= 1000" in pinctrl_handle_put_mac_binding()
will prevent any new mac-binding being handled?

The fix looks good to me.

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


Re: [ovs-dev] [PATCH 2/2] fedora: Handle upgrades from rhel package.

2019-05-10 Thread Ansis Atteka
On Fri, 10 May 2019 at 14:47, Guru Shetty  wrote:
>>>
>>>
>>> > +# daemons. Another "restart" (outside the package postinst script) is
>>> > +# needed to actually run new daemons.
>>> > +if [ -e "%{_tmppath}/ovs-upgrade-from-sysv" ]; then
>>> t seems that if rpm package that was built from rhel spec file was
>>> removed (without upgrade) and then you do fresh install, then you hit
>>> this upgrade path too. Unless the whole host was rebooted before fresh
>>> install and all contents of /tmp directory were purged. Though this
>>> may not be an issue after invoking the "sytemctl enable", right?
>>
>>
>> You are correct. I had not thought about it. The end result is that we have 
>> a start of openvswitch daemons. I think I can fix this by making this code 
>> only run during an upgrade. I will send a v2.
>>
>
> I may have misunderstood your comment. When we uninstall the previous package 
> and then we do a fresh install, the "/etc/init.d/openvswitch" will not be 
> there and we will not create %{_tmppath}/ovs-upgrade-from-sysv.  So we will 
> not restart openvswitch. I hope we are on the same page.
>


You are right. The %pre of the new package creates this file in tmp.
For strange reasons I overlooked something and incorrectly assumed
that it is %preun of the old package that creates it (which would be
impossible btw because that is code we have already shipped). So:

Acked-by: Ansis Atteka 

Sorry for raising false alarm.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH] dist-docs: Fix bugs in text to HTML conversion.

2019-05-10 Thread Ben Pfaff
This fixes two bugs.  First, & has a special meaning in the replacement
text for a sed "s" command, so this escapes it.  Second, this code
misprocessed bold or underlined &<>: >^H> would become ^H which
would display as  in most browers.

Finally, this improves the HTML output so that bold ABC becomes ABC
instead of ABC.

Reported-by: Nicolas Bouliane 
Reported-at: https://twitter.com/nicboul/status/1126959264772259842
Signed-off-by: Ben Pfaff 
---
 build-aux/dist-docs | 28 +++-
 1 file changed, 23 insertions(+), 5 deletions(-)

diff --git a/build-aux/dist-docs b/build-aux/dist-docs
index 9f6ca7b2cbfc..f6b88ca2d04b 100755
--- a/build-aux/dist-docs
+++ b/build-aux/dist-docs
@@ -69,11 +69,29 @@ EOF
  GROFF_NO_SGR=1 man -l -Tutf8 $manpage | sed 's/.//g' > $manpage.txt
  (echo ''
   GROFF_NO_SGR=1 man -l -Tutf8 $manpage | sed '
-s/&//g
-s///g
-s,\(.\)\1,\1,g
-s,_\(.\),\1,g'
+# Change bold and underline via backspacing into bracketing with control
+# characters.  We cannot directly translate them to HTML because <> need
+# to be escaped later.  (We cannot escape <> first because bold or
+# underlined escaped characters would be mis-processed.)
+s,\(.\)\1,\1,g
+s,_\(.\),\1,g
+
+# Drop redundant font changes, to keep from having every character have
+# a separate tag pair.
+s,,,g
+s,,,g
+
+# Escape special characters.
+s,&,\,g
+s,<,\,g
+s,>,\,g
+
+# Translate control characters to HTML.
+s,,,g
+s,,,g
+s,,,g
+s,,,g
+'
   echo ''
  ) > $manpage.html
 
-- 
2.20.1

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


[ovs-dev] [PATCH v1] OVN: Fix the ovn-controller 100% usage issue with put_mac_bindings

2019-05-10 Thread Ankur Sharma
ISSUE:
a. As soon as entries get added to put_mac_bindings in pinctrl.c,
   ovn-controller CPU consumption reached 100%.

b. This happens because in wait_put_mac_bindings,
   if !hmap_is_empty(_mac_bindings) succeeds and
   calls poll_immediat_wake().

   ovn-controller.log:
   "2019-05-10T19:43:28.035Z|00035|poll_loop|INFO|wakeup due to
0-ms timeout at ovn/controller/pinctrl.c:2520 (99% CPU usage)"

ROOT_CAUSE:
a. Earlier it used to work fine, because in run_put_mac_bindings
   all the bindings in put_mac_bindings would be flushed.

b. Looks like, as a part of adding a new thread in pinctrl, this
   line got replaced with calling buffer_put_mac_bindings.

"
.
.
.
   /* Move the mac bindings from 'put_mac_bindings' hmap to
 * 'buffered_mac_bindings' and notify the pinctrl_handler.
 * pinctrl_handler will reinject the buffered packets. */
if (!hmap_is_empty(_mac_bindings)) {
buffer_put_mac_bindings();
notify_pinctrl_handler();
}
"

c. Because of which put_mac_bindings is never emptied and wait_put_mac_bindings
   ends up doing poll_immediate_wake.

FIX:
a. Added call to flush_put_mac_bindings back in
   run_put_mac_bindings.

b. Additioanlly, logic mentioned in ROOT_CAUSE.b has been changed
   in 1c24b2f490ba002bbfeb23006965188a7c5b9747, hence updated
   the documentation in pinctrl.c accordingly.

Signed-off-by: Ankur Sharma 
---
 ovn/controller/pinctrl.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/ovn/controller/pinctrl.c b/ovn/controller/pinctrl.c
index 8ae1f9b..b7bb4c9 100644
--- a/ovn/controller/pinctrl.c
+++ b/ovn/controller/pinctrl.c
@@ -91,11 +91,13 @@ VLOG_DEFINE_THIS_MODULE(pinctrl);
  *
  *   - arp/nd_ns  - These actions generate an ARP/IPv6 Neighbor solicit
  *  requests. The original packets are buffered and
- *  injected back when put_arp/put_nd actions are called.
+ *  injected back when put_arp/put_nd resolves
+ *  corresponding ARP/IPv6 Neighbor solicit requests.
  *  When pinctrl_run(), writes the mac bindings from the
  *  'put_mac_bindings' hmap to the MAC_Binding table in
- *  SB DB, it moves these mac bindings to another hmap -
- *  'buffered_mac_bindings'.
+ *  SB DB, run_buffered_binding will add the buffered
+ *  packets to buffered_mac_bindings and notify
+ *  pinctrl_handler.
  *
  *  The pinctrl_handler thread calls the function -
  *  send_mac_binding_buffered_pkts(), which uses
@@ -2468,6 +2470,7 @@ run_put_mac_bindings(struct ovsdb_idl_txn *ovnsb_idl_txn,
 sbrec_mac_binding_by_lport_ip,
 pmb);
 }
+flush_put_mac_bindings();
 }
 
 static void
-- 
1.8.3.1

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


Re: [ovs-dev] [PATCH 2/2] fedora: Handle upgrades from rhel package.

2019-05-10 Thread Guru Shetty
>
>
>> > +# daemons. Another "restart" (outside the package postinst script)
>> is
>> > +# needed to actually run new daemons.
>> > +if [ -e "%{_tmppath}/ovs-upgrade-from-sysv" ]; then
>> t seems that if rpm package that was built from rhel spec file was
>> removed (without upgrade) and then you do fresh install, then you hit
>> this upgrade path too. Unless the whole host was rebooted before fresh
>> install and all contents of /tmp directory were purged. Though this
>> may not be an issue after invoking the "sytemctl enable", right?
>>
>
> You are correct. I had not thought about it. The end result is that we
> have a start of openvswitch daemons. I think I can fix this by making this
> code only run during an upgrade. I will send a v2.
>
>
I may have misunderstood your comment. When we uninstall the previous
package and then we do a fresh install, the "/etc/init.d/openvswitch" will
not be there and we will not create %{_tmppath}/ovs-upgrade-from-sysv.  So
we will not restart openvswitch. I hope we are on the same page.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 1/7 v3] datapath: Handle removal of nf_conntrack_l3proto.h

2019-05-10 Thread Yifeng Sun
Oops, nice catch, thanks, I will fix in later patch.
Yifeng

On Fri, May 10, 2019 at 1:53 PM Darrell Ball  wrote:
>
> Looks a little odd: 'HAVE_NF_CONNTRACK_L3PROATO_H'
>
> You may want a follow up patch: 
> s/HAVE_NF_CONNTRACK_L3PROATO_H/HAVE_NF_CONNTRACK_L3PROTO_H
>
>
>
> On 5/10/19, 12:31 PM, "ovs-dev-boun...@openvswitch.org on behalf of Yifeng 
> Sun"  
> wrote:
>
> Upstream kernel commit a0ae2562 ("netfilter: conntrack: remove l3proto
> abstraction") removed header file net/netfilter/nf_conntrack_l3proto.h.
> This patch detects it and fixes compilation errors of OVS on 4.19+ 
> kernels.
>
> Signed-off-by: Yifeng Sun 
> Acked-by: Yi-Hung Wei 
> ---
>  acinclude.m4   | 3 +++
>  datapath/linux/compat/nf_conntrack_proto.c | 2 ++
>  2 files changed, 5 insertions(+)
>
> diff --git a/acinclude.m4 b/acinclude.m4
> index b532a4579266..c9b744db0b94 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -926,6 +926,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
>[OVS_DEFINE([HAVE_KVMALLOC_ARRAY])])
>OVS_GREP_IFELSE([$KSRC/include/linux/mm.h], [kvmalloc_node],
>[OVS_DEFINE([HAVE_KVMALLOC_NODE])])
> +  OVS_GREP_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_l3proto.h],
> +  [nf_conntrack_l3proto],
> +  [OVS_DEFINE([HAVE_NF_CONNTRACK_L3PROATO_H])])
>
>if cmp -s datapath/linux/kcompat.h.new \
>  datapath/linux/kcompat.h >/dev/null 2>&1; then
> diff --git a/datapath/linux/compat/nf_conntrack_proto.c 
> b/datapath/linux/compat/nf_conntrack_proto.c
> index 4ac66f61c70d..fe291dbf25e1 100644
> --- a/datapath/linux/compat/nf_conntrack_proto.c
> +++ b/datapath/linux/compat/nf_conntrack_proto.c
> @@ -1,7 +1,9 @@
>  #include 
>
>  #include 
> +#ifdef HAVE_NF_CONNTRACK_L3PROATO_H
>  #include 
> +#endif
>
>  /*
>   * Upstream net-next commmit 7e35ec0e8044
> --
> 2.7.4
>
> ___
> dev mailing list
> d...@openvswitch.org
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-devdata=02%7C01%7Cdball%40vmware.com%7C0ca3d8a2fbb1444db8a708d6d57e1131%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63693113485746sdata=%2BjvNwhHQvw0bidum9%2Fw%2F1VTWASDZzU%2BXSBs5KkkVkew%3Dreserved=0
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 2/2] fedora: Handle upgrades from rhel package.

2019-05-10 Thread Guru Shetty
On Thu, 9 May 2019 at 17:37, Ansis Atteka  wrote:

> On Fri, 3 May 2019 at 11:19, Gurucharan Shetty  wrote:
> >
> > Currently we have rhel/openvswitch.spec.in that provides
> > sysv scripts. The fedora package provides systemd scripts.
> > If one upgrades openvswitch package from sysv to systemd,
> > you will end up in a situation where old OVS daemons are
> > running, but systemd does not know about it.  One "restart"
> > is needed for systemd to see the old daemons. Another "restart"
> > or "force-reload-kmod" is needed to actually use the new
> > daemons.
> >
> > This commit, just takes care of the first restart. The "real"
> > restart/force-reload-kmod will still have to be done outside
> > the package installation.
> >
> > Signed-off-by: Gurucharan Shetty 
>
> Do I understand correctly that Aaron has concern whether the
> autoenable build flag that you introduced in patch 1/2 should
> automatically enable openvswitch on every installation (opposed to
> only first installation)? Did you look into how other fedora packages
> that enable services on installation behave?


Fedora packages seem to look at system-preset files in
/etc/systemd/system-preset/ to decide whether a package needs to be
enabled. But we don't provide such a file.


> I kinda see the point
> that if admin explicitly disabled openvswitch then we should not
> blindly re-enable openvswitch back...
>

The openvswitch rhel rpm so far has always enabled it after installation or
upgrade (from 2011). So there is some compatibility there. What we can do
here is that after a few releases, only enable openvswitch for a fresh
installation and not upgrade - unless we want it right now and special case
upgrades from pre-systemd to systemd.  I don't see what we are doing as a
particularly bad behavior as this is not a default option and will only
happen if someone actually builds the RPM with a specfic non-default option.



>
> > ---
> >  rhel/openvswitch-fedora.spec.in | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/
> openvswitch-fedora.spec.in
> > index e8165f9..d41d11c 100644
> > --- a/rhel/openvswitch-fedora.spec.in
> > +++ b/rhel/openvswitch-fedora.spec.in
> > @@ -364,6 +364,12 @@ getent passwd openvswitch >/dev/null || \
> >  usermod -a -G hugetlbfs openvswitch
> >  %endif
> >  %endif
> > +
> > +%if %{with autoenable}
> > +if [ -x "/etc/init.d/openvswitch" ]; then
> > +touch %{_tmppath}/ovs-upgrade-from-sysv
> > +fi
> > +%endif
> >  exit 0
> >
> >  %post
> > @@ -397,6 +403,14 @@ fi
> >  %if %{with autoenable}
> >  systemctl daemon-reload
> >  systemctl enable openvswitch
> > +# Handle upgrades to this package from the OVS repo's rhel packages.
> > +# One "restart" is needed for newer systemd files to see the old
> running
>
> The double restart thingy seems kinda weird to me as well, but I don't
> have insight why systemd behaves that way.


This is the behavior broken down into steps
1. Old OVS daemons are running and new systemd unit files are installed.
2. "systemctl status openvswitch" - says that it is inactive as it has
never been started.
3. "systemctl stop openvswitch" - does not attempt to stop anything because
openvswitch is "inactive"
4. "systemctl start openvswitch" - will try to attempt to start openvswitch
- but does not do anything - likely because it notices that the PID file is
active and daemons are still running. Now "openvswitch" is active.
5. "systemctl stop openvswitch" - will stop old daemons.
6. "systemctl start openvswitch" - will start new daemons.



> Would calling systemctl
> stop before daemon-reload and then systemctl [re]start after
> daemon-reload solve the problem in a more elegant way? If not probably
> this is not worth something worth to bother with.
>

I tried your suggestion and that does not work.



>
> > +# daemons. Another "restart" (outside the package postinst script)
> is
> > +# needed to actually run new daemons.
> > +if [ -e "%{_tmppath}/ovs-upgrade-from-sysv" ]; then
> t seems that if rpm package that was built from rhel spec file was
> removed (without upgrade) and then you do fresh install, then you hit
> this upgrade path too. Unless the whole host was rebooted before fresh
> install and all contents of /tmp directory were purged. Though this
> may not be an issue after invoking the "sytemctl enable", right?
>

You are correct. I had not thought about it. The end result is that we have
a start of openvswitch daemons. I think I can fix this by making this code
only run during an upgrade. I will send a v2.


>
> Do you think it may make sense to commit to remove this migration code
> after couple releases? I kinda see this as a temporary solution that
> is supposed to help admins with migrating from rhel spec files to
> fedora spec files. Once everyone has migrated, then this code becomes
> clutter.
>
Yes. We can get rid of this code after a few releases.



> > +

Re: [ovs-dev] [PATCH 1/7 v3] datapath: Handle removal of nf_conntrack_l3proto.h

2019-05-10 Thread Darrell Ball via dev
Looks a little odd: 'HAVE_NF_CONNTRACK_L3PROATO_H'

You may want a follow up patch: 
s/HAVE_NF_CONNTRACK_L3PROATO_H/HAVE_NF_CONNTRACK_L3PROTO_H



On 5/10/19, 12:31 PM, "ovs-dev-boun...@openvswitch.org on behalf of Yifeng 
Sun"  
wrote:

Upstream kernel commit a0ae2562 ("netfilter: conntrack: remove l3proto
abstraction") removed header file net/netfilter/nf_conntrack_l3proto.h.
This patch detects it and fixes compilation errors of OVS on 4.19+ kernels.

Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
 acinclude.m4   | 3 +++
 datapath/linux/compat/nf_conntrack_proto.c | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/acinclude.m4 b/acinclude.m4
index b532a4579266..c9b744db0b94 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -926,6 +926,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
   [OVS_DEFINE([HAVE_KVMALLOC_ARRAY])])
   OVS_GREP_IFELSE([$KSRC/include/linux/mm.h], [kvmalloc_node],
   [OVS_DEFINE([HAVE_KVMALLOC_NODE])])
+  OVS_GREP_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_l3proto.h],
+  [nf_conntrack_l3proto],
+  [OVS_DEFINE([HAVE_NF_CONNTRACK_L3PROATO_H])])
 
   if cmp -s datapath/linux/kcompat.h.new \
 datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/linux/compat/nf_conntrack_proto.c 
b/datapath/linux/compat/nf_conntrack_proto.c
index 4ac66f61c70d..fe291dbf25e1 100644
--- a/datapath/linux/compat/nf_conntrack_proto.c
+++ b/datapath/linux/compat/nf_conntrack_proto.c
@@ -1,7 +1,9 @@
 #include 
 
 #include 
+#ifdef HAVE_NF_CONNTRACK_L3PROATO_H
 #include 
+#endif
 
 /*
  * Upstream net-next commmit 7e35ec0e8044
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fmailman%2Flistinfo%2Fovs-devdata=02%7C01%7Cdball%40vmware.com%7C0ca3d8a2fbb1444db8a708d6d57e1131%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C63693113485746sdata=%2BjvNwhHQvw0bidum9%2Fw%2F1VTWASDZzU%2BXSBs5KkkVkew%3Dreserved=0


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


Re: [ovs-dev] [PATCH 1/7 v3] datapath: Handle removal of nf_conntrack_l3proto.h

2019-05-10 Thread 0-day Robot
Bleep bloop.  Greetings Yifeng Sun, I am a robot and I have tried out your 
patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


git-am:
Failed to merge in the changes.
Patch failed at 0001 datapath: Handle removal of nf_conntrack_l3proto.h
The copy of the patch that failed is found in:
   
/var/lib/jenkins/jobs/upstream_build_from_pw/workspace/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


Please check this out.  If you feel there has been an error, please email 
acon...@bytheb.org

Thanks,
0-day Robot
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 0/7 v3] datapath: Support 4.19.x and 4.20.x kernel

2019-05-10 Thread Yifeng Sun
Thanks Ben. I will pay attention for future patches.
Yifeng

On Fri, May 10, 2019 at 1:18 PM Ben Pfaff  wrote:
>
> Please add tags to each patch, because they need to be there when the
> patches are applied.
>
> I took care of that myself, and I also reordered the tags a little
> (Signed-off-by should be last) and applied this series to master.
> Thanks, everyone!
>
> On Fri, May 10, 2019 at 12:53:08PM -0700, Yifeng Sun wrote:
> > Thanks Greg, I've put your tags in the cover letter.
> > Yifeng
> >
> > On Fri, May 10, 2019 at 12:47 PM Gregory Rose  wrote:
> > >
> > > My tags are missing.
> > >
> > > For the series:
> > >
> > > Tested-by: Greg Rose 
> > > Reviewed-by: Greg Rose 
> > >
> > > On 5/10/2019 12:30 PM, Yifeng Sun wrote:
> > > > This series of patches enabled OVS to support kernel 4.19.x and 4.20.x.
> > > >
> > > > Tests shows that this series of patches passed check-kmod tests or
> > > > didn't introduce new failed check-kmod tests for the following
> > > > kernel versions:
> > > > 3.10.0-957.12.1.el7.x86_64 (rhel)
> > > > 4.4.0-31-generic (ubuntu 14.04)
> > > > 4.4.0-146-generic (ubuntu 16.04)
> > > > 4.4.179
> > > > 4.9.171
> > > > 4.14.111
> > > > 4.15.0-48-generic (ubuntu 18.04)
> > > > 4.17.19
> > > > 4.18.0-18-generic (ubuntu 18.10)
> > > > 4.19.37
> > > > 4.20.17
> > > >
> > > > Travis passed at:
> > > > https://travis-ci.org/yifsun/ovs-travis/builds/528006159
> > > >
> > > > In addition, build is successful on:
> > > > CentOS73, Fedora, RHEL74, RHEL75, RHEL76 and Ubuntu (bionic, trusty,
> > > > xenial).
> > > >
> > > > Yifeng Sun (7):
> > > >datapath: Handle removal of nf_conntrack_l3proto.h
> > > >datapath: Pass nf_hook_state to nf_conntrack_in()
> > > >datapath: Use new header file net/ipv6_frag.h
> > > >datapath: Fix conntrack_count related compilation errors
> > > >openvswitch: use nf_ct_get_tuplepr, invert_tuplepr
> > > >netfilter: Remove useless param helper of nf_ct_helper_ext_add
> > > >datapath: Support kernel version 4.19.x and 4.20.x
> > > >
> > > > Tested-by: Greg Rose 
> > > > Reviewed-by: Greg Rose 
> > > >
> > > > v1->v2: Fix by reviewers' comments.
> > > > v2->v3: Fix patch series.
> > > >
> > > >   .travis.yml| 18 
> > > > ---
> > > >   NEWS   |  2 ++
> > > >   acinclude.m4   | 17 --
> > > >   datapath/conntrack.c   | 26 
> > > > +-
> > > >   datapath/linux/Modules.mk  |  2 ++
> > > >   datapath/linux/compat/include/linux/netfilter.h| 19 
> > > > 
> > > >   datapath/linux/compat/include/net/ipv6_frag.h  |  8 +++
> > > >   .../include/net/netfilter/nf_conntrack_core.h  |  9 
> > > >   .../include/net/netfilter/nf_conntrack_count.h |  4 ++--
> > > >   .../include/net/netfilter/nf_conntrack_helper.h| 10 +
> > > >   datapath/linux/compat/nf_conncount.c   |  6 -
> > > >   datapath/linux/compat/nf_conntrack_proto.c |  2 ++
> > > >   12 files changed, 94 insertions(+), 29 deletions(-)
> > > >   create mode 100644 datapath/linux/compat/include/linux/netfilter.h
> > > >   create mode 100644 datapath/linux/compat/include/net/ipv6_frag.h
> > > >
> > >
> > > ___
> > > 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
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 0/7 v3] datapath: Support 4.19.x and 4.20.x kernel

2019-05-10 Thread Ben Pfaff
Please add tags to each patch, because they need to be there when the
patches are applied.

I took care of that myself, and I also reordered the tags a little
(Signed-off-by should be last) and applied this series to master.
Thanks, everyone!

On Fri, May 10, 2019 at 12:53:08PM -0700, Yifeng Sun wrote:
> Thanks Greg, I've put your tags in the cover letter.
> Yifeng
> 
> On Fri, May 10, 2019 at 12:47 PM Gregory Rose  wrote:
> >
> > My tags are missing.
> >
> > For the series:
> >
> > Tested-by: Greg Rose 
> > Reviewed-by: Greg Rose 
> >
> > On 5/10/2019 12:30 PM, Yifeng Sun wrote:
> > > This series of patches enabled OVS to support kernel 4.19.x and 4.20.x.
> > >
> > > Tests shows that this series of patches passed check-kmod tests or
> > > didn't introduce new failed check-kmod tests for the following
> > > kernel versions:
> > > 3.10.0-957.12.1.el7.x86_64 (rhel)
> > > 4.4.0-31-generic (ubuntu 14.04)
> > > 4.4.0-146-generic (ubuntu 16.04)
> > > 4.4.179
> > > 4.9.171
> > > 4.14.111
> > > 4.15.0-48-generic (ubuntu 18.04)
> > > 4.17.19
> > > 4.18.0-18-generic (ubuntu 18.10)
> > > 4.19.37
> > > 4.20.17
> > >
> > > Travis passed at:
> > > https://travis-ci.org/yifsun/ovs-travis/builds/528006159
> > >
> > > In addition, build is successful on:
> > > CentOS73, Fedora, RHEL74, RHEL75, RHEL76 and Ubuntu (bionic, trusty,
> > > xenial).
> > >
> > > Yifeng Sun (7):
> > >datapath: Handle removal of nf_conntrack_l3proto.h
> > >datapath: Pass nf_hook_state to nf_conntrack_in()
> > >datapath: Use new header file net/ipv6_frag.h
> > >datapath: Fix conntrack_count related compilation errors
> > >openvswitch: use nf_ct_get_tuplepr, invert_tuplepr
> > >netfilter: Remove useless param helper of nf_ct_helper_ext_add
> > >datapath: Support kernel version 4.19.x and 4.20.x
> > >
> > > Tested-by: Greg Rose 
> > > Reviewed-by: Greg Rose 
> > >
> > > v1->v2: Fix by reviewers' comments.
> > > v2->v3: Fix patch series.
> > >
> > >   .travis.yml| 18 ---
> > >   NEWS   |  2 ++
> > >   acinclude.m4   | 17 --
> > >   datapath/conntrack.c   | 26 
> > > +-
> > >   datapath/linux/Modules.mk  |  2 ++
> > >   datapath/linux/compat/include/linux/netfilter.h| 19 
> > >   datapath/linux/compat/include/net/ipv6_frag.h  |  8 +++
> > >   .../include/net/netfilter/nf_conntrack_core.h  |  9 
> > >   .../include/net/netfilter/nf_conntrack_count.h |  4 ++--
> > >   .../include/net/netfilter/nf_conntrack_helper.h| 10 +
> > >   datapath/linux/compat/nf_conncount.c   |  6 -
> > >   datapath/linux/compat/nf_conntrack_proto.c |  2 ++
> > >   12 files changed, 94 insertions(+), 29 deletions(-)
> > >   create mode 100644 datapath/linux/compat/include/linux/netfilter.h
> > >   create mode 100644 datapath/linux/compat/include/net/ipv6_frag.h
> > >
> >
> > ___
> > 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
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 0/7 v3] datapath: Support 4.19.x and 4.20.x kernel

2019-05-10 Thread Gregory Rose



On 5/10/2019 12:53 PM, Yifeng Sun wrote:

Thanks Greg, I've put your tags in the cover letter.
Yifeng


Now I see them.  Thanks!



On Fri, May 10, 2019 at 12:47 PM Gregory Rose  wrote:

My tags are missing.

For the series:

Tested-by: Greg Rose 
Reviewed-by: Greg Rose 

On 5/10/2019 12:30 PM, Yifeng Sun wrote:

This series of patches enabled OVS to support kernel 4.19.x and 4.20.x.

Tests shows that this series of patches passed check-kmod tests or
didn't introduce new failed check-kmod tests for the following
kernel versions:
3.10.0-957.12.1.el7.x86_64 (rhel)
4.4.0-31-generic (ubuntu 14.04)
4.4.0-146-generic (ubuntu 16.04)
4.4.179
4.9.171
4.14.111
4.15.0-48-generic (ubuntu 18.04)
4.17.19
4.18.0-18-generic (ubuntu 18.10)
4.19.37
4.20.17

Travis passed at:
https://travis-ci.org/yifsun/ovs-travis/builds/528006159

In addition, build is successful on:
CentOS73, Fedora, RHEL74, RHEL75, RHEL76 and Ubuntu (bionic, trusty,
xenial).

Yifeng Sun (7):
datapath: Handle removal of nf_conntrack_l3proto.h
datapath: Pass nf_hook_state to nf_conntrack_in()
datapath: Use new header file net/ipv6_frag.h
datapath: Fix conntrack_count related compilation errors
openvswitch: use nf_ct_get_tuplepr, invert_tuplepr
netfilter: Remove useless param helper of nf_ct_helper_ext_add
datapath: Support kernel version 4.19.x and 4.20.x

Tested-by: Greg Rose 
Reviewed-by: Greg Rose 

v1->v2: Fix by reviewers' comments.
v2->v3: Fix patch series.

   .travis.yml| 18 ---
   NEWS   |  2 ++
   acinclude.m4   | 17 --
   datapath/conntrack.c   | 26 
+-
   datapath/linux/Modules.mk  |  2 ++
   datapath/linux/compat/include/linux/netfilter.h| 19 
   datapath/linux/compat/include/net/ipv6_frag.h  |  8 +++
   .../include/net/netfilter/nf_conntrack_core.h  |  9 
   .../include/net/netfilter/nf_conntrack_count.h |  4 ++--
   .../include/net/netfilter/nf_conntrack_helper.h| 10 +
   datapath/linux/compat/nf_conncount.c   |  6 -
   datapath/linux/compat/nf_conntrack_proto.c |  2 ++
   12 files changed, 94 insertions(+), 29 deletions(-)
   create mode 100644 datapath/linux/compat/include/linux/netfilter.h
   create mode 100644 datapath/linux/compat/include/net/ipv6_frag.h


___
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 0/7 v3] datapath: Support 4.19.x and 4.20.x kernel

2019-05-10 Thread Yifeng Sun
Thanks Greg, I've put your tags in the cover letter.
Yifeng

On Fri, May 10, 2019 at 12:47 PM Gregory Rose  wrote:
>
> My tags are missing.
>
> For the series:
>
> Tested-by: Greg Rose 
> Reviewed-by: Greg Rose 
>
> On 5/10/2019 12:30 PM, Yifeng Sun wrote:
> > This series of patches enabled OVS to support kernel 4.19.x and 4.20.x.
> >
> > Tests shows that this series of patches passed check-kmod tests or
> > didn't introduce new failed check-kmod tests for the following
> > kernel versions:
> > 3.10.0-957.12.1.el7.x86_64 (rhel)
> > 4.4.0-31-generic (ubuntu 14.04)
> > 4.4.0-146-generic (ubuntu 16.04)
> > 4.4.179
> > 4.9.171
> > 4.14.111
> > 4.15.0-48-generic (ubuntu 18.04)
> > 4.17.19
> > 4.18.0-18-generic (ubuntu 18.10)
> > 4.19.37
> > 4.20.17
> >
> > Travis passed at:
> > https://travis-ci.org/yifsun/ovs-travis/builds/528006159
> >
> > In addition, build is successful on:
> > CentOS73, Fedora, RHEL74, RHEL75, RHEL76 and Ubuntu (bionic, trusty,
> > xenial).
> >
> > Yifeng Sun (7):
> >datapath: Handle removal of nf_conntrack_l3proto.h
> >datapath: Pass nf_hook_state to nf_conntrack_in()
> >datapath: Use new header file net/ipv6_frag.h
> >datapath: Fix conntrack_count related compilation errors
> >openvswitch: use nf_ct_get_tuplepr, invert_tuplepr
> >netfilter: Remove useless param helper of nf_ct_helper_ext_add
> >datapath: Support kernel version 4.19.x and 4.20.x
> >
> > Tested-by: Greg Rose 
> > Reviewed-by: Greg Rose 
> >
> > v1->v2: Fix by reviewers' comments.
> > v2->v3: Fix patch series.
> >
> >   .travis.yml| 18 ---
> >   NEWS   |  2 ++
> >   acinclude.m4   | 17 --
> >   datapath/conntrack.c   | 26 
> > +-
> >   datapath/linux/Modules.mk  |  2 ++
> >   datapath/linux/compat/include/linux/netfilter.h| 19 
> >   datapath/linux/compat/include/net/ipv6_frag.h  |  8 +++
> >   .../include/net/netfilter/nf_conntrack_core.h  |  9 
> >   .../include/net/netfilter/nf_conntrack_count.h |  4 ++--
> >   .../include/net/netfilter/nf_conntrack_helper.h| 10 +
> >   datapath/linux/compat/nf_conncount.c   |  6 -
> >   datapath/linux/compat/nf_conntrack_proto.c |  2 ++
> >   12 files changed, 94 insertions(+), 29 deletions(-)
> >   create mode 100644 datapath/linux/compat/include/linux/netfilter.h
> >   create mode 100644 datapath/linux/compat/include/net/ipv6_frag.h
> >
>
> ___
> 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 0/7 v3] datapath: Support 4.19.x and 4.20.x kernel

2019-05-10 Thread Gregory Rose

My tags are missing.

For the series:

Tested-by: Greg Rose 
Reviewed-by: Greg Rose 

On 5/10/2019 12:30 PM, Yifeng Sun wrote:

This series of patches enabled OVS to support kernel 4.19.x and 4.20.x.

Tests shows that this series of patches passed check-kmod tests or
didn't introduce new failed check-kmod tests for the following
kernel versions:
3.10.0-957.12.1.el7.x86_64 (rhel)
4.4.0-31-generic (ubuntu 14.04)
4.4.0-146-generic (ubuntu 16.04)
4.4.179
4.9.171
4.14.111
4.15.0-48-generic (ubuntu 18.04)
4.17.19
4.18.0-18-generic (ubuntu 18.10)
4.19.37
4.20.17

Travis passed at:
https://travis-ci.org/yifsun/ovs-travis/builds/528006159

In addition, build is successful on:
CentOS73, Fedora, RHEL74, RHEL75, RHEL76 and Ubuntu (bionic, trusty,
xenial).

Yifeng Sun (7):
   datapath: Handle removal of nf_conntrack_l3proto.h
   datapath: Pass nf_hook_state to nf_conntrack_in()
   datapath: Use new header file net/ipv6_frag.h
   datapath: Fix conntrack_count related compilation errors
   openvswitch: use nf_ct_get_tuplepr, invert_tuplepr
   netfilter: Remove useless param helper of nf_ct_helper_ext_add
   datapath: Support kernel version 4.19.x and 4.20.x

Tested-by: Greg Rose 
Reviewed-by: Greg Rose 

v1->v2: Fix by reviewers' comments.
v2->v3: Fix patch series.

  .travis.yml| 18 ---
  NEWS   |  2 ++
  acinclude.m4   | 17 --
  datapath/conntrack.c   | 26 +-
  datapath/linux/Modules.mk  |  2 ++
  datapath/linux/compat/include/linux/netfilter.h| 19 
  datapath/linux/compat/include/net/ipv6_frag.h  |  8 +++
  .../include/net/netfilter/nf_conntrack_core.h  |  9 
  .../include/net/netfilter/nf_conntrack_count.h |  4 ++--
  .../include/net/netfilter/nf_conntrack_helper.h| 10 +
  datapath/linux/compat/nf_conncount.c   |  6 -
  datapath/linux/compat/nf_conntrack_proto.c |  2 ++
  12 files changed, 94 insertions(+), 29 deletions(-)
  create mode 100644 datapath/linux/compat/include/linux/netfilter.h
  create mode 100644 datapath/linux/compat/include/net/ipv6_frag.h



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


Re: [ovs-dev] [PATCH 7/7] datapath: Support kernel version 4.19.x and 4.20.x

2019-05-10 Thread Yifeng Sun
Please use v3, v2 was messed up, sorry.

Thanks,
Yifeng

On Fri, May 10, 2019 at 11:31 AM Ben Pfaff  wrote:
>
> Please do in this case.  It simplifies my workflow.
>
> On Fri, May 10, 2019 at 11:28:16AM -0700, Yifeng Sun wrote:
> > Hi Ben,
> >
> > All the patches in this series got acked. Do I need to send v2 for
> > those patches that were acked in v1?
> >
> > Thanks,
> > Yifeng
> >
> > On Wed, May 8, 2019 at 4:36 PM Yifeng Sun  wrote:
> > >
> > > Sure, I will submit new versions after testing is done.
> > > Thanks,
> > > Yifeng
> > >
> > > On Wed, May 8, 2019 at 4:05 PM Ben Pfaff  wrote:
> > > >
> > > > On Wed, May 08, 2019 at 02:27:57PM -0700, Yi-Hung Wei wrote:
> > > > > On Mon, May 6, 2019 at 3:01 PM Yifeng Sun  
> > > > > wrote:
> > > > > >
> > > > > > This patch updated acinclude.m4 so that OVS can be compiled on 
> > > > > > 4.19.x
> > > > > > and 4.20.x kernels.
> > > > > > This patch also updated travis files so that latest kernel versions
> > > > > > are used during travis test builds.
> > > > > >
> > > > > > Signed-off-by: Yifeng Sun 
> > > > > > ---
> > > > > Thanks for this patch. LGTM.
> > > > >
> > > > > Acked-by: Yi-Hung Wei 
> > > >
> > > > Thanks for the reviews.
> > > >
> > > > Yifeng, I will hope to see a v2 that includes the acks (and changes, if
> > > > any).
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH 7/7 v3] datapath: Support kernel version 4.19.x and 4.20.x

2019-05-10 Thread Yifeng Sun
This patch updated acinclude.m4 so that OVS can be compiled on 4.19.x
and 4.20.x kernels.
This patch also updated travis files so that latest kernel versions
are used during travis test builds.

Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
 .travis.yml  | 18 ++
 NEWS |  2 ++
 acinclude.m4 |  4 ++--
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 468c39ecd505..765692f7a2b2 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -31,19 +31,21 @@ env:
   - TESTSUITE=1 KERNEL=3.16.54
   - TESTSUITE=1 OPTS="--enable-shared"
   - BUILD_ENV="-m32" OPTS="--disable-ssl"
-  - KERNEL=3.16.54 DPDK=1 OPTS="--enable-shared"
-  - KERNEL=3.16.54 TESTSUITE=1 DPDK=1
-  - KERNEL=3.16.54 DPDK_SHARED=1
-  - KERNEL=3.16.54 DPDK_SHARED=1 OPTS="--enable-shared"
+  - KERNEL=3.16.65 DPDK=1 OPTS="--enable-shared"
+  - KERNEL=3.16.65 TESTSUITE=1 DPDK=1
+  - KERNEL=3.16.65 DPDK_SHARED=1
+  - KERNEL=3.16.65 DPDK_SHARED=1 OPTS="--enable-shared"
+  - KERNEL=4.20.17
+  - KERNEL=4.19.37
   - KERNEL=4.18.20
   - KERNEL=4.17.19
   - KERNEL=4.16.18
   - KERNEL=4.15.18
-  - KERNEL=4.14.111
-  - KERNEL=4.9.149
-  - KERNEL=4.4.148
+  - KERNEL=4.14.114
+  - KERNEL=4.9.171
+  - KERNEL=4.4.179
   - KERNEL=3.19.8
-  - KERNEL=3.16.57
+  - KERNEL=3.16.65
   - TESTSUITE=1 LIBS=-ljemalloc
 
 matrix:
diff --git a/NEWS b/NEWS
index 293531db0615..3b4160c27834 100644
--- a/NEWS
+++ b/NEWS
@@ -40,6 +40,8 @@ Post-v2.11.0
members of the same transport zone(s).
- New QoS type "linux-netem" on Linux.
- Added support for TLS Server Name Indication (SNI).
+   - Linux datapath:
+ * Support for the kernel versions 4.19.x and 4.20.x.
 
 
 v2.11.0 - 19 Feb 2019
diff --git a/acinclude.m4 b/acinclude.m4
index 878c2f6d40f2..f8fc5bcd7b4c 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -151,10 +151,10 @@ AC_DEFUN([OVS_CHECK_LINUX], [
 AC_MSG_RESULT([$kversion])
 
 if test "$version" -ge 4; then
-   if test "$version" = 4 && test "$patchlevel" -le 18; then
+   if test "$version" = 4 && test "$patchlevel" -le 20; then
   : # Linux 4.x
else
-  AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version 
newer than 4.18.x is not supported (please refer to the FAQ for advice)])
+  AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version 
newer than 4.20.x is not supported (please refer to the FAQ for advice)])
fi
 elif test "$version" = 3 && test "$patchlevel" -ge 10; then
: # Linux 3.x
-- 
2.7.4

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


[ovs-dev] [PATCH 6/7 v3] netfilter: Remove useless param helper of nf_ct_helper_ext_add

2019-05-10 Thread Yifeng Sun
From: Gao Feng 

Upstream commit:
commit 440534d3c56be04abfb26850ee882d19d223557a
Author: Gao Feng 
Date:   Mon Jul 9 18:06:33 2018 +0800

netfilter: Remove useless param helper of nf_ct_helper_ext_add

The param helper of nf_ct_helper_ext_add is useless now, then remove
it now.

Signed-off-by: Gao Feng 
Signed-off-by: Pablo Neira Ayuso 

This patch backports the above upstream patch to OVS.

Cc: Gao Feng 
Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
v1->v2: Rebase previous patch's changes.

 acinclude.m4   |  3 +++
 .../linux/compat/include/net/netfilter/nf_conntrack_helper.h   | 10 ++
 2 files changed, 13 insertions(+)

diff --git a/acinclude.m4 b/acinclude.m4
index 4f9aebc325ba..878c2f6d40f2 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -936,6 +936,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
 
[OVS_DEFINE([HAVE_NF_CONNTRACK_IN_TAKES_NF_HOOK_STATE])])
   OVS_GREP_IFELSE([$KSRC/include/net/ipv6_frag.h], [IP6_DEFRAG_CONNTRACK_IN],
   [OVS_DEFINE([HAVE_IPV6_FRAG_H])])
+  OVS_FIND_PARAM_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_helper.h],
+[nf_ct_helper_ext_add], [nf_conntrack_helper],
+[OVS_DEFINE([HAVE_NF_CT_HELPER_EXT_ADD_TAKES_HELPER])])
 
   if cmp -s datapath/linux/kcompat.h.new \
 datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h 
b/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h
index 19c35cd95f6f..b6a3d0bf75b3 100644
--- a/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h
+++ b/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h
@@ -9,4 +9,14 @@ static inline void nf_conntrack_helper_put(struct 
nf_conntrack_helper *helper) {
 }
 #endif
 
+#ifndef HAVE_NF_CT_HELPER_EXT_ADD_TAKES_HELPER
+static inline struct nf_conn_help *
+rpl_nf_ct_helper_ext_add(struct nf_conn *ct,
+struct nf_conntrack_helper *helper, gfp_t gfp)
+{
+   return nf_ct_helper_ext_add(ct, gfp);
+}
+#define nf_ct_helper_ext_add rpl_nf_ct_helper_ext_add
+#endif /* HAVE_NF_CT_HELPER_EXT_ADD_TAKES_HELPER */
+
 #endif /* _NF_CONNTRACK_HELPER_WRAPPER_H */
-- 
2.7.4

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


[ovs-dev] [PATCH 5/7 v3] openvswitch: use nf_ct_get_tuplepr, invert_tuplepr

2019-05-10 Thread Yifeng Sun
From: Florian Westphal 

Upstream commit:
commit 60e3be94e6a1c5162a0763c9aafb5190b2b1fdce
Author: Florian Westphal 
Date:   Mon Jun 25 17:55:32 2018 +0200

openvswitch: use nf_ct_get_tuplepr, invert_tuplepr

These versions deal with the l3proto/l4proto details internally.
It removes only caller of nf_ct_get_tuple, so make it static.

After this, l3proto->get_l4proto() can be removed in a followup patch.

Signed-off-by: Florian Westphal 
Acked-by: Pravin B Shelar 
Signed-off-by: Pablo Neira Ayuso 

This patch backports the above upstream kernel patch to OVS.

Cc: Florian Westphal 
Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
v1->v2: Fixed nf_ct_invert_tuplepr by YiHung's comments, Thanks YiHung.

 datapath/conntrack.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/datapath/conntrack.c b/datapath/conntrack.c
index 52825a6b20fb..292febb3c83e 100644
--- a/datapath/conntrack.c
+++ b/datapath/conntrack.c
@@ -646,23 +646,12 @@ static struct nf_conn *
 ovs_ct_find_existing(struct net *net, const struct nf_conntrack_zone *zone,
 u8 l3num, struct sk_buff *skb, bool natted)
 {
-   const struct nf_conntrack_l3proto *l3proto;
-   const struct nf_conntrack_l4proto *l4proto;
struct nf_conntrack_tuple tuple;
struct nf_conntrack_tuple_hash *h;
struct nf_conn *ct;
-   unsigned int dataoff;
-   u8 protonum;
 
-   l3proto = __nf_ct_l3proto_find(l3num);
-   if (l3proto->get_l4proto(skb, skb_network_offset(skb), ,
-) <= 0) {
-   pr_debug("ovs_ct_find_existing: Can't get protonum\n");
-   return NULL;
-   }
-   l4proto = __nf_ct_l4proto_find(l3num, protonum);
-   if (!nf_ct_get_tuple(skb, skb_network_offset(skb), dataoff, l3num,
-protonum, net, , l3proto, l4proto)) {
+   if (!nf_ct_get_tuplepr(skb, skb_network_offset(skb), l3num,
+  net, )) {
pr_debug("ovs_ct_find_existing: Can't get tuple\n");
return NULL;
}
@@ -671,7 +660,7 @@ ovs_ct_find_existing(struct net *net, const struct 
nf_conntrack_zone *zone,
if (natted) {
struct nf_conntrack_tuple inverse;
 
-   if (!nf_ct_invert_tuple(, , l3proto, l4proto)) {
+   if (!nf_ct_invert_tuplepr(, )) {
pr_debug("ovs_ct_find_existing: Inversion failed!\n");
return NULL;
}
-- 
2.7.4

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


[ovs-dev] [PATCH 4/7 v3] datapath: Fix conntrack_count related compilation errors

2019-05-10 Thread Yifeng Sun
This patch fixes the compilation errors of OVS on 4.19+ kernels.

Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
 datapath/linux/compat/include/net/netfilter/nf_conntrack_count.h | 4 ++--
 datapath/linux/compat/nf_conncount.c | 6 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/datapath/linux/compat/include/net/netfilter/nf_conntrack_count.h 
b/datapath/linux/compat/include/net/netfilter/nf_conntrack_count.h
index fd536f3e1854..614017309efe 100644
--- a/datapath/linux/compat/include/net/netfilter/nf_conntrack_count.h
+++ b/datapath/linux/compat/include/net/netfilter/nf_conntrack_count.h
@@ -2,6 +2,8 @@
 #define _NF_CONNTRACK_COUNT_WRAPPER_H
 
 #include 
+#include 
+#include 
 
 #ifdef HAVE_UPSTREAM_NF_CONNCOUNT
 #include_next 
@@ -16,8 +18,6 @@ static inline void rpl_nf_conncount_modexit(void)
 }
 
 #else
-#include 
-#include 
 #define CONFIG_NETFILTER_CONNCOUNT 1
 struct nf_conncount_data;
 
diff --git a/datapath/linux/compat/nf_conncount.c 
b/datapath/linux/compat/nf_conncount.c
index 0bee96274b00..eeae440f872d 100644
--- a/datapath/linux/compat/nf_conncount.c
+++ b/datapath/linux/compat/nf_conncount.c
@@ -13,6 +13,8 @@
  * only ignore TIME_WAIT or gone connections
  *   (C) CC Computer Consultants GmbH, 2007
  */
+#ifndef HAVE_UPSTREAM_NF_CONNCOUNT
+
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 #include 
 #include 
@@ -138,7 +140,7 @@ static bool conn_free(struct nf_conncount_list *list,
 
if (list->count == 0) {
spin_unlock(>list_lock);
-return free_entry;
+   return free_entry;
}
 
list->count--;
@@ -635,3 +637,5 @@ void rpl_nf_conncount_modexit(void)
kmem_cache_destroy(conncount_conn_cachep);
kmem_cache_destroy(conncount_rb_cachep);
 }
+
+#endif /* HAVE_UPSTREAM_NF_CONNCOUNT */
-- 
2.7.4

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


[ovs-dev] [PATCH 3/7 v3] datapath: Use new header file net/ipv6_frag.h

2019-05-10 Thread Yifeng Sun
From: Florian Westphal 

Upstream commit:
commit 70b095c84326640eeacfd69a411db8fc36e8ab1a
Author: Florian Westphal 
Date:   Sat Jul 14 01:14:01 2018 +0200

ipv6: remove dependency of nf_defrag_ipv6 on ipv6 module

IPV6=m
DEFRAG_IPV6=m
CONNTRACK=y yields:

net/netfilter/nf_conntrack_proto.o: In function `nf_ct_netns_do_get':
net/netfilter/nf_conntrack_proto.c:802: undefined reference to 
`nf_defrag_ipv6_enable'
net/netfilter/nf_conntrack_proto.o:(.rodata+0x640): undefined reference to 
`nf_conntrack_l4proto_icmpv6'

Setting DEFRAG_IPV6=y causes undefined references to ip6_rhash_params
ip6_frag_init and ip6_expire_frag_queue so it would be needed to force
IPV6=y too.

This patch gets rid of the 'followup linker error' by removing
the dependency of ipv6.ko symbols from netfilter ipv6 defrag.

Shared code is placed into a header, then used from both.

Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 

This patch backports the above upstream patch to OVS.

Cc: Florian Westphal 
Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
 acinclude.m4  | 2 ++
 datapath/conntrack.c  | 1 +
 datapath/linux/Modules.mk | 1 +
 datapath/linux/compat/include/net/ipv6_frag.h | 8 
 4 files changed, 12 insertions(+)
 create mode 100644 datapath/linux/compat/include/net/ipv6_frag.h

diff --git a/acinclude.m4 b/acinclude.m4
index 372be5f4dccd..4f9aebc325ba 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -934,6 +934,8 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
   OVS_FIND_PARAM_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_core.h],
 [nf_conntrack_in], [nf_hook_state],
 
[OVS_DEFINE([HAVE_NF_CONNTRACK_IN_TAKES_NF_HOOK_STATE])])
+  OVS_GREP_IFELSE([$KSRC/include/net/ipv6_frag.h], [IP6_DEFRAG_CONNTRACK_IN],
+  [OVS_DEFINE([HAVE_IPV6_FRAG_H])])
 
   if cmp -s datapath/linux/kcompat.h.new \
 datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/conntrack.c b/datapath/conntrack.c
index 8c1a80308d6a..52825a6b20fb 100644
--- a/datapath/conntrack.c
+++ b/datapath/conntrack.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_NF_NAT_NEEDED
 #include 
diff --git a/datapath/linux/Modules.mk b/datapath/linux/Modules.mk
index ae63e3653b41..cbb29f1c69d0 100644
--- a/datapath/linux/Modules.mk
+++ b/datapath/linux/Modules.mk
@@ -86,6 +86,7 @@ openvswitch_headers += \
linux/compat/include/net/ip6_route.h \
linux/compat/include/net/ip6_tunnel.h \
linux/compat/include/net/ipv6.h \
+   linux/compat/include/net/ipv6_frag.h \
linux/compat/include/net/mpls.h \
linux/compat/include/net/net_namespace.h \
linux/compat/include/net/netlink.h \
diff --git a/datapath/linux/compat/include/net/ipv6_frag.h 
b/datapath/linux/compat/include/net/ipv6_frag.h
new file mode 100644
index ..5d1cc901bec1
--- /dev/null
+++ b/datapath/linux/compat/include/net/ipv6_frag.h
@@ -0,0 +1,8 @@
+#ifndef __NET_IPV6_FRAG_WRAPPER_H
+#define __NET_IPV6_FRAG_WRAPPER_H
+
+#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV6) && defined(HAVE_IPV6_FRAG_H)
+#include_next 
+#endif
+
+#endif /* __NET_IPV6_FRAG_WRAPPER_H */
-- 
2.7.4

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


[ovs-dev] [PATCH 2/7 v3] datapath: Pass nf_hook_state to nf_conntrack_in()

2019-05-10 Thread Yifeng Sun
From: Florian Westphal 

Upstream Commit:
commit 93e66024b0249cec81e91328c55a754efd3192e0
Author: Florian Westphal 
Date:   Wed Sep 12 15:19:07 2018 +0200

netfilter: conntrack: pass nf_hook_state to packet and error handlers

nf_hook_state contains all the hook meta-information: netns, protocol 
family,
hook location, and so on.

Instead of only passing selected information, pass a pointer to entire
structure.

This will allow to merge the error and the packet handlers and remove
the ->new() function in followup patches.

Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 

This patch backports the above upstream patch to OVS and fixes compiling
errors on RHEL kernels.

Cc: Florian Westphal 
Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
v1->v2: Fixed by YiHung's comments, thanks YiHung.

 acinclude.m4  |  5 +
 datapath/conntrack.c  |  8 ++--
 datapath/linux/Modules.mk |  1 +
 datapath/linux/compat/include/linux/netfilter.h   | 19 +++
 .../compat/include/net/netfilter/nf_conntrack_core.h  |  9 +
 5 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100644 datapath/linux/compat/include/linux/netfilter.h

diff --git a/acinclude.m4 b/acinclude.m4
index c9b744db0b94..372be5f4dccd 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -603,6 +603,8 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
 [ndo_change_mtu], [OVS_DEFINE([HAVE_RHEL7_MAX_MTU])])
 
   OVS_GREP_IFELSE([$KSRC/include/linux/netfilter.h], [nf_hook_state])
+  OVS_FIND_FIELD_IFELSE([$KSRC/include/linux/netfilter.h], [nf_hook_state],
+[struct net ], [OVS_DEFINE([HAVE_NF_HOOK_STATE_NET])])
   OVS_GREP_IFELSE([$KSRC/include/linux/netfilter.h], [nf_register_net_hook])
   OVS_GREP_IFELSE([$KSRC/include/linux/netfilter.h], [nf_hookfn.*nf_hook_ops],
   [OVS_DEFINE([HAVE_NF_HOOKFN_ARG_OPS])])
@@ -929,6 +931,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
   OVS_GREP_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_l3proto.h],
   [nf_conntrack_l3proto],
   [OVS_DEFINE([HAVE_NF_CONNTRACK_L3PROATO_H])])
+  OVS_FIND_PARAM_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_core.h],
+[nf_conntrack_in], [nf_hook_state],
+
[OVS_DEFINE([HAVE_NF_CONNTRACK_IN_TAKES_NF_HOOK_STATE])])
 
   if cmp -s datapath/linux/kcompat.h.new \
 datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/conntrack.c b/datapath/conntrack.c
index 52208bad3029..8c1a80308d6a 100644
--- a/datapath/conntrack.c
+++ b/datapath/conntrack.c
@@ -987,6 +987,11 @@ static int __ovs_ct_lookup(struct net *net, struct 
sw_flow_key *key,
struct nf_conn *ct;
 
if (!cached) {
+   struct nf_hook_state state = {
+   .hook = NF_INET_PRE_ROUTING,
+   .pf = info->family,
+   .net = net,
+   };
struct nf_conn *tmpl = info->ct;
int err;
 
@@ -998,8 +1003,7 @@ static int __ovs_ct_lookup(struct net *net, struct 
sw_flow_key *key,
nf_ct_set(skb, tmpl, IP_CT_NEW);
}
 
-   err = nf_conntrack_in(net, info->family,
- NF_INET_PRE_ROUTING, skb);
+   err = nf_conntrack_in(skb, );
if (err != NF_ACCEPT)
return -ENOENT;
 
diff --git a/datapath/linux/Modules.mk b/datapath/linux/Modules.mk
index caa2525ff0ab..ae63e3653b41 100644
--- a/datapath/linux/Modules.mk
+++ b/datapath/linux/Modules.mk
@@ -114,5 +114,6 @@ openvswitch_headers += \
linux/compat/include/net/erspan.h \
linux/compat/include/uapi/linux/netfilter.h \
linux/compat/include/linux/mm.h \
+   linux/compat/include/linux/netfilter.h \
linux/compat/include/linux/overflow.h
 EXTRA_DIST += linux/compat/build-aux/export-check-whitelist
diff --git a/datapath/linux/compat/include/linux/netfilter.h 
b/datapath/linux/compat/include/linux/netfilter.h
new file mode 100644
index ..a6ed6172d49f
--- /dev/null
+++ b/datapath/linux/compat/include/linux/netfilter.h
@@ -0,0 +1,19 @@
+#ifndef __NETFILTER_WRAPPER_H
+#define __NETFILTER_WRAPPER_H
+
+#include_next 
+
+#if !defined(HAVE_NF_HOOK_STATE) || !defined(HAVE_NF_HOOK_STATE_NET)
+struct rpl_nf_hook_state {
+   unsigned int hook;
+   u_int8_t pf;
+   struct net_device *in;
+   struct net_device *out;
+   struct sock *sk;
+   struct net *net;
+   int (*okfn)(struct net *, struct sock *, struct sk_buff *);
+};
+#define nf_hook_state rpl_nf_hook_state
+#endif
+
+#endif /* __NETFILTER_WRAPPER_H */
diff --git a/datapath/linux/compat/include/net/netfilter/nf_conntrack_core.h 
b/datapath/linux/compat/include/net/netfilter/nf_conntrack_core.h

[ovs-dev] [PATCH 1/7 v3] datapath: Handle removal of nf_conntrack_l3proto.h

2019-05-10 Thread Yifeng Sun
Upstream kernel commit a0ae2562 ("netfilter: conntrack: remove l3proto
abstraction") removed header file net/netfilter/nf_conntrack_l3proto.h.
This patch detects it and fixes compilation errors of OVS on 4.19+ kernels.

Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
 acinclude.m4   | 3 +++
 datapath/linux/compat/nf_conntrack_proto.c | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/acinclude.m4 b/acinclude.m4
index b532a4579266..c9b744db0b94 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -926,6 +926,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
   [OVS_DEFINE([HAVE_KVMALLOC_ARRAY])])
   OVS_GREP_IFELSE([$KSRC/include/linux/mm.h], [kvmalloc_node],
   [OVS_DEFINE([HAVE_KVMALLOC_NODE])])
+  OVS_GREP_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_l3proto.h],
+  [nf_conntrack_l3proto],
+  [OVS_DEFINE([HAVE_NF_CONNTRACK_L3PROATO_H])])
 
   if cmp -s datapath/linux/kcompat.h.new \
 datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/linux/compat/nf_conntrack_proto.c 
b/datapath/linux/compat/nf_conntrack_proto.c
index 4ac66f61c70d..fe291dbf25e1 100644
--- a/datapath/linux/compat/nf_conntrack_proto.c
+++ b/datapath/linux/compat/nf_conntrack_proto.c
@@ -1,7 +1,9 @@
 #include 
 
 #include 
+#ifdef HAVE_NF_CONNTRACK_L3PROATO_H
 #include 
+#endif
 
 /*
  * Upstream net-next commmit 7e35ec0e8044
-- 
2.7.4

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


[ovs-dev] [PATCH 0/7 v3] datapath: Support 4.19.x and 4.20.x kernel

2019-05-10 Thread Yifeng Sun
This series of patches enabled OVS to support kernel 4.19.x and 4.20.x.

Tests shows that this series of patches passed check-kmod tests or
didn't introduce new failed check-kmod tests for the following
kernel versions:
3.10.0-957.12.1.el7.x86_64 (rhel)
4.4.0-31-generic (ubuntu 14.04)
4.4.0-146-generic (ubuntu 16.04)
4.4.179
4.9.171
4.14.111
4.15.0-48-generic (ubuntu 18.04)
4.17.19
4.18.0-18-generic (ubuntu 18.10)
4.19.37
4.20.17

Travis passed at:
https://travis-ci.org/yifsun/ovs-travis/builds/528006159

In addition, build is successful on:
CentOS73, Fedora, RHEL74, RHEL75, RHEL76 and Ubuntu (bionic, trusty,
xenial).

Yifeng Sun (7):
  datapath: Handle removal of nf_conntrack_l3proto.h
  datapath: Pass nf_hook_state to nf_conntrack_in()
  datapath: Use new header file net/ipv6_frag.h
  datapath: Fix conntrack_count related compilation errors
  openvswitch: use nf_ct_get_tuplepr, invert_tuplepr
  netfilter: Remove useless param helper of nf_ct_helper_ext_add
  datapath: Support kernel version 4.19.x and 4.20.x

Tested-by: Greg Rose 
Reviewed-by: Greg Rose 

v1->v2: Fix by reviewers' comments.
v2->v3: Fix patch series.

 .travis.yml| 18 ---
 NEWS   |  2 ++
 acinclude.m4   | 17 --
 datapath/conntrack.c   | 26 +-
 datapath/linux/Modules.mk  |  2 ++
 datapath/linux/compat/include/linux/netfilter.h| 19 
 datapath/linux/compat/include/net/ipv6_frag.h  |  8 +++
 .../include/net/netfilter/nf_conntrack_core.h  |  9 
 .../include/net/netfilter/nf_conntrack_count.h |  4 ++--
 .../include/net/netfilter/nf_conntrack_helper.h| 10 +
 datapath/linux/compat/nf_conncount.c   |  6 -
 datapath/linux/compat/nf_conntrack_proto.c |  2 ++
 12 files changed, 94 insertions(+), 29 deletions(-)
 create mode 100644 datapath/linux/compat/include/linux/netfilter.h
 create mode 100644 datapath/linux/compat/include/net/ipv6_frag.h

-- 
2.7.4

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


[ovs-dev] [PATCH 5/7 v2] openvswitch: use nf_ct_get_tuplepr, invert_tuplepr

2019-05-10 Thread Yifeng Sun
From: Florian Westphal 

Upstream commit:
commit 60e3be94e6a1c5162a0763c9aafb5190b2b1fdce
Author: Florian Westphal 
Date:   Mon Jun 25 17:55:32 2018 +0200

openvswitch: use nf_ct_get_tuplepr, invert_tuplepr

These versions deal with the l3proto/l4proto details internally.
It removes only caller of nf_ct_get_tuple, so make it static.

After this, l3proto->get_l4proto() can be removed in a followup patch.

Signed-off-by: Florian Westphal 
Acked-by: Pravin B Shelar 
Signed-off-by: Pablo Neira Ayuso 

This patch backports the above upstream kernel patch to OVS.

Cc: Florian Westphal 
Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
v1->v2: Fixed nf_ct_invert_tuplepr by YiHung's comments, Thanks YiHung.

 datapath/conntrack.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/datapath/conntrack.c b/datapath/conntrack.c
index 52825a6b20fb..292febb3c83e 100644
--- a/datapath/conntrack.c
+++ b/datapath/conntrack.c
@@ -646,23 +646,12 @@ static struct nf_conn *
 ovs_ct_find_existing(struct net *net, const struct nf_conntrack_zone *zone,
 u8 l3num, struct sk_buff *skb, bool natted)
 {
-   const struct nf_conntrack_l3proto *l3proto;
-   const struct nf_conntrack_l4proto *l4proto;
struct nf_conntrack_tuple tuple;
struct nf_conntrack_tuple_hash *h;
struct nf_conn *ct;
-   unsigned int dataoff;
-   u8 protonum;
 
-   l3proto = __nf_ct_l3proto_find(l3num);
-   if (l3proto->get_l4proto(skb, skb_network_offset(skb), ,
-) <= 0) {
-   pr_debug("ovs_ct_find_existing: Can't get protonum\n");
-   return NULL;
-   }
-   l4proto = __nf_ct_l4proto_find(l3num, protonum);
-   if (!nf_ct_get_tuple(skb, skb_network_offset(skb), dataoff, l3num,
-protonum, net, , l3proto, l4proto)) {
+   if (!nf_ct_get_tuplepr(skb, skb_network_offset(skb), l3num,
+  net, )) {
pr_debug("ovs_ct_find_existing: Can't get tuple\n");
return NULL;
}
@@ -671,7 +660,7 @@ ovs_ct_find_existing(struct net *net, const struct 
nf_conntrack_zone *zone,
if (natted) {
struct nf_conntrack_tuple inverse;
 
-   if (!nf_ct_invert_tuple(, , l3proto, l4proto)) {
+   if (!nf_ct_invert_tuplepr(, )) {
pr_debug("ovs_ct_find_existing: Inversion failed!\n");
return NULL;
}
-- 
2.7.4

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


[ovs-dev] [PATCH 4/7 v2] datapath: Fix conntrack_count related compilation errors

2019-05-10 Thread Yifeng Sun
This patch fixes the compilation errors of OVS on 4.19+ kernels.

Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
 datapath/linux/compat/include/net/netfilter/nf_conntrack_count.h | 4 ++--
 datapath/linux/compat/nf_conncount.c | 6 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/datapath/linux/compat/include/net/netfilter/nf_conntrack_count.h 
b/datapath/linux/compat/include/net/netfilter/nf_conntrack_count.h
index fd536f3e1854..614017309efe 100644
--- a/datapath/linux/compat/include/net/netfilter/nf_conntrack_count.h
+++ b/datapath/linux/compat/include/net/netfilter/nf_conntrack_count.h
@@ -2,6 +2,8 @@
 #define _NF_CONNTRACK_COUNT_WRAPPER_H
 
 #include 
+#include 
+#include 
 
 #ifdef HAVE_UPSTREAM_NF_CONNCOUNT
 #include_next 
@@ -16,8 +18,6 @@ static inline void rpl_nf_conncount_modexit(void)
 }
 
 #else
-#include 
-#include 
 #define CONFIG_NETFILTER_CONNCOUNT 1
 struct nf_conncount_data;
 
diff --git a/datapath/linux/compat/nf_conncount.c 
b/datapath/linux/compat/nf_conncount.c
index 0bee96274b00..eeae440f872d 100644
--- a/datapath/linux/compat/nf_conncount.c
+++ b/datapath/linux/compat/nf_conncount.c
@@ -13,6 +13,8 @@
  * only ignore TIME_WAIT or gone connections
  *   (C) CC Computer Consultants GmbH, 2007
  */
+#ifndef HAVE_UPSTREAM_NF_CONNCOUNT
+
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 #include 
 #include 
@@ -138,7 +140,7 @@ static bool conn_free(struct nf_conncount_list *list,
 
if (list->count == 0) {
spin_unlock(>list_lock);
-return free_entry;
+   return free_entry;
}
 
list->count--;
@@ -635,3 +637,5 @@ void rpl_nf_conncount_modexit(void)
kmem_cache_destroy(conncount_conn_cachep);
kmem_cache_destroy(conncount_rb_cachep);
 }
+
+#endif /* HAVE_UPSTREAM_NF_CONNCOUNT */
-- 
2.7.4

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


[ovs-dev] [PATCH 1/7 v2] datapath: Handle removal of nf_conntrack_l3proto.h

2019-05-10 Thread Yifeng Sun
Upstream kernel commit a0ae2562 ("netfilter: conntrack: remove l3proto
abstraction") removed header file net/netfilter/nf_conntrack_l3proto.h.
This patch detects it and fixes compilation errors of OVS on 4.19+ kernels.

Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
 acinclude.m4   | 3 +++
 datapath/linux/compat/nf_conntrack_proto.c | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/acinclude.m4 b/acinclude.m4
index b532a4579266..c9b744db0b94 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -926,6 +926,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
   [OVS_DEFINE([HAVE_KVMALLOC_ARRAY])])
   OVS_GREP_IFELSE([$KSRC/include/linux/mm.h], [kvmalloc_node],
   [OVS_DEFINE([HAVE_KVMALLOC_NODE])])
+  OVS_GREP_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_l3proto.h],
+  [nf_conntrack_l3proto],
+  [OVS_DEFINE([HAVE_NF_CONNTRACK_L3PROATO_H])])
 
   if cmp -s datapath/linux/kcompat.h.new \
 datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/linux/compat/nf_conntrack_proto.c 
b/datapath/linux/compat/nf_conntrack_proto.c
index 4ac66f61c70d..fe291dbf25e1 100644
--- a/datapath/linux/compat/nf_conntrack_proto.c
+++ b/datapath/linux/compat/nf_conntrack_proto.c
@@ -1,7 +1,9 @@
 #include 
 
 #include 
+#ifdef HAVE_NF_CONNTRACK_L3PROATO_H
 #include 
+#endif
 
 /*
  * Upstream net-next commmit 7e35ec0e8044
-- 
2.7.4

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


[ovs-dev] [PATCH 7/7 v2] datapath: Support kernel version 4.19.x and 4.20.x

2019-05-10 Thread Yifeng Sun
This patch updated acinclude.m4 so that OVS can be compiled on 4.19.x
and 4.20.x kernels.
This patch also updated travis files so that latest kernel versions
are used during travis test builds.

Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
 .travis.yml  | 18 ++
 NEWS |  2 ++
 acinclude.m4 |  4 ++--
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 468c39ecd505..765692f7a2b2 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -31,19 +31,21 @@ env:
   - TESTSUITE=1 KERNEL=3.16.54
   - TESTSUITE=1 OPTS="--enable-shared"
   - BUILD_ENV="-m32" OPTS="--disable-ssl"
-  - KERNEL=3.16.54 DPDK=1 OPTS="--enable-shared"
-  - KERNEL=3.16.54 TESTSUITE=1 DPDK=1
-  - KERNEL=3.16.54 DPDK_SHARED=1
-  - KERNEL=3.16.54 DPDK_SHARED=1 OPTS="--enable-shared"
+  - KERNEL=3.16.65 DPDK=1 OPTS="--enable-shared"
+  - KERNEL=3.16.65 TESTSUITE=1 DPDK=1
+  - KERNEL=3.16.65 DPDK_SHARED=1
+  - KERNEL=3.16.65 DPDK_SHARED=1 OPTS="--enable-shared"
+  - KERNEL=4.20.17
+  - KERNEL=4.19.37
   - KERNEL=4.18.20
   - KERNEL=4.17.19
   - KERNEL=4.16.18
   - KERNEL=4.15.18
-  - KERNEL=4.14.111
-  - KERNEL=4.9.149
-  - KERNEL=4.4.148
+  - KERNEL=4.14.114
+  - KERNEL=4.9.171
+  - KERNEL=4.4.179
   - KERNEL=3.19.8
-  - KERNEL=3.16.57
+  - KERNEL=3.16.65
   - TESTSUITE=1 LIBS=-ljemalloc
 
 matrix:
diff --git a/NEWS b/NEWS
index 293531db0615..3b4160c27834 100644
--- a/NEWS
+++ b/NEWS
@@ -40,6 +40,8 @@ Post-v2.11.0
members of the same transport zone(s).
- New QoS type "linux-netem" on Linux.
- Added support for TLS Server Name Indication (SNI).
+   - Linux datapath:
+ * Support for the kernel versions 4.19.x and 4.20.x.
 
 
 v2.11.0 - 19 Feb 2019
diff --git a/acinclude.m4 b/acinclude.m4
index 878c2f6d40f2..f8fc5bcd7b4c 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -151,10 +151,10 @@ AC_DEFUN([OVS_CHECK_LINUX], [
 AC_MSG_RESULT([$kversion])
 
 if test "$version" -ge 4; then
-   if test "$version" = 4 && test "$patchlevel" -le 18; then
+   if test "$version" = 4 && test "$patchlevel" -le 20; then
   : # Linux 4.x
else
-  AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version 
newer than 4.18.x is not supported (please refer to the FAQ for advice)])
+  AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version 
newer than 4.20.x is not supported (please refer to the FAQ for advice)])
fi
 elif test "$version" = 3 && test "$patchlevel" -ge 10; then
: # Linux 3.x
-- 
2.7.4

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


[ovs-dev] [PATCH 2/7 v2] datapath: Pass nf_hook_state to nf_conntrack_in()

2019-05-10 Thread Yifeng Sun
From: Florian Westphal 

Upstream Commit:
commit 93e66024b0249cec81e91328c55a754efd3192e0
Author: Florian Westphal 
Date:   Wed Sep 12 15:19:07 2018 +0200

netfilter: conntrack: pass nf_hook_state to packet and error handlers

nf_hook_state contains all the hook meta-information: netns, protocol 
family,
hook location, and so on.

Instead of only passing selected information, pass a pointer to entire
structure.

This will allow to merge the error and the packet handlers and remove
the ->new() function in followup patches.

Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 

This patch backports the above upstream patch to OVS and fixes compiling
errors on RHEL kernels.

Cc: Florian Westphal 
Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
v1->v2: Fixed by YiHung's comments, thanks YiHung.

 acinclude.m4  |  5 +
 datapath/conntrack.c  |  8 ++--
 datapath/linux/Modules.mk |  1 +
 datapath/linux/compat/include/linux/netfilter.h   | 19 +++
 .../compat/include/net/netfilter/nf_conntrack_core.h  |  9 +
 5 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100644 datapath/linux/compat/include/linux/netfilter.h

diff --git a/acinclude.m4 b/acinclude.m4
index c9b744db0b94..372be5f4dccd 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -603,6 +603,8 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
 [ndo_change_mtu], [OVS_DEFINE([HAVE_RHEL7_MAX_MTU])])
 
   OVS_GREP_IFELSE([$KSRC/include/linux/netfilter.h], [nf_hook_state])
+  OVS_FIND_FIELD_IFELSE([$KSRC/include/linux/netfilter.h], [nf_hook_state],
+[struct net ], [OVS_DEFINE([HAVE_NF_HOOK_STATE_NET])])
   OVS_GREP_IFELSE([$KSRC/include/linux/netfilter.h], [nf_register_net_hook])
   OVS_GREP_IFELSE([$KSRC/include/linux/netfilter.h], [nf_hookfn.*nf_hook_ops],
   [OVS_DEFINE([HAVE_NF_HOOKFN_ARG_OPS])])
@@ -929,6 +931,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
   OVS_GREP_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_l3proto.h],
   [nf_conntrack_l3proto],
   [OVS_DEFINE([HAVE_NF_CONNTRACK_L3PROATO_H])])
+  OVS_FIND_PARAM_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_core.h],
+[nf_conntrack_in], [nf_hook_state],
+
[OVS_DEFINE([HAVE_NF_CONNTRACK_IN_TAKES_NF_HOOK_STATE])])
 
   if cmp -s datapath/linux/kcompat.h.new \
 datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/conntrack.c b/datapath/conntrack.c
index 52208bad3029..8c1a80308d6a 100644
--- a/datapath/conntrack.c
+++ b/datapath/conntrack.c
@@ -987,6 +987,11 @@ static int __ovs_ct_lookup(struct net *net, struct 
sw_flow_key *key,
struct nf_conn *ct;
 
if (!cached) {
+   struct nf_hook_state state = {
+   .hook = NF_INET_PRE_ROUTING,
+   .pf = info->family,
+   .net = net,
+   };
struct nf_conn *tmpl = info->ct;
int err;
 
@@ -998,8 +1003,7 @@ static int __ovs_ct_lookup(struct net *net, struct 
sw_flow_key *key,
nf_ct_set(skb, tmpl, IP_CT_NEW);
}
 
-   err = nf_conntrack_in(net, info->family,
- NF_INET_PRE_ROUTING, skb);
+   err = nf_conntrack_in(skb, );
if (err != NF_ACCEPT)
return -ENOENT;
 
diff --git a/datapath/linux/Modules.mk b/datapath/linux/Modules.mk
index caa2525ff0ab..ae63e3653b41 100644
--- a/datapath/linux/Modules.mk
+++ b/datapath/linux/Modules.mk
@@ -114,5 +114,6 @@ openvswitch_headers += \
linux/compat/include/net/erspan.h \
linux/compat/include/uapi/linux/netfilter.h \
linux/compat/include/linux/mm.h \
+   linux/compat/include/linux/netfilter.h \
linux/compat/include/linux/overflow.h
 EXTRA_DIST += linux/compat/build-aux/export-check-whitelist
diff --git a/datapath/linux/compat/include/linux/netfilter.h 
b/datapath/linux/compat/include/linux/netfilter.h
new file mode 100644
index ..a6ed6172d49f
--- /dev/null
+++ b/datapath/linux/compat/include/linux/netfilter.h
@@ -0,0 +1,19 @@
+#ifndef __NETFILTER_WRAPPER_H
+#define __NETFILTER_WRAPPER_H
+
+#include_next 
+
+#if !defined(HAVE_NF_HOOK_STATE) || !defined(HAVE_NF_HOOK_STATE_NET)
+struct rpl_nf_hook_state {
+   unsigned int hook;
+   u_int8_t pf;
+   struct net_device *in;
+   struct net_device *out;
+   struct sock *sk;
+   struct net *net;
+   int (*okfn)(struct net *, struct sock *, struct sk_buff *);
+};
+#define nf_hook_state rpl_nf_hook_state
+#endif
+
+#endif /* __NETFILTER_WRAPPER_H */
diff --git a/datapath/linux/compat/include/net/netfilter/nf_conntrack_core.h 
b/datapath/linux/compat/include/net/netfilter/nf_conntrack_core.h

[ovs-dev] [PATCH 6/7 v2] netfilter: Remove useless param helper of nf_ct_helper_ext_add

2019-05-10 Thread Yifeng Sun
From: Gao Feng 

Upstream commit:
commit 440534d3c56be04abfb26850ee882d19d223557a
Author: Gao Feng 
Date:   Mon Jul 9 18:06:33 2018 +0800

netfilter: Remove useless param helper of nf_ct_helper_ext_add

The param helper of nf_ct_helper_ext_add is useless now, then remove
it now.

Signed-off-by: Gao Feng 
Signed-off-by: Pablo Neira Ayuso 

This patch backports the above upstream patch to OVS.

Cc: Gao Feng 
Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
v1->v2: Rebase previous patch's changes.

 acinclude.m4   |  3 +++
 .../linux/compat/include/net/netfilter/nf_conntrack_helper.h   | 10 ++
 2 files changed, 13 insertions(+)

diff --git a/acinclude.m4 b/acinclude.m4
index 4f9aebc325ba..878c2f6d40f2 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -936,6 +936,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
 
[OVS_DEFINE([HAVE_NF_CONNTRACK_IN_TAKES_NF_HOOK_STATE])])
   OVS_GREP_IFELSE([$KSRC/include/net/ipv6_frag.h], [IP6_DEFRAG_CONNTRACK_IN],
   [OVS_DEFINE([HAVE_IPV6_FRAG_H])])
+  OVS_FIND_PARAM_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_helper.h],
+[nf_ct_helper_ext_add], [nf_conntrack_helper],
+[OVS_DEFINE([HAVE_NF_CT_HELPER_EXT_ADD_TAKES_HELPER])])
 
   if cmp -s datapath/linux/kcompat.h.new \
 datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h 
b/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h
index 19c35cd95f6f..b6a3d0bf75b3 100644
--- a/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h
+++ b/datapath/linux/compat/include/net/netfilter/nf_conntrack_helper.h
@@ -9,4 +9,14 @@ static inline void nf_conntrack_helper_put(struct 
nf_conntrack_helper *helper) {
 }
 #endif
 
+#ifndef HAVE_NF_CT_HELPER_EXT_ADD_TAKES_HELPER
+static inline struct nf_conn_help *
+rpl_nf_ct_helper_ext_add(struct nf_conn *ct,
+struct nf_conntrack_helper *helper, gfp_t gfp)
+{
+   return nf_ct_helper_ext_add(ct, gfp);
+}
+#define nf_ct_helper_ext_add rpl_nf_ct_helper_ext_add
+#endif /* HAVE_NF_CT_HELPER_EXT_ADD_TAKES_HELPER */
+
 #endif /* _NF_CONNTRACK_HELPER_WRAPPER_H */
-- 
2.7.4

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


[ovs-dev] [PATCH 3/7] datapath: Use new header file net/ipv6_frag.h

2019-05-10 Thread Yifeng Sun
From: Florian Westphal 

Upstream commit:
commit 70b095c84326640eeacfd69a411db8fc36e8ab1a
Author: Florian Westphal 
Date:   Sat Jul 14 01:14:01 2018 +0200

ipv6: remove dependency of nf_defrag_ipv6 on ipv6 module

IPV6=m
DEFRAG_IPV6=m
CONNTRACK=y yields:

net/netfilter/nf_conntrack_proto.o: In function `nf_ct_netns_do_get':
net/netfilter/nf_conntrack_proto.c:802: undefined reference to 
`nf_defrag_ipv6_enable'
net/netfilter/nf_conntrack_proto.o:(.rodata+0x640): undefined reference to 
`nf_conntrack_l4proto_icmpv6'

Setting DEFRAG_IPV6=y causes undefined references to ip6_rhash_params
ip6_frag_init and ip6_expire_frag_queue so it would be needed to force
IPV6=y too.

This patch gets rid of the 'followup linker error' by removing
the dependency of ipv6.ko symbols from netfilter ipv6 defrag.

Shared code is placed into a header, then used from both.

Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 

This patch backports the above upstream patch to OVS.

Cc: Florian Westphal 
Signed-off-by: Yifeng Sun 
Acked-by: Yi-Hung Wei 
---
 acinclude.m4  | 2 ++
 datapath/conntrack.c  | 1 +
 datapath/linux/Modules.mk | 1 +
 datapath/linux/compat/include/net/ipv6_frag.h | 8 
 4 files changed, 12 insertions(+)
 create mode 100644 datapath/linux/compat/include/net/ipv6_frag.h

diff --git a/acinclude.m4 b/acinclude.m4
index 372be5f4dccd..4f9aebc325ba 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -934,6 +934,8 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
   OVS_FIND_PARAM_IFELSE([$KSRC/include/net/netfilter/nf_conntrack_core.h],
 [nf_conntrack_in], [nf_hook_state],
 
[OVS_DEFINE([HAVE_NF_CONNTRACK_IN_TAKES_NF_HOOK_STATE])])
+  OVS_GREP_IFELSE([$KSRC/include/net/ipv6_frag.h], [IP6_DEFRAG_CONNTRACK_IN],
+  [OVS_DEFINE([HAVE_IPV6_FRAG_H])])
 
   if cmp -s datapath/linux/kcompat.h.new \
 datapath/linux/kcompat.h >/dev/null 2>&1; then
diff --git a/datapath/conntrack.c b/datapath/conntrack.c
index 8c1a80308d6a..52825a6b20fb 100644
--- a/datapath/conntrack.c
+++ b/datapath/conntrack.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_NF_NAT_NEEDED
 #include 
diff --git a/datapath/linux/Modules.mk b/datapath/linux/Modules.mk
index ae63e3653b41..cbb29f1c69d0 100644
--- a/datapath/linux/Modules.mk
+++ b/datapath/linux/Modules.mk
@@ -86,6 +86,7 @@ openvswitch_headers += \
linux/compat/include/net/ip6_route.h \
linux/compat/include/net/ip6_tunnel.h \
linux/compat/include/net/ipv6.h \
+   linux/compat/include/net/ipv6_frag.h \
linux/compat/include/net/mpls.h \
linux/compat/include/net/net_namespace.h \
linux/compat/include/net/netlink.h \
diff --git a/datapath/linux/compat/include/net/ipv6_frag.h 
b/datapath/linux/compat/include/net/ipv6_frag.h
new file mode 100644
index ..5d1cc901bec1
--- /dev/null
+++ b/datapath/linux/compat/include/net/ipv6_frag.h
@@ -0,0 +1,8 @@
+#ifndef __NET_IPV6_FRAG_WRAPPER_H
+#define __NET_IPV6_FRAG_WRAPPER_H
+
+#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV6) && defined(HAVE_IPV6_FRAG_H)
+#include_next 
+#endif
+
+#endif /* __NET_IPV6_FRAG_WRAPPER_H */
-- 
2.7.4

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


[ovs-dev] [PATCH 0/7 v2] datapath: Support 4.19.x and 4.20.x kernel

2019-05-10 Thread Yifeng Sun
This series of patches enabled OVS to support kernel 4.19.x and 4.20.x.

Tests shows that this series of patches passed check-kmod tests or
didn't introduce new failed check-kmod tests for the following
kernel versions:
3.10.0-957.12.1.el7.x86_64 (rhel)
4.4.0-31-generic (ubuntu 14.04)
4.4.0-146-generic (ubuntu 16.04)
4.4.179
4.9.171
4.14.111
4.15.0-48-generic (ubuntu 18.04)
4.17.19
4.18.0-18-generic (ubuntu 18.10)
4.19.37
4.20.17

Travis passed at:
https://travis-ci.org/yifsun/ovs-travis/builds/528006159

In addition, build is successful on:
CentOS73, Fedora, RHEL74, RHEL75, RHEL76 and Ubuntu (bionic, trusty,
xenial).

Yifeng Sun (7):
  datapath: Handle removal of nf_conntrack_l3proto.h
  datapath: Pass nf_hook_state to nf_conntrack_in()
  datapath: Use new header file net/ipv6_frag.h
  datapath: Fix conntrack_count related compilation errors
  openvswitch: use nf_ct_get_tuplepr, invert_tuplepr
  netfilter: Remove useless param helper of nf_ct_helper_ext_add
  datapath: Support kernel version 4.19.x and 4.20.x

Tested-by: Greg Rose 
Reviewed-by: Greg Rose 

v1->v2: Fixed by reviewers' comments.

 .travis.yml| 18 ---
 NEWS   |  2 ++
 acinclude.m4   | 17 --
 datapath/conntrack.c   | 26 +-
 datapath/linux/Modules.mk  |  2 ++
 datapath/linux/compat/include/linux/netfilter.h| 19 
 datapath/linux/compat/include/net/ipv6_frag.h  |  8 +++
 .../include/net/netfilter/nf_conntrack_core.h  |  9 
 .../include/net/netfilter/nf_conntrack_count.h |  4 ++--
 .../include/net/netfilter/nf_conntrack_helper.h| 10 +
 datapath/linux/compat/nf_conncount.c   |  6 -
 datapath/linux/compat/nf_conntrack_proto.c |  2 ++
 12 files changed, 94 insertions(+), 29 deletions(-)
 create mode 100644 datapath/linux/compat/include/linux/netfilter.h
 create mode 100644 datapath/linux/compat/include/net/ipv6_frag.h

-- 
2.7.4

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


Re: [ovs-dev] [PATCH 7/7] datapath: Support kernel version 4.19.x and 4.20.x

2019-05-10 Thread Yifeng Sun
Hi Ben,

All the patches in this series got acked. Do I need to send v2 for
those patches that were acked in v1?

Thanks,
Yifeng

On Wed, May 8, 2019 at 4:36 PM Yifeng Sun  wrote:
>
> Sure, I will submit new versions after testing is done.
> Thanks,
> Yifeng
>
> On Wed, May 8, 2019 at 4:05 PM Ben Pfaff  wrote:
> >
> > On Wed, May 08, 2019 at 02:27:57PM -0700, Yi-Hung Wei wrote:
> > > On Mon, May 6, 2019 at 3:01 PM Yifeng Sun  wrote:
> > > >
> > > > This patch updated acinclude.m4 so that OVS can be compiled on 4.19.x
> > > > and 4.20.x kernels.
> > > > This patch also updated travis files so that latest kernel versions
> > > > are used during travis test builds.
> > > >
> > > > Signed-off-by: Yifeng Sun 
> > > > ---
> > > Thanks for this patch. LGTM.
> > >
> > > Acked-by: Yi-Hung Wei 
> >
> > Thanks for the reviews.
> >
> > Yifeng, I will hope to see a v2 that includes the acks (and changes, if
> > any).
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 7/7] datapath: Support kernel version 4.19.x and 4.20.x

2019-05-10 Thread Ben Pfaff
Please do in this case.  It simplifies my workflow.

On Fri, May 10, 2019 at 11:28:16AM -0700, Yifeng Sun wrote:
> Hi Ben,
> 
> All the patches in this series got acked. Do I need to send v2 for
> those patches that were acked in v1?
> 
> Thanks,
> Yifeng
> 
> On Wed, May 8, 2019 at 4:36 PM Yifeng Sun  wrote:
> >
> > Sure, I will submit new versions after testing is done.
> > Thanks,
> > Yifeng
> >
> > On Wed, May 8, 2019 at 4:05 PM Ben Pfaff  wrote:
> > >
> > > On Wed, May 08, 2019 at 02:27:57PM -0700, Yi-Hung Wei wrote:
> > > > On Mon, May 6, 2019 at 3:01 PM Yifeng Sun  
> > > > wrote:
> > > > >
> > > > > This patch updated acinclude.m4 so that OVS can be compiled on 4.19.x
> > > > > and 4.20.x kernels.
> > > > > This patch also updated travis files so that latest kernel versions
> > > > > are used during travis test builds.
> > > > >
> > > > > Signed-off-by: Yifeng Sun 
> > > > > ---
> > > > Thanks for this patch. LGTM.
> > > >
> > > > Acked-by: Yi-Hung Wei 
> > >
> > > Thanks for the reviews.
> > >
> > > Yifeng, I will hope to see a v2 that includes the acks (and changes, if
> > > any).
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] rhel: update udev rules to allow vfio access

2019-05-10 Thread Aaron Conole
Aaron Conole  writes:

> Flavio Leitner  writes:
>
>> On Thu, Apr 18, 2019 at 01:46:22PM -0600, Alex Williamson wrote:
>>> On Thu, 18 Apr 2019 15:50:43 -0300
>>> Flavio Leitner  wrote:
>>> 
>>> > On Thu, Apr 18, 2019 at 12:06:57PM -0600, Alex Williamson wrote:
>>> > > On Thu, 18 Apr 2019 13:56:23 -0300
>>> > > Flavio Leitner  wrote:
>>> > >   
>>> > > > On Thu, Apr 18, 2019 at 10:43:11AM -0600, Alex Williamson wrote:  
>>> > > > > On Thu, 18 Apr 2019 13:23:54 -0300
>>> > > > > Flavio Leitner  wrote:
>>> > > > Another thing is that when the module is ready and the event is sent
>>> > > > out, what holds OVS for not trying to open and get EACCESS before
>>> > > > udev is triggered to fix the device permission?  
>>> > > 
>>> > > If there were a race, could ovs ever run before udev on system
>>> > > startup?  Probably not.  
>>> > 
>>> > It does wait, but only for the udev to settle, which means if the
>>> > module has not triggered an event until that time, OVS will not wait
>>> > and we still have a race.
>>> 
>>> But udev isn't waiting on the module to trigger an event, the module
>>> contains a MODULE_ALIAS, so I believe it's just the static processing
>>> of the modules.alias that triggers the event.
>>
>> What I am saying is that driverctl will trigger load the module and
>> bind the device, later on systemd will trigger OVS service which
>> waits udev to settle, but none of that guarantees that the permissions
>> are updated when OVS is initializing, see below.
>>
>>> > >  Ideally perhaps a cleaner solution might be an
>>> > > explicit dependency on the vfio module specific to ovs startup rather
>>> > > than changing a system policy, but it really depends on the context and
>>> > > use cases.  Thanks,  
>>> > 
>>> > It does have. The driverctl will bind the devices to vfio-pci but
>>> > the problem is that which signal we should rely on to know when
>>> > the vfio module is still initializing, or failed or finished.
>>> 
>>> What signal/mechanism is being used currently?  If driverctl is asked
>>> to set a driver override it does:
>>> 
>>>  1) if module is not loaded, modprobe
>>>  2) unbinds device from existing driver, if any
>>>  3) sets driver_override
>>>  4) triggers drivers_probe
>>>  5) tests if device is bound to a driver, any driver
>>> 
>>> There are certainly some deficiencies here, unbinding the device before
>>> setting the driver_override leaves the device open to getting bound by
>>> the wrong driver, and the verification in the last step could be more
>>> specific in testing for binding to the correct driver, but step #1 is
>>> the modprobe of the driver, which should be a synchronous operation.
>>> We shouldn't be able to complete a 'driverctl set-override $DEV
>>> vfio-pci' without vfio being initialized, afaict.  Thanks,
>>
>> Right, sounds like systemd is starting openvswitch service before
>> the driverctl is done with the devices.
>
> I'm not sure.  The ordering could be a problem.
>
> Perhaps we could try adding:
>
>   After=basic.target
>
> for the ovs-vswitchd.service if we have a machine that exhibits this
> behavior, but I don't know if it will resolve the race.  There is some
> kind of strange ordering looking at:
>
> https://www.freedesktop.org/software/systemd/man/systemd.special.html
> and
> https://www.freedesktop.org/software/systemd/man/bootup.html#
>
> I can't find how network.target dependency really works w.r.t. ordering
> and the driverctl+basic.target services.

Ping?  Any thoughts?  Do you have an alternative approach you'd rather
see?  I can try asking the customer if they can test out the
After=basic.target change I propose, but I'm not positive it will
resolve anything.  And if it doesn't, I want to be able to say "well,
here's a follow up."

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


Re: [ovs-dev] [PATCH 6/7 v2] netfilter: Remove useless param helper of nf_ct_helper_ext_add

2019-05-10 Thread Yi-Hung Wei
On Thu, May 9, 2019 at 10:56 AM Yifeng Sun  wrote:
>
> From: Gao Feng 
>
> Upstream commit:
> commit 440534d3c56be04abfb26850ee882d19d223557a
> Author: Gao Feng 
> Date:   Mon Jul 9 18:06:33 2018 +0800
>
> netfilter: Remove useless param helper of nf_ct_helper_ext_add
>
> The param helper of nf_ct_helper_ext_add is useless now, then remove
> it now.
>
> Signed-off-by: Gao Feng 
> Signed-off-by: Pablo Neira Ayuso 
>
> This patch backports the above upstream patch to OVS.
>
> Cc: Gao Feng 
> Signed-off-by: Yifeng Sun 
> ---
Acked-by: Yi-Hung Wei 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 5/7 v2] openvswitch: use nf_ct_get_tuplepr, invert_tuplepr

2019-05-10 Thread Yi-Hung Wei
On Thu, May 9, 2019 at 10:55 AM Yifeng Sun  wrote:
>
> From: Florian Westphal 
>
> Upstream commit:
> commit 60e3be94e6a1c5162a0763c9aafb5190b2b1fdce
> Author: Florian Westphal 
> Date:   Mon Jun 25 17:55:32 2018 +0200
>
> openvswitch: use nf_ct_get_tuplepr, invert_tuplepr
>
> These versions deal with the l3proto/l4proto details internally.
> It removes only caller of nf_ct_get_tuple, so make it static.
>
> After this, l3proto->get_l4proto() can be removed in a followup patch.
>
> Signed-off-by: Florian Westphal 
> Acked-by: Pravin B Shelar 
> Signed-off-by: Pablo Neira Ayuso 
>
> This patch backports the above upstream kernel patch to OVS.
>
> Cc: Florian Westphal 
> Signed-off-by: Yifeng Sun 
> ---
Acked-by: Yi-Hung Wei 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 3/7 v2] datapath: Use new header file net/ipv6_frag.h

2019-05-10 Thread Yi-Hung Wei
On Wed, May 8, 2019 at 5:00 PM Yifeng Sun  wrote:
>
> From: Florian Westphal 
>
> Upstream commit:
> commit 70b095c84326640eeacfd69a411db8fc36e8ab1a
> Author: Florian Westphal 
> Date:   Sat Jul 14 01:14:01 2018 +0200
>
> ipv6: remove dependency of nf_defrag_ipv6 on ipv6 module
>
> IPV6=m
> DEFRAG_IPV6=m
> CONNTRACK=y yields:
>
> net/netfilter/nf_conntrack_proto.o: In function `nf_ct_netns_do_get':
> net/netfilter/nf_conntrack_proto.c:802: undefined reference to 
> `nf_defrag_ipv6_enable'
> net/netfilter/nf_conntrack_proto.o:(.rodata+0x640): undefined reference 
> to `nf_conntrack_l4proto_icmpv6'
>
> Setting DEFRAG_IPV6=y causes undefined references to ip6_rhash_params
> ip6_frag_init and ip6_expire_frag_queue so it would be needed to force
> IPV6=y too.
>
> This patch gets rid of the 'followup linker error' by removing
> the dependency of ipv6.ko symbols from netfilter ipv6 defrag.
>
> Shared code is placed into a header, then used from both.
>
> Signed-off-by: Florian Westphal 
> Signed-off-by: Pablo Neira Ayuso 
>
> This patch backports the above upstream patch to OVS.
>
> Cc: Florian Westphal 
> Signed-off-by: Yifeng Sun 
> ---
LGTM.
Acked-by: Yi-Hung Wei 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 2/7 v2] datapath: Pass nf_hook_state to nf_conntrack_in()

2019-05-10 Thread Yi-Hung Wei
On Wed, May 8, 2019 at 4:59 PM Yifeng Sun  wrote:
>
> From: Florian Westphal 
>
> Upstream Commit:
> commit 93e66024b0249cec81e91328c55a754efd3192e0
> Author: Florian Westphal 
> Date:   Wed Sep 12 15:19:07 2018 +0200
>
> netfilter: conntrack: pass nf_hook_state to packet and error handlers
>
> nf_hook_state contains all the hook meta-information: netns, protocol 
> family,
> hook location, and so on.
>
> Instead of only passing selected information, pass a pointer to entire
> structure.
>
> This will allow to merge the error and the packet handlers and remove
> the ->new() function in followup patches.
>
> Signed-off-by: Florian Westphal 
> Signed-off-by: Pablo Neira Ayuso 
>
> This patch backports the above upstream patch to OVS and fixes compiling
> errors on RHEL kernels.
>
> Cc: Florian Westphal 
> Signed-off-by: Yifeng Sun 
> ---
Thanks for the update.

Acked-by: Yi-Hung Wei 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH 1/2] fedora: Ability to auto enable openvswitch service.

2019-05-10 Thread Guru Shetty
>
>
> Hi,
> usually a package on Fedora/RHEL7+ is never enabled by default, unless
> it's necessary to enable it for a really good reason.
>

I would like to put an argument on why this a good reason in this case.

When I did a grep on 2 large repositories at VMware that use openvswitch
RPMs, there is a lot of test and dev code and places where there is an
assumption made that the openvswitch rpms enable services after
installation (which has been the case so far with rhel/openvswitch.spec)
and there is a history of 10 years there. So as a large user of openvswitch
RPMs, I should not have to go and change every bit of code that uses
openvswitch rpms to change the previous behavior.

And the code changes here does not get activated by default. Just provides
an option for openvswitch users to enable the service automatically if they
so desire.



>
> So any Fedora/RHEL7+ user knows (and expect) that he need to manually
> enable/start a service after it's installed.
>

> Probably it's better to put something like (postun?):
>
> if /sbin/chkconfig --level 3 openvswitch; then
>
> /bin/systemctl enable openvswitch.service >/dev/null 2>&1 || :
> /bin/systemctl restart openvswitch.service >/dev/null 2>&1 || :
> fi
>

I would like to have the ability to auto enable service even when it is a
new installation.

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


Re: [ovs-dev] [PATCH 1/2] fedora: Ability to auto enable openvswitch service.

2019-05-10 Thread Timothy Redaelli
On Fri,  3 May 2019 00:05:34 -0700
Gurucharan Shetty  wrote:

> We currently have rhel/openvswitch.spec.in that automatically
> enables openvswitch service when the package is installed using
> chkconfig.
> 
> But fedora rpm may not enable openvswitch service automatically.
> The macro currently being used in fedora rpm (systemd_post) will
> look for preset files in /etc/systemd/system-preset/ to figure
> out whether openvswitch service needs to be automatically enabled.
> But, the fedora package does not provide such a file. The argument
> is that people may want to install the package for binaries and
> not necessarily to run OVS.
> 
> If someone now wants to install the fedora package and automatically
> enable openvswitch, he will have to create a new package that OVS
> package depends on to install the preset file. This is unwieldy.
> 
> This commit, provides a rpm build time option to enable the openvswitch
> service automatically. If you now run the below command, openvswitch
> service will be automatically enabled during package installation.
> 
> make rpm-fedora RPMBUILD_OPT="--with autoenable"
> 
> Signed-off-by: Gurucharan Shetty 
> ---
>  rhel/openvswitch-fedora.spec.in | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in
> index ce728b4..e8165f9 100644
> --- a/rhel/openvswitch-fedora.spec.in
> +++ b/rhel/openvswitch-fedora.spec.in
> @@ -32,6 +32,9 @@
>  # This is enabled by default for versions of the distribution that
>  # have Python 3 by default (Fedora > 22).
>  %bcond_with build_python3
> +# If there is a need to automatically enable the package after installation,
> +# specify the "--with autoenable"
> +%bcond_with autoenable
>  
>  # Enable PIE, bz#955181
>  %global _hardened_build 1
> @@ -382,6 +385,7 @@ fi
>  %endif
>  
>  %if 0%{?systemd_post:1}
> +# This may not enable openvswitch service or do daemon-reload.
>  %systemd_post %{name}.service
>  %else
>  # Package install, not upgrade
> @@ -390,6 +394,11 @@ fi
>  fi
>  %endif
>  
> +%if %{with autoenable}
> +systemctl daemon-reload
> +systemctl enable openvswitch
> +%endif
> +
>  %post selinux-policy
>  %selinux_modules_install -s targeted 
> %{_datadir}/selinux/packages/%{name}/openvswitch-custom.pp
>  

Hi,
usually a package on Fedora/RHEL7+ is never enabled by default, unless
it's necessary to enable it for a really good reason.

So any Fedora/RHEL7+ user knows (and expect) that he need to manually
enable/start a service after it's installed.

Probably it's better to put something like (postun?):

if /sbin/chkconfig --level 3 openvswitch; then  
   
/bin/systemctl enable openvswitch.service >/dev/null 2>&1 || :
/bin/systemctl restart openvswitch.service >/dev/null 2>&1 || :
fi

Just to enable it if it was enabled before on sysv?

I didn't tested it, but usually (on Fedora spec files) it's the correct
way to do that.

Thank you

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


[ovs-dev] Sélectionnez les offres selon votre profil

2019-05-10 Thread Déposez votre CV
diffusion

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


Re: [ovs-dev] [PATCH v2] ovs-actions.xml: Better document the "bundle" and "bundle_load" actions.

2019-05-10 Thread Ben Pfaff
On Fri, May 10, 2019 at 02:37:33PM +0530, Numan Siddique wrote:
> On Thu, May 2, 2019 at 11:28 PM Ben Pfaff  wrote:
> 
> > Signed-off-by: Ben Pfaff 
> >
> 
> Acked-by: Numan Siddique 

Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] ovs-vswitchd: Update limits section in manpage.

2019-05-10 Thread Ben Pfaff
On Fri, May 10, 2019 at 02:33:29PM +0530, Numan Siddique wrote:
> On Wed, May 1, 2019 at 5:23 AM Ben Pfaff  wrote:
> 
> > Reported-by: William Konitzer 
> > Signed-off-by: Ben Pfaff 
> >
> 
> Acked-by: Numan Siddique 

Thanks, applied to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCHv2] odp-util: extend usage of limit for parse functions

2019-05-10 Thread Ben Pfaff
Not a big deal.

On Fri, May 10, 2019 at 05:57:01AM -0700, Cpp Code wrote:
> Ok, missed that
> 
> On Thu, May 9, 2019 at 1:59 PM Ben Pfaff  wrote:
> 
> > On Thu, May 09, 2019 at 06:29:59AM -0700, Toms Atteka wrote:
> > > This fixes stack overflow issues for odp_actions_from_string.
> > > Added wrapper functions for recursion limitation.
> > >
> > > Basic manual testing was performed.
> > >
> > > Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13808
> > > Signed-off-by: Toms Atteka 
> >
> > Thanks, applied to master.
> >
> > > v1->v2: added wrapper functions
> >
> > Please put this part after --- to keep it from becoming part of the
> > final commit message.  (There are at least two ways to do that: you can
> > put a --- line in your commit message, or if you add it from the editor
> > in "git send-email --annotate", you can just add it after the existing
> > --- line.)
> >
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCHv2] odp-util: extend usage of limit for parse functions

2019-05-10 Thread Cpp Code
Ok, missed that

On Thu, May 9, 2019 at 1:59 PM Ben Pfaff  wrote:

> On Thu, May 09, 2019 at 06:29:59AM -0700, Toms Atteka wrote:
> > This fixes stack overflow issues for odp_actions_from_string.
> > Added wrapper functions for recursion limitation.
> >
> > Basic manual testing was performed.
> >
> > Reported-at: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=13808
> > Signed-off-by: Toms Atteka 
>
> Thanks, applied to master.
>
> > v1->v2: added wrapper functions
>
> Please put this part after --- to keep it from becoming part of the
> final commit message.  (There are at least two ways to do that: you can
> put a --- line in your commit message, or if you add it from the editor
> in "git send-email --annotate", you can just add it after the existing
> --- line.)
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v7 2/2] OVN: Enable N-S Traffic, Vlan backed DVR

2019-05-10 Thread Numan Siddique
On Thu, May 9, 2019 at 4:29 AM Ankur Sharma 
wrote:

> Background:
> [1]
> https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
> [2]
> https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
>
> This Series:
> Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
> backed distributed logical router.
>
> This patch:
> For North-South traffic, we need a chassis which will respond to
> ARP requests for router port coming from outside. For this purpose,
> we will reply upon gateway-chassis construct in OVN, on a logical
> router port, we will associate one or more chassis as gateway chassis.
>
> One of these chassis would be active at a point and will become
> entry point to traffic, bound for end points behind logical router
> coming from outside network (North to South).
>
> This patch make some enhancements to gateway chassis implementation
> to manage above used case.
>
> A.
> Do not replace router port mac with chassis mac on gateway
> chassis.
> This is done, because:
> i. Chassisredirect port is NOT a distributed port, hence
>we need not replace its mac address
>   (which same as router port mac).
>
>ii. ARP cache will be consistent everywhere, i.e just like
>endpoints on OVN chassis will see configured router port
>mac as resolved mac for router port ip, outside endpoints
>will see that as well.
>
>   iii. For implementing Network Address Translation. Although
>not a part of this series. But, follow up series would
>be having this feature and approach would rely upon
>sending packets to redirect chassis using chassis redirect
>router port mac as dest mac.
>
> B.
> Advertise router port GARP on gateway chassis.
> This is needed, especially if a failover happens and
> chassisredirect port moves to a new gateway chassis.
> Otherwise, there would be packet drops till outside
> router ARPs for router port ip again.
>
> Intention of this GARP is to update top of the rack (TOR)
> to direct router port mac to new hypervisor.
>
> Hence, we could have done the same using RARP as well, but
> because ovn-controller has implementation for GARP already,
> hence it did not look like worthy to add a RARP implementation
> just for this.
>
> C.
> For South to North traffic, we need not pass through gateway
> chassis, if there is no address transalation needed.
>
> For overlay networks, NATing is a must to talk to outside networks.
> However, for vlan backed networks, NATing is not a must, and hence
> in the absence of NATing configuration we need redirect the packet
> to gateway chassis.
>
> Signed-off-by: Ankur Sharma 
> ---
>


Hi Ankur,

I am little confused with the approach taken here. I ran the tests added in
this patch.
I see below logical flows in the router pipeline

***
 table=1 (lr_in_ip_input ), priority=90   , match=(inport ==
"router-to-ls1" && arp.spa == 192.168.1.0/24 && arp.tpa == 192.168.1.3 &&
arp.op == 1), action=(put_arp(inport, arp.spa, arp.sha); eth.dst = eth.src;
eth.src = 00:00:01:01:02:03; arp.op = 2; /* ARP reply */ arp.tha = arp.sha;
arp.sha = 00:00:01:01:02:03; arp.tpa = arp.spa; arp.spa = 192.168.1.3;
outport = "router-to-ls1"; flags.loopback = 1; output;)
  table=1 (lr_in_ip_input ), priority=90   , match=(inport ==
"router-to-ls1" && nd_ns && ip6.dst == {fe80::200:1ff:fe01:203,
ff02::1:ff01:203} && nd.target == fe80::200:1ff:fe01:203 &&
is_chassis_resident("cr-router-to-ls1")), action=(put_nd(inport, ip6.src,
nd.sll); nd_na_router { eth.src = 00:00:01:01:02:03; ip6.src =
fe80::200:1ff:fe01:203; nd.target = fe80::200:1ff:fe01:203; nd.tll =
00:00:01:01:02:03; outport = inport; flags.loopback = 1; output; };)
  table=1 (lr_in_ip_input ), priority=90   , match=(inport ==
"router-to-ls2" && arp.spa == 192.168.2.0/24 && arp.tpa == 192.168.2.3 &&
arp.op == 1), action=(put_arp(inport, arp.spa, arp.sha); eth.dst = eth.src;
eth.src = 00:00:01:01:02:05; arp.op = 2; /* ARP reply */ arp.tha = arp.sha;
arp.sha = 00:00:01:01:02:05; arp.tpa = arp.spa; arp.spa = 192.168.2.3;
outport = "router-to-ls2"; flags.loopback = 1; output;)
  table=1 (lr_in_ip_input ), priority=90   , match=(inport ==
"router-to-ls2" && nd_ns && ip6.dst == {fe80::200:1ff:fe01:205,
ff02::1:ff01:205} && nd.target == fe80::200:1ff:fe01:205 &&
is_chassis_resident("cr-router-to-ls2")), action=(put_nd(inport, ip6.src,
nd.sll); nd_na_router { eth.src = 00:00:01:01:02:05; ip6.src =
fe80::200:1ff:fe01:205; nd.target = fe80::200:1ff:fe01:205; nd.tll =
00:00:01:01:02:05; outport = inport; flags.loopback = 1; output; };)



But if I inspect the port_binding rows in the Southbound DB I don't see
"cr-router-to-ls1" and "cr-router-to-ls2".
I don't understand what's the purpose of these logical flows.

>From the patch I understand that you are trying to reply for the ARP
requests to the logical router ports on the gateway-chassis (where chassis
redirect port of the distributed
router 

Re: [ovs-dev] [PATCH v7 1/2] OVN: Enable E-W Traffic, Vlan backed DVR

2019-05-10 Thread Numan Siddique
On Thu, May 9, 2019 at 4:28 AM Ankur Sharma 
wrote:

> Background:
> [1]
> https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
> [2]
> https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
>
> This Series:
> Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
> backed distributed logical router.
>
> This patch:
>
> A.
> Key difference between an overlay logical switch and
> vlan backed logical switch is that for vlan logical switches
> packets are not encapsulated.
>
> Hence, if a distributed router port is connected to vlan type
> logical switch, then router port mac as source mac could be
> seen from multiple hypervisors. Same  pairs coming
> from multiple ports from a top of the rack switch (TOR) perspective
> could be seen as a security threat and it could send alarms, drop
> the packets or block the ports etc.
>
> This patch addresses the same by introducing the concept of chassis mac.
> A chassis mac is CMS provisioned unique mac per chassis. For any routed
> packet
> (i.e source mac is router port mac) going on the wire on a vlan type
> logical switch, we will replace its source mac with chassis mac.
>
> This replacing of source mac with chassis mac will happen in table=65
> of the logical switch datapath. A flow is added at priority 150, which
> matches the source mac and replaces it with chassis mac if the value
> is a router port mac.
>
> Example flow:
> cookie=0x0, duration=67765.830s, table=65, n_packets=0, n_bytes=0,
> idle_age=65534, hard_age=65534, priority=150,reg15=0x1,metadata=0x4,
> dl_src=00:00:01:01:02:03 actions=mod_dl_src:aa:bb:cc:dd:ee:ff,
> mod_vlan_vid:1000,output:16
>
> Here, 00:00:01:01:02:03 is router port mac and aa:bb:cc:dd:ee:ff
> is chassis mac.
>
> B.
> This patch adds one more change of associating "types" with logical
> switches. i.e a logical switch could be of type "overlay" or "bridged".
> This is done to explicitly call out that on a bridged logical
> switch there will no encapsulation.
> Just a localnet port's presence is not sufficient, as we do
> encap while redirecting the packet to gateway chassis.
> By marking the logical switch as bridged, we can either
> avoid redirection totally (if there is no NAT) or do redirection
> based on router port mac, rather than encap over a tunnel.
>
>
Hi Ankur,

For most part the patch looks fine to me. Please see some additional
comments.

I still have few questions about the type added to the logical switch. How
would you handle
the case for upgrades ? i.e if the deployment already have a logical switch
with a localnet port.

What if the user sets the type as - bridged, but doesn't create the
localnet port ?

Thanks
Numan



> Signed-off-by: Ankur Sharma 
> ---
>  ovn/controller/binding.c|  12 +--
>  ovn/controller/chassis.c|  64 +++-
>  ovn/controller/chassis.h|   4 +
>  ovn/controller/ovn-controller.8.xml |  10 ++
>  ovn/controller/ovn-controller.c |   2 +-
>  ovn/controller/ovn-controller.h |   5 +-
>  ovn/controller/physical.c   |  96 ++
>  ovn/northd/ovn-northd.c |  38 +++
>  ovn/ovn-architecture.7.xml  |  24 +
>  ovn/ovn-nb.ovsschema|  10 +-
>  ovn/ovn-nb.xml  |  18 
>  ovn/ovn-sb.xml  |  15 +++
>  ovn/utilities/ovn-nbctl.c   |  49 +++--
>  tests/ovn-nbctl.at  |  48 ++---
>  tests/ovn-northd.at |  22 
>  tests/ovn.at| 197
> 
>  16 files changed, 582 insertions(+), 32 deletions(-)
>
> diff --git a/ovn/controller/binding.c b/ovn/controller/binding.c
> index 404f0e7..e9461ef 100644
> --- a/ovn/controller/binding.c
> +++ b/ovn/controller/binding.c
> @@ -159,13 +159,11 @@ add_local_datapath__(struct ovsdb_idl_index
> *sbrec_datapath_binding_by_key,
>   sbrec_port_binding_by_name,
>   peer->datapath, false,
>   depth + 1, local_datapaths);
> -ld->n_peer_dps++;
> -ld->peer_dps = xrealloc(
> -ld->peer_dps,
> -ld->n_peer_dps * sizeof *ld->peer_dps);
> -ld->peer_dps[ld->n_peer_dps - 1] =
> datapath_lookup_by_key(
> -sbrec_datapath_binding_by_key,
> -peer->datapath->tunnel_key);
> +ld->n_peer_ports++;
> +ld->peer_ports = xrealloc(ld->peer_ports,
> +  ld->n_peer_ports *
> +  sizeof *ld->peer_ports);
> +ld->peer_ports[ld->n_peer_ports - 1] = peer;
>  }
>  }
>  }
> diff --git a/ovn/controller/chassis.c b/ovn/controller/chassis.c
> index 

Re: [ovs-dev] [PATCH] ovs-vswitchd: Update limits section in manpage.

2019-05-10 Thread Numan Siddique
On Wed, May 1, 2019 at 5:23 AM Ben Pfaff  wrote:

> Reported-by: William Konitzer 
> Signed-off-by: Ben Pfaff 
>

Acked-by: Numan Siddique 


> ---
>  vswitchd/ovs-vswitchd.8.in | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/vswitchd/ovs-vswitchd.8.in b/vswitchd/ovs-vswitchd.8.in
> index 901f75e6f300..fcf22244a60f 100644
> --- a/vswitchd/ovs-vswitchd.8.in
> +++ b/vswitchd/ovs-vswitchd.8.in
> @@ -319,13 +319,12 @@ limits assume the use of the Linux kernel datapath.
>  \fBovs\-vswitchd\fR started through \fBovs\-ctl\fR(8) provides a limit of
> 65535
>  file descriptors.  The limits on the number of bridges and ports is
> decided by
>  the availability of file descriptors.  With the Linux kernel datapath,
> creation
> -of a single bridge consumes three file descriptors and adding a port
> consumes
> -"n-handler-threads" file descriptors per bridge port.  Performance will
> degrade
> -beyond 1,024 ports per bridge due to fixed hash table sizing.  Other
> platforms
> +of a single bridge consumes three file descriptors and each port
> +consumes one additional file descriptor.  Other platforms
>  may have different limitations.
>  .
>  .IP \(bu
> -2,048 MAC learning entries per bridge, by default.  (This is
> +8,192 MAC learning entries per bridge, by default.  (This is
>  configurable via \fBother\-config:mac\-table\-size\fR in the
>  \fBBridge\fR table.  See \fBovs\-vswitchd.conf.db\fR(5) for details.)
>  .
> @@ -351,7 +350,10 @@ time linear in the number of flows.
>  32 mirrors per bridge.
>  .
>  .IP \(bu
> -15 bytes for the name of a port.  (This is a Linux kernel limitation.)
> +15 bytes for the name of a port, for ports implemented in the Linux
> +kernel.  Ports implemented in userspace, such as patch ports, do not
> +have an arbitrary length limitation.  OpenFlow also limit port names
> +to 15 bytes.
>  .
>  .SH "SEE ALSO"
>  .BR ovs\-appctl (8),
> --
> 2.20.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 v2] ovs-actions.xml: Better document the "bundle" and "bundle_load" actions.

2019-05-10 Thread Numan Siddique
On Thu, May 2, 2019 at 11:28 PM Ben Pfaff  wrote:

> Signed-off-by: Ben Pfaff 
>

Acked-by: Numan Siddique 



> ---
> v1->v2: Add paragraph about liveness.
>
>  lib/ovs-actions.xml | 53 +
>  1 file changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/lib/ovs-actions.xml b/lib/ovs-actions.xml
> index cfd9b81be604..76aa5afb4d06 100644
> --- a/lib/ovs-actions.xml
> +++ b/lib/ovs-actions.xml
> @@ -789,15 +789,15 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0
> actions=mod_nw_src:1.2.3.4
>
>  
>The bundle and bundle_load
> actions
> -  bundle(fields,
> basis, algorithm,
> ofport, slaves:port...)
> -  bundle_load(fields,
> basis, algorithm,
> ofport, dst,
> slaves:port...)
> +  bundle(fields,
> basis, algorithm, ofport,
> slaves:port...)
> +  bundle_load(fields,
> basis, algorithm, ofport,
> dst,
> slaves:port...)
>
>
>  These actions choose a port (``slave'') from a comma-separated
> OpenFlow
>  port list.  After selecting the port,
> bundle
>  outputs to it, whereas bundle_load writes its port
> number
> -to dst, which must be a field or subfield in the syntax
> -described under ``Field Specifications'' above.
> +to dst, which must be a 16-bit or wider field or
> subfield in
> +the syntax described under ``Field Specifications'' above.
>
>
>
> @@ -847,6 +847,51 @@ $ ovs-ofctl -O OpenFlow10 add-flow br0
> actions=mod_nw_src:1.2.3.4
>  
>
>
> +  
> +algorithm must be one of the following:
> +  
> +
> +  
> +active_backup
> +
> +  Chooses the first live port listed in slaves.
> +
> +
> +hrw (Highest Random Weight)
> +
> +  
> +Computes the following, considering only the live ports in
> +slaves:
> +  
> +
> +  
> +for i in [1,n_slaves]:
> +weights[i] = hash(flow, i)
> +slave = { i such that
> weights[i] = weights[j] for
> all j != i }
> +  
> +
> +  
> +This algorithm is specified by RFC 2992.
> +  
> +
> +  
> +
> +  
> +The algorithms take port liveness into account when selecting
> slaves.
> +The definition of whether a port is live is subject to change.  It
> +currently takes into account carrier status and link monitoring
> +protocols such as BFD and CFM.  If none of the slaves is live,
> +bundle does not output the packet and
> +bundle_load stores OFPP_NONE (65535) in
> the
> +output field.
> +  
> +
> +  
> +Example: bundle(eth_src,0,hrw,ofport,slaves:4,8)
> uses an
> +Ethernet source hash with basis 0, to select between OpenFlow
> ports 4
> +and 8 using the Highest Random Weight algorithm.
> +  
> +
>
>  Open vSwitch 1.2 introduced the bundle and
>  bundle_load OpenFlow extension actions.
> --
> 2.20.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] ovn: Properly set the index for chassis lookup

2019-05-10 Thread Numan Siddique
On Thu, May 9, 2019 at 1:40 PM Dumitru Ceara  wrote:

> The chassis_lookup_by_name function now calls
> sbrec_chassis_index_set_name instead of sbrec_chassis_set_name. Due to
> the use of the wrong API memory was leaked every time a chassis was
> looked up by name. This was mostly visible when chassis lookups had to
> be done continuously (e.g., when two chassis were misconfigured
> with the same system-id).
>
> Reported-at: https://bugzilla.redhat.com/1698462
> Reported-by: Alexander 
> Signed-off-by: Dumitru Ceara 
> ---
>

Acked-by: Numan Siddique 


>  ovn/lib/chassis-index.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/ovn/lib/chassis-index.c b/ovn/lib/chassis-index.c
> index 34d4a31..423 100644
> --- a/ovn/lib/chassis-index.c
> +++ b/ovn/lib/chassis-index.c
> @@ -30,7 +30,7 @@ chassis_lookup_by_name(struct ovsdb_idl_index
> *sbrec_chassis_by_name,
>  {
>  struct sbrec_chassis *target = sbrec_chassis_index_init_row(
>  sbrec_chassis_by_name);
> -sbrec_chassis_set_name(target, name);
> +sbrec_chassis_index_set_name(target, name);
>
>  struct sbrec_chassis *retval = sbrec_chassis_index_find(
>  sbrec_chassis_by_name, target);
> --
> 1.8.3.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