Re: [ovs-dev] [PATCH] ofproto: Fix for frequent invalidation of mega flows for push actions

2019-10-09 Thread Vishal Deep Ajmera via dev
 
> Thanks, applied to master.

Thanks Ben.

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


Re: [ovs-dev] [PATCH ovn v1] utilities: add ovn-sim

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

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


checkpatch:
WARNING: Line is 81 characters long (recommended limit is 79)
#160 FILE: Documentation/ref/ovn-sim.1.rst:77:
Simulating hypervisors and and starting ovn controller (via ovn_attach) on 
each::

WARNING: Line is 89 characters long (recommended limit is 79)
#170 FILE: Documentation/ref/ovn-sim.1.rst:87:
ovs-vsctl add-port br-int vif$i -- set Interface vif$i 
external-ids:iface-id=lp$i

WARNING: Line is 92 characters long (recommended limit is 79)
#189 FILE: Documentation/ref/ovn-sim.1.rst:106:
ovs-vsctl add-port br-int vif$i -- set Interface vif$i 
external-ids:iface-id=lp$i) &

WARNING: Line is 99 characters long (recommended limit is 79)
#205 FILE: Documentation/ref/ovn-sim.1.rst:122:
watch 'for i in `seq $n`; do if test `ovn-nbctl lsp-get-up lp$i` != up; 
then echo $i; fi; done'

WARNING: Line has trailing whitespace
#777 FILE: utilities/ovn-sim.in:278:
   --pidfile=ovn-controller.${sandbox}.pid 

WARNING: New doc ovn-sim.1.rst not listed in Documentation/automake.mk
Lines checked: 810, Warnings: 6, Errors: 0


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


[ovs-dev] [PATCH ovn v1] utilities: add ovn-sim

2019-10-09 Thread Flavio Fernandes
Adding a wrapper to ovs-sim called ovn-sim, which re-introduces the
primitives for OVN in the simulator that were lost as part of
the ovn-org/ovn split.

Also resurrected the man page used to document ovn-sim usage.

Lastly, there were some leftover ovs-sim references that were
not proper. This patch renames these to ovn-sim.

All in all, this change is nothing but porting over the
OVN sections of ovs-sim from OVS version 2.12 (pre-split).
Fixes #21

Reported-by: Flavio Fernandes 
Reported-at: https://github.com/ovn-org/ovn/issues/21
Signed-off-by: Flavio Fernandes 
---
 Documentation/automake.mk   |   2 +-
 Documentation/conf.py   |   4 +-
 Documentation/ref/index.rst |   2 +-
 Documentation/ref/ovn-sim.1.rst | 122 +
 Documentation/ref/ovs-sim.1.rst | 244 -
 Makefile.am |   1 +
 utilities/.gitignore|   1 +
 utilities/automake.mk   |   6 +-
 utilities/ovn-sim.in| 308 
 9 files changed, 441 insertions(+), 249 deletions(-)
 create mode 100644 Documentation/ref/ovn-sim.1.rst
 delete mode 100644 Documentation/ref/ovs-sim.1.rst
 create mode 100755 utilities/ovn-sim.in

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 5968d6941..bf2166349 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -106,7 +106,7 @@ RST_MANPAGES = \
 # rST formatted manpages that we don't want to install because they
 # document stuff that only works with a build tree, not with an
 # installed OVS.
-RST_MANPAGES_NOINST = ovs-sim.1.rst
+RST_MANPAGES_NOINST = ovn-sim.1.rst
 
 # The GNU standards say that these variables should control
 # installation directories for manpages in each section.  Automake
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 6bf528bde..2c85dcf4d 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -114,8 +114,8 @@ html_static_path = ['_static']
 # One entry per manual page. List of tuples
 # (source start file, name, description, authors, manual section).
 _man_pages = [
-('ovs-sim.1',
- u'Open vSwitch simulator environment'),
+('ovn-sim.1',
+ u'Open Virtual Network simulator environment'),
 ('ovsdb-server.7',
  u'Open vSwitch Database Server Protocol'),
 ('ovsdb.5',
diff --git a/Documentation/ref/index.rst b/Documentation/ref/index.rst
index 530d639d6..7ff9edd09 100644
--- a/Documentation/ref/index.rst
+++ b/Documentation/ref/index.rst
@@ -39,7 +39,7 @@ time:
 .. toctree::
:maxdepth: 3
 
-   ovs-sim.1
+   ovn-sim.1
ovsdb-server.7
ovsdb.5
ovsdb.7
diff --git a/Documentation/ref/ovn-sim.1.rst b/Documentation/ref/ovn-sim.1.rst
new file mode 100644
index 0..b906740f0
--- /dev/null
+++ b/Documentation/ref/ovn-sim.1.rst
@@ -0,0 +1,122 @@
+===
+ovn-sim
+===
+
+Synopsis
+
+
+``ovn-sim`` [*option*]... [*script*]...
+
+Description
+===
+
+``ovn-sim`` is a wrapper script that adds ovn related commands on
+top of ``ovs-sim``.
+
+``ovs-sim`` provides a convenient environment for running one or more Open
+vSwitch instances and related software in a sandboxed simulation environment.
+
+To use ``ovn-sim``, first build Open vSwitch, then invoke it directly from the
+build directory, e.g.::
+
+git clone https://github.com/openvswitch/ovs.git
+cd ovs
+./boot.sh && ./configure && make
+cd ..
+git clone https://github.com/ovn-org/ovn.git
+cd ovn
+./boot.sh && ./configure --with-ovs-source=${PWD}/../ovs
+make
+utilities/ovn-sim
+
+See documentation on ``ovs-sim`` for info on simulator, including the
+parameters you can use.
+
+OVN Commands
+
+
+These commands interact with OVN, the Open Virtual Network.
+
+``ovn_start`` [*options*]
+Creates and initializes the central OVN databases (both
+``ovn-sb(5)`` and ``ovn-nb(5)``) and starts an instance of
+``ovsdb-server`` for each one.  Also starts an instance of
+``ovn-northd``.
+
+The following options are available:
+
+   ``--nbdb-model`` *model*
+   Uses the given database model for the northbound database.
+   The *model* may be ``standalone`` (the default), ``backup``,
+   or ``clustered``.
+
+   ``--nbdb-servers`` *n*
+   For a clustered northbound database, the number of servers in
+   the cluster.  The default is 3.
+
+   ``--sbdb-model`` *model*
+   Uses the given database model for the southbound database.
+   The *model* may be ``standalone`` (the default), ``backup``,
+   or ``clustered``.
+
+   ``--sbdb-servers`` *n*
+   For a clustered southbound database, the number of servers in
+   the cluster.  The default is 3.
+
+``ovn_attach`` *network* *bridge* *ip* [*masklen*]
+First, this command attaches bridge to interconnection network
+network, just like ``net_attach`` *network* *bridge*.  Second, it
+configures (simulated) IP ad

Re: [ovs-dev] [PATCH 0/1] Encap & Decap actions for MPLS Packet Type

2019-10-09 Thread Martin Varghese
On Wed, Oct 09, 2019 at 11:31:44AM -0700, Ben Pfaff wrote:
> On Tue, Oct 08, 2019 at 08:13:16AM +0530, Martin Varghese wrote:
> > The existing PUSH MPLS & POP MPLS actions inserts & removes MPLS header
> > between ethernet header and the IP header. Though this behaviour is fine
> > for L3 VPN where an IP packet is encapsulated inside a MPLS tunnel, it does
> > not suffice the L2 VPN requirements. In L2 VPN the ethernet packets must be
> > encapsulated inside MPLS tunnel.
> 
> Thanks a lot for working to make OVS better.
> 
> I have a few minor comments on the code.  I didn't look at it in detail.
> 
> This patch adds a few lines that exceed the normal 79-column limit.
> checkpatch reports those.  It's better to wrap lines to fit.
> 
> The compiler reports a few warnings that should be fixed:
> 
> ../ofproto/ofproto-dpif-ipfix.c:2980:17: error: enumeration values 
> 'OVS_ACTION_ATTR_PTAP_PUSH_MPLS' and 'OVS_ACTION_ATTR_PTAP_POP_MPLS' not 
> explicitly handled in switch [-Werror,-Wswitch-enum]
> ../ofproto/ofproto-dpif-sflow.c:1130:17: error: enumeration values 
> 'OVS_ACTION_ATTR_PTAP_PUSH_MPLS' and 'OVS_ACTION_ATTR_PTAP_POP_MPLS' not 
> explicitly handled in switch [-Werror,-Wswitch-enum]
> 
> The biggest issue, however, is a process one.  Updates to the kernel
> module need to go upstream to net-next before we put them into the OVS
> tree.  Have you submitted them there yet?
> 
> It also would be a good idea to implement this in the OVS userspace
> datapath.
> 
> I suggest adding an item to NEWS to mention the new feature.
>

Thanks for your time.

I was trying to get the feeback for the approach taken.
I will go ahead and send the  kernel changes to net-next
 

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


Re: [ovs-dev] [PATCH] appveyor: Update OpenSSL link and python3 to path

2019-10-09 Thread William Tu
On Wed, Oct 09, 2019 at 09:44:14AM -0700, Ben Pfaff wrote:
> On Wed, Oct 09, 2019 at 05:10:08PM +0300, Alin Gabriel Serdean wrote:
> > This patch fixes the appveyor build by adding the python version 3 to path
> > as per:
> > https://www.appveyor.com/docs/windows-images-software/#python
> > 
> > We also create a hardlink for python3 in the same directory to ease up 
> > scripts
> > which checks for its existence.
> > 
> > This patch also bumps the OpenSSL version from 1.0.2n to 1.0.2t.
> > 
> > Signed-off-by: Alin Gabriel Serdean 
> 
> Thanks.  Sorry I broke this.
> 
> I am amused that there is a "/verysilent" option.
> 
> Acked-by: Ben Pfaff 

Thanks! I applied to master.
William

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


Re: [ovs-dev] [PATCH v1 ovn] ovn-nb/sbctl.c: Set no-leader-only as default for clustered dbs

2019-10-09 Thread aginwala
Thanks Ben and Han. As suggested, I used env vars OVN_NBCTL_OPTIONS and
OVN_SBCTL_OPTIONS and sent the new patch @
https://patchwork.ozlabs.org/patch/1174211/. PTAL.

On Fri, Oct 4, 2019 at 10:39 AM Ben Pfaff  wrote:

> OK.
>
> I've made the points that I consider relevant.  I'll let the rest of the
> OVN community come to consensus here.
>
> On Thu, Oct 03, 2019 at 02:17:48PM -0700, aginwala wrote:
> > Thanks Han and ben for the suggestions. However, one more reason for
> using
> > this approach is because ovn-controller uses no-leader-only by default so
> > that all the chassis can be randomly distributed to talk to any node in
> the
> > cluster to avoid overloading leader node in a large scale env
> > "ovsdb_idl_set_leader_only(ovnsb_idl_loop.idl, false)"
> >
> > On Thu, Oct 3, 2019 at 12:38 PM Han Zhou  wrote:
> >
> > > On Thu, Oct 3, 2019 at 11:35 AM Ben Pfaff  wrote:
> > > >
> > > > On Thu, Oct 03, 2019 at 10:19:35AM -0700, Han Zhou wrote:
> > > > > On Thu, Oct 3, 2019 at 9:09 AM Ben Pfaff  wrote:
> > > > > >
> > > > > > On Tue, Oct 01, 2019 at 05:05:28PM -0700, amgin...@gmail.com
> wrote:
> > > > > > > From: Aliasgar Ginwala 
> > > > > > >
> > > > > > > When using ovn-nb/sbctl running in cluster, one can use local
> > > > > > > socket to run different commands. It is very inconvenient to
> pass
> > > > > > > no-leader-only in different tools using ovn-nb/sbctl instead of
> > > > > > > allowing one to to connect to any nodes in the cluster
> including
> > > > > > > itself.
> > > > > > > e.g common usage ovn-nb/sbctl show.
> > > > > > > Hence, this commit handles the same.
> > > > > > >
> > > > > > > Signed-off-by: Aliasgar Ginwala 
> > > > > >
> > > > > > This change makes more of a difference than its size implies,
> because
> > > it
> > > > > > means that scripts that previously were guaranteed to get
> up-to-date
> > > > > > data can now get inconsistent results.  It loses read-after-write
> > > > > > consistency, for example.  I'd really prefer to avoid surprising
> > > users
> > > > > > with that kind of thing (especially as a change).
> > > > > >
> > > > > > If it's common to want that kind of behavior, though, perhaps
> there
> > > > > > could be a nice way to set it as the default for a session.  In
> > > daemon
> > > > > > mode, of course, it's already possible to control it for the
> daemon's
> > > > > > users.  One option for outside daemon mode might be to introduce
> an
> > > > > > environment variable.  The environment variable could be
> specific to
> > > > > > this feature, e.g. OVN_LEADER_ONLY=0 or OVN_LEADER_ONLY=1, or it
> > > could
> > > > > > be a general-purpose options variable,
> > > > > > e.g. OVN_OPTIONS=--no-leader-only.  I don't know whether it
> should be
> > > > > > specific to one of ovn-sbctl and ovn-nbctl or apply to both.
> > > > > >
> > > > > > Have you thought about these possibilities?
> > > > > >
> > > > > Thanks Ben for the comments. Let's compare the pros and cons of
> each
> > > > > solution:
> > > >
> > > > Thank you for listing the pros and cons.  I agree with them.
> > > >
> > > > One factor that is not completely captured by your list is the
> effect on
> > > > transitioning deployments from standalone to clustered.  Currently,
> this
> > > > should not have surprising effects: one would just replace the single
> > > > database URL by a comma-separated list and it will continue to work,
> > > > just more reliably.  If the default changes to --no-leader-only, then
> > > > each use of ovn-nbctl and ovn-sbctl in the deployment requires some
> > > > thought.
> > > >
> > > > I have one comment that's really about the patch rather than the pros
> > > > and cons, but I didn't mention it earlier and I should have.  It's
> > > > related to this.
> > > >
> > > > > cons: There are *small* chances that inconsistent (stale) data can
> be
> > > read
> > > > > by the existing tools (except daemon mode, because this patch
> enforces
> > > > > leader-only as default for daemon mode). [...]
> > > >
> > > > I believe the patch does something like "daemon_mode = true;
> leader_only
> > > > = true;" for --daemon-mode.  I think this is a bad idea because it
> means
> > > > that "--no-leader-only --daemon-mode" will not have the intended
> > > > effect.  Instead, we should start out with "leader_only = -1;" and
> then
> > > > after parsing options do something like "if (leader_only < 0) {
> > > > leader_only = daemon_mode; }".
> > > >
> > > Thanks for the finding!
> > >
> > > > > I just listed the pros and cons for discussion. I don't have a
> strong
> > > > > opinion which way is the best. (The number of pros/cons doesn't
> > > necessarily
> > > > > mean it is better/worse)
> > > >
> > > > I don't have a strong opinion either, but I want to make sure that
> the
> > > > implications receive some discussion.
> > >
> > > Overall, the --no-leader-only is for convenience. In most cases when
> > > executing ovn-nb/sbctl it is read-only using default OVN_NB/SB_DB
> which is
> > > the 

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

2019-10-09 Thread amginwal
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 any single
supported option. e.g export OVN_NBCTL_OPTIONS=--no-leader-only.
Above env var OVN_NBCTL_OPTIONS have no effect if user runs
command as ovn-nbctl --no-leader-only 

Signed-off-by: Aliasgar Ginwala 
---
 utilities/ovn-nbctl.8.xml |  7 +++
 utilities/ovn-nbctl.c | 36 ++--
 utilities/ovn-sbctl.8.in  |  6 ++
 utilities/ovn-sbctl.c | 36 ++--
 4 files changed, 81 insertions(+), 4 deletions(-)

diff --git a/utilities/ovn-nbctl.8.xml b/utilities/ovn-nbctl.8.xml
index fd75c0e44..6a7962973 100644
--- a/utilities/ovn-nbctl.8.xml
+++ b/utilities/ovn-nbctl.8.xml
@@ -1178,6 +1178,13 @@
   wait at all.  Use the sync command to override this
   behavior.
 
+
+
+  If the OVN_NBCTL_OPTIONS environment variable is set,
+  its value is used as the default to set above options. If user
+  passes options via cli, OVN_NBCTL_OPTIONS environment
+  variable will have no effect.
+
   
 
 --db database
diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
index a89a9cb4d..8d2bc0968 100644
--- a/utilities/ovn-nbctl.c
+++ b/utilities/ovn-nbctl.c
@@ -124,18 +124,49 @@ static char * OVS_WARN_UNUSED_RESULT main_loop(const char 
*args,
 static void server_loop(struct ovsdb_idl *idl, int argc, char *argv[]);
 
 int
-main(int argc, char *argv[])
+main(int argc, char *argv_[])
 {
 struct ovsdb_idl *idl;
 struct shash local_options;
 
-set_program_name(argv[0]);
+set_program_name(argv_[0]);
 fatal_ignore_sigpipe();
 vlog_set_levels(NULL, VLF_CONSOLE, VLL_WARN);
 vlog_set_levels_from_string_assert("reconnect:warn");
 
 nbctl_cmd_init();
 
+/* Check if options are set via env var. */
+static int ops_passed = false;
+int i, j = 0;
+char *ovn_nbctl_options = getenv("OVN_NBCTL_OPTIONS");
+char **argv = xcalloc(argc + 1, sizeof( *argv_) + 1);
+if (ovn_nbctl_options) {
+for (i = 0; i < argc; i++) {
+if (strcmp(argv_[i], ovn_nbctl_options) == 0) {
+ops_passed = true;
+break;
+}
+}
+/* if option not passed via cli, read env var set by user.*/
+if (!ops_passed) {
+for (i = 0, j = 0; i < argc; i++, j++) {
+if (j == 1) {
+argv[j] = ovn_nbctl_options;
+j++;
+}
+argv[j] = xstrdup(argv_[i]);
+}
+argc = j;
+}
+}
+if (ops_passed || !ovn_nbctl_options) {
+/* Copy args for parsing as is from argv_ */
+for (i = 0; i < argc; i++) {
+argv[i] = xstrdup(argv_[i]);
+}
+}
+
 /* ovn-nbctl has three operation modes:
  *
  *- Direct: Executes commands by contacting ovsdb-server directly.
@@ -240,6 +271,7 @@ main(int argc, char *argv[])
 idl = the_idl = NULL;
 
 free(args);
+free(argv);
 exit(EXIT_SUCCESS);
 }
 
diff --git a/utilities/ovn-sbctl.8.in b/utilities/ovn-sbctl.8.in
index 2aaa457e8..b9cfde897 100644
--- a/utilities/ovn-sbctl.8.in
+++ b/utilities/ovn-sbctl.8.in
@@ -93,6 +93,12 @@ to approximately \fIsecs\fR seconds.  If the timeout expires,
 would normally happen only if the database cannot be contacted, or if
 the system is overloaded.)
 .
+.IP "\fBOVN_SBCTL_OPTIONS\fR"
+If \fBOVN_SBCTL_OPTIONS\fR environment variable is set,
+its value is used as the default to set above options. If user
+passes options via cli, \fBOVN_SBCTL_OPTIONS\fR environment
+variable will have no effect.
+.
 .so lib/vlog.man
 .so lib/common.man
 .
diff --git a/utilities/ovn-sbctl.c b/utilities/ovn-sbctl.c
index 9a9b6f0ec..51bfe7101 100644
--- a/utilities/ovn-sbctl.c
+++ b/utilities/ovn-sbctl.c
@@ -93,7 +93,7 @@ static bool do_sbctl(const char *args, struct ctl_command *, 
size_t n,
  struct ovsdb_idl *);
 
 int
-main(int argc, char *argv[])
+main(int argc, char *argv_[])
 {
 struct ovsdb_idl *idl;
 struct ctl_command *commands;
@@ -101,13 +101,44 @@ main(int argc, char *argv[])
 unsigned int seqno;
 size_t n_commands;
 
-set_program_name(argv[0]);
+set_program_name(argv_[0]);
 fatal_ignore_sigpipe();
 vlog_set_levels(NULL, VLF_CONSOLE, VLL_WARN);
 vlog_set_levels_from_string_assert("reconnect:warn");
 
 sbctl_cmd_init();
 
+/* Check if options are set via env var. */
+static int ops_passed = false;
+int i, j = 0;
+char *ovn_sbctl_options = getenv("OVN_SBCTL_OPTIONS");
+char **argv = xcalloc(argc + 1, sizeof( *argv_) + 1);
+if (ovn_sbctl_options) {
+for (i = 0; i < argc; i++) {
+if (strcmp(argv_[i], ovn_sbctl_options) == 0) {
+ops_passed = true;
+break;
+}
+}
+/

Re: [ovs-dev] [PATCH] tests: Allow valgrind check for afxdp testsuite.

2019-10-09 Thread William Tu
On Wed, Oct 09, 2019 at 11:20:00AM -0700, Ben Pfaff wrote:
> On Wed, Oct 09, 2019 at 04:36:49PM +0200, Ilya Maximets wrote:
> > New 'make' target 'check-afxdp-valgrind'.
> > 
> > Signed-off-by: Ilya Maximets 
> 
> Makes sense to me.  I did not test it.
> 
> Acked-by: Ben Pfaff 

Thanks, I tested the script and it works ok.
(Although some test cases fail, I'm looking at it).

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


Re: [ovs-dev] [PATCH] Fix "the the" typo in two places.

2019-10-09 Thread Ben Pfaff
On Wed, Oct 09, 2019 at 03:40:55PM -0700, Gregory Rose wrote:
> 
> On 10/9/2019 2:30 PM, Ben Pfaff wrote:
> > Signed-off-by: Ben Pfaff 
> > ---
> >   Documentation/topics/testing.rst | 2 +-
> >   acinclude.m4 | 2 +-
> >   2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/topics/testing.rst 
> > b/Documentation/topics/testing.rst
> > index 6c93826fbc40..31433c591744 100644
> > --- a/Documentation/topics/testing.rst
> > +++ b/Documentation/topics/testing.rst
> > @@ -424,7 +424,7 @@ Instructions to setup travis-ci for your GitHub 
> > repository:
> >  builds for pushes or pull requests.
> >   3. In order to avoid forks sending build failures to the upstream mailing 
> > list,
> >  the notification email recipient is encrypted. If you want to receive 
> > email
> > -   notification for build failures, replace the the encrypted string:
> > +   notification for build failures, replace the encrypted string:
> >  1. Install the travis-ci CLI (Requires ruby >=2.0): gem install travis
> >  2. In your Open vSwitch repository: travis encrypt myl...@mydomain.org
> > diff --git a/acinclude.m4 b/acinclude.m4
> > index 066c134d2735..52f92870eaaa 100644
> > --- a/acinclude.m4
> > +++ b/acinclude.m4
> > @@ -1211,7 +1211,7 @@ AC_DEFUN([OVS_CHECK_SPARSE_TARGET],
> >[x86_64], [SPARSEFLAGS=-m64 CGCCFLAGS="-target=x86_64 
> > -target=host_os_specs"],
> >[SPARSEFLAGS= CGCCFLAGS=])
> > -   dnl Get the the default defines for vector instructions from compiler to
> > +   dnl Get the default defines for vector instructions from compiler to
> >  dnl allow "sparse" correctly check the same code that will be built.
> >  dnl Required for checking DPDK headers.
> >  AC_MSG_CHECKING([vector options for cgcc])
> 
> Looks good Ben.
> 
> Thanks,
> 
> Reviewed-by: Greg Rose 

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


Re: [ovs-dev] [PATCH] Fix "the the" typo in two places.

2019-10-09 Thread Gregory Rose



On 10/9/2019 2:30 PM, Ben Pfaff wrote:

Signed-off-by: Ben Pfaff 
---
  Documentation/topics/testing.rst | 2 +-
  acinclude.m4 | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/topics/testing.rst b/Documentation/topics/testing.rst
index 6c93826fbc40..31433c591744 100644
--- a/Documentation/topics/testing.rst
+++ b/Documentation/topics/testing.rst
@@ -424,7 +424,7 @@ Instructions to setup travis-ci for your GitHub repository:
 builds for pushes or pull requests.
  3. In order to avoid forks sending build failures to the upstream mailing 
list,
 the notification email recipient is encrypted. If you want to receive email
-   notification for build failures, replace the the encrypted string:
+   notification for build failures, replace the encrypted string:
  
 1. Install the travis-ci CLI (Requires ruby >=2.0): gem install travis

 2. In your Open vSwitch repository: travis encrypt myl...@mydomain.org
diff --git a/acinclude.m4 b/acinclude.m4
index 066c134d2735..52f92870eaaa 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -1211,7 +1211,7 @@ AC_DEFUN([OVS_CHECK_SPARSE_TARGET],
   [x86_64], [SPARSEFLAGS=-m64 CGCCFLAGS="-target=x86_64 
-target=host_os_specs"],
   [SPARSEFLAGS= CGCCFLAGS=])
  
-   dnl Get the the default defines for vector instructions from compiler to

+   dnl Get the default defines for vector instructions from compiler to
 dnl allow "sparse" correctly check the same code that will be built.
 dnl Required for checking DPDK headers.
 AC_MSG_CHECKING([vector options for cgcc])


Looks good Ben.

Thanks,

Reviewed-by: Greg Rose 


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


Re: [ovs-dev] [PATCH 4/5] datapath: rename flow_stats to sw_flow_stats

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

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


checkpatch:
ERROR: Author Pablo Neira Ayuso  needs to sign off.
WARNING: Unexpected sign-offs from developers who are not authors or co-authors 
or committers: Greg Rose 
Lines checked: 135, Warnings: 1, Errors: 1


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 3/5] compat: remove the incorrect mtu limit for erspan

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

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


checkpatch:
ERROR: Author Haishuang Yan  needs to sign 
off.
WARNING: Unexpected sign-offs from developers who are not authors or co-authors 
or committers: Greg Rose 
Lines checked: 57, Warnings: 1, Errors: 1


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 2/5] datapath: change type of UPCALL_PID attribute to NLA_UNSPEC

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

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


checkpatch:
ERROR: Author Li RongQing  needs to sign off.
WARNING: Unexpected sign-offs from developers who are not authors or co-authors 
or committers: Greg Rose 
Lines checked: 51, Warnings: 1, Errors: 1


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 1/5] datapath: hide clang frame-overflow warnings

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

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


checkpatch:
ERROR: Author Arnd Bergmann  needs to sign off.
WARNING: Unexpected sign-offs from developers who are not authors or co-authors 
or committers: Greg Rose 
Lines checked: 75, Warnings: 1, Errors: 1


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


[ovs-dev] [PATCH] Fix "the the" typo in two places.

2019-10-09 Thread Ben Pfaff
Signed-off-by: Ben Pfaff 
---
 Documentation/topics/testing.rst | 2 +-
 acinclude.m4 | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/topics/testing.rst b/Documentation/topics/testing.rst
index 6c93826fbc40..31433c591744 100644
--- a/Documentation/topics/testing.rst
+++ b/Documentation/topics/testing.rst
@@ -424,7 +424,7 @@ Instructions to setup travis-ci for your GitHub repository:
builds for pushes or pull requests.
 3. In order to avoid forks sending build failures to the upstream mailing list,
the notification email recipient is encrypted. If you want to receive email
-   notification for build failures, replace the the encrypted string:
+   notification for build failures, replace the encrypted string:
 
1. Install the travis-ci CLI (Requires ruby >=2.0): gem install travis
2. In your Open vSwitch repository: travis encrypt myl...@mydomain.org
diff --git a/acinclude.m4 b/acinclude.m4
index 066c134d2735..52f92870eaaa 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -1211,7 +1211,7 @@ AC_DEFUN([OVS_CHECK_SPARSE_TARGET],
  [x86_64], [SPARSEFLAGS=-m64 CGCCFLAGS="-target=x86_64 
-target=host_os_specs"],
  [SPARSEFLAGS= CGCCFLAGS=])
 
-   dnl Get the the default defines for vector instructions from compiler to
+   dnl Get the default defines for vector instructions from compiler to
dnl allow "sparse" correctly check the same code that will be built.
dnl Required for checking DPDK headers.
AC_MSG_CHECKING([vector options for cgcc])
-- 
2.21.0

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


[ovs-dev] [PATCH 5/5] datapath: compat: drop bridge nf reset from nf_reset

2019-10-09 Thread Greg Rose
Upstream commmit:
commit 895b5c9f206eb7d25dc1360a8ccfc5958895eb89
Author: Florian Westphal 
Date:   Sun Sep 29 20:54:03 2019 +0200

netfilter: drop bridge nf reset from nf_reset

commit 174e23810cd31
("sk_buff: drop all skb extensions on free and skb scrubbing") made napi
recycle always drop skb extensions.  The additional skb_ext_del() that is
performed via nf_reset on napi skb recycle is not needed anymore.

Most nf_reset() calls in the stack are there so queued skb won't block
'rmmod nf_conntrack' indefinitely.

This removes the skb_ext_del from nf_reset, and renames it to a more
fitting nf_reset_ct().

In a few selected places, add a call to skb_ext_reset to make sure that
no active extensions remain.

I am submitting this for "net", because we're still early in the release
cycle.  The patch applies to net-next too, but I think the rename causes
needless divergence between those trees.

Suggested-by: Eric Dumazet 
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 

Added some compat layer fixups for nf_reset_ct.  This is just a portion
of the upstream commit that applies to openvswitch.

Cc: Florian Westphal 
Signed-off-by: Greg Rose 
---
 acinclude.m4 | 1 +
 datapath/linux/compat/include/linux/skbuff.h | 4 
 datapath/vport-internal_dev.c| 2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/acinclude.m4 b/acinclude.m4
index c729266..b1de8c9 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -740,6 +740,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
   OVS_FIND_PARAM_IFELSE([$KSRC/include/net/rtnetlink.h],
 [rtnl_create_link], [extack],
 [OVS_DEFINE([HAVE_RTNL_CREATE_LINK_TAKES_EXTACK])])
+  OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [nf_reset_ct])
 
   # Check for the proto_data_valid member in struct sk_buff.  The [^@]
   # is necessary because some versions of this header remove the
diff --git a/datapath/linux/compat/include/linux/skbuff.h 
b/datapath/linux/compat/include/linux/skbuff.h
index 4a6ac23..6397289 100644
--- a/datapath/linux/compat/include/linux/skbuff.h
+++ b/datapath/linux/compat/include/linux/skbuff.h
@@ -452,4 +452,8 @@ static inline void skb_set_inner_ipproto(struct sk_buff 
*skb,
 }
 #endif
 
+#ifndef HAVE_NF_RESET_CT
+#define nf_reset_ct nf_reset
+#endif
+
 #endif
diff --git a/datapath/vport-internal_dev.c b/datapath/vport-internal_dev.c
index 0318f58..dbc2002 100644
--- a/datapath/vport-internal_dev.c
+++ b/datapath/vport-internal_dev.c
@@ -281,7 +281,7 @@ static netdev_tx_t internal_dev_recv(struct sk_buff *skb)
}
 
skb_dst_drop(skb);
-   nf_reset(skb);
+   nf_reset_ct(skb);
secpath_reset(skb);
 
skb->pkt_type = PACKET_HOST;
-- 
1.8.3.1

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


[ovs-dev] [PATCH 4/5] datapath: rename flow_stats to sw_flow_stats

2019-10-09 Thread Greg Rose
From: Pablo Neira Ayuso 

Upstream commit:
commit aef833c58d321f09ae4ce4467723542842ba9faf
Author: Pablo Neira Ayuso 
Date:   Fri Jul 19 18:20:13 2019 +0200

net: openvswitch: rename flow_stats to sw_flow_stats

There is a flow_stats structure defined in include/net/flow_offload.h
and a follow up patch adds #include  to
net/sch_generic.h.

This breaks compilation since OVS codebase includes net/sock.h which
pulls in linux/filter.h which includes net/sch_generic.h.

In file included from ./include/net/sch_generic.h:18:0,
 from ./include/linux/filter.h:25,
 from ./include/net/sock.h:59,
 from ./include/linux/tcp.h:19,
 from net/openvswitch/datapath.c:24

This definition takes precedence on OVS since it is placed in the
networking core, so rename flow_stats in OVS to sw_flow_stats since
this structure is contained in sw_flow.

Signed-off-by: Pablo Neira Ayuso 
Acked-by: Jiri Pirko 
Signed-off-by: David S. Miller 

Cc: Pablo Neira Ayuso 
Signed-off-by: Greg Rose 
---
 datapath/flow.c   | 8 
 datapath/flow.h   | 4 ++--
 datapath/flow_table.c | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/datapath/flow.c b/datapath/flow.c
index 46e2bac..916f7f4 100644
--- a/datapath/flow.c
+++ b/datapath/flow.c
@@ -72,7 +72,7 @@ u64 ovs_flow_used_time(unsigned long flow_jiffies)
 void ovs_flow_stats_update(struct sw_flow *flow, __be16 tcp_flags,
   const struct sk_buff *skb)
 {
-   struct flow_stats *stats;
+   struct sw_flow_stats *stats;
unsigned int cpu = smp_processor_id();
int len = skb->len + (skb_vlan_tag_present(skb) ? VLAN_HLEN : 0);
 
@@ -100,7 +100,7 @@ void ovs_flow_stats_update(struct sw_flow *flow, __be16 
tcp_flags,
if (likely(flow->stats_last_writer != -1) &&
likely(!rcu_access_pointer(flow->stats[cpu]))) {
/* Try to allocate CPU-specific stats. */
-   struct flow_stats *new_stats;
+   struct sw_flow_stats *new_stats;
 
new_stats =
kmem_cache_alloc_node(flow_stats_cache,
@@ -147,7 +147,7 @@ void ovs_flow_stats_get(const struct sw_flow *flow,
 
/* We open code this to make sure cpu 0 is always considered */
for (cpu = 0; cpu < nr_cpu_ids; cpu = cpumask_next(cpu, 
&flow->cpu_used_mask)) {
-   struct flow_stats *stats = 
rcu_dereference_ovsl(flow->stats[cpu]);
+   struct sw_flow_stats *stats = 
rcu_dereference_ovsl(flow->stats[cpu]);
 
if (stats) {
/* Local CPU may write on non-local stats, so we must
@@ -171,7 +171,7 @@ void ovs_flow_stats_clear(struct sw_flow *flow)
 
/* We open code this to make sure cpu 0 is always considered */
for (cpu = 0; cpu < nr_cpu_ids; cpu = cpumask_next(cpu, 
&flow->cpu_used_mask)) {
-   struct flow_stats *stats = ovsl_dereference(flow->stats[cpu]);
+   struct sw_flow_stats *stats = 
ovsl_dereference(flow->stats[cpu]);
 
if (stats) {
spin_lock_bh(&stats->lock);
diff --git a/datapath/flow.h b/datapath/flow.h
index 1a5df38..5560300 100644
--- a/datapath/flow.h
+++ b/datapath/flow.h
@@ -206,7 +206,7 @@ struct sw_flow_actions {
struct nlattr actions[];
 };
 
-struct flow_stats {
+struct sw_flow_stats {
u64 packet_count;   /* Number of packets matched. */
u64 byte_count; /* Number of bytes matched. */
unsigned long used; /* Last used time (in jiffies). */
@@ -228,7 +228,7 @@ struct sw_flow {
struct cpumask cpu_used_mask;
struct sw_flow_mask *mask;
struct sw_flow_actions __rcu *sf_acts;
-   struct flow_stats __rcu *stats[]; /* One for each CPU.  First one
+   struct sw_flow_stats __rcu *stats[]; /* One for each CPU.  First one
   * is allocated at flow creation time,
   * the rest are allocated on demand
   * while holding the 'stats[0].lock'.
diff --git a/datapath/flow_table.c b/datapath/flow_table.c
index 83ea2be..76b390e 100644
--- a/datapath/flow_table.c
+++ b/datapath/flow_table.c
@@ -85,7 +85,7 @@ void ovs_flow_mask_key(struct sw_flow_key *dst, const struct 
sw_flow_key *src,
 struct sw_flow *ovs_flow_alloc(void)
 {
struct sw_flow *flow;
-   struct flow_stats *stats;
+   struct sw_flow_stats *stats;
 
flow = kmem_cache_zalloc(flow_cache, GFP_KERNEL);
if (!flow)
@@ -953,13 +953,13 @@ int ovs_flow_init(void)
 
flow_cache = kmem_cache_create("sw_flow", sizeof(struct sw_flow)
   + (nr_cpu_ids
-  

[ovs-dev] [PATCH 3/5] compat: remove the incorrect mtu limit for erspan

2019-10-09 Thread Greg Rose
From: Haishuang Yan 

Upstream commit:
commit 0e141f757b2c78c983df893e9993313e2dc21e38
Author: Haishuang Yan 
Date:   Fri Sep 27 14:58:20 2019 +0800

erspan: remove the incorrect mtu limit for erspan

erspan driver calls ether_setup(), after commit 61e84623ace3
("net: centralize net_device min/max MTU checking"), the range
of mtu is [min_mtu, max_mtu], which is [68, 1500] by default.

It causes the dev mtu of the erspan device to not be greater
than 1500, this limit value is not correct for ipgre tap device.

Tested:
Before patch:
# ip link set erspan0 mtu 1600
Error: mtu greater than device maximum.
After patch:
# ip link set erspan0 mtu 1600
# ip -d link show erspan0
21: erspan0@NONE:  mtu 1600 qdisc noop state DOWN
mode DEFAULT group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 
68 maxmtu 0

Fixes: 61e84623ace3 ("net: centralize net_device min/max MTU checking")
Signed-off-by: Haishuang Yan 
Signed-off-by: David S. Miller 

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

diff --git a/datapath/linux/compat/ip_gre.c b/datapath/linux/compat/ip_gre.c
index 2015d59..2852dad 100644
--- a/datapath/linux/compat/ip_gre.c
+++ b/datapath/linux/compat/ip_gre.c
@@ -1099,6 +1099,9 @@ static void erspan_setup(struct net_device *dev)
 
eth_hw_addr_random(dev);
ether_setup(dev);
+#ifdef HAVE_NET_DEVICE_MAX_MTU
+   dev->max_mtu = 0;
+#endif
dev->netdev_ops = &erspan_netdev_ops;
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
-- 
1.8.3.1

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


[ovs-dev] [PATCH 2/5] datapath: change type of UPCALL_PID attribute to NLA_UNSPEC

2019-10-09 Thread Greg Rose
From: Li RongQing 

Upstream commit:
commit ea8564c865299815095bebeb4b25bef474218e4c
Author: Li RongQing 
Date:   Tue Sep 24 19:11:52 2019 +0800

openvswitch: change type of UPCALL_PID attribute to NLA_UNSPEC

userspace openvswitch patch "(dpif-linux: Implement the API
functions to allow multiple handler threads read upcall)"
changes its type from U32 to UNSPEC, but leave the kernel
unchanged

and after kernel 6e237d099fac "(netlink: Relax attr validation
for fixed length types)", this bug is exposed by the below
warning

[   57.215841] netlink: 'ovs-vswitchd': attribute type 5 has an invalid 
length.

Fixes: 5cd667b0a456 ("openvswitch: Allow each vport to have an array of 
'port_id's")
Signed-off-by: Li RongQing 
Acked-by: Pravin B Shelar 
Signed-off-by: David S. Miller 

Fixes: beb1c69a3 ("datapath: Allow each vport to have an array of 'port_id's.")
Cc: Li RongQing 
Signed-off-by: Greg Rose 
---
 datapath/datapath.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/datapath/datapath.c b/datapath/datapath.c
index 15af156..a787276 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -2269,7 +2269,7 @@ static const struct nla_policy 
vport_policy[OVS_VPORT_ATTR_MAX + 1] = {
[OVS_VPORT_ATTR_STATS] = { .len = sizeof(struct ovs_vport_stats) },
[OVS_VPORT_ATTR_PORT_NO] = { .type = NLA_U32 },
[OVS_VPORT_ATTR_TYPE] = { .type = NLA_U32 },
-   [OVS_VPORT_ATTR_UPCALL_PID] = { .type = NLA_U32 },
+   [OVS_VPORT_ATTR_UPCALL_PID] = { .type = NLA_UNSPEC },
[OVS_VPORT_ATTR_OPTIONS] = { .type = NLA_NESTED },
[OVS_VPORT_ATTR_IFINDEX] = { .type = NLA_U32 },
[OVS_VPORT_ATTR_NETNSID] = { .type = NLA_S32 },
-- 
1.8.3.1

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


[ovs-dev] [PATCH 1/5] datapath: hide clang frame-overflow warnings

2019-10-09 Thread Greg Rose
From: Arnd Bergmann 

Upstream commit:
commit 260637903f47f20c5918bb5c1eea52b2a28ea863
Author: Arnd Bergmann 
Date:   Mon Jul 22 17:00:01 2019 +0200

ovs: datapath: hide clang frame-overflow warnings

Some functions in the datapath code are factored out so that each
one has a stack frame smaller than 1024 bytes with gcc. However,
when compiling with clang, the functions are inlined more aggressively
and combined again so we get

net/openvswitch/datapath.c:1124:12: error: stack frame size of 1528 bytes 
in function 'ovs_flow_cmd_set' [-Werror,-Wframe-larger-than=]

Marking both get_flow_actions() and ovs_nla_init_match_and_action()
as 'noinline_for_stack' gives us the same behavior that we see with
gcc, and no warning. Note that this does not mean we actually use
less stack, as the functions call each other, and we still get
three copies of the large 'struct sw_flow_key' type on the stack.

The comment tells us that this was previously considered safe,
presumably since the netlink parsing functions are called with
a known backchain that does not also use a lot of stack space.

Fixes: 9cc9a5cb176c ("datapath: Avoid using stack larger than 1024.")
Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 

Cc: Arnd Bergmann 
Signed-off-by: Greg Rose 
---
 datapath/datapath.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/datapath/datapath.c b/datapath/datapath.c
index 94e4f6f..15af156 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -1069,7 +1069,7 @@ error:
 }
 
 /* Factor out action copy to avoid "Wframe-larger-than=1024" warning. */
-static struct sw_flow_actions *get_flow_actions(struct net *net,
+static noinline_for_stack struct sw_flow_actions *get_flow_actions(struct net 
*net,
const struct nlattr *a,
const struct sw_flow_key *key,
const struct sw_flow_mask *mask,
@@ -1103,12 +1103,13 @@ static struct sw_flow_actions *get_flow_actions(struct 
net *net,
  * we should not to return match object with dangling reference
  * to mask.
  * */
-static int ovs_nla_init_match_and_action(struct net *net,
-struct sw_flow_match *match,
-struct sw_flow_key *key,
-struct nlattr **a,
-struct sw_flow_actions **acts,
-bool log)
+static noinline_for_stack int
+ovs_nla_init_match_and_action(struct net *net,
+ struct sw_flow_match *match,
+ struct sw_flow_key *key,
+ struct nlattr **a,
+ struct sw_flow_actions **acts,
+ bool log)
 {
struct sw_flow_mask mask;
int error = 0;
-- 
1.8.3.1

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


[ovs-dev] [PATCH 0/5] Backport upstream Linux kernel patches

2019-10-09 Thread Greg Rose
Pull in upstream kernel patches not related to conntrack and
add compatibility layer code where needed.

The upstream conntrack related patches will come later from Yi-Hung.

Passes Travis:
https://travis-ci.org/gvrose8192/ovs-experimental/builds/595755449

Passes check-kmod with no regressions on Ubuntu 16.04 and 18.04

Arnd Bergmann (1):
  datapath: hide clang frame-overflow warnings

Greg Rose (1):
  datapath: compat: drop bridge nf reset from nf_reset

Haishuang Yan (1):
  compat: remove the incorrect mtu limit for erspan

Li RongQing (1):
  datapath: change type of UPCALL_PID attribute to NLA_UNSPEC

Pablo Neira Ayuso (1):
  datapath: rename flow_stats to sw_flow_stats

 acinclude.m4 |  1 +
 datapath/datapath.c  | 17 +
 datapath/flow.c  |  8 
 datapath/flow.h  |  4 ++--
 datapath/flow_table.c|  6 +++---
 datapath/linux/compat/include/linux/skbuff.h |  4 
 datapath/linux/compat/ip_gre.c   |  3 +++
 datapath/vport-internal_dev.c|  2 +-
 8 files changed, 27 insertions(+), 18 deletions(-)

-- 
1.8.3.1

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


Re: [ovs-dev] [PATCH 0/1] Encap & Decap actions for MPLS Packet Type

2019-10-09 Thread Ben Pfaff
On Tue, Oct 08, 2019 at 08:13:16AM +0530, Martin Varghese wrote:
> The existing PUSH MPLS & POP MPLS actions inserts & removes MPLS header
> between ethernet header and the IP header. Though this behaviour is fine
> for L3 VPN where an IP packet is encapsulated inside a MPLS tunnel, it does
> not suffice the L2 VPN requirements. In L2 VPN the ethernet packets must be
> encapsulated inside MPLS tunnel.

Thanks a lot for working to make OVS better.

I have a few minor comments on the code.  I didn't look at it in detail.

This patch adds a few lines that exceed the normal 79-column limit.
checkpatch reports those.  It's better to wrap lines to fit.

The compiler reports a few warnings that should be fixed:

../ofproto/ofproto-dpif-ipfix.c:2980:17: error: enumeration values 
'OVS_ACTION_ATTR_PTAP_PUSH_MPLS' and 'OVS_ACTION_ATTR_PTAP_POP_MPLS' not 
explicitly handled in switch [-Werror,-Wswitch-enum]
../ofproto/ofproto-dpif-sflow.c:1130:17: error: enumeration values 
'OVS_ACTION_ATTR_PTAP_PUSH_MPLS' and 'OVS_ACTION_ATTR_PTAP_POP_MPLS' not 
explicitly handled in switch [-Werror,-Wswitch-enum]

The biggest issue, however, is a process one.  Updates to the kernel
module need to go upstream to net-next before we put them into the OVS
tree.  Have you submitted them there yet?

It also would be a good idea to implement this in the OVS userspace
datapath.

I suggest adding an item to NEWS to mention the new feature.

Thanks,

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


Re: [ovs-dev] [PATCH] ofproto: Fix for frequent invalidation of mega flows for push actions

2019-10-09 Thread Ben Pfaff
On Wed, Oct 09, 2019 at 02:06:30PM +0530, Vishal Deep Ajmera via dev wrote:
> When a packet is processed by the slow path and the matching OpenFlow
> rule has actions like push_mpls/set_field and push_vlan/set_field, the
> ofproto layer un-wildcards the MPLS and VLAN match fields in the megaflow
> entry that it plans to install. However, when the megaflow entry is
> actually installed, all protocol match fields that are not present in the
> packet are wildcarded. Thus, the wildcard bits in the installed megaflow
> entry could be different from the bits originally generated by the ofproto
> layer.
> 
> When the revalidator thread validates a megaflow, it will first query the
> ofproto layer to get the wildcard bits and then compare it against the
> wildcard bits in the megaflow. If the bits are different the entry will be
> removed.  A subsequent packet will again result in the same megaflow entry
> being installed only for it to be removed by the revalidator thread. This
> cycle will continue and will significantly degrade performance.
> 
> This patch fixes the issue by wildcarding flow fields which are not present
> in the incoming packet.
> 
> Signed-off-by: Vishal Deep Ajmera 

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


Re: [ovs-dev] [PATCH] tests: Allow valgrind check for afxdp testsuite.

2019-10-09 Thread Ben Pfaff
On Wed, Oct 09, 2019 at 04:36:49PM +0200, Ilya Maximets wrote:
> New 'make' target 'check-afxdp-valgrind'.
> 
> Signed-off-by: Ilya Maximets 

Makes sense to me.  I did not test it.

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


Re: [ovs-dev] [PATCH] flow: Fix using pointer to member of packed struct icmp6_hdr.

2019-10-09 Thread Ben Pfaff
On Wed, Oct 09, 2019 at 06:54:29PM +0200, Ilya Maximets wrote:
> On 08.10.2019 18:55, William Tu wrote:
> > On Tue, Oct 01, 2019 at 08:04:00PM +0300, Ilya Maximets wrote:
> > > OVS has no structure definition for ICMPv6 header with additional
> > > data. More precisely, it has, but this structure named as
> > > 'icmp6_error_header' and only suitable to store error related
> > > extended information.  'flow_compose_l4' stores additional
> > > information in reserved bits by using system defined structure
> > > 'icmp6_hdr', which is marked as 'packed' and this leads to
> > > build failure with gcc >= 9:
> > > 
> > >lib/flow.c:3041:34: error:
> > >  taking address of packed member of 'struct icmp6_hdr' may result
> > >  in an unaligned pointer value [-Werror=address-of-packed-member]
> > > 
> > >  uint32_t *reserved = &icmp->icmp6_dataun.icmp6_un_data32[0];
> > >   ^~
> > > Fix that by renaming 'icmp6_error_header' to 'icmp6_data_header'
> > > and allowing it to store not only errors, but any type of additional
> > > information by analogue with 'struct icmp6_hdr'.
> > > All the usages of 'struct icmp6_hdr' replaced with this new structure.
> > > Removed redundant conversions between network and host representations.
> > > Now fields are always in be.
> > > 
> > > This also, probably, makes flow_compose_l4 more robust by avoiding
> > > possible unaligned accesses to 32 bit value.
> > > 
> > > Fixes: 9b2b84973db7 ("Support for match & set ICMPv6 reserved and options 
> > > type fields")
> > > Signed-off-by: Ilya Maximets 
> > 
> > Looks good to me! Thanks.
> > Tested on travis and cirrus.
> > 
> > Acked-by: William Tu 
> 
> Thanks, William!
> 
> Ben, could you, please, take a look at this too?
> 
> I just want to be sure that this change is aligned with
> expectations from the network header structures in OVS.

It seems like a positive change.  We used to have periodic problems with
misaligned accesses on RISC architectures and moving to the 16aligned_*
types, while annoying in some ways, has avoided those.  This change is
helpful because it updates a struct that somehow had been missed
previously.

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


Re: [ovs-dev] [PATCH lib: v2] Avoid clobbered variable warning on ppc64le.

2019-10-09 Thread Ben Pfaff
On Tue, Oct 08, 2019 at 12:40:19PM -0700, David Wilder wrote:
> Since commit e2ed6fbeb1, Ci on ppc64le with Ubuntu 16.04.6 LTS throws
> this error:
> 
> lib/fatal-signal.c: In function 'send_backtrace_to_monitor':
> lib/fatal-signal.c:168:9: error: variable 'dep' might be clobbered by
> 'longjmp' or 'vfork' [-Werror=clobbered]
>  int dep;
> 
> Declaring dep as a volatile int.
> 
> Signed-off-by: David Wilder 

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


Re: [ovs-dev] [PATCH 1/1] ovsdb-client: fix memory leak while executing database backup

2019-10-09 Thread Ben Pfaff
On Wed, Oct 09, 2019 at 08:34:24AM +0200, Damijan Skvarc wrote:
> valgrind detects this leak while running functional test "ovsdb-client backup 
> and restore"

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


Re: [ovs-dev] [PATCH] netdev-offload: replace netdev_hmap_mutex to netdev_hmap_rwlock

2019-10-09 Thread Ben Pfaff
On Wed, Oct 09, 2019 at 03:01:00PM +0800, we...@ucloud.cn wrote:
> From: wenxu 
> 
> All the kmap lookup operations netdev_ports_flow_del, netdev_ports_get
> netdev_ifindex_to_odp_port should protected by rdlock without
> affect each other in the handlers and revalidators
> 
> Signed-off-by: wenxu 

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


[ovs-dev] [PATCH] debian: Update list of copyright holders.

2019-10-09 Thread Ben Pfaff
The list of copyright holders was incomplete and out of date.  This
updates it based on a "grep" for copyright notices, which I reviewed by
hand.

CC: 942...@bugs.debian.org
Reported-by: Chris Lamb 
Reported-at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942056
Signed-off-by: Ben Pfaff 
---
 debian/copyright.in | 80 -
 1 file changed, 64 insertions(+), 16 deletions(-)

diff --git a/debian/copyright.in b/debian/copyright.in
index 9ad00340f6bb..3669255c75cd 100644
--- a/debian/copyright.in
+++ b/debian/copyright.in
@@ -8,22 +8,70 @@ Upstream Authors (from AUTHORS):
 
 Upstream Copyright Holders:
 
-Copyright (c) 2007, 2008, 2009, 2010, 2011, 2012, 2013 Nicira, Inc.
-Copyright (c) 2010 Jean Tourrilhes - HP-Labs.
-Copyright (c) 2008,2009,2010 Citrix Systems, Inc.
-and authors listed above.
-Copyright (c) 2011 Gaetano Catalli
-Copyright (C) 2000-2003 Geoffrey Wossum (gwos...@acm.org)
-Copyright (C) 2000 The NetBSD Foundation, Inc.
-Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
-Copyright (c) 1982, 1986, 1990, 1993 The Regents of the University of 
California.
-Copyright (c) 2008, 2012 Vincent Bernat 
-Copyright (c) 2014 Michael Chapman
-Copyright (c) 2014 WindRiver, Inc.
-Copyright (c) 2014 Avaya, Inc.
-Copyright (c) 2001 Daniel Hartmeier
-Copyright (c) 2002 - 2008 Henning Brauer
-Copyright (c) 2012 Gleb Smirnoff 
+6WIND S.A.
+Alexandru Copot , with support from IXIA.
+Alexey I. Froloff.
+Amir Vadai 
+Arm Limited
+Avaya, Inc.
+Benjamin Kosnik 
+Cisco Systems, Inc
+Citrix Systems, Inc.
+Cloudbase Solutions Srl
+Cumulus Netowkrs
+Daniel Baluta 
+Daniel Hartmeier
+Dan Nicholson 
+Dustin J. Mitchell 
+Ed Maste
+Eelco Chaudron
+Ericsson AB
+Free Software Foundation, Inc.,
+Gaetano Catalli
+Gary S. Brown.
+Geoffrey Wossum (gwos...@acm.org)
+Gleb Smirnoff 
+Grant Jenks
+Henning Brauer
+Hewlett Packard Enterprise Development LP
+Horms Solutions Ltd.
+IBM
+Ilya Maximets 
+Javier Fernandez-Sanguino 
+Jean Tourrilhes - HP-Labs.
+Jiri Pirko 
+Kmindg 
+Krzesimir Nowak 
+M3S, Srl - Italy
+Mark Pilgrim
+Mellanox Technologies, Ltd.
+Michael Chapman
+Moritz Klammler
+Netronome
+Nicira, Inc.
+Open Networking Foundation
+Paolo Abeni 
+Paul Norman 
+Red Hat, Inc.
+Roy Stogner 
+Samsung Electronics Co.,Ltd.
+Scott James Remnant 
+Scott Pakin 
+Siemens AG
+Sten Spans 
+Stephen Finucane 
+The Board of Trustees of The Leland Stanford Junior University
+The NetBSD Foundation, Inc.
+The Regents of the University of California.
+The University of Waikato
+USAGI/WIDE Project
+Vincent Bernat 
+VMware, Inc.
+WIDE Project.
+WindRiver, Inc.
+YAMAMOTO Takashi
+Zack Weinberg 
+Zmanda Inc. 
 
 License:
 
-- 
2.21.0

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


Re: [ovs-dev] [PATCH] flow: Fix using pointer to member of packed struct icmp6_hdr.

2019-10-09 Thread Ilya Maximets

On 08.10.2019 18:55, William Tu wrote:

On Tue, Oct 01, 2019 at 08:04:00PM +0300, Ilya Maximets wrote:

OVS has no structure definition for ICMPv6 header with additional
data. More precisely, it has, but this structure named as
'icmp6_error_header' and only suitable to store error related
extended information.  'flow_compose_l4' stores additional
information in reserved bits by using system defined structure
'icmp6_hdr', which is marked as 'packed' and this leads to
build failure with gcc >= 9:

   lib/flow.c:3041:34: error:
 taking address of packed member of 'struct icmp6_hdr' may result
 in an unaligned pointer value [-Werror=address-of-packed-member]

 uint32_t *reserved = &icmp->icmp6_dataun.icmp6_un_data32[0];
  ^~
Fix that by renaming 'icmp6_error_header' to 'icmp6_data_header'
and allowing it to store not only errors, but any type of additional
information by analogue with 'struct icmp6_hdr'.
All the usages of 'struct icmp6_hdr' replaced with this new structure.
Removed redundant conversions between network and host representations.
Now fields are always in be.

This also, probably, makes flow_compose_l4 more robust by avoiding
possible unaligned accesses to 32 bit value.

Fixes: 9b2b84973db7 ("Support for match & set ICMPv6 reserved and options type 
fields")
Signed-off-by: Ilya Maximets 


Looks good to me! Thanks.
Tested on travis and cirrus.

Acked-by: William Tu 


Thanks, William!

Ben, could you, please, take a look at this too?

I just want to be sure that this change is aligned with
expectations from the network header structures in OVS.

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


Re: [ovs-dev] [PATCH] upcall: Configure datapath max-unkeep-op through ovs-vsctl.

2019-10-09 Thread Ben Pfaff
On Wed, Oct 09, 2019 at 02:50:39PM +0800, wenxu wrote:
> 
> On 10/9/2019 1:33 AM, Ben Pfaff wrote:
> > On Tue, Oct 08, 2019 at 03:01:44PM +0800, wenxu wrote:
> >> Thx.  I  found the root cause of the bad performance  delete tc flower
> >> rule in revalidator threads.
> >>
> >> All the block is for the  netdev_hmap_mutex mutex. In the
> >> netdev_ports_get the handler with compete with revlalidator. The
> >> netdev_ifindex_to_odp_port and netdev_ports_flow_del with this mutex
> >> will bolock revalidator each other. So Maybe replace the hmap to
> >> rcuhlist is much better?  But there is no such rcuhlist utilitis in
> >> the lib
> > The cmap data structure might be better suited for this kind of use.
> > Would it solve the problem, in your view?
> 
> yes cmap can this. But I find it is more easy to solve the problem through 
> replacing
> 
> the netdev_hmap_mutex to netdev_hmap_rwlock.

OK.  That seems reasonable too.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] appveyor: Update OpenSSL link and python3 to path

2019-10-09 Thread Ben Pfaff
On Wed, Oct 09, 2019 at 05:10:08PM +0300, Alin Gabriel Serdean wrote:
> This patch fixes the appveyor build by adding the python version 3 to path
> as per:
> https://www.appveyor.com/docs/windows-images-software/#python
> 
> We also create a hardlink for python3 in the same directory to ease up scripts
> which checks for its existence.
> 
> This patch also bumps the OpenSSL version from 1.0.2n to 1.0.2t.
> 
> Signed-off-by: Alin Gabriel Serdean 

Thanks.  Sorry I broke this.

I am amused that there is a "/verysilent" option.

Acked-by: Ben Pfaff 

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


Re: [ovs-dev] [PATCH ovn v2] ovn-northd: Add static IP multicast flood configuration

2019-10-09 Thread Dumitru Ceara
On Wed, Oct 9, 2019 at 5:01 PM Mark Michelson  wrote:
>
> I've merged this to master.

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


Re: [ovs-dev] [PATCH ovn v2] ovn-northd: Add static IP multicast flood configuration

2019-10-09 Thread Mark Michelson

I've merged this to master.

On 9/24/19 4:02 AM, Dumitru Ceara wrote:

Add the following new configuration options to the
Logical_Switch_Port:options column in the OVN Northbound database:

- mcast_flood: if set to 'true' all incoming IP multicast traffic
   (except IP multicast reports) entering the switch will also be
   flooded on the logical switch port.
- mcast_flood_reports: if set to 'true' all incoming IP multicast
   entering the switch will also be flooded on the logical switch
   port. A clone of the packets is also processed by ovn-controller
   for snooping.

Add the following new configuration option to the
Logical_Router_Port:options column in the OVN Northbound database:

- mcast_flood: if set to 'true' all incoming IP multicast traffic
   (including IP multicast reports) entering the router will be also
   flooded on the logical router port.

Due to the fact that in the router pipeline multicast reports are
not treated in a special way there's no need for an explicit
'mcast_flood_reports' option for router ports.

Signed-off-by: Dumitru Ceara 

---
v2: Rebase & fix tag in ovn-nb.xml
---
  lib/mcast-group-index.h |   2 +
  northd/ovn-northd.8.xml |  30 +--
  northd/ovn-northd.c | 212 ++--
  ovn-nb.xml  |  33 
  tests/ovn.at|  81 +-
  5 files changed, 324 insertions(+), 34 deletions(-)

diff --git a/lib/mcast-group-index.h b/lib/mcast-group-index.h
index cb49ad7..ba995ba 100644
--- a/lib/mcast-group-index.h
+++ b/lib/mcast-group-index.h
@@ -28,6 +28,8 @@ enum ovn_mcast_tunnel_keys {
  OVN_MCAST_FLOOD_TUNNEL_KEY = OVN_MIN_MULTICAST,
  OVN_MCAST_UNKNOWN_TUNNEL_KEY,
  OVN_MCAST_MROUTER_FLOOD_TUNNEL_KEY,
+OVN_MCAST_MROUTER_STATIC_TUNNEL_KEY,
+OVN_MCAST_STATIC_TUNNEL_KEY,
  OVN_MIN_IP_MULTICAST,
  OVN_MAX_IP_MULTICAST = OVN_MAX_MULTICAST,
  };
diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index 0f4f1c1..429ed7e 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -954,7 +954,11 @@ output;

  A priority-100 flow that punts all IGMP packets to
  ovn-controller if IGMP snooping is enabled on the
-logical switch.
+logical switch. The flow also forwards the IGMP packets to the
+MC_MROUTER_STATIC multicast group, which
+ovn-northd populates with all the logical ports that
+have 
+:mcast_flood_reports='true'.

  


@@ -976,10 +980,15 @@ output;
  


  A priority-80 flow that forwards all unregistered IP multicast traffic
-to the MC_MROUTER_FLOOD multicast group, if any.
-Otherwise the flow drops all unregistered IP multicast packets.  This
-flow is added only if :mcast_flood_unregistered='false'.
+to the MC_STATIC multicast group, which
+ovn-northd populates with all the logical ports that
+have 
+:mcast_flood='true'. The flow also forwards
+unregistered IP multicast traffic to the MC_MROUTER_FLOOD
+multicast group, which ovn-northd populates with all the
+logical ports connected to logical routers that have
+
+:mcast_relay='true'.

  


@@ -2027,6 +2036,17 @@ output;
  


  
+  Priority-450 flow that matches unregistered IP multicast traffic
+  and sets outport to the MC_STATIC
+  multicast group, which ovn-northd populates with the
+  logical ports that have
+  
+  :mcast_flood='true'.
+
+  
+
+  
+
For distributed logical routers where one of the logical router
ports specifies a redirect-chassis, a priority-400
logical flow for each ip source/destination couple that matches the
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index f393ceb..538daa1 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -448,7 +448,12 @@ struct mcast_switch_info {
   * should be flooded to the mrouter. Only
   * applicable if flood_unregistered == false.
   */
-
+bool flood_reports; /* True if the switch has at least one port
+ * configured to flood reports.
+ */
+bool flood_static;  /* True if the switch has at least one port
+ * configured to flood traffic.
+ */
  int64_t table_size; /* Max number of IP multicast groups. */
  int64_t idle_timeout;   /* Timeout after which an idle group is
   * flushed.
@@ -466,7 +471,10 @@ struct mcast_switch_info {
  };
  
  struct mcast_router_info {

-bool relay; /* True if the router should relay IP multicast. */
+bool relay;/* True if the router should relay IP 

Re: [ovs-dev] [PATCH] appveyor: Update OpenSSL link and python3 to path

2019-10-09 Thread 0-day Robot
Bleep bloop.  Greetings Alin Gabriel Serdean, I am a robot and I have tried out 
your patch.
Thanks for your contribution.

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


checkpatch:
WARNING: Line is 93 characters long (recommended limit is 79)
#29 FILE: appveyor.yml:8:
- ps: New-Item -Type HardLink -Path "C:\Python37\python3.exe" -Value 
"C:\Python37\python.exe"

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


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


[ovs-dev] Lieber Geliebter in Christus,

2019-10-09 Thread aa zz via dev
Lieber Geliebter in Christus,
ICH BRINGE KALVARISCHE GRÜSSE
Ich bin Frau Angelica Louise aus Kap Verde, ich bin mit Herrn Teo J Louise 
verheiratet, ich und mein verstorbener Ehemann waren vor dem Tod meines 
Ehemanns in der Nachlassverwaltung und auch in einem staatlichen 
Nachlassbauunternehmen. Wir waren elf Jahre ohne Kind verheiratet, weil ich ein 
Faserproblem hatte. Er starb nach einer kurzen Krankheit, die nur vier Tage 
dauerte.
Vor seinem Tod wurden wir beide wieder christlich geboren. Seit dem Tod meines 
Mannes wurde bei mir Speiseröhrenkrebs diagnostiziert. Als mein verstorbener 
Ehemann noch lebte, zahlte er 3,5 Millionen US-Dollar bei einer Bank ein.
Derzeit ist das Geld noch auf der Bank. Vor kurzem sagte mir mein Arzt, dass 
ich wegen eines Krebsleiden die nächsten vier Monate nicht durchhalten würde. 
Aus allen Anzeichen geht hervor, dass sich mein Zustand wirklich 
verschlechtert, und es ist offensichtlich, dass ich nicht länger als zwei 
Monate lebe, da das Krebsstadium ein sehr gefährliches Stadium erreicht hat.
Nachdem ich meinen Zustand gekannt hatte, entschloss ich mich, diesen Fonds an 
eine gute Person zu spenden, die dieses Geld so verwendet, wie ich es hier 
anweisen werde. Ich möchte, dass Sie mindestens 80% dieses Fonds für 
Waisenhäuser, Witwen und die Verbreitung des Wortes Gottes verwenden und mich 
bemühen, dass das Haus Gottes erhalten bleibt, und die verbleibenden 20% für 
die gute Pflege Ihres von Gott gegebenen Hauses aufbringen. Ich habe diese 
Entscheidung getroffen, weil ich kein Kind habe, das dieses Geld erbt.
Aus diesem Grund entscheide ich mich, diesen Fonds für wohltätige Zwecke zu 
spenden. Ich habe keine Angst vor dem Tod, daher weiß ich, wohin ich gehe. Ich 
weiß, dass ich in der Brust des Herrn sein werde. 2. Mose 14 VS 14 sagt, dass 
"der Herr meinen Fall bekämpfen wird und ich meinen Frieden bewahren werde". 
Ich brauche diesbezüglich aus gesundheitlichen Gründen keine Telefonverbindung 
Glück ist, dass ich ein Leben eines würdigen Christen geführt habe. Wer dem 
Herrn dienen will, muss ihm im Geiste und in der Wahrheit dienen. Sei immer 
dein ganzes Leben lang betend. Schreiben Sie mir umgehend unter dieser E-Mail 
Adresse, und jede Verzögerung Ihrer Antwort gibt mir Raum, eine andere gute 
Person für denselben Zweck zu finden.
Versichere mir, dass du dementsprechend handeln wirst, wie ich es hier 
angegeben habe.
In der Hoffnung, Ihre E-Mail zu erhalten antworte über diese meine private 
email adresse; angelicalouise2...@yahoo.com
Danke und bleibe im Herrn gesegnet.
lch bleibe deine Schwester in Christus.
Frau Angelica Louise.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] Lieber Geliebter in Christus,

2019-10-09 Thread aa zz via dev
Lieber Geliebter in Christus,
ICH BRINGE KALVARISCHE GRÜSSE
Ich bin Frau Angelica Louise aus Kap Verde, ich bin mit Herrn Teo J Louise 
verheiratet, ich und mein verstorbener Ehemann waren vor dem Tod meines 
Ehemanns in der Nachlassverwaltung und auch in einem staatlichen 
Nachlassbauunternehmen. Wir waren elf Jahre ohne Kind verheiratet, weil ich ein 
Faserproblem hatte. Er starb nach einer kurzen Krankheit, die nur vier Tage 
dauerte.
Vor seinem Tod wurden wir beide wieder christlich geboren. Seit dem Tod meines 
Mannes wurde bei mir Speiseröhrenkrebs diagnostiziert. Als mein verstorbener 
Ehemann noch lebte, zahlte er 3,5 Millionen US-Dollar bei einer Bank ein.
Derzeit ist das Geld noch auf der Bank. Vor kurzem sagte mir mein Arzt, dass 
ich wegen eines Krebsleiden die nächsten vier Monate nicht durchhalten würde. 
Aus allen Anzeichen geht hervor, dass sich mein Zustand wirklich 
verschlechtert, und es ist offensichtlich, dass ich nicht länger als zwei 
Monate lebe, da das Krebsstadium ein sehr gefährliches Stadium erreicht hat.
Nachdem ich meinen Zustand gekannt hatte, entschloss ich mich, diesen Fonds an 
eine gute Person zu spenden, die dieses Geld so verwendet, wie ich es hier 
anweisen werde. Ich möchte, dass Sie mindestens 80% dieses Fonds für 
Waisenhäuser, Witwen und die Verbreitung des Wortes Gottes verwenden und mich 
bemühen, dass das Haus Gottes erhalten bleibt, und die verbleibenden 20% für 
die gute Pflege Ihres von Gott gegebenen Hauses aufbringen. Ich habe diese 
Entscheidung getroffen, weil ich kein Kind habe, das dieses Geld erbt.
Aus diesem Grund entscheide ich mich, diesen Fonds für wohltätige Zwecke zu 
spenden. Ich habe keine Angst vor dem Tod, daher weiß ich, wohin ich gehe. Ich 
weiß, dass ich in der Brust des Herrn sein werde. 2. Mose 14 VS 14 sagt, dass 
"der Herr meinen Fall bekämpfen wird und ich meinen Frieden bewahren werde". 
Ich brauche diesbezüglich aus gesundheitlichen Gründen keine Telefonverbindung 
Glück ist, dass ich ein Leben eines würdigen Christen geführt habe. Wer dem 
Herrn dienen will, muss ihm im Geiste und in der Wahrheit dienen. Sei immer 
dein ganzes Leben lang betend. Schreiben Sie mir umgehend unter dieser E-Mail 
Adresse, und jede Verzögerung Ihrer Antwort gibt mir Raum, eine andere gute 
Person für denselben Zweck zu finden.
Versichere mir, dass du dementsprechend handeln wirst, wie ich es hier 
angegeben habe.
In der Hoffnung, Ihre E-Mail zu erhalten antworte über diese meine private 
email adresse; angelicalouise2...@yahoo.com
Danke und bleibe im Herrn gesegnet.
lch bleibe deine Schwester in Christus.
Frau Angelica Louise.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH] tests: Allow valgrind check for afxdp testsuite.

2019-10-09 Thread Ilya Maximets
New 'make' target 'check-afxdp-valgrind'.

Signed-off-by: Ilya Maximets 
---
 tests/automake.mk | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tests/automake.mk b/tests/automake.mk
index 9dd07a2d9..4bf8f00d5 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -282,6 +282,12 @@ check-userspace-valgrind: all $(valgrind_wrappers) 
$(check_DATA)
@echo 
'--'
@echo 'Valgrind output can be found in 
tests/system-userspace-testsuite.dir/*/valgrind.*'
@echo 
'--'
+check-afxdp-valgrind: all $(valgrind_wrappers) $(check_DATA)
+   $(SHELL) '$(SYSTEM_AFXDP_TESTSUITE)' -C tests VALGRIND='$(VALGRIND)' 
AUTOTEST_PATH='tests/valgrind:$(AUTOTEST_PATH)' -d $(TESTSUITEFLAGS) -j1
+   @echo
+   @echo 
'--'
+   @echo 'Valgrind output can be found in 
tests/system-afxdp-testsuite.dir/*/valgrind.*'
+   @echo 
'--'
 check-helgrind: all $(valgrind_wrappers) $(check_DATA)
-$(SHELL) '$(TESTSUITE)' -C tests CHECK_VALGRIND=true 
VALGRIND='$(HELGRIND)' AUTOTEST_PATH='tests/valgrind:$(AUTOTEST_PATH)' -d 
$(TESTSUITEFLAGS)
 
-- 
2.17.1

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


[ovs-dev] [PATCH] netdev-afxdp: Update memory locking limits unconditionally.

2019-10-09 Thread Ilya Maximets
Any type of AF_XDP socket in all modes implies creation of BPF map of
type BPF_MAP_TYPE_XSKMAP.  This leads to BPF_MAP_CREATE syscall and
subsequently 'xsk_map_alloc()' function that will charge required
memory from the memlock limit and fail with EPERM if we're trying
to allocate more.

On my system with 64K bytes of max locked memory by default, OVS
frequently starts to fail after addition of 3rd afxdp port in SKB
mode:

  netdev_afxdp|ERR|xsk_socket__create failed (Operation not permitted)
   mode: SKB qid: 0

Fixes: 0de1b425962d ("netdev-afxdp: add new netdev type for AF_XDP.")
Signed-off-by: Ilya Maximets 
---
 lib/netdev-afxdp.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
index 6e0180327..50ac1c5a5 100644
--- a/lib/netdev-afxdp.c
+++ b/lib/netdev-afxdp.c
@@ -524,19 +524,12 @@ netdev_afxdp_reconfigure(struct netdev *netdev)
 netdev->n_rxq = dev->requested_n_rxq;
 netdev->n_txq = netdev->n_rxq;
 
-if (dev->requested_xdpmode == XDP_ZEROCOPY) {
-dev->xdpmode = XDP_ZEROCOPY;
-VLOG_INFO("AF_XDP device %s in DRV mode.", netdev_get_name(netdev));
-if (setrlimit(RLIMIT_MEMLOCK, &r)) {
-VLOG_ERR("ERROR: setrlimit(RLIMIT_MEMLOCK): %s",
-  ovs_strerror(errno));
-}
-} else {
-dev->xdpmode = XDP_COPY;
-VLOG_INFO("AF_XDP device %s in SKB mode.", netdev_get_name(netdev));
-/* TODO: set rlimit back to previous value
- * when no device is in DRV mode.
- */
+dev->xdpmode = dev->requested_xdpmode;
+VLOG_INFO("%s: Setting XDP mode to %s.", netdev_get_name(netdev),
+  dev->xdpmode == XDP_ZEROCOPY ? "DRV" : "SKB");
+
+if (setrlimit(RLIMIT_MEMLOCK, &r)) {
+VLOG_ERR("setrlimit(RLIMIT_MEMLOCK) failed: %s", ovs_strerror(errno));
 }
 
 err = xsk_configure_all(netdev);
-- 
2.17.1

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


[ovs-dev] [PATCH] netdev-afxdp: Fix umem creation failure due to uninitialized config.

2019-10-09 Thread Ilya Maximets
Later version of 'struct xsk_umem_config' contains additional field
'flags'.  OVS doesn't use that field passing uninitialized stack
memory to the 'xsk_umem__create()' call that could fail with
'Invalid argument' if 'flags' are non-zero or, even worse, create
umem with unexpected properties.

We need to clear the whole structure explicitly to avoid this kind
of issues.

Fixes: 0de1b425962d ("netdev-afxdp: add new netdev type for AF_XDP.")
Signed-off-by: Ilya Maximets 
---
 lib/netdev-afxdp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/netdev-afxdp.c b/lib/netdev-afxdp.c
index 6e0180327..4619245a8 100644
--- a/lib/netdev-afxdp.c
+++ b/lib/netdev-afxdp.c
@@ -168,6 +168,7 @@ xsk_configure_umem(void *buffer, uint64_t size, int xdpmode)
 
 umem = xzalloc(sizeof *umem);
 
+memset(&uconfig, 0, sizeof uconfig);
 uconfig.fill_size = PROD_NUM_DESCS;
 uconfig.comp_size = CONS_NUM_DESCS;
 uconfig.frame_size = FRAME_SIZE;
-- 
2.17.1

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


Re: [ovs-dev] [PATCH 2/2] backtrace: Fix 32-bit libunwind build.

2019-10-09 Thread Alin Serdean



On 8 Oct 2019, at 20:51, Ben Pfaff mailto:b...@ovn.org>> wrote:

On Tue, Oct 08, 2019 at 06:33:10PM +0200, Ilya Maximets wrote:
On 08.10.2019 18:13, William Tu wrote:
On Mon, Oct 07, 2019 at 07:10:26PM +0200, Ilya Maximets wrote:
On 07.10.2019 18:11, Ilya Maximets wrote:
On 07.10.2019 18:07, William Tu wrote:
On Mon, Oct 7, 2019 at 5:06 AM Ilya Maximets 
mailto:i.maxim...@ovn.org>> wrote:

On 04.10.2019 23:21, William Tu wrote:
The libunwind unw_word_t type is defined as uint32_t for 32-bit
system and uint64_t for 64-bit system.  The patch fixes the
compile error using PRIxPTR to print this value.

Fixes: e2ed6fbeb18c ("fatal-signal: Catch SIGSEGV and print backtrace.")
Signed-off-by: William Tu mailto:u9012...@gmail.com>>
Acked-by: Ilya Maximets mailto:i.maxim...@ovn.org>>
---

Thanks! I applied both patches to master, but in the reverse order.

Best regards, Ilya Maximets.

Hi Ilya,

Thanks...
Now the cirrus CI and appveyor seem to be failing. I will work on it.

Not sure about appveyor, but cirrus is failing because of this:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/363182.html

It's not related to current patch, freebsd just updated to use gcc > 9.
And it's not possible to build OVS with -Werror and gcc 9 right now.

Thanks, I'm reviewing this patch.

And this somehow FreeBSD specific. netinet/icmp6.h from glibc development
package doesn't mark the structure as 'packed' on linux.

Best regards, Ilya Maximets.


The appveyor failure is not due to other issues.

appveyor failure is due to missing python3 binary.
Caused by the patch:
1ca0323e7c29 ("Require Python 3 and remove support for Python 2.")

Need to add something like this to the build script:

SET PYTHON="C:\\Python37-x64"
SET PATH="%PYTHON%;%PYTHON%\\Scripts;%PATH%"
python --version

And revert back 's/python3/python/'.

Best regards, Ilya Maximets.

It looks like Alin is working on this:
https://github.com/openvswitch/ovs/pull/296

Sorry for the lack of communication on my side.

I sent a patch to update appveyor here: 
https://patchwork.ozlabs.org/patch/1173786/

Alin.


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


[ovs-dev] [PATCH] appveyor: Update OpenSSL link and python3 to path

2019-10-09 Thread Alin Gabriel Serdean
This patch fixes the appveyor build by adding the python version 3 to path
as per:
https://www.appveyor.com/docs/windows-images-software/#python

We also create a hardlink for python3 in the same directory to ease up scripts
which checks for its existence.

This patch also bumps the OpenSSL version from 1.0.2n to 1.0.2t.

Signed-off-by: Alin Gabriel Serdean 
---
 appveyor.yml | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/appveyor.yml b/appveyor.yml
index b30122744..ee72a948b 100644
--- a/appveyor.yml
+++ b/appveyor.yml
@@ -4,6 +4,8 @@ branches:
   - master
 clone_folder: C:\openvswitch
 init:
+- ps: $env:PATH ="C:\Python37;"+$env:PATH
+- ps: New-Item -Type HardLink -Path "C:\Python37\python3.exe" -Value 
"C:\Python37\python.exe"
 - ps: >-
 mkdir C:\pthreads-win32
 
@@ -15,9 +17,9 @@ init:
 
 Invoke-WebRequest $source -OutFile $destination
 
-$source = "https://slproweb.com/download/Win32OpenSSL-1_0_2n.exe";
+$source = "https://slproweb.com/download/Win32OpenSSL-1_0_2t.exe";
 
-$destination = "C:\ovs-build-downloads\Win32OpenSSL-1_0_2n.exe"
+$destination = "C:\ovs-build-downloads\Win32OpenSSL-1_0_2t.exe"
 
 Invoke-WebRequest $source -OutFile $destination
 
@@ -27,7 +29,7 @@ init:
 
 cd C:\ovs-build-downloads
 
-.\Win32OpenSSL-1_0_2n.exe /silent /verysilent /sp- /suppressmsgboxes
+.\Win32OpenSSL-1_0_2t.exe /silent /verysilent /sp- /suppressmsgboxes
 
 Start-Sleep -s 30
 
-- 
2.21.0.windows.1

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


[ovs-dev] Apply For Financial investment at a lower rate 2%

2019-10-09 Thread Nadia Artha Dewi
-- 
Hello,

We are private lenders based in UK.
Do you need a loan (credit) as soon as possible. Are you in search of
money to solve your personal needs or finance your business venture,
then get Your desired loan today! Consult us at Sunrise Funding Ltd.

* We offer personal loan & huge capital loan at 2% interest rate to
the general public both locally and internationally.
* Credit amount range from $5,000.00 -- $500,000.00 and above.
* Special $10,000,000.00 Loan offer for huge project also available.
* Loan period of 6 months -- 10 years.
* Loan is granted 24 hours after approval and accredited, directly in
hand or bank account.

Please note that you are advised to contact us for more details via
the following e-mail address below;

EMAIL : sunrisefundinglt...@gmail.com
FIRM : Sunrise Funding Ltd UK.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH] ofproto: Fix for frequent invalidation of mega flows for push actions

2019-10-09 Thread Vishal Deep Ajmera via dev
When a packet is processed by the slow path and the matching OpenFlow
rule has actions like push_mpls/set_field and push_vlan/set_field, the
ofproto layer un-wildcards the MPLS and VLAN match fields in the megaflow
entry that it plans to install. However, when the megaflow entry is
actually installed, all protocol match fields that are not present in the
packet are wildcarded. Thus, the wildcard bits in the installed megaflow
entry could be different from the bits originally generated by the ofproto
layer.

When the revalidator thread validates a megaflow, it will first query the
ofproto layer to get the wildcard bits and then compare it against the
wildcard bits in the megaflow. If the bits are different the entry will be
removed.  A subsequent packet will again result in the same megaflow entry
being installed only for it to be removed by the revalidator thread. This
cycle will continue and will significantly degrade performance.

This patch fixes the issue by wildcarding flow fields which are not present
in the incoming packet.

Signed-off-by: Vishal Deep Ajmera 
---
 ofproto/ofproto-dpif-xlate.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 44f856d..f92cb62 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -7343,6 +7343,26 @@ xlate_wc_finish(struct xlate_ctx *ctx)
 ctx->wc->masks.tp_src = 0;
 ctx->wc->masks.tp_dst = 0;
 }
+
+/* Clear flow wildcard bits for fields which are not present
+ * in the original packet header. These wildcards may get set
+ * due to push/set_field actions. This results into frequent
+ * invalidation of datapath flows by revalidator thread. */
+
+/* Clear mpls label wc bits if original packet is non-mpls. */
+if (!eth_type_mpls(ctx->xin->upcall_flow->dl_type)) {
+for (i = 0; i < FLOW_MAX_MPLS_LABELS; i++) {
+ctx->wc->masks.mpls_lse[i] = 0;
+}
+}
+/* Clear vlan header wc bits if original packet does not have
+ * vlan header. */
+for (i = 0; i < FLOW_MAX_VLAN_HEADERS; i++) {
+if (!eth_type_vlan(ctx->xin->upcall_flow->vlans[i].tpid)) {
+ctx->wc->masks.vlans[i].tpid = 0;
+ctx->wc->masks.vlans[i].tci = 0;
+}
+}
 }
 
 /* Translates the flow, actions, or rule in 'xin' into datapath actions in
-- 
1.9.1

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


Re: [ovs-dev] [PATCH ovn v4] Document process for compatibility between OVS and OVN.

2019-10-09 Thread Numan Siddique
On Wed, Oct 9, 2019 at 2:42 AM Mark Michelson  wrote:

> This document serves to provide an explanation for how OVN will remain
> compatible with OVS. It provides instructions for OVN contributors for
> how to maintain compatibility even across older versions of OVS when
> possible.
>
> It also creates a document to detail compatibility of specific OVN
> versions.
>
> Signed-off-by: Mark Michelson 
> Acked-by: Han Zhou 
>

Acked-by: Numan Siddique 




> ---
> v3 -> v4:
> * Addressed grammatical fixes
> ---
> v2 -> v3:
> * Removed RFC designation
> * Added the compatibility document for specific versions of OVS and OVN
> * Clarified compatibility concerns prior to the split
> * Mentioned possibility of a change to OVS major version as a reason for
>   dropping compatibility.
> * Clarified where warning messages should be output in the case that
>   feature incompatibility is detected.
> * Added mention of "tested" and "untested" versions of OVS for
>   compatibility.
>  ---
>
>  Documentation/automake.mk  |   2 +
>  Documentation/internals/contributing/index.rst |   1 +
>  .../contributing/ovs-ovn-compatibility.rst | 153
> +
>  Documentation/topics/index.rst |   1 +
>  Documentation/topics/ovs-compatibility.rst |  70 ++
>  5 files changed, 227 insertions(+)
>  create mode 100644
> Documentation/internals/contributing/ovs-ovn-compatibility.rst
>  create mode 100644 Documentation/topics/ovs-compatibility.rst
>
> diff --git a/Documentation/automake.mk b/Documentation/automake.mk
> index f7e1d2628..bfb0a87bc 100644
> --- a/Documentation/automake.mk
> +++ b/Documentation/automake.mk
> @@ -25,6 +25,7 @@ DOC_SOURCE = \
> Documentation/topics/high-availability.rst \
> Documentation/topics/integration.rst \
> Documentation/topics/ovn-news-2.8.rst \
> +   Documentation/topics/ovs-compatibility.rst \
> Documentation/topics/role-based-access-control.rst \
> Documentation/howto/index.rst \
> Documentation/howto/docker.rst \
> @@ -56,6 +57,7 @@ DOC_SOURCE = \
> Documentation/internals/contributing/documentation-style.rst \
> Documentation/internals/contributing/libopenvswitch-abi.rst \
> Documentation/internals/contributing/submitting-patches.rst \
> +   Documentation/internals/contributing/ovs-ovn-compatibility.rst \
> Documentation/requirements.txt \
> $(addprefix Documentation/ref/,$(RST_MANPAGES)
> $(RST_MANPAGES_NOINST))
>  FLAKE8_PYFILES += Documentation/conf.py
> diff --git a/Documentation/internals/contributing/index.rst
> b/Documentation/internals/contributing/index.rst
> index a46cb046a..7ef57a1e2 100644
> --- a/Documentation/internals/contributing/index.rst
> +++ b/Documentation/internals/contributing/index.rst
> @@ -36,3 +36,4 @@ The below guides provide information on contributing to
> Open vSwitch itself.
> coding-style-windows
> documentation-style
> libopenvswitch-abi
> +   ovs-ovn-compatibility
> diff --git
> a/Documentation/internals/contributing/ovs-ovn-compatibility.rst
> b/Documentation/internals/contributing/ovs-ovn-compatibility.rst
> new file mode 100644
> index 0..125640fec
> --- /dev/null
> +++ b/Documentation/internals/contributing/ovs-ovn-compatibility.rst
> @@ -0,0 +1,153 @@
> +..
> +  Copyright (c) 2019 Red Hat, Inc.
> +
> +  Licensed under the Apache License, Version 2.0 (the "License"); you
> may
> +  not use this file except in compliance with the License. You may
> obtain
> +  a copy of the License at
> +
> +  http://www.apache.org/licenses/LICENSE-2.0
> +
> +  Unless required by applicable law or agreed to in writing, software
> +  distributed under the License is distributed on an "AS IS" BASIS,
> WITHOUT
> +  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> See the
> +  License for the specific language governing permissions and
> limitations
> +  under the License.
> +
> +  Convention for heading levels in Open vSwitch documentation:
> +
> +  ===  Heading 0 (reserved for the title in a document)
> +  ---  Heading 1
> +  ~~~  Heading 2
> +  +++  Heading 3
> +  '''  Heading 4
> +
> +  Avoid deeper levels because they do not render well.
> +
> +===
> +Keeping OVN Compatible with OVS
> +===
> +
> +This document discusses the general policy of compatibility between OVS
> and OVN.
> +If you are looking for a listing of version compatibility, please see
> +:doc:`topics/ovs-compatibility`
> +
> +OVN has split from OVS. Prior to this split, there were few issues with
> +compatibility. All code changes happened at the same time and in the same
> repo.
> +New releases contained the latest OVS and OVN changes. The most common
> time
> +that compatibility typically came into question was during an upgrade;
> there
> +might be a 

[ovs-dev] [PATCH] netdev-offload: replace netdev_hmap_mutex to netdev_hmap_rwlock

2019-10-09 Thread wenxu
From: wenxu 

All the kmap lookup operations netdev_ports_flow_del, netdev_ports_get
netdev_ifindex_to_odp_port should protected by rdlock without
affect each other in the handlers and revalidators

Signed-off-by: wenxu 
---
 lib/netdev-offload.c | 58 +---
 1 file changed, 28 insertions(+), 30 deletions(-)

diff --git a/lib/netdev-offload.c b/lib/netdev-offload.c
index e4279f6..e5c7fca 100644
--- a/lib/netdev-offload.c
+++ b/lib/netdev-offload.c
@@ -362,11 +362,11 @@ netdev_set_hw_info(struct netdev *netdev, int type, int 
val)
 }
 
 /* Protects below port hashmaps. */
-static struct ovs_mutex netdev_hmap_mutex = OVS_MUTEX_INITIALIZER;
+static struct ovs_rwlock netdev_hmap_rwlock = OVS_RWLOCK_INITIALIZER;
 
-static struct hmap port_to_netdev OVS_GUARDED_BY(netdev_hmap_mutex)
+static struct hmap port_to_netdev OVS_GUARDED_BY(netdev_hmap_rwlock)
 = HMAP_INITIALIZER(&port_to_netdev);
-static struct hmap ifindex_to_port OVS_GUARDED_BY(netdev_hmap_mutex)
+static struct hmap ifindex_to_port OVS_GUARDED_BY(netdev_hmap_rwlock)
 = HMAP_INITIALIZER(&ifindex_to_port);
 
 struct port_to_netdev_data {
@@ -384,12 +384,12 @@ struct port_to_netdev_data {
  */
 bool
 netdev_any_oor(void)
-OVS_EXCLUDED(netdev_hmap_mutex)
+OVS_EXCLUDED(netdev_hmap_rwlock)
 {
 struct port_to_netdev_data *data;
 bool oor = false;
 
-ovs_mutex_lock(&netdev_hmap_mutex);
+ovs_rwlock_rdlock(&netdev_hmap_rwlock);
 HMAP_FOR_EACH (data, portno_node, &port_to_netdev) {
 struct netdev *dev = data->netdev;
 
@@ -398,7 +398,7 @@ netdev_any_oor(void)
 break;
 }
 }
-ovs_mutex_unlock(&netdev_hmap_mutex);
+ovs_rwlock_unlock(&netdev_hmap_rwlock);
 
 return oor;
 }
@@ -414,13 +414,13 @@ netdev_ports_flow_flush(const struct dpif_class 
*dpif_class)
 {
 struct port_to_netdev_data *data;
 
-ovs_mutex_lock(&netdev_hmap_mutex);
+ovs_rwlock_rdlock(&netdev_hmap_rwlock);
 HMAP_FOR_EACH (data, portno_node, &port_to_netdev) {
 if (data->dpif_class == dpif_class) {
 netdev_flow_flush(data->netdev);
 }
 }
-ovs_mutex_unlock(&netdev_hmap_mutex);
+ovs_rwlock_unlock(&netdev_hmap_rwlock);
 }
 
 struct netdev_flow_dump **
@@ -431,7 +431,7 @@ netdev_ports_flow_dump_create(const struct dpif_class 
*dpif_class, int *ports)
 int count = 0;
 int i = 0;
 
-ovs_mutex_lock(&netdev_hmap_mutex);
+ovs_rwlock_rdlock(&netdev_hmap_rwlock);
 HMAP_FOR_EACH (data, portno_node, &port_to_netdev) {
 if (data->dpif_class == dpif_class) {
 count++;
@@ -450,7 +450,7 @@ netdev_ports_flow_dump_create(const struct dpif_class 
*dpif_class, int *ports)
 i++;
 }
 }
-ovs_mutex_unlock(&netdev_hmap_mutex);
+ovs_rwlock_unlock(&netdev_hmap_rwlock);
 
 *ports = i;
 return dumps;
@@ -463,15 +463,15 @@ netdev_ports_flow_del(const struct dpif_class *dpif_class,
 {
 struct port_to_netdev_data *data;
 
-ovs_mutex_lock(&netdev_hmap_mutex);
+ovs_rwlock_rdlock(&netdev_hmap_rwlock);
 HMAP_FOR_EACH (data, portno_node, &port_to_netdev) {
 if (data->dpif_class == dpif_class
 && !netdev_flow_del(data->netdev, ufid, stats)) {
-ovs_mutex_unlock(&netdev_hmap_mutex);
+ovs_rwlock_unlock(&netdev_hmap_rwlock);
 return 0;
 }
 }
-ovs_mutex_unlock(&netdev_hmap_mutex);
+ovs_rwlock_unlock(&netdev_hmap_rwlock);
 
 return ENOENT;
 }
@@ -484,16 +484,16 @@ netdev_ports_flow_get(const struct dpif_class 
*dpif_class, struct match *match,
 {
 struct port_to_netdev_data *data;
 
-ovs_mutex_lock(&netdev_hmap_mutex);
+ovs_rwlock_rdlock(&netdev_hmap_rwlock);
 HMAP_FOR_EACH (data, portno_node, &port_to_netdev) {
 if (data->dpif_class == dpif_class
 && !netdev_flow_get(data->netdev, match, actions,
 ufid, stats, attrs, buf)) {
-ovs_mutex_unlock(&netdev_hmap_mutex);
+ovs_rwlock_unlock(&netdev_hmap_rwlock);
 return 0;
 }
 }
-ovs_mutex_unlock(&netdev_hmap_mutex);
+ovs_rwlock_unlock(&netdev_hmap_rwlock);
 return ENOENT;
 }
 
@@ -505,7 +505,7 @@ netdev_ports_hash(odp_port_t port, const struct dpif_class 
*dpif_class)
 
 static struct port_to_netdev_data *
 netdev_ports_lookup(odp_port_t port_no, const struct dpif_class *dpif_class)
-OVS_REQUIRES(netdev_hmap_mutex)
+OVS_REQUIRES(netdev_hmap_rwlock)
 {
 struct port_to_netdev_data *data;
 
@@ -531,9 +531,9 @@ netdev_ports_insert(struct netdev *netdev, const struct 
dpif_class *dpif_class,
 return ENODEV;
 }
 
-ovs_mutex_lock(&netdev_hmap_mutex);
+ovs_rwlock_wrlock(&netdev_hmap_rwlock);
 if (netdev_ports_lookup(dpif_port->port_no, dpif_class)) {
-ovs_mutex_unlock(&netdev_hmap_mutex);
+ovs_rwlock_unlock(&netdev_hmap_rwlock);
 return EEXIST;
 }
 
@@ -546,7 +546,7 @@ ne