[ovs-dev] DRINGENDE SPENDE

2019-11-01 Thread Marie Holmes Charity 
Sie wurden nach dem Zufallsprinzip ausgewählt, um eine Spende von Marie Holmes 
Charity zu erhalten. Kontaktieren Sie sie für weitere Informationen: E-Mail 
marieholmescharity...@gmail.com 

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 0/2] travis: Unskip tests.

2019-11-01 Thread Ilya Maximets 

On 01.11.2019 23:42, Ben Pfaff wrote:

On Fri, Nov 01, 2019 at 11:38:33PM +0100, Ilya Maximets wrote:

Ilya Maximets (2):
   travis: Workaround skipping of IPv6 tests.
   travis: Fix skipping of python SSL tests.


Nice!

Acked-by: Ben Pfaff 


Thanks! Applied to master.

Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next v6 01/10] net: openvswitch: add flow-mask cache for performance

2019-11-01 Thread William Tu 
On Fri, Nov 1, 2019 at 7:25 AM  wrote:
>
> From: Tonghao Zhang 
>
> The idea of this optimization comes from a patch which
> is committed in 2014, openvswitch community. The author
> is Pravin B Shelar. In order to get high performance, I
> implement it again. Later patches will use it.
>
> Pravin B Shelar, says:
> | On every packet OVS needs to lookup flow-table with every
> | mask until it finds a match. The packet flow-key is first
> | masked with mask in the list and then the masked key is
> | looked up in flow-table. Therefore number of masks can
> | affect packet processing performance.
>
> Link: 
> https://github.com/openvswitch/ovs/commit/5604935e4e1cbc16611d2d97f50b717aa31e8ec5
> Signed-off-by: Tonghao Zhang 
> Tested-by: Greg Rose 
> Acked-by: William Tu 
> ---

Do you consider change author of this patch to Pravin?

Regards,
William


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

[ovs-dev] [PATCHv2] tests: Skip tests using tcp nc under check-afxdp.

2019-11-01 Thread William Tu 
AF_XDP veth does not support TCP with namespaces.
This patch skips two cases that use it.
  118: conntrack - floating IP
  119: conntrack - negative test for recirculation optimization

Signed-off-by: William Tu 
---
v2:
  - skip only 118 and 119.
v1:
  - Tested-at: https://travis-ci.org/williamtu/ovs-travis/builds/606194550
  - make check-afxdp all pass on my machine, but cirrus, it is still unstable,
observe 1 failed at:
https://cirrus-ci.com/task/6597038589870080
---
 tests/system-afxdp-macros.at | 6 ++
 tests/system-kmod-macros.at  | 6 ++
 tests/system-traffic.at  | 2 ++
 tests/system-userspace-macros.at | 6 ++
 4 files changed, 20 insertions(+)

diff --git a/tests/system-afxdp-macros.at b/tests/system-afxdp-macros.at
index f0683c0a901b..3392c7e5ada3 100644
--- a/tests/system-afxdp-macros.at
+++ b/tests/system-afxdp-macros.at
@@ -37,3 +37,9 @@ m4_define([CONFIGURE_VETH_OFFLOADS],
 #
 m4_define([OVS_START_L7],
[AT_SKIP_IF([:])])
+
+# OVS_SKIP_AFXDP()
+#
+# Skip when check-afxdp.
+m4_define([OVS_SKIP_AFXDP],
+[AT_SKIP_IF([:])])
diff --git a/tests/system-kmod-macros.at b/tests/system-kmod-macros.at
index 9e89aec43734..cfcd63ab0bab 100644
--- a/tests/system-kmod-macros.at
+++ b/tests/system-kmod-macros.at
@@ -211,3 +211,9 @@ m4_define([VSCTL_ADD_DATAPATH_TABLE],
 # or necessary for the userspace datapath as it is checking for a kernel
 # specific regression.
 m4_define([CHECK_L3L4_CONNTRACK_REASM])
+
+# OVS_SKIP_AFXDP()
+#
+# Skip when check-afxdp.
+m4_define([OVS_SKIP_AFXDP],
+[AT_SKIP_IF([false])])
diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index 870a05efe04c..32af74c9953b 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -5660,6 +5660,7 @@ AT_CLEANUP
 
 AT_SETUP([conntrack - floating IP])
 AT_SKIP_IF([test $HAVE_NC = no])
+OVS_SKIP_AFXDP()
 CHECK_CONNTRACK()
 OVS_TRAFFIC_VSWITCHD_START()
 OVS_CHECK_CT_CLEAR()
@@ -5735,6 +5736,7 @@ AT_SETUP([conntrack - negative test for recirculation 
optimization])
 dnl This test will fail if 'conn' caching is being used, because the tuple
 dnl has been changed outside of conntrack.
 AT_SKIP_IF([test $HAVE_NC = no])
+OVS_SKIP_AFXDP()
 CHECK_CONNTRACK()
 OVS_TRAFFIC_VSWITCHD_START()
 OVS_CHECK_CT_CLEAR()
diff --git a/tests/system-userspace-macros.at b/tests/system-userspace-macros.at
index a419f30c1563..6cf2d70ea046 100644
--- a/tests/system-userspace-macros.at
+++ b/tests/system-userspace-macros.at
@@ -323,3 +323,9 @@ m4_define([CHECK_L3L4_CONNTRACK_REASM],
 [
 AT_SKIP_IF([:])
 ])
+
+# OVS_SKIP_AFXDP()
+#
+# Skip when check-afxdp.
+m4_define([OVS_SKIP_AFXDP],
+[AT_SKIP_IF([false])])
-- 
2.7.4

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

Re: [ovs-dev] [PATCH 0/2] travis: Unskip tests.

2019-11-01 Thread Ben Pfaff 
On Fri, Nov 01, 2019 at 11:38:33PM +0100, Ilya Maximets wrote:
> Ilya Maximets (2):
>   travis: Workaround skipping of IPv6 tests.
>   travis: Fix skipping of python SSL tests.

Nice!

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

[ovs-dev] [PATCH 2/2] travis: Fix skipping of python SSL tests.

2019-11-01 Thread Ilya Maximets 
After this change we'll have only one windows related skipped test
in default build.

Signed-off-by: Ilya Maximets 
---
 .travis.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.travis.yml b/.travis.yml
index 84bdb4ba4..482efd2d1 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -21,6 +21,7 @@ addons:
   - libjemalloc-dev
   - libnuma-dev
   - libpcap-dev
+  - python3-openssl
   - python3-sphinx
   - libelf-dev
   - selinux-policy-dev
-- 
2.17.1

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

[ovs-dev] [PATCH 0/2] travis: Unskip tests.

2019-11-01 Thread Ilya Maximets 
Ilya Maximets (2):
  travis: Workaround skipping of IPv6 tests.
  travis: Fix skipping of python SSL tests.

 .travis.yml  | 1 +
 .travis/linux-prepare.sh | 5 +
 2 files changed, 6 insertions(+)

-- 
2.17.1

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

[ovs-dev] [PATCH 1/2] travis: Workaround skipping of IPv6 tests.

2019-11-01 Thread Ilya Maximets 
IPv6 support disabled in TravisCI images but supported by kernel.
So, we could enable it in order to not skip unit tests.
We are not trying to communicate over network with IPv6, so this
should not make any harm.

Related issue: https://github.com/travis-ci/travis-ci/issues/8891

Signed-off-by: Ilya Maximets 
---
 .travis/linux-prepare.sh | 5 +
 1 file changed, 5 insertions(+)

diff --git a/.travis/linux-prepare.sh b/.travis/linux-prepare.sh
index e546d32cb..9e3ac0df7 100755
--- a/.travis/linux-prepare.sh
+++ b/.travis/linux-prepare.sh
@@ -20,3 +20,8 @@ if [ "$M32" ]; then
 # This will remove the 64-bit libunwind and install 32-bit version.
 sudo apt-get install -y libunwind-dev:i386
 fi
+
+# IPv6 is supported by kernel but disabled in TravisCI images:
+#   https://github.com/travis-ci/travis-ci/issues/8891
+# Enable it to avoid skipping of IPv6 related tests.
+sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0
-- 
2.17.1

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

Re: [ovs-dev] [PATCH] tests: Skip testcases using nc under check-afxdp.

2019-11-01 Thread William Tu 
On Fri, Nov 1, 2019 at 3:10 PM Ilya Maximets  wrote:
>
>
>
> On 01.11.2019 22:51, William Tu wrote:
> > AF_XDP veth does not support TCP with namespaces. This patch skips them.
> >
> > Signed-off-by: William Tu 
> > ---
> > v1:
> >- Tested-at: https://travis-ci.org/williamtu/ovs-travis/builds/606194550
> >- make check-afxdp all pass on my machine, but cirrus, it is still 
> > unstable,
> >  observe 1 failed at:
> >  https://cirrus-ci.com/task/6597038589870080
> > ---
> >   tests/system-afxdp-macros.at |  7 +++
> >   tests/system-kmod-macros.at  |  8 
> >   tests/system-traffic.at  | 18 +-
> >   tests/system-userspace-macros.at |  8 
> >   4 files changed, 32 insertions(+), 9 deletions(-)
> >
> > diff --git a/tests/system-afxdp-macros.at b/tests/system-afxdp-macros.at
> > index f0683c0a901b..27c220998355 100644
> > --- a/tests/system-afxdp-macros.at
> > +++ b/tests/system-afxdp-macros.at
> > @@ -37,3 +37,10 @@ m4_define([CONFIGURE_VETH_OFFLOADS],
> >   #
> >   m4_define([OVS_START_L7],
> >  [AT_SKIP_IF([:])])
> > +
> > +# OVS_CHECK_NC()
> > +#
> > +# Check if comman nc is available. Always skip because
> > +# AF_XDP veth does not support TCP with namespaces.
> > +m4_define([OVS_CHECK_NC],
> > +[AT_SKIP_IF([:])])
>
> Most of the tests uses 'nc -u' generating UDP traffic and works fine.
> We should not skip them.  There are only 2 tests that are failing now.
> Both uses 'nc' without '-u' option, i.e. generates TCP traffic.
> Only these tests should be skipped.

OK, thanks.
In this case, I'm thinking about adding a new macro, ex:
OVS_SKIP_AFXDP in all tests at system-traffic.at that use
TCP with nc.

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

Re: [ovs-dev] [PATCH] tests: Skip testcases using nc under check-afxdp.

2019-11-01 Thread Ilya Maximets 




On 01.11.2019 22:51, William Tu wrote:

AF_XDP veth does not support TCP with namespaces. This patch skips them.

Signed-off-by: William Tu 
---
v1:
   - Tested-at: https://travis-ci.org/williamtu/ovs-travis/builds/606194550
   - make check-afxdp all pass on my machine, but cirrus, it is still unstable,
 observe 1 failed at:
 https://cirrus-ci.com/task/6597038589870080
---
  tests/system-afxdp-macros.at |  7 +++
  tests/system-kmod-macros.at  |  8 
  tests/system-traffic.at  | 18 +-
  tests/system-userspace-macros.at |  8 
  4 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/tests/system-afxdp-macros.at b/tests/system-afxdp-macros.at
index f0683c0a901b..27c220998355 100644
--- a/tests/system-afxdp-macros.at
+++ b/tests/system-afxdp-macros.at
@@ -37,3 +37,10 @@ m4_define([CONFIGURE_VETH_OFFLOADS],
  #
  m4_define([OVS_START_L7],
 [AT_SKIP_IF([:])])
+
+# OVS_CHECK_NC()
+#
+# Check if comman nc is available. Always skip because
+# AF_XDP veth does not support TCP with namespaces.
+m4_define([OVS_CHECK_NC],
+[AT_SKIP_IF([:])])


Most of the tests uses 'nc -u' generating UDP traffic and works fine.
We should not skip them.  There are only 2 tests that are failing now.
Both uses 'nc' without '-u' option, i.e. generates TCP traffic.
Only these tests should be skipped.

Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] tests: Skip testcases using nc under check-afxdp.

2019-11-01 Thread William Tu 
AF_XDP veth does not support TCP with namespaces. This patch skips them.

Signed-off-by: William Tu 
---
v1:
  - Tested-at: https://travis-ci.org/williamtu/ovs-travis/builds/606194550
  - make check-afxdp all pass on my machine, but cirrus, it is still unstable,
observe 1 failed at:
https://cirrus-ci.com/task/6597038589870080
---
 tests/system-afxdp-macros.at |  7 +++
 tests/system-kmod-macros.at  |  8 
 tests/system-traffic.at  | 18 +-
 tests/system-userspace-macros.at |  8 
 4 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/tests/system-afxdp-macros.at b/tests/system-afxdp-macros.at
index f0683c0a901b..27c220998355 100644
--- a/tests/system-afxdp-macros.at
+++ b/tests/system-afxdp-macros.at
@@ -37,3 +37,10 @@ m4_define([CONFIGURE_VETH_OFFLOADS],
 #
 m4_define([OVS_START_L7],
[AT_SKIP_IF([:])])
+
+# OVS_CHECK_NC()
+#
+# Check if comman nc is available. Always skip because
+# AF_XDP veth does not support TCP with namespaces.
+m4_define([OVS_CHECK_NC],
+[AT_SKIP_IF([:])])
diff --git a/tests/system-kmod-macros.at b/tests/system-kmod-macros.at
index 9e89aec43734..5b610f5517ec 100644
--- a/tests/system-kmod-macros.at
+++ b/tests/system-kmod-macros.at
@@ -211,3 +211,11 @@ m4_define([VSCTL_ADD_DATAPATH_TABLE],
 # or necessary for the userspace datapath as it is checking for a kernel
 # specific regression.
 m4_define([CHECK_L3L4_CONNTRACK_REASM])
+
+# OVS_CHECK_NC()
+#
+# Check if comman nc is available.
+m4_define([OVS_CHECK_NC],
+[
+AT_SKIP_IF([test $HAVE_NC = no])
+])
diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index 870a05efe04c..d3214696aff1 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -993,7 +993,7 @@ NS_CHECK_EXEC([at_ns1], [ping -q -c 3 -i 0.3 -w 2 10.1.1.1 
| FORMAT_PING], [0],
 OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 AT_SETUP([datapath - basic truncate action])
-AT_SKIP_IF([test $HAVE_NC = no])
+OVS_CHECK_NC()
 OVS_TRAFFIC_VSWITCHD_START()
 AT_CHECK([ovs-ofctl del-flows br0])
 
@@ -1109,7 +1109,7 @@ dnl   br-underlay: with IP: 172.31.1.100
 dnl   ns0: connect to br-underlay, with IP: 10.1.1.1
 AT_SETUP([datapath - truncate and output to gre tunnel by simulated packets])
 OVS_CHECK_MIN_KERNEL(3, 10)
-AT_SKIP_IF([test $HAVE_NC = no])
+OVS_CHECK_NC()
 OVS_TRAFFIC_VSWITCHD_START()
 
 ADD_BR([br-underlay], [set bridge br-underlay 
other-config:hwaddr=\"02:90:8c:a8:a1:49\"])
@@ -1240,7 +1240,7 @@ dnl   ns1: connect to br0, with IP:10.1.1.2
 dnl   br-underlay: with IP: 172.31.1.100
 dnl   ns0: connect to br-underlay, with IP: 10.1.1.1
 AT_SETUP([datapath - truncate and output to gre tunnel])
-AT_SKIP_IF([test $HAVE_NC = no])
+OVS_CHECK_NC()
 OVS_CHECK_KERNEL_EXCL(3, 10, 4, 15)
 OVS_CHECK_GRE()
 OVS_TRAFFIC_VSWITCHD_START()
@@ -2252,7 +2252,7 @@ OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
 AT_SETUP([conntrack - ICMP related])
-AT_SKIP_IF([test $HAVE_NC = no])
+OVS_CHECK_NC()
 CHECK_CONNTRACK()
 OVS_TRAFFIC_VSWITCHD_START()
 
@@ -2288,7 +2288,7 @@ OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
 AT_SETUP([conntrack - ICMP related to original direction])
-AT_SKIP_IF([test $HAVE_NC = no])
+OVS_CHECK_NC()
 CHECK_CONNTRACK()
 OVS_TRAFFIC_VSWITCHD_START()
 
@@ -4417,7 +4417,7 @@ OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
 AT_SETUP([conntrack - ICMP related with NAT])
-AT_SKIP_IF([test $HAVE_NC = no])
+OVS_CHECK_NC()
 AT_SKIP_IF([test $HAVE_TCPDUMP = no])
 CHECK_CONNTRACK()
 CHECK_CONNTRACK_NAT()
@@ -5571,7 +5571,7 @@ AT_CLEANUP
 
 
 AT_SETUP([conntrack - DNAT load balancing with NC])
-AT_SKIP_IF([test $HAVE_NC = no])
+OVS_CHECK_NC()
 CHECK_CONNTRACK()
 CHECK_CONNTRACK_NAT()
 OVS_TRAFFIC_VSWITCHD_START()
@@ -5659,7 +5659,7 @@ OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
 AT_SETUP([conntrack - floating IP])
-AT_SKIP_IF([test $HAVE_NC = no])
+OVS_CHECK_NC()
 CHECK_CONNTRACK()
 OVS_TRAFFIC_VSWITCHD_START()
 OVS_CHECK_CT_CLEAR()
@@ -5734,7 +5734,7 @@ AT_CLEANUP
 AT_SETUP([conntrack - negative test for recirculation optimization])
 dnl This test will fail if 'conn' caching is being used, because the tuple
 dnl has been changed outside of conntrack.
-AT_SKIP_IF([test $HAVE_NC = no])
+OVS_CHECK_NC()
 CHECK_CONNTRACK()
 OVS_TRAFFIC_VSWITCHD_START()
 OVS_CHECK_CT_CLEAR()
diff --git a/tests/system-userspace-macros.at b/tests/system-userspace-macros.at
index a419f30c1563..9e9787429f6f 100644
--- a/tests/system-userspace-macros.at
+++ b/tests/system-userspace-macros.at
@@ -323,3 +323,11 @@ m4_define([CHECK_L3L4_CONNTRACK_REASM],
 [
 AT_SKIP_IF([:])
 ])
+
+# OVS_CHECK_NC()
+#
+# Check if comman nc is available.
+m4_define([OVS_CHECK_NC],
+[
+AT_SKIP_IF([test $HAVE_NC = no])
+])
-- 
2.7.4

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

Re: [ovs-dev] [PATCH v2] ofp-monitor: Fixed the usage of 'usable_protocols' variable in 'parse_flow_monitor_request' function.

2019-11-01 Thread Ben Pfaff 
On Tue, Jul 23, 2019 at 01:02:10PM -0700, Ashish Varma wrote:
> 'usable_protocols' is now getting set to OFPUTIL_P_OF10_ANY on return from
> 'parse_flow_monitor_request' function. The calling function now checks for the
> value in this variable against the 'allowed_protocols' variable.
> Also a check is added for a match field which is not supported in OpenFlow 1.0
> and return an error.
> Modified the man page of ovs-ofctl to reflect Flow Monitor support as
> OpenFlow 1.0 Nicira extension only.
> 
> Signed-off-by: Ashish Varma 
> ---
> v1-v2:
> Added a test that triggers the error condition fixed in this patch.
> Setting the usable_protocols variable to OFPUTIL_P_OF10_ANY or even a
> further subset if the match field requires it to. e.g. 'sctp_dst' is supported
> as only NXM protocol and not in STD protocol.
> Consistent wording for the error message on encountering an unusable flow
> format.

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

[ovs-dev] [PATCH] ofproto: Fix crash on PACKET_OUT due to recursive locking after upcall.

2019-11-01 Thread Ilya Maximets 
Handling of OpenFlow PACKET_OUT implies pushing the packet through
the datapath and packet processing inside the datapath could trigger
an upcall.  In case of system datapath, 'dpif_execute()' sends packet
to the kernel module and returns.  If any, upcall  will be triggered
inside the kernel and handled by a separate thread in userspace.
But in case of userspace datapath full processing of the packet happens
inside the 'dpif_execute()' in the same thread that handled PACKET_OUT.
This causes an issue if upcall will lead to modification of flow rules.
For example, it could happen while processing of 'learn' actions.
Since whole handling of PACKET_OUT is protected by 'ofproto_mutex',
OVS will assert on attempt to take it recursively while processing
'learn' actions:

   0 __GI_raise (sig=sig@entry=6)
   1 __GI_abort ()
   2 ovs_abort_valist ()
   3 ovs_abort ()
   4 ovs_mutex_lock_at (where=where@entry=0xad4199 "ofproto/ofproto.c:5391")

   5 ofproto_flow_mod_learn ()   at ofproto/ofproto.c:5391

   6 xlate_learn_action ()   at ofproto/ofproto-dpif-xlate.c:5378
<'learn' action found>
   7 do_xlate_actions () at ofproto/ofproto-dpif-xlate.c:6893
   8 xlate_recursively ()at ofproto/ofproto-dpif-xlate.c:4233
   9 xlate_table_action ()   at ofproto/ofproto-dpif-xlate.c:4361
  10 in xlate_ofpact_resubmit () at ofproto/ofproto-dpif-xlate.c:4672
  11 do_xlate_actions () at ofproto/ofproto-dpif-xlate.c:6773
  12 xlate_actions ()at ofproto/ofproto-dpif-xlate.c:7570
 
  13 upcall_xlate () at ofproto/ofproto-dpif-upcall.c:1197
  14 process_upcall ()   at ofproto/ofproto-dpif-upcall.c:1413
  15 upcall_cb ()at ofproto/ofproto-dpif-upcall.c:1315
  16 dp_netdev_upcall (DPIF_UC_MISS) at lib/dpif-netdev.c:6236
 
  17 handle_packet_upcall () at lib/dpif-netdev.c:6591
  18 fast_path_processing () at lib/dpif-netdev.c:6709
  19 dp_netdev_input__ ()at lib/dpif-netdev.c:6797
  20 dp_netdev_recirculate ()at lib/dpif-netdev.c:6842
  21 dp_execute_cb ()at lib/dpif-netdev.c:7158
  22 odp_execute_actions ()  at lib/odp-execute.c:794
  23 dp_netdev_execute_actions ()at lib/dpif-netdev.c:7332
  24 dpif_netdev_execute ()  at lib/dpif-netdev.c:3725
  25 dpif_netdev_operate ()  at lib/dpif-netdev.c:3756
 
  26 dpif_operate () at lib/dpif.c:1367
  27 dpif_execute () at lib/dpif.c:1321
  28 packet_execute ()   at ofproto/ofproto-dpif.c:4760
  29 ofproto_packet_out_finish ()at ofproto/ofproto.c:3594
 
  30 handle_packet_out ()at ofproto/ofproto.c:3635
  31 handle_single_part_openflow (OFPTYPE_PACKET_OUT) at ofproto/ofproto.c:8400
  32 handle_openflow ()   at ofproto/ofproto.c:8587
  33 ofconn_run ()
  34 connmgr_run ()
  35 ofproto_run ()
  36 bridge_run__ ()
  37 bridge_run ()
  38 main ()

Fix that by splitting the 'ofproto_packet_out_finish()' in two parts.
First one that translates side-effects and requires holding 'ofproto_mutex'
and the second that only pushes packet to datapath.  The second part moved
out of 'ofproto_mutex' because 'ofproto_mutex' is not required and actually
should not be taken in order to avoid recursive locking.

Reported-by: Anil Kumar Koli 
Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-April/048494.html
Signed-off-by: Ilya Maximets 
---

Previous discussion about implementation:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-August/362082.html

I'm not able to reproduce the original issue, so I can not test if
this patch fixes it.

 ofproto/ofproto-dpif.c | 40 --
 ofproto/ofproto-provider.h | 12 +---
 ofproto/ofproto.c  | 29 +++
 3 files changed, 64 insertions(+), 17 deletions(-)

diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index c35ec3e61..0466952e2 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -4827,12 +4827,13 @@ ofproto_dpif_xcache_execute(struct ofproto_dpif 
*ofproto,
 }
 
 static void
-packet_execute(struct ofproto *ofproto_, struct ofproto_packet_out *opo)
+packet_execute_prepare(struct ofproto *ofproto_,
+   struct ofproto_packet_out *opo)
 OVS_REQUIRES(ofproto_mutex)
 {
 struct ofproto_dpif *ofproto = ofproto_dpif_cast(ofproto_);
 struct dpif_flow_stats stats;
-struct dpif_execute execute;
+struct dpif_execute *execute;
 
 struct ofproto_dpif_packet_out *aux = opo->aux;
 ovs_assert(aux);
@@ -4841,22 +4842,40 @@ packet_execute(struct ofproto *ofproto_, struct 
ofproto_packet_out *opo)
 dpif_flow_stats_extract(opo->flow, opo->packet, time_msec(), );
 ofproto_dpif_xcache_execute(ofproto, >xcache, );
 
-

Re: [ovs-dev] [PATCH v1] NEWS: Add stateless NAT support

2019-11-01 Thread Mark Michelson 

Thanks, I applied this to master.

On 11/1/19 4:30 PM, Ankur Sharma wrote:

Signed-off-by: Ankur Sharma 
---
  NEWS | 1 +
  1 file changed, 1 insertion(+)

diff --git a/NEWS b/NEWS
index c6c2a3a..0ad9677 100644
--- a/NEWS
+++ b/NEWS
@@ -3,6 +3,7 @@ Post-OVS-v2.12.0
 - OVN was split out from the OVS repository and is now released
   independently.
 - Added IPv6 NAT support for OVN routers.
+   - Added Stateless Floating IP support in OVN.
  
  v2.12.0 - 03 Sep 2019

  -



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

Re: [ovs-dev] [PATCH v1] NEWS: Add stateless NAT support

2019-11-01 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.


git-am:
fatal: sha1 information is lacking or useless (NEWS).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 NEWS: Add stateless NAT support
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...@redhat.com

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

Re: [ovs-dev] [PATCH ovn] Improve debuggability of OVN to OpenFlow translations.

2019-11-01 Thread Mark Michelson 

Great addition, Dumitru!

Acked-by: Mark Michelson 

On 11/1/19 8:05 AM, Dumitru Ceara wrote:

Until now, when translating SB database contents to OpenFlow flows,
ovn-controller stored (part of) the SB record UUID in the cookie field
of the OpenFlow entry only when translating logical flows.

Extend this behavior to the following SB Database table records too:
- Port_Binding
- Mac_Binding
- Multicast_Group
- Chassis

This makes debugging easier by allowing the user to trace back the
original SB entry that generated the OpenFlow entry. Also, the
"ovn-sbctl lflow-list" command now supports an additional "--vflows"
argument (virtual flows). When present this will instruct ovn-sbctl
to also pretty print the contents of the above mentioned tables for
the given datapath (or all datapaths if none is specified).

Combined with the "--ovs" and "--stats" arguments it allows the
user to have a more complete view of how forwarding in the
logical network is translated to forwarding in OVS.

A usage example:
$ ovn-sbctl --ovs --vflows lflow-list
[...]
Port Bindings:
   datapath="ls", logical_port=vm2, tunnel_key=4
 cookie=0xeaee10a0, duration=2122.949s, table=65, n_packets=0,
   n_bytes=0, priority=100,reg15=0x4,metadata=0x2 actions=output:2
   datapath="rtr", logical_port=rtr-ls, tunnel_key=1
 cookie=0x640b6337, duration=2122.945s, table=65, n_packets=0,
   n_bytes=0, priority=100,reg15=0x1,metadata=0x1
   actions=clone(ct_clear,set_field:0->reg11,set_field:0->reg12,
 set_field:0->reg13,set_field:0x4->reg11,set_field:0x3->reg12,
 set_field:0x2->metadata,set_field:0x3->reg14,set_field:0->reg10,
 set_field:0->reg15,set_field:0->reg0,set_field:0->reg1,
 set_field:0->reg2,set_field:0->reg3,set_field:0->reg4,
 set_field:0->reg5,set_field:0->reg6,set_field:0->reg7,
 set_field:0->reg8,set_field:0->reg9,set_field:0->in_port,
 resubmit(,8))

MAC Bindings:
   datapath="rtr", logical_port=rtr-ls, ip=10::254, mac=00:00:00:00:00:01
 cookie=0x1c2b771d, duration=2122.946s, table=66, n_packets=0,
   n_bytes=0,priority=100,reg0=0x10,reg1=0,reg2=0,reg3=0x254,
   reg15=0x1,metadata=0x1
   actions=set_field:00:00:00:00:00:01->eth_dst
 cookie=0x1c2b771d, duration=2122.945s, table=67, n_packets=0,
   n_bytes=0,priority=100,icmp6,reg0=0x10,reg1=0,reg2=0,
   reg3=0x254,reg14=0x1,metadata=0x1,dl_src=00:00:00:00:00:01,icmp_code=0
   actions=load:0x1->NXM_NX_REG10[6]

MC Groups:
   datapath="ls", name=_MC_flood, tunnel_key=32768, ports=(vm1, ls-rtr, vm2)
 cookie=0x4a196492, duration=2122.949s, table=33, n_packets=0,
   n_bytes=0, priority=100,reg15=0x8000,metadata=0x2
   actions=set_field:0x1->reg13,set_field:0x2->reg15,resubmit(,34),
   set_field:0xc->reg13,set_field:0x4->reg15,resubmit(,34),
   set_field:0x8000->reg15
 cookie=0x4a196492, duration=2122.947s, table=32, n_packets=0,
   n_bytes=0, priority=100,reg15=0x8000,metadata=0x2
   actions=set_field:0x3->reg15,resubmit(,34),set_field:0x8000->reg15,
   resubmit(,33)
[..]

Signed-off-by: Dumitru Ceara 
---
  controller/lflow.c   |   6 +-
  controller/physical.c|  58 +-
  utilities/ovn-sbctl.8.in |   8 +-
  utilities/ovn-sbctl.c| 196 +++
  4 files changed, 230 insertions(+), 38 deletions(-)

diff --git a/controller/lflow.c b/controller/lflow.c
index f34abce..36150bd 100644
--- a/controller/lflow.c
+++ b/controller/lflow.c
@@ -817,7 +817,8 @@ consider_neighbor_flow(struct ovsdb_idl_index 
*sbrec_port_binding_by_name,
  uint64_t stub[1024 / 8];
  struct ofpbuf ofpacts = OFPBUF_STUB_INITIALIZER(stub);
  put_load(mac.ea, sizeof mac.ea, MFF_ETH_DST, 0, 48, );
-ofctrl_add_flow(flow_table, OFTABLE_MAC_BINDING, 100, 0, _arp_match,
+ofctrl_add_flow(flow_table, OFTABLE_MAC_BINDING, 100,
+b->header_.uuid.parts[0], _arp_match,
  , >header_.uuid);
  
  ofpbuf_clear();

@@ -825,7 +826,8 @@ consider_neighbor_flow(struct ovsdb_idl_index 
*sbrec_port_binding_by_name,
  put_load(, sizeof value, MFF_LOG_FLAGS, MLF_LOOKUP_MAC_BIT, 1,
   );
  match_set_dl_src(_arp_match, mac);
-ofctrl_add_flow(flow_table, OFTABLE_MAC_LOOKUP, 100, 0, _arp_match,
+ofctrl_add_flow(flow_table, OFTABLE_MAC_LOOKUP, 100,
+b->header_.uuid.parts[0], _arp_match,
  , >header_.uuid);
  
  ofpbuf_uninit();

diff --git a/controller/physical.c b/controller/physical.c
index 6e606d3..500d419 100644
--- a/controller/physical.c
+++ b/controller/physical.c
@@ -298,7 +298,8 @@ put_remote_port_redirect_bridged(const struct
   , NULL);
  
  put_resubmit(OFTABLE_LOG_TO_PHY, ofpacts_p);

-ofctrl_add_flow(flow_table, OFTABLE_LOCAL_OUTPUT, 100, 0,
+ofctrl_add_flow(flow_table, OFTABLE_LOCAL_OUTPUT, 100,
+

[ovs-dev] Estrategias de fidelización de personal.

2019-11-01 Thread Temario - Acciones preventivas 
27 de Noviembre | Horario de 10:00 a 17:00 hrs.  |   (hora del centro de 
México) 

- Rotación Cero -  Webinar en Línea

Presentaremos los fundamentos para identificar el impacto que la rotación de
personal tiene en nuestra empresa así como de las estrategias a aplicar para 
sobrellevarla.


¿Qué aprenderás?:

• Causas de la rotación de personal.
• Medición de la rotación de personal.
• Acciones preventivas.
• Estrategias de fidelización de personal.

Solicita información respondiendo a este correo con la palabra Rotación, junto 
con los siguientes datos:

Nombre:
Correo electrónico:
Número telefónico:
 
Dirigido a: Personal del área de RRHH, Reclutamiento y Selección de personal, 
Desarrollo
Organizacional. Directores, gerentes y jefes responsables de la administración 
de personal.

Números de Atención: 
(045) 55 15 54 66 30 - (045) 55 85567293 - (045) 5530167085 

En caso de que haya recibido este correo sin haberlo solicitado o si desea 
dejar de recibir nuestra promoción favor de responder con la palabra baja o 
enviar un correo a bajas@ innovalearn.net


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

Re: [ovs-dev] [PATCH v4 0/2] ALLOW Stateless NAT operations

2019-11-01 Thread Ankur Sharma 
Hi Numan,

Thanks for applying the patches.
Sure, I have sent out the NEW entry changes.

Just noticed that Acked-by is missing in the commits.

Regards,
Ankur

From: Numan Siddique 
Sent: Friday, November 1, 2019 9:51 AM
To: Ankur Sharma 
Cc: ovs-dev@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v4 0/2] ALLOW Stateless NAT operations


On Fri, Nov 1, 2019, 2:57 PM Numan Siddique 
mailto:num...@ovn.org>> wrote:
On Fri, Nov 1, 2019 at 6:58 AM Ankur Sharma 
mailto:ankur.sha...@nutanix.com>> wrote:
>
> NAT implementation in OVN uses connection tracker to replace
> source and dest ips. This implementation works fine and
> is the right approach for cases where external ips are shared
> (i.e. SNAT) or where we replace ip only when relevant flow is there
> (i.e. DNAT).
>
> However, it opens the possibility of Dos Attack, where attacker
> can easily simluate multiple 5 tuples, to consume the connection
> tracker entry in an OVN chassis. This way they can easily attain
> the CT limit, there by impacting the usage of it by other features
> like valid NAT, ACL etc.
>
> This attack is even worse, when external ip is a public ip,
> i.e internet routable ip.
>
> In this patch we are introducing an option with NAT table entry.
> Option "stateless=true" indicates that NAT implmentation
> should not be using CT, i.e it should not use ct_snat/dnat actions.
>
> Instead of ct_* actions, we will use ip4.src/dst OVN actions, which
> will replace source and destination ips, while recalculating the
> checksums.
>
> This option is applicable only for the NAT rules which can be
> 1:1 mapped between inner and external ips, i.e dnat_and_snat rule.
>
> Signed-off-by: Ankur Sharma 
> mailto:ankur.sha...@nutanix.com>>

Thanks.

I applied this series to master.

Can you please submit a follow up patch to add a news entry ?

Numan


Numan

>
> Ankur Sharma (2):
>   OVN: ADD nbctl cli to mark a dnat_and_snat rule as stateless
>   OVN: Use ip4.src and ip4.dst actions for NAT rules
>
>  northd/ovn-northd.8.xml   |  33 -
>  northd/ovn-northd.c   |  84 +++--
>  ovn-nb.ovsschema  |   6 +-
>  ovn-nb.xml|   5 +
>  tests/ovn-nbctl.at 
> [ovn-nbctl.at]
> |  37 ++
>  tests/ovn-northd.at 
> [ovn-northd.at]
>|  95 ++
>  tests/ovn.at 
> [ovn.at]
>   | 311 ++
>  utilities/ovn-nbctl.8.xml |  12 +-
>  utilities/ovn-nbctl.c |  30 -
>  9 files changed, 594 insertions(+), 19 deletions(-)
>
> --
> 1.8.3.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev 
> [mail.openvswitch.org]
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH v1] NEWS: Add stateless NAT support

2019-11-01 Thread Ankur Sharma 
Signed-off-by: Ankur Sharma 
---
 NEWS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/NEWS b/NEWS
index c6c2a3a..0ad9677 100644
--- a/NEWS
+++ b/NEWS
@@ -3,6 +3,7 @@ Post-OVS-v2.12.0
- OVN was split out from the OVS repository and is now released
  independently.
- Added IPv6 NAT support for OVN routers.
+   - Added Stateless Floating IP support in OVN.
 
 v2.12.0 - 03 Sep 2019
 -
-- 
1.8.3.1

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

[ovs-dev] [PATCHv3] netdev-afxdp: Enable loading XDP program.

2019-11-01 Thread William Tu 
Now netdev-afxdp always forwards all packets to userspace because
it is using libbpf's default XDP program, see 'xsk_load_xdp_prog'.
There are some cases when users want to keep packets in kernel instead
of sending to userspace, for example, management traffic such as SSH
should be processed in kernel.

The patch enables loading the user-provide XDP program by doing
  $ovs-vsctl -- set int afxdp-p0 options:xdp-obj=

So users can implement their filtering logic or traffic steering idea
in their XDP program, and rest of the traffic passes to AF_XDP socket
handled by OVS.

Signed-off-by: William Tu 
---
v3:
Feedbacks from Eelco.
- keep using xdpobj not xdp-obj (because we alread use xdpmode)
  or we change both to xdp-obj and xdp-mode?
- log a info message when using external program for better debugging
- combine some failure messages
- update doc
NEW:
- add options:xdpobj=__default__, to set back to libbpf default prog
- Tested-at: https://travis-ci.org/williamtu/ovs-travis/builds/606153231

v2:
A couple fixes and remove RFC
---
 Documentation/intro/install/afxdp.rst |  49 +++
 lib/netdev-afxdp.c| 148 +-
 lib/netdev-linux-private.h|   2 +
 3 files changed, 181 insertions(+), 18 deletions(-)

diff --git a/Documentation/intro/install/afxdp.rst 
b/Documentation/intro/install/afxdp.rst
index a136db0c950a..89bc97da9548 100644
--- a/Documentation/intro/install/afxdp.rst
+++ b/Documentation/intro/install/afxdp.rst
@@ -273,6 +273,55 @@ Or, use OVS pmd tool::
   ovs-appctl dpif-netdev/pmd-stats-show
 
 
+Loading Custom XDP Program
+--
+By defailt, netdev-afxdp always forwards all packets to userspace because
+it is using libbpf's default XDP program. There are some cases when users
+want to keep packets in kernel instead of sending to userspace, for example,
+management traffic such as SSH should be processed in kernel. This can be
+done by loading the user-provided XDP program::
+
+  ovs-vsctl -- set int afxdp-p0 options:xdpobj=
+
+So users can implement their filtering logic or traffic steering idea
+in their XDP program, and rest of the traffic passes to AF_XDP socket
+handled by OVS. To set it back to default, use::
+
+  ovs-vsctl -- set int afxdp-p0 options:xdpobj=__default__
+
+Below is a sample C program compiled under kernel's samples/bpf/.
+
+.. code-block:: c
+
+  #include 
+  #include "bpf_helpers.h"
+
+  /* OVS will associate map 'xsks_map' to xsk socket. */
+  struct bpf_map_def SEC("maps") xsks_map = {
+  .type = BPF_MAP_TYPE_XSKMAP,
+  .key_size = sizeof(int),
+  .value_size = sizeof(int),
+  .max_entries = 32,
+  };
+
+  SEC("xdp_sock")
+  int xdp_sock_prog(struct xdp_md *ctx)
+  {
+  int index = ctx->rx_queue_index;
+
+  /* Customized by user.
+   * For example
+   * 1) filter out all SSH traffic and return XDP_PASS
+   *for kernel to process.
+   * 2) Drop unwanted packet by returning XDP_DROP.
+   */
+
+  /* Rest of packets goes to AF_XDP. */
+  return bpf_redirect_map(_map, index, 0);
+  }
+  char _license[] SEC("license") = "GPL";
+
+
 Example Script
 --
 
diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
index af654d498a88..be74527946a4 100644
--- a/lib/netdev-afxdp.c
+++ b/lib/netdev-afxdp.c
@@ -21,6 +21,7 @@
 #include "netdev-afxdp.h"
 #include "netdev-afxdp-pool.h"
 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -88,8 +90,11 @@ BUILD_ASSERT_DECL(PROD_NUM_DESCS == CONS_NUM_DESCS);
 
 #define UMEM2DESC(elem, base) ((uint64_t)((char *)elem - (char *)base))
 
+#define LIBBPF_XDP_PROGRAM "__default__"
+
 static struct xsk_socket_info *xsk_configure(int ifindex, int xdp_queue_id,
- int mode, bool use_need_wakeup);
+ int mode, bool use_need_wakeup,
+ bool use_default_xdp);
 static void xsk_remove_xdp_program(uint32_t ifindex, int xdpmode);
 static void xsk_destroy(struct xsk_socket_info *xsk);
 static int xsk_configure_all(struct netdev *netdev);
@@ -213,6 +218,50 @@ netdev_afxdp_sweep_unused_pools(void *aux OVS_UNUSED)
 ovs_mutex_unlock(_pools_mutex);
 }
 
+static int
+xsk_load_prog(const char *path, struct bpf_object **obj,
+  int *prog_fd)
+{
+struct bpf_prog_load_attr attr = {
+.prog_type = BPF_PROG_TYPE_XDP,
+.file = path,
+};
+
+if (bpf_prog_load_xattr(, obj, prog_fd)) {
+VLOG_ERR("Can't load XDP program at '%s'", path);
+return EINVAL;
+}
+
+return 0;
+}
+
+static int
+xsk_configure_map(struct bpf_object *obj, struct xsk_socket_info *xsk,
+  int queue_id)
+{
+struct bpf_map *map;
+int xsks_map_fd;
+int xsk_fd;
+int ret;
+
+map = bpf_object__find_map_by_name(obj,

Re: [ovs-dev] [PATCH ovn 1/3] ovn-northd: Add support for Load Balancer health check

2019-11-01 Thread Mark Michelson 

On 10/31/19 9:43 AM, num...@ovn.org wrote:

From: Numan Siddique 

The present Load balancer feature in OVN provides load balancing
functionality to the back end ips without checking if the chosen
backend ip is reachable or not. In case a back end service is
down and if that IP is chosen, then packet will be lost.

This patch series adds the health check feature for these
backend IPs and  only active backend IPs are considered for
load balancing. CMS needs to enable this functionality.
In the SB DB a new table Service_Monitor is added. For every
backend IP in the load balancer for which health check is configured,
a new row in the Service_Monitor table is created. In the upcoming
patch in this series, ovn-controller will monitor the services set
in this table by generating a health check packet.

Health checks are supported only for IPv4 Load balancers in this patch.

Existing load balancers will be unaffected after this patch.

Signed-off-by: Numan Siddique 
---
  northd/ovn-northd.8.xml |  75 +-
  northd/ovn-northd.c | 493 
  ovn-nb.ovsschema|  25 +-
  ovn-nb.xml  |  68 ++
  ovn-sb.ovsschema|  33 ++-
  ovn-sb.xml  |  85 +++
  tests/ovn-northd.at | 215 ++
  7 files changed, 948 insertions(+), 46 deletions(-)

diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index f6cafbd55..91d3cff55 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -308,6 +308,16 @@
previously created, it will be associated to the empty_lb logical flow
  
  
+

+  This table also has a priority-110 flow with the match
+  eth.src == E for all logical switch
+  datapaths to move traffic to the next table. Where E
+  is the service monitor mac defined in the
+   colum of  table.
+
+
  Ingress Table 5: Pre-stateful
  
  

@@ -476,7 +486,10 @@
  , where args contains comma separated IP addresses
  (and optional port numbers) to load balance to.  The address family of
  the IP addresses of args is the same as the address family
-of VIP
+of VIP. If health check is enabled, then args
+will only contain those endpoints whose service monitor status entry
+in OVN_Southbound db is either online or
+empty.


  For all the configured load balancing rules for a switch in
@@ -698,6 +711,51 @@ nd_na_router {
  

  
+  

+
+  For each SVC_MON_SRC_IP defined in the value of
+  the  column of
+   table, priority-110
+  logical flow is added with the match
+  arp.tpa == SVC_MON_SRC_IP
+arp.op == 1 and applies the action
+
+
+
+eth.dst = eth.src;
+eth.src = E;
+arp.op = 2; /* ARP reply. */
+arp.tha = arp.sha;
+arp.sha = E;
+arp.tpa = arp.spa;
+arp.spa = A;
+outport = inport;
+flags.loopback = 1;
+output;
+
+
+
+  where E is the service monitor source mac defined in
+  the  column in the  table. This mac is used as the source mac
+  in the service monitor packets for the load balancer endpoint IP
+  health checks.
+
+
+
+  SVC_MON_SRC_IP is used as the source ip in the
+  service monitor IPv4 packets for the load balancer endpoint IP
+  health checks.
+
+
+
+  These flows are required if an ARP request is sent for the IP
+  SVC_MON_SRC_IP.
+
+  
+

  One priority-0 fallback flow that matches all packets and advances to
  the next table.
@@ -1086,6 +1144,16 @@ output;
tracker for packet de-fragmentation.
  
  
+

+  This table also has a priority-110 flow with the match
+  eth.src == E for all logical switch
+  datapaths to move traffic to the next table. Where E
+  is the service monitor mac defined in the
+   colum of  table.
+
+
  Egress Table 1: to-lport Pre-ACLs
  
  

@@ -1920,7 +1988,10 @@ icmp6 {
  (and optional port numbers) to load balance to.  If the router is
  configured to force SNAT any load-balanced packets, the above action
  will be replaced by flags.force_snat_for_lb = 1;
-ct_lb(args);.
+ct_lb(args);. If health check is enabled, then
+args will only contain those endpoints whose service
+monitor status entry in OVN_Southbound db is
+either online or empty.

  


diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 71ee0b678..5c7a179f3 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -88,6 +88,13 @@ static struct eth_addr mac_prefix;
  
  static bool controller_event_en;
  
+/* MAC allocated for service monitor usage. Just one mac is allocated

+ * for this purpose and ovn-controller's on each chassis will make use
+ * of this mac when sending out the packets to

Re: [ovs-dev] [PATCH ovn 0/3] Health check feature for Load balancer backends

2019-11-01 Thread Mark Michelson 

Hi Numan,

I'm curious why this feature is IPv4-only. Based on patch 3, it looks 
like the way is paved for IPv6 support. I'm not sure why IPv6 isn't part 
of the initial changeset.


Aside from a small nit in patch 1, this looks great!

For the series,
Acked-by: Mark Michelson 

On 10/31/19 9:42 AM, num...@ovn.org wrote:

From: Numan Siddique 

This series adds load balancer health check feature. With this
ovn-controllers will periodically check the status of the backend
services. Only those services which are online/active will be considered
for load balancing.

Right now this feature is restricted to IPv4 Load balancers only.
CMS needs to enable this feature and the load balancer vips and backends
should have L4 port defined.

For TCP backends, the local ovn-controller which binds that service's
VIF, will periodically send a SYN packet and would expect SYN-ACK
response to set the status of that service to online. If no response
is received within the timeout, then the service status is set to
offline.

For UDP backends, the local ovn-controller which binds that service's
VIF, will periodically send an UDP packet and expects no reply. If no
reply is received within the timeout vallue, the service status is set
to online. In case the service is down, then ovn-controller expects
ICMP unreachable packet and upon receiving this ICMP packets, it sets
the status to offline.

ovn-northd adds only those backends whose status is 'online' or empty to
the ct_lb action.

Numan Siddique (3):
   ovn-northd: Add support for Load Balancer health check
   Add a new action - handle_svc_check
   Send service monitor health checks

  controller/ovn-controller.c   |   2 +
  controller/pinctrl.c  | 775 --
  controller/pinctrl.h  |   2 +
  include/ovn/actions.h |  17 +-
  lib/actions.c |  42 ++
  northd/ovn-northd.8.xml   |  85 +++-
  northd/ovn-northd.c   | 512 --
  ovn-nb.ovsschema  |  25 +-
  ovn-nb.xml|  68 +++
  ovn-sb.ovsschema  |  33 +-
  ovn-sb.xml| 102 +
  tests/ovn-northd.at   | 215 ++
  tests/ovn.at  | 133 ++
  tests/system-common-macros.at |   1 +
  tests/system-ovn.at   | 180 
  utilities/ovn-trace.c |   3 +
  16 files changed, 2122 insertions(+), 73 deletions(-)



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

Re: [ovs-dev] [PATCH] Revert "ip_gre: Remove even more unused code"

2019-11-01 Thread Gregory Rose 


On 11/1/2019 11:04 AM, Simon Horman wrote:

On Fri, Nov 01, 2019 at 10:27:09AM -0700, Gregory Rose wrote:

On 11/1/2019 9:07 AM, Greg Rose wrote:

This reverts commit 42a059e02bf343787951be2824c579e1c9a26e12.

Not all the necessary ipgre prefixed code was removed that
should have been.  Another patch will follow with the correct
removed code.

Signed-off-by: Greg Rose 
---

Maintainers, please apply this revert patch to fix the Travis builds.  Patch
passes Travis here:

https://travis-ci.org/gvrose8192/ovs-experimental/builds/606080092

Thanks Greg,

pushed to master.


And thank you Simon, I'll make sure I mail the right patch next time.

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

Re: [ovs-dev] [PATCH] Revert "ip_gre: Remove even more unused code"

2019-11-01 Thread Simon Horman 
On Fri, Nov 01, 2019 at 10:27:09AM -0700, Gregory Rose wrote:
> 
> On 11/1/2019 9:07 AM, Greg Rose wrote:
> > This reverts commit 42a059e02bf343787951be2824c579e1c9a26e12.
> > 
> > Not all the necessary ipgre prefixed code was removed that
> > should have been.  Another patch will follow with the correct
> > removed code.
> > 
> > Signed-off-by: Greg Rose 
> > ---
> 
> Maintainers, please apply this revert patch to fix the Travis builds.  Patch
> passes Travis here:
> 
> https://travis-ci.org/gvrose8192/ovs-experimental/builds/606080092

Thanks Greg,

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

Re: [ovs-dev] [PATCH] ip_gre: Removed unused ipgre netdev ops

2019-11-01 Thread Simon Horman 
On Fri, Nov 01, 2019 at 09:54:40AM -0700, Gregory Rose wrote:
> 
> 
> On 11/1/2019 9:52 AM, Gregory Rose wrote:
> > > >     42a059e02bf3 ("ip_gre: Remove even more unused code")
> > 
> > That one should be fine.
> > 
> > Thanks,
> > 
> 
> Oh goodness, I meant this one should be fine.
> 
> adf9ac69aee1 ("ip_gre: Removed unused ipgre netdev ops")

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

Re: [ovs-dev] [PATCH ovn] Improve debuggability of OVN to OpenFlow translations.

2019-11-01 Thread Ben Pfaff 
On Fri, Nov 01, 2019 at 01:05:15PM +0100, Dumitru Ceara wrote:
> Until now, when translating SB database contents to OpenFlow flows,
> ovn-controller stored (part of) the SB record UUID in the cookie field
> of the OpenFlow entry only when translating logical flows.
> 
> Extend this behavior to the following SB Database table records too:
> - Port_Binding
> - Mac_Binding
> - Multicast_Group
> - Chassis
> 
> This makes debugging easier by allowing the user to trace back the
> original SB entry that generated the OpenFlow entry. Also, the
> "ovn-sbctl lflow-list" command now supports an additional "--vflows"
> argument (virtual flows). When present this will instruct ovn-sbctl
> to also pretty print the contents of the above mentioned tables for
> the given datapath (or all datapaths if none is specified).

This is smart and I fully endorse the idea.

I haven't properly reviewed the patch, so the following is for the idea:
Acked-by: Ben Pfaff 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v1] ofproto: Fix OVS crash when packets hit Openflow rules with certain combinations of nested actions

2019-11-01 Thread Ben Pfaff 
On Fri, Nov 01, 2019 at 02:35:55PM +0100, Ilya Maximets wrote:
> CC: ovs-dev
> Sorry.
> 
> On 01.11.2019 14:34, Ilya Maximets wrote:
> > On 31.10.2019 18:12, Ben Pfaff wrote:
> > > On Thu, Sep 05, 2019 at 11:12:26PM +0530, Anil Kumar Koli wrote:
> > > > > * We can't get rid of ofproto_mutex in do_bundle_commit(), or drop it
> > > > >    temporarily around flow translation (i.e. the call to
> > > > >    ofproto_packet_out_start()), because it might need to revert all 
> > > > > the
> > > > >    flow table changes and dropping the mutex would allow other 
> > > > > threads to
> > > > >    race in and make conflicting changes
> > > > 
> > > > But it seems that the issue happens on ofproto_packet_out_finish() and 
> > > > not on
> > > > ofproto_packet_out_start(). So, the flow translation should be OK under 
> > > > the
> > > > ofproto_mutex and revert is still possible under the mutex.
> > > > The only thing we need to take out of the mutex is real action 
> > > > execution by
> > > > the datapath triggered by ofproto_packet_out_finish(). Callers never 
> > > > check the
> > > > status of this function so it should be not so hard.
> > > > 
> > > > So, possible solution:
> > > > * Move ofproto_packet_out_finish() out of ofproto_mutex in all the 
> > > > callers:
> > > >    * It's easy for handle_packet_out()
> > > >    * For do_bundle_commit() we could temporary store all the 
> > > > ofproto_packet_out
> > > >  entities and finish them later.
> > > > 
> > > > Am I missing something?  Is there reason for 
> > > > ofproto_packet_out_finish() to
> > > > require ofproto_mutex?
> > > > 
> > > > Ben, Anil, what do you think?
> > > > 
> > > > Best regards, Ilya Maximets.
> > > 
> > > This does seem like a reasonable solution.  Do you want to take a shot
> > > at implementing it?  I promise to review a patch much more quickly than
> > > I responded to the thread :-(
> > > 
> > 
> > I could try. The hard part here is that I can not reproduce the issue.

I can't either.

Anil, do you get the crash when you run the five commands cited in your
commit message under the OVS sandbox (that you can obtain running "make
sandbox")?  It would be a lot easier for Ilya and I to work on and talk
about this issue if we could reproduce the problem.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v1] ofproto: Fix OVS crash when packets hit Openflow rules with certain combinations of nested actions

2019-11-01 Thread Ben Pfaff 
On Fri, Nov 01, 2019 at 02:39:30PM +0100, Ilya Maximets wrote:
> On 31.10.2019 18:24, Ben Pfaff wrote:
> > For Ilya and others: the email to Anil bounced, so he probably isn't at
> > Calsoft Labs any longer.
> 
> Are you sure that it wasn't mine old email address?

Oh, you're right.  Apparently I have reading comprehension problems.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] connection tracking questions

2019-11-01 Thread Ben Pfaff 
On Fri, Nov 01, 2019 at 01:24:24PM -0400, Aaron Conole wrote:
> Nicolas Bouliane via dev  writes:
> > - When I use ofproto/trace and hit flows that use the connection tracking:
> > ct(), does an actual lookup is made even though I'm just tracing ? or it's
> > just simulated.
> 
> If I remember correctly, the ofproto trace command needs to be primed
> with the expected next state information.  But it's been a while since I
> looked at it.

That's what ovn-trace does.  I don't recall what ofproto/trace does.  I
think it might actually trace through recirculation--I remember adding
some feature like that--but I don't remember the details.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] Revert "ip_gre: Remove even more unused code"

2019-11-01 Thread Gregory Rose 


On 11/1/2019 9:07 AM, Greg Rose wrote:

This reverts commit 42a059e02bf343787951be2824c579e1c9a26e12.

Not all the necessary ipgre prefixed code was removed that
should have been.  Another patch will follow with the correct
removed code.

Signed-off-by: Greg Rose 
---


Maintainers, please apply this revert patch to fix the Travis builds.  
Patch passes Travis here:


https://travis-ci.org/gvrose8192/ovs-experimental/builds/606080092

Thanks,

- Greg


  datapath/linux/compat/ip_gre.c | 38 ++
  1 file changed, 38 insertions(+)

diff --git a/datapath/linux/compat/ip_gre.c b/datapath/linux/compat/ip_gre.c
index 8536241..3b7e607 100644
--- a/datapath/linux/compat/ip_gre.c
+++ b/datapath/linux/compat/ip_gre.c
@@ -922,6 +922,44 @@ static int erspan_tunnel_init(struct net_device *dev)
return ip_tunnel_init(dev);
  }
  
+static int ipgre_header(struct sk_buff *skb, struct net_device *dev,

+   unsigned short type,
+   const void *daddr, const void *saddr, unsigned int len)
+{
+   struct ip_tunnel *t = netdev_priv(dev);
+   struct iphdr *iph;
+   struct gre_base_hdr *greh;
+
+   iph = (struct iphdr *)__skb_push(skb, t->hlen + sizeof(*iph));
+   greh = (struct gre_base_hdr *)(iph+1);
+   greh->flags = gre_tnl_flags_to_gre_flags(t->parms.o_flags);
+   greh->protocol = htons(type);
+
+   memcpy(iph, >parms.iph, sizeof(struct iphdr));
+
+   /* Set the source hardware address. */
+   if (saddr)
+   memcpy(>saddr, saddr, 4);
+   if (daddr)
+   memcpy(>daddr, daddr, 4);
+   if (iph->daddr)
+   return t->hlen + sizeof(*iph);
+
+   return -(t->hlen + sizeof(*iph));
+}
+
+static int ipgre_header_parse(const struct sk_buff *skb, unsigned char *haddr)
+{
+   const struct iphdr *iph = (const struct iphdr *) skb_mac_header(skb);
+   memcpy(haddr, >saddr, 4);
+   return 4;
+}
+
+static const struct header_ops ipgre_header_ops = {
+   .create = ipgre_header,
+   .parse  = ipgre_header_parse,
+};
+
  static int ipgre_tunnel_init(struct net_device *dev)
  {
struct ip_tunnel *tunnel = netdev_priv(dev);


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

Re: [ovs-dev] connection tracking questions

2019-11-01 Thread Aaron Conole 
Nicolas Bouliane via dev  writes:

> Hi,
>
> I'm manually inserting an entry with the conntrack tool.
>
> # conntrack -I -d 10.36.96.56 -s 10.36.96.12 -p tcp --sport 80 --dport 80
> --state ESTABLISHED --status A
> SSURED -t 300 --zone 5
> conntrack v1.4.4 (conntrack-tools): 1 flow entries have been created.
>
> # conntrack -L
> tcp  6 295 ESTABLISHED src=10.36.96.12 dst=10.36.96.56 sport=80
> dport=80 [UNREPLIED] src=10.36.96.56 dst=10.36.96.12 sport=80 dport=80
> [ASSURED] mark=0 zone=5 use=1
> conntrack v1.4.4 (conntrack-tools): 1 flow entries have been shown.
>
> But when I use dump-conntrack I see nothing:
>
> # ovs-appctl dpctl/dump-conntrack
> #

I don't see that in my setup.

01:18:38 aconole@dhcp-25 {(c4d4c37e4...)} ~/git/dpdk$ sudo ovs-appctl 
dpctl/dump-conntrack | grep zone
tcp,orig=(src=10.36.96.12,dst=10.36.96.56,sport=80,dport=80),reply=(src=10.36.96.56,dst=10.36.96.12,sport=80,dport=80),zone=5,protoinfo=(state=ESTABLISHED)

Can you try:

  # ovs-appctl dpctl/dump-conntrack system@ovs-system zone=5

and see if you see the connection you've inserted is visible?

> - Does OVS use the same datastructure as the one used by the conntrack tool
> ? (I would presume so since all that is abstracted behind netlink?)

Yes.

> - What distinguishes an entry used by the datapath or not ?

Nothing.

> - When I use ofproto/trace and hit flows that use the connection tracking:
> ct(), does an actual lookup is made even though I'm just tracing ? or it's
> just simulated.

If I remember correctly, the ofproto trace command needs to be primed
with the expected next state information.  But it's been a while since I
looked at it.

> thanks !
> Nick
> ___
> 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 ] travis: support ppc64le builds

2019-11-01 Thread dwilder 

On 2019-10-30 19:04, Yanqin Wei (Arm Technology China) wrote:

Hi,

We are working to support arm64 build for ovs travis CI. It is indeed
to use arch: arm64 to choose cpu architecture, because travis has
provided native arm64 option now.
But in this patch it seems ppc64 builds run on the ppc-VM + x86 native
machine.
Currently arm only select a part of jobs to run, which is defined in
matrix:include. But the final object is to run all jobs. It means that
 arch: arm64 will be moved out of marix. If ppc plans to do the same
in the future, it will conflict with arm jobs.

Best Regards,
Wei Yanqin


Hi,
I have added a build only test for ppc64le following the model used for 
osx. I think this is a good start for getting multi-arch support into 
Ci.


I agree that running all jobs on the matrix on every arch is good goal.  
I dont completely understand your issue, is your concern the use of os: 
vs arch: ?


I am glad to work with you to find a solution. Can you share your arm64 
changes?  We can discuss off-list if you prefer.





-Original Message-
From: ovs-dev-boun...@openvswitch.org
 On Behalf Of dwilder
Sent: Wednesday, October 30, 2019 1:55 AM
To: Ilya Maximets 
Cc: ovs-dev@openvswitch.org; wil...@us.ibm.com
Subject: Re: [ovs-dev] [PATCH ] travis: support ppc64le builds

On 2019-10-29 09:52, Ilya Maximets wrote:

On 28.10.2019 22:22, David Wilder wrote:

Add support for travis-ci ppc64le builds.

- Updated matrix in .travis.yml to include a ppc64le build.
- Added support to install packages needed by specific architectures.

To keep the total build time at an acceptable level only a single
build job is included in the matrix for ppc64le.

A build report example can be found here [1] [0]
https://urldefense.proofpoint.com/v2/url?u=http-3A__travis-2Dci.org_;
d=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=7ndxyKjH9UrBD68Us2WP1wI4BwEBQbeAy
z8i_vwCCaI=6JANehIfGoxUMtwHhe4yob4UPeby0Y8ovgzRDIyJZFo=UMYL8rzJNp
h87seC0oJLBiWoe-sUSL80AJy0RMTgBzQ=
[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_
djlwilder_ovs_builds_604098141=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=7n
dxyKjH9UrBD68Us2WP1wI4BwEBQbeAyz8i_vwCCaI=6JANehIfGoxUMtwHhe4yob4UP
eby0Y8ovgzRDIyJZFo=pyd2yQpQ0snpwGE5El4RYZsatwl74sthM1KLqtIKCnY=
Signed-off-by: David Wilder 


Hi David,
Thanks for working on this. I have a couple of question regarding
ppc64le support by TravisCI.  It seems that they are not supporting
this architecture officially and refusing[1] to solve any issues that
appears while using it. There also no official documentation.
It's kind of a hidden feature that some projects are using for their
own risk [2]. Do you know why this happens or maybe you have some
insights about what is going on/how it works?


Work is going on to increase ppc64le support on Travis by the end of
the year.  I dont have any details yet. My plan is to keep this to
build-only ci until then.  Important, ppc64le VM are only available on
travis-ci.org, they are not available on travis-ci.com.


The API is also a bit strange because Travis started to officially
support arm builds, but this is done via 'arch' knob, not the 'os'.
Will it be changed over time for ppc64le?



Sorry, I dont know.


[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.commu
nity_t_ppc64le-2Darch-2Dsupport-2Don-2Dtravis-2Dci-2Dcom-2Dvs-2Dtravis
-2Dci-2Dorg_2898_2=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=7ndxyKjH9UrBD68
Us2WP1wI4BwEBQbeAyz8i_vwCCaI=6JANehIfGoxUMtwHhe4yob4UPeby0Y8ovgzRDIy
JZFo=TrXdSxjvnbbVQz7EzR5r0aE93lZMSdCiIUQT2wt8E3I=
[2]
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openss
l_openssl_commit_13da3ad00c80e1da816ca27f6c15b0ecee1bb0b8=DwICaQ=j
f_iaSHvJObTbx-siA1ZOg=7ndxyKjH9UrBD68Us2WP1wI4BwEBQbeAyz8i_vwCCaI=
6JANehIfGoxUMtwHhe4yob4UPeby0Y8ovgzRDIyJZFo=RWVuli-BT8E2IsW3rAA9MtqC
VPZahNk8k7yqxEbgTT4=

Few code comments inline.


---
  .travis.yml  |  5 +++--
  .travis/linux-prepare.sh | 18 ++
  2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/.travis.yml b/.travis.yml index 5676d9748..c99f26815
100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -14,7 +14,6 @@ addons:
apt:
  packages:
- bc
-  - gcc-multilib
- libssl-dev
- llvm-dev
- libjemalloc1
@@ -24,7 +23,6 @@ addons:
- libelf-dev
- selinux-policy-dev
- libunbound-dev
-  - libunbound-dev:i386
- libunwind-dev
before_install: ./.travis/${TRAVIS_OS_NAME}-prepare.sh
@@ -50,6 +48,9 @@ matrix:
  - os: osx
compiler: clang
env: OPTS="--disable-ssl"
+- os: linux-ppc64le
+  compiler: gcc
+  env: OPTS="--disable-ssl"
script: ./.travis/${TRAVIS_OS_NAME}-build.sh $OPTS
  diff --git a/.travis/linux-prepare.sh b/.travis/linux-prepare.sh
index e546d32cb..f3a9a6d44 100755
--- a/.travis/linux-prepare.sh
+++ b/.travis/linux-prepare.sh
@@ -15,8 +15,18 @@ cd ..
  pip install --disable-pip-version-check --user six flake8 hacking
  pip install --user --upgrade docutils

Re: [ovs-dev] [PATCH] ip_gre: Removed unused ipgre netdev ops

2019-11-01 Thread Gregory Rose 



On 11/1/2019 9:52 AM, Gregory Rose wrote:

    42a059e02bf3 ("ip_gre: Remove even more unused code")


That one should be fine.

Thanks,



Oh goodness, I meant this one should be fine.

adf9ac69aee1 ("ip_gre: Removed unused ipgre netdev ops")


- Greg

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

Re: [ovs-dev] [PATCH] ip_gre: Removed unused ipgre netdev ops

2019-11-01 Thread Gregory Rose 



On 11/1/2019 9:48 AM, Simon Horman wrote:

On Fri, Nov 01, 2019 at 09:39:29AM -0700, Gregory Rose wrote:

On 11/1/2019 9:36 AM, Simon Horman wrote:

On Fri, Nov 01, 2019 at 09:24:08AM -0700, Gregory Rose wrote:

On 11/1/2019 9:20 AM, Simon Horman wrote:

On Fri, Nov 01, 2019 at 09:02:43AM -0700, Gregory Rose wrote:

On 11/1/2019 8:48 AM, Gregory Rose wrote:

On 11/1/2019 7:50 AM, Simon Horman wrote:

On Thu, Oct 31, 2019 at 03:18:23PM -0700, Gregory Rose wrote:

On 10/31/2019 2:08 PM, Ben Pfaff wrote:

On Thu, Oct 31, 2019 at 01:30:39PM -0700, Greg Rose wrote:

When cleaning up unused ipgre code the ipgre_netdev_ops structure
was missed. Get rid of it now.

Fixes: d5822f428814 ("gre: Remove dead ipgre code")
Signed-off-by: Greg Rose 

Applied to master, thanks!

Oh, I guess you didn't see my request to hold off on this.  No worries.

I'll send a follow up patch with some more code to be excised.

And thanks for the quick response!

This appears to break travis-ci.

https://travis-ci.org/openvswitch/ovs/builds/605766351

OK, it passed here
https://travis-ci.org/gvrose8192/ovs-experimental/builds/605736578

Let me check what happened.

- Greg

So the patch that got applied yesterday is not the patch that I pushed to
test travis.  ipgre_tunnel_init and ipgre_xmit
also supposed to be deleted.  Let's revert the old patch and start over.  I
have no idea what happened.

Thanks Greg,

I'm running a revert by travis-ci here:

https://travis-ci.org/horms2/ovs/builds/606077577

Thanks!  I'm doing that also.  My apologies for the mix up.

Thanks, we can race them :)

Unfortunately I am still seeing a failure so perhaps the following also
needs to be reverted?

42a059e02bf3 ("ip_gre: Remove even more unused code")


That one should be fine.

Thanks,

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

Re: [ovs-dev] [PATCH v4 0/2] ALLOW Stateless NAT operations

2019-11-01 Thread Numan Siddique 
On Fri, Nov 1, 2019, 2:57 PM Numan Siddique  wrote:

> On Fri, Nov 1, 2019 at 6:58 AM Ankur Sharma 
> wrote:
> >
> > NAT implementation in OVN uses connection tracker to replace
> > source and dest ips. This implementation works fine and
> > is the right approach for cases where external ips are shared
> > (i.e. SNAT) or where we replace ip only when relevant flow is there
> > (i.e. DNAT).
> >
> > However, it opens the possibility of Dos Attack, where attacker
> > can easily simluate multiple 5 tuples, to consume the connection
> > tracker entry in an OVN chassis. This way they can easily attain
> > the CT limit, there by impacting the usage of it by other features
> > like valid NAT, ACL etc.
> >
> > This attack is even worse, when external ip is a public ip,
> > i.e internet routable ip.
> >
> > In this patch we are introducing an option with NAT table entry.
> > Option "stateless=true" indicates that NAT implmentation
> > should not be using CT, i.e it should not use ct_snat/dnat actions.
> >
> > Instead of ct_* actions, we will use ip4.src/dst OVN actions, which
> > will replace source and destination ips, while recalculating the
> > checksums.
> >
> > This option is applicable only for the NAT rules which can be
> > 1:1 mapped between inner and external ips, i.e dnat_and_snat rule.
> >
> > Signed-off-by: Ankur Sharma 
>
> Thanks.
>
> I applied this series to master.


Can you please submit a follow up patch to add a news entry ?

Numan


> Numan
>
> >
> > Ankur Sharma (2):
> >   OVN: ADD nbctl cli to mark a dnat_and_snat rule as stateless
> >   OVN: Use ip4.src and ip4.dst actions for NAT rules
> >
> >  northd/ovn-northd.8.xml   |  33 -
> >  northd/ovn-northd.c   |  84 +++--
> >  ovn-nb.ovsschema  |   6 +-
> >  ovn-nb.xml|   5 +
> >  tests/ovn-nbctl.at|  37 ++
> >  tests/ovn-northd.at   |  95 ++
> >  tests/ovn.at  | 311
> ++
> >  utilities/ovn-nbctl.8.xml |  12 +-
> >  utilities/ovn-nbctl.c |  30 -
> >  9 files changed, 594 insertions(+), 19 deletions(-)
> >
> > --
> > 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

Re: [ovs-dev] [PATCH] ip_gre: Removed unused ipgre netdev ops

2019-11-01 Thread Simon Horman 
On Fri, Nov 01, 2019 at 09:39:29AM -0700, Gregory Rose wrote:
> 
> On 11/1/2019 9:36 AM, Simon Horman wrote:
> > On Fri, Nov 01, 2019 at 09:24:08AM -0700, Gregory Rose wrote:
> > > On 11/1/2019 9:20 AM, Simon Horman wrote:
> > > > On Fri, Nov 01, 2019 at 09:02:43AM -0700, Gregory Rose wrote:
> > > > > On 11/1/2019 8:48 AM, Gregory Rose wrote:
> > > > > > On 11/1/2019 7:50 AM, Simon Horman wrote:
> > > > > > > On Thu, Oct 31, 2019 at 03:18:23PM -0700, Gregory Rose wrote:
> > > > > > > > On 10/31/2019 2:08 PM, Ben Pfaff wrote:
> > > > > > > > > On Thu, Oct 31, 2019 at 01:30:39PM -0700, Greg Rose wrote:
> > > > > > > > > > When cleaning up unused ipgre code the ipgre_netdev_ops 
> > > > > > > > > > structure
> > > > > > > > > > was missed. Get rid of it now.
> > > > > > > > > > 
> > > > > > > > > > Fixes: d5822f428814 ("gre: Remove dead ipgre code")
> > > > > > > > > > Signed-off-by: Greg Rose 
> > > > > > > > > Applied to master, thanks!
> > > > > > > > Oh, I guess you didn't see my request to hold off on this.  No 
> > > > > > > > worries.
> > > > > > > > 
> > > > > > > > I'll send a follow up patch with some more code to be excised.
> > > > > > > > 
> > > > > > > > And thanks for the quick response!
> > > > > > > This appears to break travis-ci.
> > > > > > > 
> > > > > > > https://travis-ci.org/openvswitch/ovs/builds/605766351
> > > > > > OK, it passed here
> > > > > > https://travis-ci.org/gvrose8192/ovs-experimental/builds/605736578
> > > > > > 
> > > > > > Let me check what happened.
> > > > > > 
> > > > > > - Greg
> > > > > So the patch that got applied yesterday is not the patch that I 
> > > > > pushed to
> > > > > test travis.  ipgre_tunnel_init and ipgre_xmit
> > > > > also supposed to be deleted.  Let's revert the old patch and start 
> > > > > over.  I
> > > > > have no idea what happened.
> > > > Thanks Greg,
> > > > 
> > > > I'm running a revert by travis-ci here:
> > > > 
> > > > https://travis-ci.org/horms2/ovs/builds/606077577
> > > Thanks!  I'm doing that also.  My apologies for the mix up.
> > Thanks, we can race them :)
> > 
> > Unfortunately I am still seeing a failure so perhaps the following also
> > needs to be reverted?
> > 
> > 42a059e02bf3 ("ip_gre: Remove even more unused code")
> 
> Yes, that is the patch that needs reverting.  I sent the revert patch
> already, as soon as my travis build passes
> then we should apply it but I'm sure that's the one.
> 
> Which patch did you revert?

adf9ac69aee1 ("ip_gre: Removed unused ipgre netdev ops")

> >  From a process PoV I think it would be best if you posted
> > a revert patch(es) that someone can apply. Does that work for you?
> 
> Yes, agreed.
> 
> Thanks,
> 
> - Greg
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ip_gre: Removed unused ipgre netdev ops

2019-11-01 Thread Gregory Rose 


On 11/1/2019 9:36 AM, Simon Horman wrote:

On Fri, Nov 01, 2019 at 09:24:08AM -0700, Gregory Rose wrote:

On 11/1/2019 9:20 AM, Simon Horman wrote:

On Fri, Nov 01, 2019 at 09:02:43AM -0700, Gregory Rose wrote:

On 11/1/2019 8:48 AM, Gregory Rose wrote:

On 11/1/2019 7:50 AM, Simon Horman wrote:

On Thu, Oct 31, 2019 at 03:18:23PM -0700, Gregory Rose wrote:

On 10/31/2019 2:08 PM, Ben Pfaff wrote:

On Thu, Oct 31, 2019 at 01:30:39PM -0700, Greg Rose wrote:

When cleaning up unused ipgre code the ipgre_netdev_ops structure
was missed. Get rid of it now.

Fixes: d5822f428814 ("gre: Remove dead ipgre code")
Signed-off-by: Greg Rose 

Applied to master, thanks!

Oh, I guess you didn't see my request to hold off on this.  No worries.

I'll send a follow up patch with some more code to be excised.

And thanks for the quick response!

This appears to break travis-ci.

https://travis-ci.org/openvswitch/ovs/builds/605766351

OK, it passed here
https://travis-ci.org/gvrose8192/ovs-experimental/builds/605736578

Let me check what happened.

- Greg

So the patch that got applied yesterday is not the patch that I pushed to
test travis.  ipgre_tunnel_init and ipgre_xmit
also supposed to be deleted.  Let's revert the old patch and start over.  I
have no idea what happened.

Thanks Greg,

I'm running a revert by travis-ci here:

https://travis-ci.org/horms2/ovs/builds/606077577

Thanks!  I'm doing that also.  My apologies for the mix up.

Thanks, we can race them :)

Unfortunately I am still seeing a failure so perhaps the following also
needs to be reverted?

42a059e02bf3 ("ip_gre: Remove even more unused code")


Yes, that is the patch that needs reverting.  I sent the revert patch 
already, as soon as my travis build passes

then we should apply it but I'm sure that's the one.

Which patch did you revert?



 From a process PoV I think it would be best if you posted
a revert patch(es) that someone can apply. Does that work for you?


Yes, agreed.

Thanks,

- Greg

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

Re: [ovs-dev] [PATCH] ip_gre: Removed unused ipgre netdev ops

2019-11-01 Thread Simon Horman 
On Fri, Nov 01, 2019 at 09:24:08AM -0700, Gregory Rose wrote:
> 
> On 11/1/2019 9:20 AM, Simon Horman wrote:
> > On Fri, Nov 01, 2019 at 09:02:43AM -0700, Gregory Rose wrote:
> > > On 11/1/2019 8:48 AM, Gregory Rose wrote:
> > > > On 11/1/2019 7:50 AM, Simon Horman wrote:
> > > > > On Thu, Oct 31, 2019 at 03:18:23PM -0700, Gregory Rose wrote:
> > > > > > On 10/31/2019 2:08 PM, Ben Pfaff wrote:
> > > > > > > On Thu, Oct 31, 2019 at 01:30:39PM -0700, Greg Rose wrote:
> > > > > > > > When cleaning up unused ipgre code the ipgre_netdev_ops 
> > > > > > > > structure
> > > > > > > > was missed. Get rid of it now.
> > > > > > > > 
> > > > > > > > Fixes: d5822f428814 ("gre: Remove dead ipgre code")
> > > > > > > > Signed-off-by: Greg Rose 
> > > > > > > Applied to master, thanks!
> > > > > > Oh, I guess you didn't see my request to hold off on this.  No 
> > > > > > worries.
> > > > > > 
> > > > > > I'll send a follow up patch with some more code to be excised.
> > > > > > 
> > > > > > And thanks for the quick response!
> > > > > This appears to break travis-ci.
> > > > > 
> > > > > https://travis-ci.org/openvswitch/ovs/builds/605766351
> > > > OK, it passed here
> > > > https://travis-ci.org/gvrose8192/ovs-experimental/builds/605736578
> > > > 
> > > > Let me check what happened.
> > > > 
> > > > - Greg
> > > So the patch that got applied yesterday is not the patch that I pushed to
> > > test travis.  ipgre_tunnel_init and ipgre_xmit
> > > also supposed to be deleted.  Let's revert the old patch and start over.  
> > > I
> > > have no idea what happened.
> > Thanks Greg,
> > 
> > I'm running a revert by travis-ci here:
> > 
> > https://travis-ci.org/horms2/ovs/builds/606077577
> Thanks!  I'm doing that also.  My apologies for the mix up.

Thanks, we can race them :)

Unfortunately I am still seeing a failure so perhaps the following also
needs to be reverted?

42a059e02bf3 ("ip_gre: Remove even more unused code")

From a process PoV I think it would be best if you posted
a revert patch(es) that someone can apply. Does that work for you?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ip_gre: Removed unused ipgre netdev ops

2019-11-01 Thread Gregory Rose 


On 11/1/2019 9:20 AM, Simon Horman wrote:

On Fri, Nov 01, 2019 at 09:02:43AM -0700, Gregory Rose wrote:

On 11/1/2019 8:48 AM, Gregory Rose wrote:

On 11/1/2019 7:50 AM, Simon Horman wrote:

On Thu, Oct 31, 2019 at 03:18:23PM -0700, Gregory Rose wrote:

On 10/31/2019 2:08 PM, Ben Pfaff wrote:

On Thu, Oct 31, 2019 at 01:30:39PM -0700, Greg Rose wrote:

When cleaning up unused ipgre code the ipgre_netdev_ops structure
was missed. Get rid of it now.

Fixes: d5822f428814 ("gre: Remove dead ipgre code")
Signed-off-by: Greg Rose 

Applied to master, thanks!

Oh, I guess you didn't see my request to hold off on this.  No worries.

I'll send a follow up patch with some more code to be excised.

And thanks for the quick response!

This appears to break travis-ci.

https://travis-ci.org/openvswitch/ovs/builds/605766351

OK, it passed here
https://travis-ci.org/gvrose8192/ovs-experimental/builds/605736578

Let me check what happened.

- Greg

So the patch that got applied yesterday is not the patch that I pushed to
test travis.  ipgre_tunnel_init and ipgre_xmit
also supposed to be deleted.  Let's revert the old patch and start over.  I
have no idea what happened.

Thanks Greg,

I'm running a revert by travis-ci here:

https://travis-ci.org/horms2/ovs/builds/606077577

Thanks!  I'm doing that also.  My apologies for the mix up.

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

Re: [ovs-dev] [PATCH] ip_gre: Removed unused ipgre netdev ops

2019-11-01 Thread Simon Horman 
On Fri, Nov 01, 2019 at 09:02:43AM -0700, Gregory Rose wrote:
> 
> On 11/1/2019 8:48 AM, Gregory Rose wrote:
> > 
> > On 11/1/2019 7:50 AM, Simon Horman wrote:
> > > On Thu, Oct 31, 2019 at 03:18:23PM -0700, Gregory Rose wrote:
> > > > On 10/31/2019 2:08 PM, Ben Pfaff wrote:
> > > > > On Thu, Oct 31, 2019 at 01:30:39PM -0700, Greg Rose wrote:
> > > > > > When cleaning up unused ipgre code the ipgre_netdev_ops structure
> > > > > > was missed. Get rid of it now.
> > > > > > 
> > > > > > Fixes: d5822f428814 ("gre: Remove dead ipgre code")
> > > > > > Signed-off-by: Greg Rose 
> > > > > Applied to master, thanks!
> > > > Oh, I guess you didn't see my request to hold off on this.  No worries.
> > > > 
> > > > I'll send a follow up patch with some more code to be excised.
> > > > 
> > > > And thanks for the quick response!
> > > This appears to break travis-ci.
> > > 
> > > https://travis-ci.org/openvswitch/ovs/builds/605766351
> > 
> > OK, it passed here
> > https://travis-ci.org/gvrose8192/ovs-experimental/builds/605736578
> > 
> > Let me check what happened.
> > 
> > - Greg
> 
> So the patch that got applied yesterday is not the patch that I pushed to
> test travis.  ipgre_tunnel_init and ipgre_xmit
> also supposed to be deleted.  Let's revert the old patch and start over.  I
> have no idea what happened.

Thanks Greg,

I'm running a revert by travis-ci here:

https://travis-ci.org/horms2/ovs/builds/606077577
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] Revert "ip_gre: Remove even more unused code"

2019-11-01 Thread Greg Rose 
This reverts commit 42a059e02bf343787951be2824c579e1c9a26e12.

Not all the necessary ipgre prefixed code was removed that
should have been.  Another patch will follow with the correct
removed code.

Signed-off-by: Greg Rose 
---
 datapath/linux/compat/ip_gre.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/datapath/linux/compat/ip_gre.c b/datapath/linux/compat/ip_gre.c
index 8536241..3b7e607 100644
--- a/datapath/linux/compat/ip_gre.c
+++ b/datapath/linux/compat/ip_gre.c
@@ -922,6 +922,44 @@ static int erspan_tunnel_init(struct net_device *dev)
return ip_tunnel_init(dev);
 }
 
+static int ipgre_header(struct sk_buff *skb, struct net_device *dev,
+   unsigned short type,
+   const void *daddr, const void *saddr, unsigned int len)
+{
+   struct ip_tunnel *t = netdev_priv(dev);
+   struct iphdr *iph;
+   struct gre_base_hdr *greh;
+
+   iph = (struct iphdr *)__skb_push(skb, t->hlen + sizeof(*iph));
+   greh = (struct gre_base_hdr *)(iph+1);
+   greh->flags = gre_tnl_flags_to_gre_flags(t->parms.o_flags);
+   greh->protocol = htons(type);
+
+   memcpy(iph, >parms.iph, sizeof(struct iphdr));
+
+   /* Set the source hardware address. */
+   if (saddr)
+   memcpy(>saddr, saddr, 4);
+   if (daddr)
+   memcpy(>daddr, daddr, 4);
+   if (iph->daddr)
+   return t->hlen + sizeof(*iph);
+
+   return -(t->hlen + sizeof(*iph));
+}
+
+static int ipgre_header_parse(const struct sk_buff *skb, unsigned char *haddr)
+{
+   const struct iphdr *iph = (const struct iphdr *) skb_mac_header(skb);
+   memcpy(haddr, >saddr, 4);
+   return 4;
+}
+
+static const struct header_ops ipgre_header_ops = {
+   .create = ipgre_header,
+   .parse  = ipgre_header_parse,
+};
+
 static int ipgre_tunnel_init(struct net_device *dev)
 {
struct ip_tunnel *tunnel = netdev_priv(dev);
-- 
1.8.3.1

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

Re: [ovs-dev] [PATCH] ip_gre: Remove even more unused code

2019-11-01 Thread Gregory Rose 



On 11/1/2019 1:27 AM, Ilya Maximets wrote:

On 31.10.2019 23:46, Greg Rose wrote:

There is a confusing mix of ipgre and gretap functions with some
needed for gretap still having ipgre_ prefixes.  This time though
I think I got the rest of the unused ipgre code.

Fixes: d5822f428814 ("gre: Remove dead ipgre code")
Signed-off-by: Greg Rose 
---
  datapath/linux/compat/ip_gre.c | 38 
--

  1 file changed, 38 deletions(-)


Hi.

This broke build with kernel 4.15.18:
https://travis-ci.org/openvswitch/ovs/jobs/605766364

datapath/linux/ip_gre.c: In function ‘ipgre_tunnel_init’:
datapath/linux/ip_gre.c:940:22: error: ‘ipgre_header_ops’ undeclared 
(first use in this function)

   dev->header_ops = _header_ops;
  ^
datapath/linux/ip_gre.c:940:22: note: each undeclared identifier is 
reported only once for each function it appears in

datapath/linux/ip_gre.c: At top level:
datapath/linux/ip_gre.c:925:12: warning: ‘ipgre_tunnel_init’ defined 
but not used [-Wunused-function]

 static int ipgre_tunnel_init(struct net_device *dev)
    ^
datapath/linux/ip_gre.c:946:20: warning: ‘ipgre_xmit’ defined but not 
used [-Wunused-function]

 static netdev_tx_t ipgre_xmit(struct sk_buff *skb,
    ^

Best regards, Ilya Maximets.


Thanks Ilya, I'm working on fixing it.  I must have pushed a 'between' 
patch in my own travis test.


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

Re: [ovs-dev] [PATCH] ip_gre: Removed unused ipgre netdev ops

2019-11-01 Thread Gregory Rose 


On 11/1/2019 8:48 AM, Gregory Rose wrote:


On 11/1/2019 7:50 AM, Simon Horman wrote:

On Thu, Oct 31, 2019 at 03:18:23PM -0700, Gregory Rose wrote:

On 10/31/2019 2:08 PM, Ben Pfaff wrote:

On Thu, Oct 31, 2019 at 01:30:39PM -0700, Greg Rose wrote:

When cleaning up unused ipgre code the ipgre_netdev_ops structure
was missed. Get rid of it now.

Fixes: d5822f428814 ("gre: Remove dead ipgre code")
Signed-off-by: Greg Rose 

Applied to master, thanks!

Oh, I guess you didn't see my request to hold off on this.  No worries.

I'll send a follow up patch with some more code to be excised.

And thanks for the quick response!

This appears to break travis-ci.

https://travis-ci.org/openvswitch/ovs/builds/605766351


OK, it passed here
https://travis-ci.org/gvrose8192/ovs-experimental/builds/605736578

Let me check what happened.

- Greg


So the patch that got applied yesterday is not the patch that I pushed 
to test travis.  ipgre_tunnel_init and ipgre_xmit
also supposed to be deleted.  Let's revert the old patch and start 
over.  I have no idea what happened.


- Greg

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

Re: [ovs-dev] [PATCH] ip_gre: Removed unused ipgre netdev ops

2019-11-01 Thread Gregory Rose 


On 11/1/2019 7:50 AM, Simon Horman wrote:

On Thu, Oct 31, 2019 at 03:18:23PM -0700, Gregory Rose wrote:

On 10/31/2019 2:08 PM, Ben Pfaff wrote:

On Thu, Oct 31, 2019 at 01:30:39PM -0700, Greg Rose wrote:

When cleaning up unused ipgre code the ipgre_netdev_ops structure
was missed. Get rid of it now.

Fixes: d5822f428814 ("gre: Remove dead ipgre code")
Signed-off-by: Greg Rose 

Applied to master, thanks!

Oh, I guess you didn't see my request to hold off on this.  No worries.

I'll send a follow up patch with some more code to be excised.

And thanks for the quick response!

This appears to break travis-ci.

https://travis-ci.org/openvswitch/ovs/builds/605766351


OK, it passed here:

https://travis-ci.org/gvrose8192/ovs-experimental/builds/605736578

Let me check what happened.

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

Re: [ovs-dev] [PATCH] lib/tc: Fix flow dump for tunnel id equal zero

2019-11-01 Thread Simon Horman 
On Wed, Oct 30, 2019 at 02:40:35PM +0200, Roi Dayan wrote:
> From: Dmytro Linkin 
> 
> Tunnel id 0 is not printed unless tunnel flag FLOW_TNL_F_KEY is set.
> Fix that by always setting FLOW_TNL_F_KEY when tunnel id is valid.
> 
> Fixes: 0227bf092ee6 ("lib/tc: Support optional tunnel id")
> Signed-off-by: Dmytro Linkin 
> Reviewed-by: Roi Dayan 

Hi Roi,

this looks fine to me but I am holding off on pushing it
until master passes travis-ci again.

It also seems to backport cleanly to branch-2.11 and I plan
to apply it there too.

If it is suitable for older branches could you please post a
backport/backports?

Thanks

> ---
>  lib/netdev-offload-tc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
> index f6d1abb2e695..502e73ad5332 100644
> --- a/lib/netdev-offload-tc.c
> +++ b/lib/netdev-offload-tc.c
> @@ -600,6 +600,7 @@ parse_tc_flower_to_match(struct tc_flower *flower,
>  if (flower->tunnel) {
>  if (flower->mask.tunnel.id) {
>  match_set_tun_id(match, flower->key.tunnel.id);
> +match->flow.tunnel.flags |= FLOW_TNL_F_KEY;
>  }
>  if (flower->key.tunnel.ipv4.ipv4_dst) {
>  match_set_tun_src(match, flower->key.tunnel.ipv4.ipv4_src);
> -- 
> 2.8.4
> 
> ___
> 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] ip_gre: Removed unused ipgre netdev ops

2019-11-01 Thread Simon Horman 
On Thu, Oct 31, 2019 at 03:18:23PM -0700, Gregory Rose wrote:
> 
> On 10/31/2019 2:08 PM, Ben Pfaff wrote:
> > On Thu, Oct 31, 2019 at 01:30:39PM -0700, Greg Rose wrote:
> > > When cleaning up unused ipgre code the ipgre_netdev_ops structure
> > > was missed. Get rid of it now.
> > > 
> > > Fixes: d5822f428814 ("gre: Remove dead ipgre code")
> > > Signed-off-by: Greg Rose 
> > Applied to master, thanks!
> 
> Oh, I guess you didn't see my request to hold off on this.  No worries.
> 
> I'll send a follow up patch with some more code to be excised.
> 
> And thanks for the quick response!

This appears to break travis-ci.

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

[ovs-dev] [PATCH net-next v6 10/10] net: openvswitch: simplify the ovs_dp_cmd_new

2019-11-01 Thread xiangxia . m . yue 
From: Tonghao Zhang 

use the specified functions to init resource.

Signed-off-by: Tonghao Zhang 
Tested-by: Greg Rose 
---
 net/openvswitch/datapath.c | 60 +-
 1 file changed, 38 insertions(+), 22 deletions(-)

diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index aeb76e4..4d48e48 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -1576,6 +1576,31 @@ static int ovs_dp_change(struct datapath *dp, struct 
nlattr *a[])
return 0;
 }
 
+static int ovs_dp_stats_init(struct datapath *dp)
+{
+   dp->stats_percpu = netdev_alloc_pcpu_stats(struct dp_stats_percpu);
+   if (!dp->stats_percpu)
+   return -ENOMEM;
+
+   return 0;
+}
+
+static int ovs_dp_vport_init(struct datapath *dp)
+{
+   int i;
+
+   dp->ports = kmalloc_array(DP_VPORT_HASH_BUCKETS,
+ sizeof(struct hlist_head),
+ GFP_KERNEL);
+   if (!dp->ports)
+   return -ENOMEM;
+
+   for (i = 0; i < DP_VPORT_HASH_BUCKETS; i++)
+   INIT_HLIST_HEAD(>ports[i]);
+
+   return 0;
+}
+
 static int ovs_dp_cmd_new(struct sk_buff *skb, struct genl_info *info)
 {
struct nlattr **a = info->attrs;
@@ -1584,7 +1609,7 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct 
genl_info *info)
struct datapath *dp;
struct vport *vport;
struct ovs_net *ovs_net;
-   int err, i;
+   int err;
 
err = -EINVAL;
if (!a[OVS_DP_ATTR_NAME] || !a[OVS_DP_ATTR_UPCALL_PID])
@@ -1597,35 +1622,26 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct 
genl_info *info)
err = -ENOMEM;
dp = kzalloc(sizeof(*dp), GFP_KERNEL);
if (dp == NULL)
-   goto err_free_reply;
+   goto err_destroy_reply;
 
ovs_dp_set_net(dp, sock_net(skb->sk));
 
/* Allocate table. */
err = ovs_flow_tbl_init(>table);
if (err)
-   goto err_free_dp;
+   goto err_destroy_dp;
 
-   dp->stats_percpu = netdev_alloc_pcpu_stats(struct dp_stats_percpu);
-   if (!dp->stats_percpu) {
-   err = -ENOMEM;
+   err = ovs_dp_stats_init(dp);
+   if (err)
goto err_destroy_table;
-   }
 
-   dp->ports = kmalloc_array(DP_VPORT_HASH_BUCKETS,
- sizeof(struct hlist_head),
- GFP_KERNEL);
-   if (!dp->ports) {
-   err = -ENOMEM;
-   goto err_destroy_percpu;
-   }
-
-   for (i = 0; i < DP_VPORT_HASH_BUCKETS; i++)
-   INIT_HLIST_HEAD(>ports[i]);
+   err = ovs_dp_vport_init(dp);
+   if (err)
+   goto err_destroy_stats;
 
err = ovs_meters_init(dp);
if (err)
-   goto err_destroy_ports_array;
+   goto err_destroy_ports;
 
/* Set up our datapath device. */
parms.name = nla_data(a[OVS_DP_ATTR_NAME]);
@@ -1675,15 +1691,15 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct 
genl_info *info)
 
 err_destroy_meters:
ovs_meters_exit(dp);
-err_destroy_ports_array:
+err_destroy_ports:
kfree(dp->ports);
-err_destroy_percpu:
+err_destroy_stats:
free_percpu(dp->stats_percpu);
 err_destroy_table:
ovs_flow_tbl_destroy(>table);
-err_free_dp:
+err_destroy_dp:
kfree(dp);
-err_free_reply:
+err_destroy_reply:
kfree_skb(reply);
 err:
return err;
-- 
1.8.3.1

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

[ovs-dev] [PATCH net-next v6 09/10] net: openvswitch: don't unlock mutex when changing the user_features fails

2019-11-01 Thread xiangxia . m . yue 
From: Tonghao Zhang 

Unlocking of a not locked mutex is not allowed.
Other kernel thread may be in critical section while
we unlock it because of setting user_feature fail.

Fixes: 95a7233c4 ("net: openvswitch: Set OvS recirc_id from tc chain index")
Cc: Paul Blakey 
Signed-off-by: Tonghao Zhang 
Tested-by: Greg Rose 
Acked-by: William Tu 
---
 net/openvswitch/datapath.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 9fea7e1..aeb76e4 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -1657,6 +1657,7 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct 
genl_info *info)
ovs_dp_reset_user_features(skb, info);
}
 
+   ovs_unlock();
goto err_destroy_meters;
}
 
@@ -1673,7 +1674,6 @@ static int ovs_dp_cmd_new(struct sk_buff *skb, struct 
genl_info *info)
return 0;
 
 err_destroy_meters:
-   ovs_unlock();
ovs_meters_exit(dp);
 err_destroy_ports_array:
kfree(dp->ports);
-- 
1.8.3.1

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

[ovs-dev] [PATCH net-next v6 08/10] net: openvswitch: fix possible memleak on destroy flow-table

2019-11-01 Thread xiangxia . m . yue 
From: Tonghao Zhang 

When we destroy the flow tables which may contain the flow_mask,
so release the flow mask struct.

Signed-off-by: Tonghao Zhang 
Tested-by: Greg Rose 
---
 net/openvswitch/flow_table.c | 186 +++
 1 file changed, 98 insertions(+), 88 deletions(-)

diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 9f5a06e..5904e93 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -210,6 +210,74 @@ static int tbl_mask_array_realloc(struct flow_table *tbl, 
int size)
return 0;
 }
 
+static int tbl_mask_array_add_mask(struct flow_table *tbl,
+  struct sw_flow_mask *new)
+{
+   struct mask_array *ma = ovsl_dereference(tbl->mask_array);
+   int err, ma_count = READ_ONCE(ma->count);
+
+   if (ma_count >= ma->max) {
+   err = tbl_mask_array_realloc(tbl, ma->max +
+ MASK_ARRAY_SIZE_MIN);
+   if (err)
+   return err;
+
+   ma = ovsl_dereference(tbl->mask_array);
+   }
+
+   BUG_ON(ovsl_dereference(ma->masks[ma_count]));
+
+   rcu_assign_pointer(ma->masks[ma_count], new);
+   WRITE_ONCE(ma->count, ma_count +1);
+
+   return 0;
+}
+
+static void tbl_mask_array_del_mask(struct flow_table *tbl,
+   struct sw_flow_mask *mask)
+{
+   struct mask_array *ma = ovsl_dereference(tbl->mask_array);
+   int i, ma_count = READ_ONCE(ma->count);
+
+   /* Remove the deleted mask pointers from the array */
+   for (i = 0; i < ma_count; i++) {
+   if (mask == ovsl_dereference(ma->masks[i]))
+   goto found;
+   }
+
+   BUG();
+   return;
+
+found:
+   WRITE_ONCE(ma->count, ma_count -1);
+
+   rcu_assign_pointer(ma->masks[i], ma->masks[ma_count -1]);
+   RCU_INIT_POINTER(ma->masks[ma_count -1], NULL);
+
+   kfree_rcu(mask, rcu);
+
+   /* Shrink the mask array if necessary. */
+   if (ma->max >= (MASK_ARRAY_SIZE_MIN * 2) &&
+   ma_count <= (ma->max / 3))
+   tbl_mask_array_realloc(tbl, ma->max / 2);
+}
+
+/* Remove 'mask' from the mask list, if it is not needed any more. */
+static void flow_mask_remove(struct flow_table *tbl, struct sw_flow_mask *mask)
+{
+   if (mask) {
+   /* ovs-lock is required to protect mask-refcount and
+* mask list.
+*/
+   ASSERT_OVSL();
+   BUG_ON(!mask->ref_count);
+   mask->ref_count--;
+
+   if (!mask->ref_count)
+   tbl_mask_array_del_mask(tbl, mask);
+   }
+}
+
 int ovs_flow_tbl_init(struct flow_table *table)
 {
struct table_instance *ti, *ufid_ti;
@@ -257,7 +325,28 @@ static void flow_tbl_destroy_rcu_cb(struct rcu_head *rcu)
__table_instance_destroy(ti);
 }
 
-static void table_instance_destroy(struct table_instance *ti,
+static void table_instance_flow_free(struct flow_table *table,
+ struct table_instance *ti,
+ struct table_instance *ufid_ti,
+ struct sw_flow *flow,
+ bool count)
+{
+   hlist_del_rcu(>flow_table.node[ti->node_ver]);
+   if (count)
+   table->count--;
+
+   if (ovs_identifier_is_ufid(>id)) {
+   hlist_del_rcu(>ufid_table.node[ufid_ti->node_ver]);
+
+   if (count)
+   table->ufid_count--;
+   }
+
+   flow_mask_remove(table, flow->mask);
+}
+
+static void table_instance_destroy(struct flow_table *table,
+  struct table_instance *ti,
   struct table_instance *ufid_ti,
   bool deferred)
 {
@@ -274,13 +363,12 @@ static void table_instance_destroy(struct table_instance 
*ti,
struct sw_flow *flow;
struct hlist_head *head = >buckets[i];
struct hlist_node *n;
-   int ver = ti->node_ver;
-   int ufid_ver = ufid_ti->node_ver;
 
-   hlist_for_each_entry_safe(flow, n, head, flow_table.node[ver]) {
-   hlist_del_rcu(>flow_table.node[ver]);
-   if (ovs_identifier_is_ufid(>id))
-   hlist_del_rcu(>ufid_table.node[ufid_ver]);
+   hlist_for_each_entry_safe(flow, n, head,
+ flow_table.node[ti->node_ver]) {
+
+   table_instance_flow_free(table, ti, ufid_ti,
+flow, false);
ovs_flow_free(flow, deferred);
}
}
@@ -305,7 +393,7 @@ void ovs_flow_tbl_destroy(struct flow_table *table)
 
free_percpu(table->mask_cache);

[ovs-dev] [PATCH net-next v6 06/10] net: openvswitch: simplify the flow_hash

2019-11-01 Thread xiangxia . m . yue 
From: Tonghao Zhang 

Simplify the code and remove the unnecessary BUILD_BUG_ON.

Signed-off-by: Tonghao Zhang 
Tested-by: Greg Rose 
Acked-by: William Tu 
---
 net/openvswitch/flow_table.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index a10d421..96757e2 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -432,13 +432,10 @@ int ovs_flow_tbl_flush(struct flow_table *flow_table)
 static u32 flow_hash(const struct sw_flow_key *key,
 const struct sw_flow_key_range *range)
 {
-   int key_start = range->start;
-   int key_end = range->end;
-   const u32 *hash_key = (const u32 *)((const u8 *)key + key_start);
-   int hash_u32s = (key_end - key_start) >> 2;
+   const u32 *hash_key = (const u32 *)((const u8 *)key + range->start);
 
/* Make sure number of hash bytes are multiple of u32. */
-   BUILD_BUG_ON(sizeof(long) % sizeof(u32));
+   int hash_u32s = range_n_bytes(range) >> 2;
 
return jhash2(hash_key, hash_u32s, 0);
 }
-- 
1.8.3.1

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

[ovs-dev] [PATCH net-next v6 07/10] net: openvswitch: add likely in flow_lookup

2019-11-01 Thread xiangxia . m . yue 
From: Tonghao Zhang 

The most case *index < ma->max, and flow-mask is not NULL.
We add un/likely for performance.

Signed-off-by: Tonghao Zhang 
Tested-by: Greg Rose 
Acked-by: William Tu 
---
 net/openvswitch/flow_table.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 96757e2..9f5a06e 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -519,7 +519,7 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
struct sw_flow_mask *mask;
int i;
 
-   if (*index < ma->max) {
+   if (likely(*index < ma->max)) {
mask = rcu_dereference_ovsl(ma->masks[*index]);
if (mask) {
flow = masked_flow_lookup(ti, key, mask, n_mask_hit);
@@ -534,7 +534,7 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
continue;
 
mask = rcu_dereference_ovsl(ma->masks[i]);
-   if (!mask)
+   if (unlikely(!mask))
break;
 
flow = masked_flow_lookup(ti, key, mask, n_mask_hit);
-- 
1.8.3.1

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

[ovs-dev] [PATCH net-next v6 05/10] net: openvswitch: optimize flow-mask looking up

2019-11-01 Thread xiangxia . m . yue 
From: Tonghao Zhang 

The full looking up on flow table traverses all mask array.
If mask-array is too large, the number of invalid flow-mask
increase, performance will be drop.

One bad case, for example: M means flow-mask is valid and NULL
of flow-mask means deleted.

+---+
| M | NULL | ...  | NULL | M|
+---+

In that case, without this patch, openvswitch will traverses all
mask array, because there will be one flow-mask in the tail. This
patch changes the way of flow-mask inserting and deleting, and the
mask array will be keep as below: there is not a NULL hole. In the
fast path, we can "break" "for" (not "continue") in flow_lookup
when we get a NULL flow-mask.

 "break"
v
+---+
| M | M |  NULL |...   | NULL | NULL|
+---+

This patch don't optimize slow or control path, still using ma->max
to traverse. Slow path:
* tbl_mask_array_realloc
* ovs_flow_tbl_lookup_exact
* flow_mask_find

Signed-off-by: Tonghao Zhang 
Tested-by: Greg Rose 
---
 net/openvswitch/flow_table.c | 104 ++-
 1 file changed, 53 insertions(+), 51 deletions(-)

diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index c7ba435..a10d421 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -518,8 +518,8 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
   u32 *n_mask_hit,
   u32 *index)
 {
-   struct sw_flow_mask *mask;
struct sw_flow *flow;
+   struct sw_flow_mask *mask;
int i;
 
if (*index < ma->max) {
@@ -538,7 +538,7 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
 
mask = rcu_dereference_ovsl(ma->masks[i]);
if (!mask)
-   continue;
+   break;
 
flow = masked_flow_lookup(ti, key, mask, n_mask_hit);
if (flow) { /* Found */
@@ -695,8 +695,7 @@ struct sw_flow *ovs_flow_tbl_lookup_ufid(struct flow_table 
*tbl,
 int ovs_flow_tbl_num_masks(const struct flow_table *table)
 {
struct mask_array *ma = rcu_dereference_ovsl(table->mask_array);
-
-   return ma->count;
+   return READ_ONCE(ma->count);
 }
 
 static struct table_instance *table_instance_expand(struct table_instance *ti,
@@ -705,21 +704,33 @@ static struct table_instance 
*table_instance_expand(struct table_instance *ti,
return table_instance_rehash(ti, ti->n_buckets * 2, ufid);
 }
 
-static void tbl_mask_array_delete_mask(struct mask_array *ma,
-  struct sw_flow_mask *mask)
+static void tbl_mask_array_del_mask(struct flow_table *tbl,
+   struct sw_flow_mask *mask)
 {
-   int i;
+   struct mask_array *ma = ovsl_dereference(tbl->mask_array);
+   int i, ma_count = READ_ONCE(ma->count);
 
/* Remove the deleted mask pointers from the array */
-   for (i = 0; i < ma->max; i++) {
-   if (mask == ovsl_dereference(ma->masks[i])) {
-   RCU_INIT_POINTER(ma->masks[i], NULL);
-   ma->count--;
-   kfree_rcu(mask, rcu);
-   return;
-   }
+   for (i = 0; i < ma_count; i++) {
+   if (mask == ovsl_dereference(ma->masks[i]))
+   goto found;
}
+
BUG();
+   return;
+
+found:
+   WRITE_ONCE(ma->count, ma_count -1);
+
+   rcu_assign_pointer(ma->masks[i], ma->masks[ma_count -1]);
+   RCU_INIT_POINTER(ma->masks[ma_count -1], NULL);
+
+   kfree_rcu(mask, rcu);
+
+   /* Shrink the mask array if necessary. */
+   if (ma->max >= (MASK_ARRAY_SIZE_MIN * 2) &&
+   ma_count <= (ma->max / 3))
+   tbl_mask_array_realloc(tbl, ma->max / 2);
 }
 
 /* Remove 'mask' from the mask list, if it is not needed any more. */
@@ -733,17 +744,8 @@ static void flow_mask_remove(struct flow_table *tbl, 
struct sw_flow_mask *mask)
BUG_ON(!mask->ref_count);
mask->ref_count--;
 
-   if (!mask->ref_count) {
-   struct mask_array *ma;
-
-   ma = ovsl_dereference(tbl->mask_array);
-   tbl_mask_array_delete_mask(ma, mask);
-
-   /* Shrink the mask array if necessary. */
-   if (ma->max >= (MASK_ARRAY_SIZE_MIN * 2) &&
-   ma->count <= (ma->max / 3))
-   tbl_mask_array_realloc(tbl, ma->max / 2);
-   }
+   if (!mask->ref_count)
+   tbl_mask_array_del_mask(tbl, mask);
}
 }
 
@@ -807,6 +809,29 @@ static struct sw_flow_mask *flow_mask_find(const struct 
flow_table *tbl,

[ovs-dev] [PATCH net-next v6 04/10] net: openvswitch: optimize flow mask cache hash collision

2019-11-01 Thread xiangxia . m . yue 
From: Tonghao Zhang 

Port the codes to linux upstream and with little changes.

Pravin B Shelar, says:
| In case hash collision on mask cache, OVS does extra flow
| lookup. Following patch avoid it.

Link: 
https://github.com/openvswitch/ovs/commit/0e6efbe2712da03522532dc5e84806a96f6a0dd1
Signed-off-by: Tonghao Zhang 
Tested-by: Greg Rose 
---
 net/openvswitch/flow_table.c | 95 
 1 file changed, 53 insertions(+), 42 deletions(-)

diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 0c0fcd6..c7ba435 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -508,6 +508,9 @@ static struct sw_flow *masked_flow_lookup(struct 
table_instance *ti,
return NULL;
 }
 
+/* Flow lookup does full lookup on flow table. It starts with
+ * mask from index passed in *index.
+ */
 static struct sw_flow *flow_lookup(struct flow_table *tbl,
   struct table_instance *ti,
   struct mask_array *ma,
@@ -515,19 +518,32 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
   u32 *n_mask_hit,
   u32 *index)
 {
+   struct sw_flow_mask *mask;
struct sw_flow *flow;
int i;
 
-   for (i = 0; i < ma->max; i++)  {
-   struct sw_flow_mask *mask;
-
-   mask = rcu_dereference_ovsl(ma->masks[i]);
+   if (*index < ma->max) {
+   mask = rcu_dereference_ovsl(ma->masks[*index]);
if (mask) {
flow = masked_flow_lookup(ti, key, mask, n_mask_hit);
-   if (flow) { /* Found */
-   *index = i;
+   if (flow)
return flow;
-   }
+   }
+   }
+
+   for (i = 0; i < ma->max; i++)  {
+
+   if (i == *index)
+   continue;
+
+   mask = rcu_dereference_ovsl(ma->masks[i]);
+   if (!mask)
+   continue;
+
+   flow = masked_flow_lookup(ti, key, mask, n_mask_hit);
+   if (flow) { /* Found */
+   *index = i;
+   return flow;
}
}
 
@@ -546,58 +562,54 @@ struct sw_flow *ovs_flow_tbl_lookup_stats(struct 
flow_table *tbl,
  u32 skb_hash,
  u32 *n_mask_hit)
 {
-   struct mask_array *ma = rcu_dereference_ovsl(tbl->mask_array);
-   struct table_instance *ti = rcu_dereference_ovsl(tbl->ti);
-   struct mask_cache_entry  *entries, *ce, *del;
+   struct mask_array *ma = rcu_dereference(tbl->mask_array);
+   struct table_instance *ti = rcu_dereference(tbl->ti);
+   struct mask_cache_entry *entries, *ce;
struct sw_flow *flow;
-   u32 hash = skb_hash;
+   u32 hash;
int seg;
 
*n_mask_hit = 0;
if (unlikely(!skb_hash)) {
-   u32 __always_unused mask_index;
+   u32 mask_index = 0;
 
return flow_lookup(tbl, ti, ma, key, n_mask_hit, _index);
}
 
-   del = NULL;
+   /* Pre and post recirulation flows usually have the same skb_hash
+* value. To avoid hash collisions, rehash the 'skb_hash' with
+* 'recirc_id'.  */
+   if (key->recirc_id)
+   skb_hash = jhash_1word(skb_hash, key->recirc_id);
+
+   ce = NULL;
+   hash = skb_hash;
entries = this_cpu_ptr(tbl->mask_cache);
 
+   /* Find the cache entry 'ce' to operate on. */
for (seg = 0; seg < MC_HASH_SEGS; seg++) {
-   int index;
-
-   index = hash & (MC_HASH_ENTRIES - 1);
-   ce = [index];
-
-   if (ce->skb_hash == skb_hash) {
-   struct sw_flow_mask *mask;
-   struct sw_flow *flow;
-
-   mask = rcu_dereference_ovsl(ma->masks[ce->mask_index]);
-   if (mask) {
-   flow = masked_flow_lookup(ti, key, mask,
- n_mask_hit);
-   if (flow)  /* Found */
-   return flow;
-   }
-
-   del = ce;
-   break;
+   int index = hash & (MC_HASH_ENTRIES - 1);
+   struct mask_cache_entry *e;
+
+   e = [index];
+   if (e->skb_hash == skb_hash) {
+   flow = flow_lookup(tbl, ti, ma, key, n_mask_hit,
+  >mask_index);
+   if (!flow)
+   e->skb_hash = 0;
+   return flow;
}
 
-   if (!del || (del->skb_hash && !ce->skb_hash) ||
-

[ovs-dev] [PATCH net-next v6 03/10] net: openvswitch: shrink the mask array if necessary

2019-11-01 Thread xiangxia . m . yue 
From: Tonghao Zhang 

When creating and inserting flow-mask, if there is no available
flow-mask, we realloc the mask array. When removing flow-mask,
if necessary, we shrink mask array.

Signed-off-by: Tonghao Zhang 
Tested-by: Greg Rose 
Acked-by: William Tu 
---
 net/openvswitch/flow_table.c | 33 +++--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 92efa23..0c0fcd6 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -694,6 +694,23 @@ static struct table_instance *table_instance_expand(struct 
table_instance *ti,
return table_instance_rehash(ti, ti->n_buckets * 2, ufid);
 }
 
+static void tbl_mask_array_delete_mask(struct mask_array *ma,
+  struct sw_flow_mask *mask)
+{
+   int i;
+
+   /* Remove the deleted mask pointers from the array */
+   for (i = 0; i < ma->max; i++) {
+   if (mask == ovsl_dereference(ma->masks[i])) {
+   RCU_INIT_POINTER(ma->masks[i], NULL);
+   ma->count--;
+   kfree_rcu(mask, rcu);
+   return;
+   }
+   }
+   BUG();
+}
+
 /* Remove 'mask' from the mask list, if it is not needed any more. */
 static void flow_mask_remove(struct flow_table *tbl, struct sw_flow_mask *mask)
 {
@@ -707,18 +724,14 @@ static void flow_mask_remove(struct flow_table *tbl, 
struct sw_flow_mask *mask)
 
if (!mask->ref_count) {
struct mask_array *ma;
-   int i;
 
ma = ovsl_dereference(tbl->mask_array);
-   for (i = 0; i < ma->max; i++) {
-   if (mask == ovsl_dereference(ma->masks[i])) {
-   RCU_INIT_POINTER(ma->masks[i], NULL);
-   ma->count--;
-   kfree_rcu(mask, rcu);
-   return;
-   }
-   }
-   BUG();
+   tbl_mask_array_delete_mask(ma, mask);
+
+   /* Shrink the mask array if necessary. */
+   if (ma->max >= (MASK_ARRAY_SIZE_MIN * 2) &&
+   ma->count <= (ma->max / 3))
+   tbl_mask_array_realloc(tbl, ma->max / 2);
}
}
 }
-- 
1.8.3.1

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

[ovs-dev] [PATCH net-next v6 02/10] net: openvswitch: convert mask list in mask array

2019-11-01 Thread xiangxia . m . yue 
From: Tonghao Zhang 

Port the codes to linux upstream and with little changes.

Pravin B Shelar, says:
| mask caches index of mask in mask_list. On packet recv OVS
| need to traverse mask-list to get cached mask. Therefore array
| is better for retrieving cached mask. This also allows better
| cache replacement algorithm by directly checking mask's existence.

Link: 
https://github.com/openvswitch/ovs/commit/d49fc3ff53c65e4eca9cabd52ac63396746a7ef5
Signed-off-by: Tonghao Zhang 
Tested-by: Greg Rose 
Acked-by: William Tu 
---
 net/openvswitch/flow.h   |   1 -
 net/openvswitch/flow_table.c | 209 +--
 net/openvswitch/flow_table.h |   8 +-
 3 files changed, 167 insertions(+), 51 deletions(-)

diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index b830d5f..8080518 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -166,7 +166,6 @@ struct sw_flow_key_range {
 struct sw_flow_mask {
int ref_count;
struct rcu_head rcu;
-   struct list_head list;
struct sw_flow_key_range range;
struct sw_flow_key key;
 };
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 3d515c0..92efa23 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -34,6 +34,7 @@
 #include 
 
 #define TBL_MIN_BUCKETS1024
+#define MASK_ARRAY_SIZE_MIN16
 #define REHASH_INTERVAL(10 * 60 * HZ)
 
 #define MC_HASH_SHIFT  8
@@ -168,9 +169,51 @@ static struct table_instance *table_instance_alloc(int 
new_size)
return ti;
 }
 
+static struct mask_array *tbl_mask_array_alloc(int size)
+{
+   struct mask_array *new;
+
+   size = max(MASK_ARRAY_SIZE_MIN, size);
+   new = kzalloc(sizeof(struct mask_array) +
+ sizeof(struct sw_flow_mask *) * size, GFP_KERNEL);
+   if (!new)
+   return NULL;
+
+   new->count = 0;
+   new->max = size;
+
+   return new;
+}
+
+static int tbl_mask_array_realloc(struct flow_table *tbl, int size)
+{
+   struct mask_array *old;
+   struct mask_array *new;
+
+   new = tbl_mask_array_alloc(size);
+   if (!new)
+   return -ENOMEM;
+
+   old = ovsl_dereference(tbl->mask_array);
+   if (old) {
+   int i;
+
+   for (i = 0; i < old->max; i++) {
+   if (ovsl_dereference(old->masks[i]))
+   new->masks[new->count++] = old->masks[i];
+   }
+   }
+
+   rcu_assign_pointer(tbl->mask_array, new);
+   kfree_rcu(old, rcu);
+
+   return 0;
+}
+
 int ovs_flow_tbl_init(struct flow_table *table)
 {
struct table_instance *ti, *ufid_ti;
+   struct mask_array *ma;
 
table->mask_cache = __alloc_percpu(sizeof(struct mask_cache_entry) *
   MC_HASH_ENTRIES,
@@ -178,9 +221,13 @@ int ovs_flow_tbl_init(struct flow_table *table)
if (!table->mask_cache)
return -ENOMEM;
 
+   ma = tbl_mask_array_alloc(MASK_ARRAY_SIZE_MIN);
+   if (!ma)
+   goto free_mask_cache;
+
ti = table_instance_alloc(TBL_MIN_BUCKETS);
if (!ti)
-   goto free_mask_cache;
+   goto free_mask_array;
 
ufid_ti = table_instance_alloc(TBL_MIN_BUCKETS);
if (!ufid_ti)
@@ -188,7 +235,7 @@ int ovs_flow_tbl_init(struct flow_table *table)
 
rcu_assign_pointer(table->ti, ti);
rcu_assign_pointer(table->ufid_ti, ufid_ti);
-   INIT_LIST_HEAD(>mask_list);
+   rcu_assign_pointer(table->mask_array, ma);
table->last_rehash = jiffies;
table->count = 0;
table->ufid_count = 0;
@@ -196,6 +243,8 @@ int ovs_flow_tbl_init(struct flow_table *table)
 
 free_ti:
__table_instance_destroy(ti);
+free_mask_array:
+   kfree(ma);
 free_mask_cache:
free_percpu(table->mask_cache);
return -ENOMEM;
@@ -255,6 +304,7 @@ void ovs_flow_tbl_destroy(struct flow_table *table)
struct table_instance *ufid_ti = rcu_dereference_raw(table->ufid_ti);
 
free_percpu(table->mask_cache);
+   kfree_rcu(rcu_dereference_raw(table->mask_array), rcu);
table_instance_destroy(ti, ufid_ti, false);
 }
 
@@ -460,17 +510,27 @@ static struct sw_flow *masked_flow_lookup(struct 
table_instance *ti,
 
 static struct sw_flow *flow_lookup(struct flow_table *tbl,
   struct table_instance *ti,
+  struct mask_array *ma,
   const struct sw_flow_key *key,
-  u32 *n_mask_hit)
+  u32 *n_mask_hit,
+  u32 *index)
 {
-   struct sw_flow_mask *mask;
struct sw_flow *flow;
+   int i;
 
-   list_for_each_entry_rcu(mask, >mask_list, list) {
-   flow = masked_flow_lookup(ti, key, mask, n_mask_hit);
-

[ovs-dev] [PATCH net-next v6 01/10] net: openvswitch: add flow-mask cache for performance

2019-11-01 Thread xiangxia . m . yue 
From: Tonghao Zhang 

The idea of this optimization comes from a patch which
is committed in 2014, openvswitch community. The author
is Pravin B Shelar. In order to get high performance, I
implement it again. Later patches will use it.

Pravin B Shelar, says:
| On every packet OVS needs to lookup flow-table with every
| mask until it finds a match. The packet flow-key is first
| masked with mask in the list and then the masked key is
| looked up in flow-table. Therefore number of masks can
| affect packet processing performance.

Link: 
https://github.com/openvswitch/ovs/commit/5604935e4e1cbc16611d2d97f50b717aa31e8ec5
Signed-off-by: Tonghao Zhang 
Tested-by: Greg Rose 
Acked-by: William Tu 
---
 net/openvswitch/datapath.c   |   3 +-
 net/openvswitch/flow_table.c | 109 +--
 net/openvswitch/flow_table.h |  11 -
 3 files changed, 107 insertions(+), 16 deletions(-)

diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index f30e406..9fea7e1 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -227,7 +227,8 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct 
sw_flow_key *key)
stats = this_cpu_ptr(dp->stats_percpu);
 
/* Look up flow. */
-   flow = ovs_flow_tbl_lookup_stats(>table, key, _mask_hit);
+   flow = ovs_flow_tbl_lookup_stats(>table, key, skb_get_hash(skb),
+_mask_hit);
if (unlikely(!flow)) {
struct dp_upcall_info upcall;
 
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index cf3582c..3d515c0 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -36,6 +36,10 @@
 #define TBL_MIN_BUCKETS1024
 #define REHASH_INTERVAL(10 * 60 * HZ)
 
+#define MC_HASH_SHIFT  8
+#define MC_HASH_ENTRIES(1u << MC_HASH_SHIFT)
+#define MC_HASH_SEGS   ((sizeof(uint32_t) * 8) / MC_HASH_SHIFT)
+
 static struct kmem_cache *flow_cache;
 struct kmem_cache *flow_stats_cache __read_mostly;
 
@@ -168,10 +172,15 @@ int ovs_flow_tbl_init(struct flow_table *table)
 {
struct table_instance *ti, *ufid_ti;
 
-   ti = table_instance_alloc(TBL_MIN_BUCKETS);
+   table->mask_cache = __alloc_percpu(sizeof(struct mask_cache_entry) *
+  MC_HASH_ENTRIES,
+  __alignof__(struct 
mask_cache_entry));
+   if (!table->mask_cache)
+   return -ENOMEM;
 
+   ti = table_instance_alloc(TBL_MIN_BUCKETS);
if (!ti)
-   return -ENOMEM;
+   goto free_mask_cache;
 
ufid_ti = table_instance_alloc(TBL_MIN_BUCKETS);
if (!ufid_ti)
@@ -187,6 +196,8 @@ int ovs_flow_tbl_init(struct flow_table *table)
 
 free_ti:
__table_instance_destroy(ti);
+free_mask_cache:
+   free_percpu(table->mask_cache);
return -ENOMEM;
 }
 
@@ -243,6 +254,7 @@ void ovs_flow_tbl_destroy(struct flow_table *table)
struct table_instance *ti = rcu_dereference_raw(table->ti);
struct table_instance *ufid_ti = rcu_dereference_raw(table->ufid_ti);
 
+   free_percpu(table->mask_cache);
table_instance_destroy(ti, ufid_ti, false);
 }
 
@@ -425,7 +437,8 @@ static bool ovs_flow_cmp_unmasked_key(const struct sw_flow 
*flow,
 
 static struct sw_flow *masked_flow_lookup(struct table_instance *ti,
  const struct sw_flow_key *unmasked,
- const struct sw_flow_mask *mask)
+ const struct sw_flow_mask *mask,
+ u32 *n_mask_hit)
 {
struct sw_flow *flow;
struct hlist_head *head;
@@ -435,6 +448,8 @@ static struct sw_flow *masked_flow_lookup(struct 
table_instance *ti,
ovs_flow_mask_key(_key, unmasked, false, mask);
hash = flow_hash(_key, >range);
head = find_bucket(ti, hash);
+   (*n_mask_hit)++;
+
hlist_for_each_entry_rcu(flow, head, flow_table.node[ti->node_ver]) {
if (flow->mask == mask && flow->flow_table.hash == hash &&
flow_cmp_masked_key(flow, _key, >range))
@@ -443,30 +458,97 @@ static struct sw_flow *masked_flow_lookup(struct 
table_instance *ti,
return NULL;
 }
 
-struct sw_flow *ovs_flow_tbl_lookup_stats(struct flow_table *tbl,
-   const struct sw_flow_key *key,
-   u32 *n_mask_hit)
+static struct sw_flow *flow_lookup(struct flow_table *tbl,
+  struct table_instance *ti,
+  const struct sw_flow_key *key,
+  u32 *n_mask_hit)
 {
-   struct table_instance *ti = rcu_dereference_ovsl(tbl->ti);
struct sw_flow_mask *mask;
struct sw_flow *flow;
 
-   *n_mask_hit = 0;

[ovs-dev] [PATCH net-next v6 00/10] optimize openvswitch flow looking up

2019-11-01 Thread xiangxia . m . yue 
From: Tonghao Zhang 

This series patch optimize openvswitch for performance or simplify
codes.

Patch 1, 2, 4: Port Pravin B Shelar patches to
linux upstream with little changes.

Patch 5, 6, 7: Optimize the flow looking up and
simplify the flow hash.

Patch 8, 9: are bugfix.

The performance test is on Intel Xeon E5-2630 v4.
The test topology is show as below:

+---+
|   +---+   |
|   | eth0   ovs-switcheth1 |   | Host0
|   +---+   |
+---+
  ^   |
  |   |
  |   |
  |   |
  |   v
+-++ ++-+
| netperf  | Host1   | netserver| Host2
+--+ +--+

We use netperf send the 64B packets, and insert 255+ flow-mask:
$ ovs-dpctl add-flow ovs-switch 
"in_port(1),eth(dst=00:01:00:00:00:00/ff:ff:ff:ff:ff:01),eth_type(0x0800),ipv4(frag=no)"
 2
...
$ ovs-dpctl add-flow ovs-switch 
"in_port(1),eth(dst=00:ff:00:00:00:00/ff:ff:ff:ff:ff:ff),eth_type(0x0800),ipv4(frag=no)"
 2
$
$ netperf -t UDP_STREAM -H 2.2.2.200 -l 40 -- -m 18

* Without series patch, throughput 8.28Mbps
* With series patch, throughput 46.05Mbps

v6:
some coding style fixes

v5:
rewrite patch 8, release flow-mask when freeing flow

v4:
access ma->count with READ_ONCE/WRITE_ONCE API. More information,
see patch 5 comments. 

v3:
update ma point when realloc mask_array in patch 5

v2:
simplify codes. e.g. use kfree_rcu instead of call_rcu

Tonghao Zhang (10):
  net: openvswitch: add flow-mask cache for performance
  net: openvswitch: convert mask list in mask array
  net: openvswitch: shrink the mask array if necessary
  net: openvswitch: optimize flow mask cache hash collision
  net: openvswitch: optimize flow-mask looking up
  net: openvswitch: simplify the flow_hash
  net: openvswitch: add likely in flow_lookup
  net: openvswitch: fix possible memleak on destroy flow-table
  net: openvswitch: don't unlock mutex when changing the user_features
fails
  net: openvswitch: simplify the ovs_dp_cmd_new

 net/openvswitch/datapath.c   |  65 +---
 net/openvswitch/flow.h   |   1 -
 net/openvswitch/flow_table.c | 381 ++-
 net/openvswitch/flow_table.h |  19 ++-
 4 files changed, 361 insertions(+), 105 deletions(-)

-- 
1.8.3.1

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

Re: [ovs-dev] [RFC] dpdk: Deprecate pdump support.

2019-11-01 Thread Aaron Conole 
Ilya Maximets  writes:

> The conventional way for packet dumping in OVS is to use ovs-tcpdump
> that works via traffic mirroring.  DPDK pdump could probably be used
> for some lower level debugging, but it is not commonly used for
> various reasons.
>
> There are lots of limitations for using this functionality in practice.
> Most of them connected with running secondary pdump process and
> memory layout issues like requirement to disable ASLR in kernel.
> More details are available in DPDK guide:
> https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html#multi-process-limitations
>
> Beside the functional limitations it's also hard to use this
> functionality correctly.  User must be sure that OVS and pdump utility
> are running on different CPU cores, which is hard because non-PMD
> threads could float over available CPU cores.  This or any other
> misconfiguration will likely lead to crash of the pdump utility
> or/and OVS.
>
> Another problem is that the user must actually have this special pdump
> utility in a system and it might be not available in distributions.
>
> This change disables pdump support by default introducing special
> configuration option '--enable-dpdk-pdump'.  Deprecation warnings will
> be shown to users on configuration and in runtime.
>
> Claiming to completely remove this functionality from OVS in one
> of the next releases.
>
> Signed-off-by: Ilya Maximets 
> ---

Acked-by: Aaron Conole 

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

Re: [ovs-dev] [PATCH v1] ofproto: Fix OVS crash when packets hit Openflow rules with certain combinations of nested actions

2019-11-01 Thread Ilya Maximets 

On 31.10.2019 18:24, Ben Pfaff wrote:

For Ilya and others: the email to Anil bounced, so he probably isn't at
Calsoft Labs any longer.


Are you sure that it wasn't mine old email address?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v1] ofproto: Fix OVS crash when packets hit Openflow rules with certain combinations of nested actions

2019-11-01 Thread Ilya Maximets 

CC: ovs-dev
Sorry.

On 01.11.2019 14:34, Ilya Maximets wrote:

On 31.10.2019 18:12, Ben Pfaff wrote:

On Thu, Sep 05, 2019 at 11:12:26PM +0530, Anil Kumar Koli wrote:

* We can't get rid of ofproto_mutex in do_bundle_commit(), or drop it
   temporarily around flow translation (i.e. the call to
   ofproto_packet_out_start()), because it might need to revert all the
   flow table changes and dropping the mutex would allow other threads to
   race in and make conflicting changes


But it seems that the issue happens on ofproto_packet_out_finish() and not on
ofproto_packet_out_start(). So, the flow translation should be OK under the
ofproto_mutex and revert is still possible under the mutex.
The only thing we need to take out of the mutex is real action execution by
the datapath triggered by ofproto_packet_out_finish(). Callers never check the
status of this function so it should be not so hard.

So, possible solution:
* Move ofproto_packet_out_finish() out of ofproto_mutex in all the callers:
   * It's easy for handle_packet_out()
   * For do_bundle_commit() we could temporary store all the ofproto_packet_out
 entities and finish them later.

Am I missing something?  Is there reason for ofproto_packet_out_finish() to
require ofproto_mutex?

Ben, Anil, what do you think?

Best regards, Ilya Maximets.


This does seem like a reasonable solution.  Do you want to take a shot
at implementing it?  I promise to review a patch much more quickly than
I responded to the thread :-(



I could try. The hard part here is that I can not reproduce the issue.

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

[ovs-dev] [RFC] bridge: Allow manual notifications about interfaces' updates.

2019-11-01 Thread Ilya Maximets 
Sometimes interface updates could happen in a way ifnotifier is not
able to catch.  For example some heavy operations (device reset) in
netdev-dpdk could require re-applying of the bridge configuration.

For this purpose new function 'bridge_report_if_update' introduced.
It could be called directly by the code that aware about changes.

Since the calls could go from the different thread contexts we need
to protect the sequence number itself from updates before allocation
and after destruction.  Using the same seq mutex for this purpose to
not introduce another one.

Signed-off-by: Ilya Maximets 
---

Sending this as RFC that might be useful in context of the following patch:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364155.html

It will allow us to not introduce heavy dpdk notifier just to update
one sequence number on RTE_ETH_EVENT_INTR_RESET events. We could also
use it to report other changes from DPDK, e.g. LSC interrupts.

 vswitchd/bridge.c | 26 +-
 vswitchd/bridge.h |  2 ++
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 9095ebf5d..68239783f 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -252,6 +252,7 @@ static long long int aa_refresh_timer = LLONG_MIN;
 static struct if_notifier *ifnotifier;
 static struct seq *ifaces_changed;
 static uint64_t last_ifaces_changed;
+static bool ifaces_updates_enabled = false;
 
 /* Default/min/max packet-in queue sizes towards the controllers. */
 #define BRIDGE_CONTROLLER_PACKET_QUEUE_DEFAULT_SIZE 100
@@ -403,7 +404,19 @@ bridge_init_ofproto(const struct ovsrec_open_vswitch *cfg)
 static void
 if_change_cb(void *aux OVS_UNUSED)
 {
-seq_change(ifaces_changed);
+seq_lock();
+if (ifaces_updates_enabled) {
+seq_change_protected(ifaces_changed);
+}
+seq_unlock();
+}
+
+static void
+if_updates_enable(bool enable)
+{
+seq_lock();
+ifaces_updates_enabled = enable;
+seq_unlock();
 }
 
 static bool
@@ -422,6 +435,15 @@ if_notifier_changed(struct if_notifier *notifier 
OVS_UNUSED)
 
 /* Public functions. */
 
+/* Raports that some interfaces were changed from the outside of OVS.
+ * Could be used for catching events that could not be tracked by
+ * if_notifier, e.g. port updates in netdev-dpdk. */
+void
+bridge_report_if_update(void)
+{
+if_change_cb(NULL);
+}
+
 /* Initializes the bridge module, configuring it to obtain its configuration
  * from an OVSDB server accessed over 'remote', which should be a string in a
  * form acceptable to ovsdb_idl_create(). */
@@ -529,11 +551,13 @@ bridge_init(const char *remote)
 ifaces_changed = seq_create();
 last_ifaces_changed = seq_read(ifaces_changed);
 ifnotifier = if_notifier_create(if_change_cb, NULL);
+if_updates_enable(true);
 }
 
 void
 bridge_exit(bool delete_datapath)
 {
+if_updates_enable(false);
 if_notifier_destroy(ifnotifier);
 seq_destroy(ifaces_changed);
 
diff --git a/vswitchd/bridge.h b/vswitchd/bridge.h
index 8b2fce451..69a3db2bc 100644
--- a/vswitchd/bridge.h
+++ b/vswitchd/bridge.h
@@ -28,4 +28,6 @@ void bridge_wait(void);
 
 void bridge_get_memory_usage(struct simap *usage);
 
+void bridge_report_if_update(void);
+
 #endif /* bridge.h */
-- 
2.17.1

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

[ovs-dev] [RFC] dpdk: Deprecate pdump support.

2019-11-01 Thread Ilya Maximets 
The conventional way for packet dumping in OVS is to use ovs-tcpdump
that works via traffic mirroring.  DPDK pdump could probably be used
for some lower level debugging, but it is not commonly used for
various reasons.

There are lots of limitations for using this functionality in practice.
Most of them connected with running secondary pdump process and
memory layout issues like requirement to disable ASLR in kernel.
More details are available in DPDK guide:
https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html#multi-process-limitations

Beside the functional limitations it's also hard to use this
functionality correctly.  User must be sure that OVS and pdump utility
are running on different CPU cores, which is hard because non-PMD
threads could float over available CPU cores.  This or any other
misconfiguration will likely lead to crash of the pdump utility
or/and OVS.

Another problem is that the user must actually have this special pdump
utility in a system and it might be not available in distributions.

This change disables pdump support by default introducing special
configuration option '--enable-dpdk-pdump'.  Deprecation warnings will
be shown to users on configuration and in runtime.

Claiming to completely remove this functionality from OVS in one
of the next releases.

Signed-off-by: Ilya Maximets 
---
 .travis/linux-build.sh  |  4 +++-
 Documentation/topics/dpdk/pdump.rst |  8 +++-
 NEWS|  4 
 acinclude.m4| 24 ++--
 lib/dpdk.c  |  2 ++
 5 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index 69260181b..4e74973a3 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -124,7 +124,7 @@ function install_dpdk()
 sed -i '/CONFIG_RTE_EAL_IGB_UIO=y/s/=y/=n/' build/.config
 sed -i '/CONFIG_RTE_KNI_KMOD=y/s/=y/=n/' build/.config
 
-# Enable pdump.  This will enable building of the relevant OVS code.
+# Enable pdump support in DPDK.
 sed -i '/CONFIG_RTE_LIBRTE_PMD_PCAP=n/s/=n/=y/' build/.config
 sed -i '/CONFIG_RTE_LIBRTE_PDUMP=n/s/=n/=y/' build/.config
 
@@ -168,6 +168,8 @@ if [ "$DPDK" ] || [ "$DPDK_SHARED" ]; then
 DPDK_VER="18.11.2"
 fi
 install_dpdk $DPDK_VER
+# Enable pdump support in OVS.
+EXTRA_OPTS="${EXTRA_OPTS} --enable-dpdk-pdump"
 if [ "$CC" = "clang" ]; then
 # Disregard cast alignment errors until DPDK is fixed
 CFLAGS_FOR_OVS="${CFLAGS_FOR_OVS} -Wno-cast-align"
diff --git a/Documentation/topics/dpdk/pdump.rst 
b/Documentation/topics/dpdk/pdump.rst
index 7bd1d3e9f..b4d8aa8e9 100644
--- a/Documentation/topics/dpdk/pdump.rst
+++ b/Documentation/topics/dpdk/pdump.rst
@@ -27,10 +27,16 @@ pdump
 
 .. versionadded:: 2.6.0
 
+.. warning::
+
+   DPDK pdump support is deprecated in OVS and will be removed in next
+   releases.
+
 pdump allows you to listen on DPDK ports and view the traffic that is passing
 on them. To use this utility, one must have libpcap installed on the system.
 Furthermore, DPDK must be built with ``CONFIG_RTE_LIBRTE_PDUMP=y`` and
-``CONFIG_RTE_LIBRTE_PMD_PCAP=y``.
+``CONFIG_RTE_LIBRTE_PMD_PCAP=y``. OVS should be built with
+``--enable-dpdk-pdump`` configuration option.
 
 .. warning::
 
diff --git a/NEWS b/NEWS
index 88b818948..0d65d5a7f 100644
--- a/NEWS
+++ b/NEWS
@@ -10,6 +10,10 @@ Post-v2.12.0
if supported by libbpf.
  * Add option to enable, disable and query TCP sequence checking in
conntrack.
+   - DPDK:
+ * DPDK pdump packet capture support disabled by default. New configure
+   option '--enable-dpdk-pdump' to enable it.
+ * DPDK pdump support is deprecated and will be removed in next releases.
 
 v2.12.0 - 03 Sep 2019
 -
diff --git a/acinclude.m4 b/acinclude.m4
index a0507cfe0..588a0bdf2 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -343,12 +343,24 @@ AC_DEFUN([OVS_CHECK_DPDK], [
   AC_DEFINE([VHOST_NUMA], [1], [NUMA Aware vHost support detected in 
DPDK.])
 ], [], [[#include ]])
 
-AC_CHECK_DECL([RTE_LIBRTE_PMD_PCAP], [
-  OVS_FIND_DEPENDENCY([pcap_dump], [pcap], [libpcap])
-  AC_CHECK_DECL([RTE_LIBRTE_PDUMP], [
-AC_DEFINE([DPDK_PDUMP], [1], [DPDK pdump enabled in OVS.])
-  ], [], [[#include ]])
-], [], [[#include ]])
+   AC_MSG_CHECKING([whether DPDK pdump support is enabled])
+   AC_ARG_ENABLE(
+ [dpdk-pdump],
+ [AC_HELP_STRING([--enable-dpdk-pdump],
+ [Enable DPDK pdump packet capture support])],
+ [AC_MSG_RESULT([yes])
+  AC_MSG_WARN([DPDK pdump is deprecated, consider using ovs-tcpdump 
instead])
+  AC_CHECK_DECL([RTE_LIBRTE_PMD_PCAP], [
+OVS_FIND_DEPENDENCY([pcap_dump], [pcap], [libpcap])
+AC_CHECK_DECL([RTE_LIBRTE_PDUMP], [
+  AC_DEFINE([DPDK_PDUMP], [1], [DPDK pdump enabled in OVS.])
+], [
+  AC_MSG_ERROR([RTE_LIBRTE_PDUMP

[ovs-dev] [PATCH ovn] Improve debuggability of OVN to OpenFlow translations.

2019-11-01 Thread Dumitru Ceara 
Until now, when translating SB database contents to OpenFlow flows,
ovn-controller stored (part of) the SB record UUID in the cookie field
of the OpenFlow entry only when translating logical flows.

Extend this behavior to the following SB Database table records too:
- Port_Binding
- Mac_Binding
- Multicast_Group
- Chassis

This makes debugging easier by allowing the user to trace back the
original SB entry that generated the OpenFlow entry. Also, the
"ovn-sbctl lflow-list" command now supports an additional "--vflows"
argument (virtual flows). When present this will instruct ovn-sbctl
to also pretty print the contents of the above mentioned tables for
the given datapath (or all datapaths if none is specified).

Combined with the "--ovs" and "--stats" arguments it allows the
user to have a more complete view of how forwarding in the
logical network is translated to forwarding in OVS.

A usage example:
$ ovn-sbctl --ovs --vflows lflow-list
[...]
Port Bindings:
  datapath="ls", logical_port=vm2, tunnel_key=4
cookie=0xeaee10a0, duration=2122.949s, table=65, n_packets=0,
  n_bytes=0, priority=100,reg15=0x4,metadata=0x2 actions=output:2
  datapath="rtr", logical_port=rtr-ls, tunnel_key=1
cookie=0x640b6337, duration=2122.945s, table=65, n_packets=0,
  n_bytes=0, priority=100,reg15=0x1,metadata=0x1
  actions=clone(ct_clear,set_field:0->reg11,set_field:0->reg12,
set_field:0->reg13,set_field:0x4->reg11,set_field:0x3->reg12,
set_field:0x2->metadata,set_field:0x3->reg14,set_field:0->reg10,
set_field:0->reg15,set_field:0->reg0,set_field:0->reg1,
set_field:0->reg2,set_field:0->reg3,set_field:0->reg4,
set_field:0->reg5,set_field:0->reg6,set_field:0->reg7,
set_field:0->reg8,set_field:0->reg9,set_field:0->in_port,
resubmit(,8))

MAC Bindings:
  datapath="rtr", logical_port=rtr-ls, ip=10::254, mac=00:00:00:00:00:01
cookie=0x1c2b771d, duration=2122.946s, table=66, n_packets=0,
  n_bytes=0,priority=100,reg0=0x10,reg1=0,reg2=0,reg3=0x254,
  reg15=0x1,metadata=0x1
  actions=set_field:00:00:00:00:00:01->eth_dst
cookie=0x1c2b771d, duration=2122.945s, table=67, n_packets=0,
  n_bytes=0,priority=100,icmp6,reg0=0x10,reg1=0,reg2=0,
  reg3=0x254,reg14=0x1,metadata=0x1,dl_src=00:00:00:00:00:01,icmp_code=0
  actions=load:0x1->NXM_NX_REG10[6]

MC Groups:
  datapath="ls", name=_MC_flood, tunnel_key=32768, ports=(vm1, ls-rtr, vm2)
cookie=0x4a196492, duration=2122.949s, table=33, n_packets=0,
  n_bytes=0, priority=100,reg15=0x8000,metadata=0x2
  actions=set_field:0x1->reg13,set_field:0x2->reg15,resubmit(,34),
  set_field:0xc->reg13,set_field:0x4->reg15,resubmit(,34),
  set_field:0x8000->reg15
cookie=0x4a196492, duration=2122.947s, table=32, n_packets=0,
  n_bytes=0, priority=100,reg15=0x8000,metadata=0x2
  actions=set_field:0x3->reg15,resubmit(,34),set_field:0x8000->reg15,
  resubmit(,33)
[..]

Signed-off-by: Dumitru Ceara 
---
 controller/lflow.c   |   6 +-
 controller/physical.c|  58 +-
 utilities/ovn-sbctl.8.in |   8 +-
 utilities/ovn-sbctl.c| 196 +++
 4 files changed, 230 insertions(+), 38 deletions(-)

diff --git a/controller/lflow.c b/controller/lflow.c
index f34abce..36150bd 100644
--- a/controller/lflow.c
+++ b/controller/lflow.c
@@ -817,7 +817,8 @@ consider_neighbor_flow(struct ovsdb_idl_index 
*sbrec_port_binding_by_name,
 uint64_t stub[1024 / 8];
 struct ofpbuf ofpacts = OFPBUF_STUB_INITIALIZER(stub);
 put_load(mac.ea, sizeof mac.ea, MFF_ETH_DST, 0, 48, );
-ofctrl_add_flow(flow_table, OFTABLE_MAC_BINDING, 100, 0, _arp_match,
+ofctrl_add_flow(flow_table, OFTABLE_MAC_BINDING, 100,
+b->header_.uuid.parts[0], _arp_match,
 , >header_.uuid);
 
 ofpbuf_clear();
@@ -825,7 +826,8 @@ consider_neighbor_flow(struct ovsdb_idl_index 
*sbrec_port_binding_by_name,
 put_load(, sizeof value, MFF_LOG_FLAGS, MLF_LOOKUP_MAC_BIT, 1,
  );
 match_set_dl_src(_arp_match, mac);
-ofctrl_add_flow(flow_table, OFTABLE_MAC_LOOKUP, 100, 0, _arp_match,
+ofctrl_add_flow(flow_table, OFTABLE_MAC_LOOKUP, 100,
+b->header_.uuid.parts[0], _arp_match,
 , >header_.uuid);
 
 ofpbuf_uninit();
diff --git a/controller/physical.c b/controller/physical.c
index 6e606d3..500d419 100644
--- a/controller/physical.c
+++ b/controller/physical.c
@@ -298,7 +298,8 @@ put_remote_port_redirect_bridged(const struct
  , NULL);
 
 put_resubmit(OFTABLE_LOG_TO_PHY, ofpacts_p);
-ofctrl_add_flow(flow_table, OFTABLE_LOCAL_OUTPUT, 100, 0,
+ofctrl_add_flow(flow_table, OFTABLE_LOCAL_OUTPUT, 100,
+binding->header_.uuid.parts[0],
 match, ofpacts_p, >header_.uuid);
 
 }
@@ -393,7 +394,8 @@ put_remote_port_redirect_overlay(const struct

Re: [ovs-dev] [PATCH] travis: Enable pdump for DPDK build.

2019-11-01 Thread Ilya Maximets 

On 31.10.2019 9:02, David Marchand wrote:

On Wed, Oct 30, 2019 at 8:53 PM Ilya Maximets  wrote:


OVS has support for DPDK pdump that checked in configure script.
Enabling it to increase OVS build test coverage by the code guarded
by DPDK_PDUMP macro.

Signed-off-by: Ilya Maximets 
---

Travis cache should be manually cleared before pushing this change for
it to have effect.

  .travis.yml| 1 +
  .travis/linux-build.sh | 4 
  2 files changed, 5 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 37a2ba5ce..049529d50 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -20,6 +20,7 @@ addons:
- libjemalloc1
- libjemalloc-dev
- libnuma-dev
+  - libpcap-dev
- python3-sphinx
- libelf-dev
- selinux-policy-dev
diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index 889c7d2fe..e11ff47ee 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -124,6 +124,10 @@ function install_dpdk()
  sed -i '/CONFIG_RTE_EAL_IGB_UIO=y/s/=y/=n/' build/.config
  sed -i '/CONFIG_RTE_KNI_KMOD=y/s/=y/=n/' build/.config

+# Enable pdump.  This will enable building of revelant OVS code.
+sed -i '/RTE_LIBRTE_PMD_PCAP=n/s/=n/=y/' build/.config


CONFIG_ for consistency with the rest?


+sed -i '/CONFIG_RTE_LIBRTE_PDUMP=n/s/=n/=y/' build/.config
+
  make -j4 CC=gcc EXTRA_CFLAGS='-fPIC'
  EXTRA_OPTS="$EXTRA_OPTS --with-dpdk=$(pwd)/build"
  echo "Installed DPDK source in $(pwd)"
--
2.17.1



Waiting for travis to finish, but the patch looks good.
Reviewed-by: David Marchand 


Thanks! I added the 'CONFIG_', fixed small typo in comment,
cleared Travis cache and applied to master.

Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3 ovn] ovn-nb/sbctl.c: Use env variables for passing options.

2019-11-01 Thread Numan Siddique 
On Fri, Nov 1, 2019, 2:37 AM Ben Pfaff  wrote:

> On Thu, Oct 31, 2019 at 11:45:07PM +0530, Numan Siddique wrote:
> > On Sat, Oct 26, 2019 at 2:02 AM Ben Pfaff  wrote:
> > >
> > > On Fri, Oct 25, 2019 at 01:10:57PM -0700, amgin...@gmail.com wrote:
> > > > From: Aliasgar Ginwala 
> > > >
> > > > Add new env variables OVN_NBCTL_OPTIONS and OVN_SBCTL_OPTIONS for
> > > > ovn-nbctl and ovn-sbctl respectively where user can set
> > > > supported ovn-nb/sbctl options using environment variable.
> > > > e.g. OVN_SBCTL_OPTIONS="--db=unix:sb1.ovsdb --no-leader-only"
> > > >
> > > > Signed-off-by: Aliasgar Ginwala 
> > >
> > > I didn't test this.
> > >
> > > Acked-by: Ben Pfaff 
> >
> > Hi Aliasgar,
> >
> > Compilation was failing with the below errors
>
> Well, gosh, I guess I didn't even build it.  I apologize!  Sorry about
> that!
>

No worries :)

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

Re: [ovs-dev] [PATCH v4 0/2] ALLOW Stateless NAT operations

2019-11-01 Thread Numan Siddique 
On Fri, Nov 1, 2019 at 6:58 AM Ankur Sharma  wrote:
>
> NAT implementation in OVN uses connection tracker to replace
> source and dest ips. This implementation works fine and
> is the right approach for cases where external ips are shared
> (i.e. SNAT) or where we replace ip only when relevant flow is there
> (i.e. DNAT).
>
> However, it opens the possibility of Dos Attack, where attacker
> can easily simluate multiple 5 tuples, to consume the connection
> tracker entry in an OVN chassis. This way they can easily attain
> the CT limit, there by impacting the usage of it by other features
> like valid NAT, ACL etc.
>
> This attack is even worse, when external ip is a public ip,
> i.e internet routable ip.
>
> In this patch we are introducing an option with NAT table entry.
> Option "stateless=true" indicates that NAT implmentation
> should not be using CT, i.e it should not use ct_snat/dnat actions.
>
> Instead of ct_* actions, we will use ip4.src/dst OVN actions, which
> will replace source and destination ips, while recalculating the
> checksums.
>
> This option is applicable only for the NAT rules which can be
> 1:1 mapped between inner and external ips, i.e dnat_and_snat rule.
>
> Signed-off-by: Ankur Sharma 

Thanks.

I applied this series to master.

Numan

>
> Ankur Sharma (2):
>   OVN: ADD nbctl cli to mark a dnat_and_snat rule as stateless
>   OVN: Use ip4.src and ip4.dst actions for NAT rules
>
>  northd/ovn-northd.8.xml   |  33 -
>  northd/ovn-northd.c   |  84 +++--
>  ovn-nb.ovsschema  |   6 +-
>  ovn-nb.xml|   5 +
>  tests/ovn-nbctl.at|  37 ++
>  tests/ovn-northd.at   |  95 ++
>  tests/ovn.at  | 311 
> ++
>  utilities/ovn-nbctl.8.xml |  12 +-
>  utilities/ovn-nbctl.c |  30 -
>  9 files changed, 594 insertions(+), 19 deletions(-)
>
> --
> 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

Re: [ovs-dev] [PATCH] ip_gre: Remove even more unused code

2019-11-01 Thread Ilya Maximets 

On 31.10.2019 23:46, Greg Rose wrote:

There is a confusing mix of ipgre and gretap functions with some
needed for gretap still having ipgre_ prefixes.  This time though
I think I got the rest of the unused ipgre code.

Fixes: d5822f428814 ("gre: Remove dead ipgre code")
Signed-off-by: Greg Rose 
---
  datapath/linux/compat/ip_gre.c | 38 --
  1 file changed, 38 deletions(-)


Hi.

This broke build with kernel 4.15.18:
https://travis-ci.org/openvswitch/ovs/jobs/605766364

datapath/linux/ip_gre.c: In function ‘ipgre_tunnel_init’:
datapath/linux/ip_gre.c:940:22: error: ‘ipgre_header_ops’ undeclared (first use 
in this function)
   dev->header_ops = _header_ops;
  ^
datapath/linux/ip_gre.c:940:22: note: each undeclared identifier is reported 
only once for each function it appears in
datapath/linux/ip_gre.c: At top level:
datapath/linux/ip_gre.c:925:12: warning: ‘ipgre_tunnel_init’ defined but not 
used [-Wunused-function]
 static int ipgre_tunnel_init(struct net_device *dev)
^
datapath/linux/ip_gre.c:946:20: warning: ‘ipgre_xmit’ defined but not used 
[-Wunused-function]
 static netdev_tx_t ipgre_xmit(struct sk_buff *skb,
^

Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev