[ovs-dev] [PATCH] AUTHORS: Update email for Alin Serdean
Signed-off-by: Alin-Gabriel Serdean --- .mailmap| 4 ++-- AUTHORS.rst | 2 +- MAINTAINERS.rst | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/.mailmap b/.mailmap index 824af56b2..6cefe3cd4 100644 --- a/.mailmap +++ b/.mailmap @@ -14,8 +14,8 @@ Aaron Conole Aaron Rosen Alex Wang Alexey I. Froloff -Alin Serdean -Alin Serdean +Alin Serdean +Alin Serdean Andy Zhou Andy Zhou Andy Zhou diff --git a/AUTHORS.rst b/AUTHORS.rst index 4bd1aeb17..42eda83dd 100644 --- a/AUTHORS.rst +++ b/AUTHORS.rst @@ -46,7 +46,7 @@ Alexey Roytman royt...@il.ibm.com Alex Wang ee07b...@gmail.com Alfredo Finellia...@computationes.de Alin Balutoiu abalut...@cloudbasesolutions.com -Alin Serdean aserd...@cloudbasesolutions.com +Alin Serdean aserd...@ovn.org Amber Kumarkumar.am...@intel.com Ambika Arora ambika.ar...@tcs.com Amit Bose b...@noironetworks.com diff --git a/MAINTAINERS.rst b/MAINTAINERS.rst index f4f6188c8..9dcbf3f8c 100644 --- a/MAINTAINERS.rst +++ b/MAINTAINERS.rst @@ -44,7 +44,7 @@ This is the current list of active Open vSwitch committers: * - Alex Wang - ee07b...@gmail.com * - Alin Serdean - - aserd...@cloudbasesolutions.com + - aserd...@ovn.org * - Andy Zhou - az...@ovn.org * - Ansis Atteka -- 2.32.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] datapath-windows: Add file digest algorithm for signtool
This patch specifies the file digest algorithm for signtool on the package and ovsext VS projects. Fixes broken appveyor build. Signed-off-by: Alin-Gabriel Serdean --- datapath-windows/Package/package.VcxProj | 27 datapath-windows/ovsext/ovsext.vcxproj | 13 +++- 2 files changed, 39 insertions(+), 1 deletion(-) diff --git a/datapath-windows/Package/package.VcxProj b/datapath-windows/Package/package.VcxProj index 5939a8816..994c34dc2 100644 --- a/datapath-windows/Package/package.VcxProj +++ b/datapath-windows/Package/package.VcxProj @@ -151,46 +151,73 @@ true + + SHA256 + true + + SHA256 + true + + SHA256 + true + + SHA256 + true + + SHA256 + true + + SHA256 + true + + SHA256 + true + + SHA256 + true + + SHA256 + diff --git a/datapath-windows/ovsext/ovsext.vcxproj b/datapath-windows/ovsext/ovsext.vcxproj index 18f884f41..7a2cbd2de 100644 --- a/datapath-windows/ovsext/ovsext.vcxproj +++ b/datapath-windows/ovsext/ovsext.vcxproj @@ -377,6 +377,17 @@ $(Version) + + SHA256 + SHA256 + SHA256 + SHA256 + SHA256 + SHA256 + SHA256 + SHA256 + SHA256 + @@ -441,4 +452,4 @@ - \ No newline at end of file + -- 2.32.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] northd-ddlog slowness when adding the first regular LSP to a LS full of router ports
On Thu, Sep 30, 2021 at 12:23:57AM -0700, Han Zhou wrote: > Hi Ben, > > I understand that we have difficulties for northd-ddlog progress, but I > still want to try it before it goes away. I tested with the latest version, > and it is super fast for most of the operations. With a large NB & SB > created, the C northd takes ~8 seconds for any change computation. For the > same DB, northd usually takes less than 1 sec for most operations. > > However, I did find an interesting problem. I tried to create one more LSP > on a LS that already has 800 gateway-routers connected to it, which means > there are already 800 LSPs on the LS of the type "router". Creating the > extra LSP (without type) took 12 sec, which is even longer than a full > compute of the C version. What's more interesting is, when I create another > LSP on the same LS, it takes only 100+ms, and same for the 3rd, 4th LSPs, > etc. When I remove any one of the extra LSPs I created, it is also fast, > just 100+ms. But when I remove the last LSP that I just created it takes 12 > sec again. Then I tried creating a LSP with type=router on the same LS, it > is very fast, less than 100ms. Basically, only creating the first > non-router LSP or removing the last non-router LSP takes a very long time. > > I haven't debugged yet (and not sure if I am capable of), but I think it > might be useful to report it first. This kind of thing usually happens because there is a lot of intermediate data being built up in internal relations that changes when the input changes. My usual strategy for figuring it out is to configure with --output-internal-relations (that might not be the exactly correct option; the documentation should say) and then replay using the CLI to see what's changing before and after the changes in question. It's usually big. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [EXTERNAL] [PATCH] RFC: netdev-dpdk: Add Windows support.
>> Dynamic lib still not supported yet in DPDK Windows). - We have Dynamic LIB support. IIRC, it was upstreamed. - Let's discuss in the DPDK bi-weekly to align >> the userspace netdev datapath currently used by OVS-DPDK and AF_XDP, currently only works on Linux platform. - We have AF_XDP and AF_XDP PMD functional and under development. - We intend to upstream the Windows AF_XDP PMD to DPDK mainline once ready. >> f. With clang support on Windows, can we remove MSVC? - We are actively working to add MSVC support for Windows DPDK. - Please do not remove MSVC support. >> f. How does OVS-DPDK connect to VM/Container in Windows? - Containers Connect through a new "Windows Host vNIC PMD" - (POC available and work in-progress) - VMs connect through new "VMNIC PMD" which is will be fully backward compatible with all Hyper-V Guests - (POC available and work in-progress) -Original Message- From: William Tu Sent: Wednesday, October 6, 2021 10:01 AM To: d...@openvswitch.org Cc: i.maxim...@ovn.org; b...@cs.stanford.edu; Dmitry Kozlyuk ; talshn ; Kadam, Pallavi ; Omar Cardona ; sergey.madami...@gmail.com; t...@vmware.com Subject: [EXTERNAL] [PATCH] RFC: netdev-dpdk: Add Windows support. The patch adds OVS-DPDK supports on Windows. Motivation -- Currently OVS supports multiple datapath implementations: Linux kernel, Windows kernel, userspace with OVS-DPDK Linux, and HW offload. Adding any new feature to OVS datapath requires OS-specific expertise and usually ends up with feature mismatch, ex: Linux kernel supports feature A, but Windows does not, and high maintenace cost [1]. It would be great if OVS just uses single datapath across different platforms, and the datapath is portatble, performant, and easy to maintain. The natural choice is the dpif-netdev, the usersapce netdev datapath currently used by OVS-DPDK and AF_XDP, currently only works on Linux platform. So the last piece is to make OVS-DPDK runs on Windows. With this work, the OVS userspace datapath becomes the one runs on Windows/Linux/FreeBSD and any new datapath feature should naturally work on different OSes. Performance of userspace datapath should be equal or better to the kernel datapath, due to the kernel bypass design of DPDK/AF_XDP, and optimizations in OVS userspace datapath. OVS also translates its datapath flows into HW offload-capable NICs, such as Mellanox CX6. With userspace datapath, HW offload works by using tc-flower (when using AF_XDP netdev) or using rte_flow API, (when using DPDK netdev). We've tried non-triival OVS actions such as conntrack or tunnel actions offloaded into Mellanox card. Moving forward, OVS will have better cross-platform support, better performance, and easier to maintain. So far I haven't seen any virtual switch capable of doing all of the above. Implementation on Windows - It's harder than I thought due to my Linux only background. Sergey and I first need to add meson build support to OVS, in order to make compiling and linking to Windows DPDK library easier[2]. In this patch, we use clang compiler on Windows to compile DPDK and OVS, and OVS links to DPDK static library (Dynamic lib still not supported yet in DPDK Windows). Windows DPDK library hasn't finished all its library/driver porting to Windows. So a couple of DPDK library code used by OVS doesn't compile. For examples: 1) ovs-numa.c: used to detect lcores used by DPDK. 2) open_memstream, fopencookies: used to redirect DPDK logs. 3) vhostuser doesn't support: used to connect VM/container. 4) dpdk-socket-mem not support: configuration I simply remove them in this patch. In the future, I will probably refactor or #ifdef. In addition, only a few DPDK PMD drivers are supported. (please check the DPDK doc[3]) 1) Physical: ice, i40e, mlx5, ixgbe 3) Virtual: none (still work in progress) For ice, i40, ixgbe, you will need additional two Windows drivers, netuio and virt2phys. For mlx5, you will need WINOF-2. I tested this patch using mlx5 pmd on Azure cloud and on-prem and ixgbevf on AWS EC2, using Windows server 2019. And I only tested basic OpenFlow actions such as matching ipv4 headers, drop and output. Future Work --- In priority ordering a. Add CI or Dockerfile for building the code b. Performance numbers, compared with OVS kernel datapath c. Try rte_flow HW offload on Windows d. Resolve all the compiler warnings e. Refactor the vhostuser code Some thoughts: f. With clang support on Windows, can we remove MSVC? so OVS will have less compiler-specific code, ex: include\openvswitch\compiler.h g. DPDK starts to implement pthread in Windows, can OVS uses pthread library from DPDK, instead of pthreads4w? h. Mingw/msys is pretty slow, by switching to meson+clang, what's the improvement of build process? f. How does OVS-DPDK connect to VM/Container in Windows? There is no vhostuser, we should look at netvsc/vmbus. I got lots of help
[ovs-dev] [PATCH] connect: Add min_backoff parameter to the Manager table
To adjust the minimum number of connection attempts by
ovsdb-server to the cloud controller (to avoid ddos when controller
was down and then up)
Was carefully tested within product's codestack
Signed-off-by: Anton Pryima
diff --git a/lib/jsonrpc.c b/lib/jsonrpc.c
index c8ce5362e..f7c5f17c1 100644
--- a/lib/jsonrpc.c
+++ b/lib/jsonrpc.c
@@ -1306,6 +1306,16 @@ jsonrpc_session_set_max_backoff(struct jsonrpc_session
*s, int max_backoff)
reconnect_set_backoff(s->reconnect, 0, max_backoff);
}
+/* Sets 'min_backoff and 'max_backoff' as the minimum and maximum time,
+ * in milliseconds, to wait after a connection attempt fails before attempting
+ * to connect again. */
+void
+jsonrpc_session_set_backoff(struct jsonrpc_session *s, int min_backoff,
+int max_backoff)
+{
+reconnect_set_backoff(s->reconnect, min_backoff, max_backoff);
+}
+
/* Sets the "probe interval" for 's' to 'probe_interval', in milliseconds. If
* this is zero, it disables the connection keepalive feature. Otherwise, if
* 's' is idle for 'probe_interval' milliseconds then 's' will send an echo
diff --git a/lib/jsonrpc.h b/lib/jsonrpc.h
index 2aa97d3fe..cece97f3b 100644
--- a/lib/jsonrpc.h
+++ b/lib/jsonrpc.h
@@ -141,6 +141,8 @@ void jsonrpc_session_reset_backoff(struct jsonrpc_session
*);
void jsonrpc_session_set_max_backoff(struct jsonrpc_session *,
int max_backoff);
+void jsonrpc_session_set_backoff(struct jsonrpc_session *,
+ int min_backoff, int max_backoff);
void jsonrpc_session_set_probe_interval(struct jsonrpc_session *,
int probe_interval);
void jsonrpc_session_set_dscp(struct jsonrpc_session *,
diff --git a/lib/reconnect.c b/lib/reconnect.c
index a929ddfd2..e23763fb8 100644
--- a/lib/reconnect.c
+++ b/lib/reconnect.c
@@ -551,7 +551,8 @@ reconnect_deadline__(const struct reconnect *fsm)
return fsm->state_entered + fsm->backoff;
case S_CONNECTING:
-return fsm->state_entered + MAX(1000, fsm->backoff);
+return fsm->state_entered + MAX(1000, MAX(fsm->min_backoff,
+ fsm->backoff));
case S_ACTIVE:
if (fsm->probe_interval) {
diff --git a/ovsdb/jsonrpc-server.c b/ovsdb/jsonrpc-server.c
index 351c39d8a..8e283bf0c 100644
--- a/ovsdb/jsonrpc-server.c
+++ b/ovsdb/jsonrpc-server.c
@@ -212,6 +212,7 @@ ovsdb_jsonrpc_default_options(const char *target)
{
struct ovsdb_jsonrpc_options *options = xzalloc(sizeof *options);
options->max_backoff = RECONNECT_DEFAULT_MAX_BACKOFF;
+options->min_backoff = RECONNECT_DEFAULT_MIN_BACKOFF;
options->probe_interval = (stream_or_pstream_needs_probes(target)
? RECONNECT_DEFAULT_PROBE_INTERVAL
: 0);
@@ -577,7 +578,8 @@ static void
ovsdb_jsonrpc_session_set_options(struct ovsdb_jsonrpc_session *session,
const struct ovsdb_jsonrpc_options *options)
{
-jsonrpc_session_set_max_backoff(session->js, options->max_backoff);
+jsonrpc_session_set_backoff(session->js, options->min_backoff,
+options->max_backoff);
jsonrpc_session_set_probe_interval(session->js, options->probe_interval);
jsonrpc_session_set_dscp(session->js, options->dscp);
}
diff --git a/ovsdb/jsonrpc-server.h b/ovsdb/jsonrpc-server.h
index e0653aa39..b157c2860 100644
--- a/ovsdb/jsonrpc-server.h
+++ b/ovsdb/jsonrpc-server.h
@@ -34,6 +34,7 @@ void ovsdb_jsonrpc_server_destroy(struct ovsdb_jsonrpc_server
*);
/* Options for a remote. */
struct ovsdb_jsonrpc_options {
int max_backoff;/* Maximum reconnection backoff, in msec. */
+int min_backoff;/* Minimum reconnection backoff, in msec. */
int probe_interval; /* Max idle time before probing, in msec. */
bool read_only; /* Only read-only transactions are allowed. */
int dscp; /* Dscp value for manager connections */
diff --git a/ovsdb/ovsdb-server.c b/ovsdb/ovsdb-server.c
index b34d97e29..2696643a2 100644
--- a/ovsdb/ovsdb-server.c
+++ b/ovsdb/ovsdb-server.c
@@ -948,7 +948,7 @@ add_manager_options(struct shash *remotes, const struct
ovsdb_row *row)
{
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
struct ovsdb_jsonrpc_options *options;
-long long int max_backoff, probe_interval;
+long long int max_backoff, min_backoff, probe_interval;
bool read_only;
const char *target, *dscp_string, *role;
@@ -962,6 +962,9 @@ add_manager_options(struct shash *remotes, const struct
ovsdb_row *row)
if (ovsdb_util_read_integer_column(row, "max_backoff", _backoff)) {
options->max_backoff = max_backoff;
}
+if (ovsdb_util_read_integer_column(row, "min_backoff", _backoff)) {
+options->min_backoff = min_backoff;
+}
if
[ovs-dev] ovsdb failures in cluster mode in IPv6 setup
Hi all, I have an issue with ovsdb in cluster mode when an instance of a db server fails. I'm running a HA single-stack IPv6 ovn-kubernetes Kind cluster, where we have ovnnb_db and ovnsb_db replicated on three nodes. All control traffic is IPv6. Then I take one node, I delete the db files, and I also delete the pod itself that holds the db server, so as to simulate a node failure. The pod is recreated as well as the db files, but "ovs-appctl cluster/status OVN_Northbound" still shows the *old* server instance, along with the new one. Indeed, when I look at the ovsdb-server-nb debug logs on the affected node, I see that it is still receiving heartbeat messages to both the new server (to which it correctly replies) and the old now (for which it raises an error: "syntax error: Parsing raft append_request RPC failed: misrouted message (addressed to 0227 but we're bcda"). On the other hand, in an HA single-stack IPv4 cluster, everything works as expected: 1) during a few tens of seconds, the cluster/status command from above shows the old and the new server, as in the ipv6 case; 2) then, the old server is removed, as the new one is correctly added to the cluster. This is confirmed in ovsdb-server-nb.logs, where I see the remove_server_request and remove_server_reply messages. However, in a HA IPv6 cluster, I keep seeing 4 servers and no "remove_server_*" messages in the logs... so it's stuck in the first point from above. Is this a bug? Is there anything I can do to debug this further? Thanks! Riccardo ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v5 10/12] lib: Add infrastructure for plug providers.
On Tue, Oct 5, 2021 at 4:48 AM Numan Siddique wrote: > > On Tue, Sep 28, 2021 at 8:58 AM Frode Nordahl > wrote: > > > > New lib/plug-provider module contains the infrastructure for > > registering plug provider classes which may be hosted inside or > > outside the core OVN repository. > > > > New controller/plug module adds internal interface for interacting > > with the plug providers. > > > > Extend build system to allow enabling building of built-in plugging > > providers and linking an externally built plugging provider. > > > > Signed-off-by: Frode Nordahl > > --- > > Documentation/automake.mk | 2 + > > Documentation/topics/index.rst| 1 + > > Documentation/topics/plug_providers/index.rst | 32 + > > .../topics/plug_providers/plug-providers.rst | 196 ++ > > acinclude.m4 | 49 ++ > > configure.ac | 2 + > > controller/automake.mk| 4 +- > > controller/plug.c | 636 ++ > > controller/plug.h | 80 +++ > > controller/test-plug.c| 70 ++ > > lib/automake.mk | 10 +- > > lib/plug-provider.c | 204 ++ > > lib/plug-provider.h | 164 + > > lib/plug_providers/dummy/plug-dummy.c | 121 > > ovn-architecture.7.xml| 35 +- > > tests/automake.mk | 13 +- > > tests/ovn-plug.at | 8 + > > 17 files changed, 1611 insertions(+), 16 deletions(-) > > create mode 100644 Documentation/topics/plug_providers/index.rst > > create mode 100644 Documentation/topics/plug_providers/plug-providers.rst > > create mode 100644 controller/plug.c > > create mode 100644 controller/plug.h > > create mode 100644 controller/test-plug.c > > create mode 100644 lib/plug-provider.c > > create mode 100644 lib/plug-provider.h > > create mode 100644 lib/plug_providers/dummy/plug-dummy.c > > create mode 100644 tests/ovn-plug.at > > > > diff --git a/Documentation/automake.mk b/Documentation/automake.mk > > index b3fd3d62b..ff245d218 100644 > > --- a/Documentation/automake.mk > > +++ b/Documentation/automake.mk > > @@ -28,6 +28,8 @@ DOC_SOURCE = \ > > Documentation/topics/ovn-news-2.8.rst \ > > Documentation/topics/role-based-access-control.rst \ > > Documentation/topics/debugging-ddlog.rst \ > > + Documentation/topics/plug_providers/index.rst \ > > + Documentation/topics/plug_providers/plug-providers.rst \ > > Documentation/howto/index.rst \ > > Documentation/howto/docker.rst \ > > Documentation/howto/firewalld.rst \ > > diff --git a/Documentation/topics/index.rst b/Documentation/topics/index.rst > > index d58d5618b..12bd113b7 100644 > > --- a/Documentation/topics/index.rst > > +++ b/Documentation/topics/index.rst > > @@ -41,6 +41,7 @@ OVN > > high-availability > > role-based-access-control > > ovn-news-2.8 > > + plug_providers/index > > testing > > > > .. list-table:: > > diff --git a/Documentation/topics/plug_providers/index.rst > > b/Documentation/topics/plug_providers/index.rst > > new file mode 100644 > > index 0..837eeae15 > > --- /dev/null > > +++ b/Documentation/topics/plug_providers/index.rst > > @@ -0,0 +1,32 @@ > > +.. > > + 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 OVN 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. > > + > > +== > > +Plug Providers > > +== > > + > > + > > +.. toctree:: > > + :maxdepth: 2 > > + > > + plug-providers > > diff --git a/Documentation/topics/plug_providers/plug-providers.rst > > b/Documentation/topics/plug_providers/plug-providers.rst > > new file mode 100644 > > index 0..a0a638d1b > > --- /dev/null > > +++ b/Documentation/topics/plug_providers/plug-providers.rst > > @@ -0,0 +1,196 @@ > > +.. > > + Licensed under the Apache License, Version 2.0 (the "License"); you > > may >
[ovs-dev] [PATCH v2] python: replace pyOpenSSL with ssl
Currently, pyOpenSSL is half-deprecated upstream and so it's removed on some distributions (for example on CentOS Stream 9, https://issues.redhat.com/browse/CS-336), but since OVS only supports Python 3 it's possible to replace pyOpenSSL with "import ssl" included in base Python 3. Stream recv and send had to be splitted as _recv and _send, since SSLError is a subclass of socket.error and so it was not possible to except for SSLWantReadError and SSLWantWriteError in recv and send of SSLStream. Reported-by: Timothy Redaelli Reported-at: https://bugzilla.redhat.com/1988429 Signed-off-by: Timothy Redaelli --- v1 -> v2: - asyncronous connect with ssl is different than with pyOpenSSL, so a different approach is needed or it fails when connect is not ready when ctx.wrap_socket is executed. Moreover it's not possible to use connect, but it's necessary to use connect_ex (probably due to a python bug or limitation). So to do not behave diffently than TCPSocket, it's necessary to raise the errno exception like connect do. --- .ci/linux-prepare.sh | 2 +- .cirrus.yml | 2 +- .travis.yml | 1 - python/ovs/poller.py | 6 +-- python/ovs/stream.py | 118 +-- tests/ovsdb-idl.at | 2 +- 6 files changed, 86 insertions(+), 45 deletions(-) diff --git a/.ci/linux-prepare.sh b/.ci/linux-prepare.sh index c55125cf7..b9b499bad 100755 --- a/.ci/linux-prepare.sh +++ b/.ci/linux-prepare.sh @@ -21,7 +21,7 @@ make -j4 HAVE_LLVM= HAVE_SQLITE= install cd .. pip3 install --disable-pip-version-check --user \ -flake8 hacking sphinx pyOpenSSL wheel setuptools +flake8 hacking sphinx wheel setuptools pip3 install --user --upgrade docutils pip3 install --user 'meson==0.47.1' diff --git a/.cirrus.yml b/.cirrus.yml index 358f2ba25..bb206f35f 100644 --- a/.cirrus.yml +++ b/.cirrus.yml @@ -9,7 +9,7 @@ freebsd_build_task: env: DEPENDENCIES: automake libtool gmake gcc wget openssl python3 -PY_DEPS: sphinx|openssl +PY_DEPS: sphinx matrix: COMPILER: gcc COMPILER: clang diff --git a/.travis.yml b/.travis.yml index 51d051108..c7aeede06 100644 --- a/.travis.yml +++ b/.travis.yml @@ -17,7 +17,6 @@ addons: - libjemalloc-dev - libnuma-dev - libpcap-dev - - python3-openssl - python3-pip - python3-sphinx - libelf-dev diff --git a/python/ovs/poller.py b/python/ovs/poller.py index 3624ec865..157719c3a 100644 --- a/python/ovs/poller.py +++ b/python/ovs/poller.py @@ -26,9 +26,9 @@ if sys.platform == "win32": import ovs.winutils as winutils try: -from OpenSSL import SSL +import ssl except ImportError: -SSL = None +ssl = None try: from eventlet import patcher as eventlet_patcher @@ -73,7 +73,7 @@ class _SelectSelect(object): def register(self, fd, events): if isinstance(fd, socket.socket): fd = fd.fileno() -if SSL and isinstance(fd, SSL.Connection): +if ssl and isinstance(fd, ssl.SSLSocket): fd = fd.fileno() if sys.platform != 'win32': diff --git a/python/ovs/stream.py b/python/ovs/stream.py index f5a520862..205e74888 100644 --- a/python/ovs/stream.py +++ b/python/ovs/stream.py @@ -22,9 +22,9 @@ import ovs.socket_util import ovs.vlog try: -from OpenSSL import SSL +import ssl except ImportError: -SSL = None +ssl = None if sys.platform == 'win32': import ovs.winutils as winutils @@ -322,6 +322,12 @@ class Stream(object): The recv function will not block waiting for data to arrive. If no data have been received, it returns (errno.EAGAIN, "") immediately.""" +try: +return self._recv(n) +except socket.error as e: +return (ovs.socket_util.get_exception_errno(e), "") + +def _recv(self, n): retval = self.connect() if retval != 0: return (retval, "") @@ -331,10 +337,7 @@ class Stream(object): if sys.platform == 'win32' and self.socket is None: return self.__recv_windows(n) -try: -return (0, self.socket.recv(n)) -except socket.error as e: -return (ovs.socket_util.get_exception_errno(e), "") +return (0, self.socket.recv(n)) def __recv_windows(self, n): if self._read_pending: @@ -396,6 +399,12 @@ class Stream(object): Will not block. If no bytes can be immediately accepted for transmission, returns -errno.EAGAIN immediately.""" +try: +return self._send(buf) +except socket.error as e: +return -ovs.socket_util.get_exception_errno(e) + +def _send(self, buf): retval = self.connect() if retval != 0: return -retval @@ -409,10 +418,7 @@ class Stream(object): if sys.platform == 'win32' and self.socket is None: return self.__send_windows(buf) -try: -
Re: [ovs-dev] [PATCH] RFC: netdev-dpdk: Add Windows support.
On Wed, Oct 6, 2021 at 10:01 AM William Tu wrote: > The patch adds OVS-DPDK supports on Windows. Fantastic! I'm happy to see this work in progress. OVS(-DPDK) everywhere! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn] doc: Fix Update Openflow Table numbers
On Fri, Sep 24, 2021 at 6:52 AM Xavier Simonart wrote:
>
> Openflow tables OFTABLE_REMOTE_OUTPUT, OFTABLE_LOCAL_OUTPUT
> and OFTABLE_CHECK_LOOPBACK numbering changed, but documentation
> was not updated.
>
> Fixes: dd94f1266c ("northd: MAC learning: Add logical flows for fdb.")
>
> Signed-off-by: Xavier Simonart
Thanks. Applied.
Numan
> ---
> controller/physical.c | 40
> ovn-architecture.7.xml | 70 +-
> 2 files changed, 55 insertions(+), 55 deletions(-)
>
> diff --git a/controller/physical.c b/controller/physical.c
> index 0cfb158c8..c5effe521 100644
> --- a/controller/physical.c
> +++ b/controller/physical.c
> @@ -955,12 +955,12 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
> || ha_chassis_group_is_active(binding->ha_chassis_group,
>active_tunnels, chassis))) {
>
> -/* Table 33, priority 100.
> +/* Table 38, priority 100.
> * ===
> *
> * Implements output to local hypervisor. Each flow matches a
> * logical output port on the local hypervisor, and resubmits to
> - * table 34. For ports of type "chassisredirect", the logical
> + * table 39. For ports of type "chassisredirect", the logical
> * output port is changed from the "chassisredirect" port to the
> * underlying distributed port. */
>
> @@ -1007,7 +1007,7 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
> put_load(zone_ids.snat, MFF_LOG_SNAT_ZONE, 0, 32, ofpacts_p);
> }
>
> -/* Resubmit to table 34. */
> +/* Resubmit to table 39. */
> put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts_p);
> }
>
> @@ -1312,7 +1312,7 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
>
> } else if (!tun && !is_ha_remote) {
> /* Remote port connected by localnet port */
> -/* Table 33, priority 100.
> +/* Table 38, priority 100.
> * ===
> *
> * Implements switching to localnet port. Each flow matches a
> @@ -1329,7 +1329,7 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
>
> put_load(localnet_port->tunnel_key, MFF_LOG_OUTPORT, 0, 32,
> ofpacts_p);
>
> -/* Resubmit to table 33. */
> +/* Resubmit to table 38. */
> put_resubmit(OFTABLE_LOCAL_OUTPUT, ofpacts_p);
> ofctrl_add_flow(flow_table, OFTABLE_LOCAL_OUTPUT, 100,
> binding->header_.uuid.parts[0],
> @@ -1341,7 +1341,7 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
>
> /* Remote port connected by tunnel */
>
> -/* Table 32, priority 100.
> +/* Table 38, priority 100.
> * ===
> *
> * Handles traffic that needs to be sent to a remote hypervisor.
> Each
> @@ -1469,7 +1469,7 @@ consider_mc_group(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
> }
> }
>
> -/* Table 33, priority 100.
> +/* Table 38, priority 100.
> * ===
> *
> * Handle output to the local logical ports in the multicast group, if
> @@ -1485,7 +1485,7 @@ consider_mc_group(struct ovsdb_idl_index
> *sbrec_port_binding_by_name,
> , , >header_.uuid);
> }
>
> -/* Table 32, priority 100.
> +/* Table 37, priority 100.
> * ===
> *
> * Handle output to the remote chassis in the multicast group, if
> @@ -1635,7 +1635,7 @@ physical_run(struct physical_ctx *p_ctx,
>p_ctx->chassis, flow_table, );
> }
>
> -/* Handle output to multicast groups, in tables 32 and 33. */
> +/* Handle output to multicast groups, in tables 37 and 38. */
> const struct sbrec_multicast_group *mc;
> SBREC_MULTICAST_GROUP_TABLE_FOR_EACH (mc, p_ctx->mc_group_table) {
> consider_mc_group(p_ctx->sbrec_port_binding_by_name,
> @@ -1656,7 +1656,7 @@ physical_run(struct physical_ctx *p_ctx,
> * encapsulations have metadata about the ingress and egress logical
> ports.
> * VXLAN encapsulations have metadata about the egress logical port only.
> * We set MFF_LOG_DATAPATH, MFF_LOG_INPORT, and MFF_LOG_OUTPORT from the
> - * tunnel key data where possible, then resubmit to table 33 to handle
> + * tunnel key data where possible, then resubmit to table 38 to handle
> * packets to the local hypervisor. */
> struct chassis_tunnel *tun;
> HMAP_FOR_EACH (tun, hmap_node, p_ctx->chassis_tunnels) {
> @@ -1730,12 +1730,12 @@ physical_run(struct physical_ctx *p_ctx,
> }
> }
>
> -/* Table 32, priority 150.
> +/* Table 37, priority 150.
> * ===
Re: [ovs-dev] [PATCH ovn] MAINTAINERS: Transition myself to emeritus status.
On Tue, Oct 5, 2021 at 1:46 PM Han Zhou wrote: > > On Tue, Oct 5, 2021 at 9:39 AM Ben Pfaff wrote: > > > > I have not been actively maintaining OVN for some time now. I don't > expect > > that to change. I think that the responsible thing to do is to > > acknowledge this properly by transitioning to emeritus status. > > > > Signed-off-by: Ben Pfaff > > --- > > MAINTAINERS.rst | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/MAINTAINERS.rst b/MAINTAINERS.rst > > index 0d19bd622..fff2cd977 100644 > > --- a/MAINTAINERS.rst > > +++ b/MAINTAINERS.rst > > @@ -41,8 +41,6 @@ This is the current list of active OVN committers: > > > > * - Name > > - Email > > - * - Ben Pfaff > > - - b...@ovn.org > > * - Gurucharan Shetty > > - g...@ovn.org > > * - Han Zhou > > @@ -67,3 +65,5 @@ More information about Emeritus Committers can be found > > > > * - Name > > - Email > > + * - Ben Pfaff > > + - b...@ovn.org > > -- > > 2.31.1 > > > > ___ > > dev mailing list > > d...@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > Hi Ben, > > The patch LGTM, although I really don't like the solution :( > Thank you so much for building the amazing stuff from scratch! > > Acked-by: Han Zhou Thanks again Ben for all your amazing work. I applied this patch to the main branch. Numan > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn] ovn.at: Fix flaky test "controller I-P handling with monitoring disabled".
On Wed, Sep 15, 2021 at 4:53 AM Xavier Simonart wrote:
>
> Test was waiting for port to be up in SBDB before checking number of flows
> in OVS. However, there is no guarantee that all flows are installed
> in OVS when port is up. Test was randomly failing as some flows were
> installed, but not all.
> To fix this, we wait until the last flow (with actions=output) is
> installed.
> Also fixed small typo in logging (for the same test).
>
> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2004390
> Fixes: f8a81693b0 ("ovn-controller: Fix the missing flows with monitor-all
> set to True")
> Signed-off-by: Xavier Simonart
Thanks for fixing this issue. I applied this patch to the main branch.
I did one change. Please see below
Thanks
Numan
> ---
> tests/ovn.at | 28 ++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/tests/ovn.at b/tests/ovn.at
> index 30625ec37..18aeacd02 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -23448,6 +23448,12 @@ ovs-vsctl -- add-port br-int hv1-vif1 -- \
>
> wait_for_ports_up sw0-p1
>
> +# Wait for last flow to be installed
> +OVS_WAIT_UNTIL([
> +test $(as hv1 ovs-ofctl dump-flows br-int | \
> +grep "actions=output" -c) -eq 1
> +])
> +
> # Get the number of OF flows in hv1 and hv2
> hv1_offlows=$(as hv1 ovs-ofctl dump-flows br-int | wc -l)
> echo "hv1 flows : $hv1_offlows"
> @@ -23462,6 +23468,12 @@ ovs-vsctl -- add-port br-int hv2-vif1 -- \
>
> wait_for_ports_up sw0-p2
>
> +# Wait for last flow to be installed
> +OVS_WAIT_UNTIL([
> +test $(as hv2 ovs-ofctl dump-flows br-int | \
> +grep "actions=output" -c) -eq 1
> +])
> +
> hv2_offlows=$(as hv2 ovs-ofctl dump-flows br-int | wc -l)
> echo "hv2 flows : $hv2_offlows"
> AT_CHECK([test $hv2_offlows -gt 0])
> @@ -23500,9 +23512,15 @@ ovs-vsctl -- add-port br-int hv1-vif1 -- \
>
> wait_for_ports_up sw0-p1
>
> +# Wait for last flow to be installed
With the commit 2cc42bdef("northd: Change the default value of
ignore_lsp_down to true.")
merged, this arp flow may not be the last flow. So I replaced "last
flow" with "arp flow".
Numan
> +OVS_WAIT_UNTIL([
> +test $(as hv1 ovs-ofctl dump-flows br-int | \
> +grep "actions=output" -c) -eq 1
> +])
> +
> # Get the number of OF flows in hv1 and hv2
> hv1_offlows_mon=$(as hv1 ovs-ofctl dump-flows br-int | wc -l)
> -echo "hv1 flows after monitor-all=true : $hv1_offlows"
> +echo "hv1 flows after monitor-all=true : $hv1_offlows_mon"
> AT_CHECK([test "$hv1_offlows" = "$hv1_offlows_mon"])
>
> as hv2
> @@ -23514,8 +23532,14 @@ ovs-vsctl -- add-port br-int hv2-vif1 -- \
>
> wait_for_ports_up sw0-p2
>
> +# Wait for last flow to be installed
> +OVS_WAIT_UNTIL([
> +test $(as hv2 ovs-ofctl dump-flows br-int | \
> +grep "actions=output" -c) -eq 1
> +])
> +
> hv2_offlows_mon=$(as hv2 ovs-ofctl dump-flows br-int | wc -l)
> -echo "hv2 flows after monitor-all=true : $hv2_offlows"
> +echo "hv2 flows after monitor-all=true : $hv2_offlows_mon"
> AT_CHECK([test "$hv2_offlows" = "$hv2_offlows_mon"])
>
> OVN_CLEANUP([hv1], [hv2])
> --
> 2.31.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
[ovs-dev] [PATCH] RFC: netdev-dpdk: Add Windows support.
The patch adds OVS-DPDK supports on Windows. Motivation -- Currently OVS supports multiple datapath implementations: Linux kernel, Windows kernel, userspace with OVS-DPDK Linux, and HW offload. Adding any new feature to OVS datapath requires OS-specific expertise and usually ends up with feature mismatch, ex: Linux kernel supports feature A, but Windows does not, and high maintenace cost [1]. It would be great if OVS just uses single datapath across different platforms, and the datapath is portatble, performant, and easy to maintain. The natural choice is the dpif-netdev, the usersapce netdev datapath currently used by OVS-DPDK and AF_XDP, currently only works on Linux platform. So the last piece is to make OVS-DPDK runs on Windows. With this work, the OVS userspace datapath becomes the one runs on Windows/Linux/FreeBSD and any new datapath feature should naturally work on different OSes. Performance of userspace datapath should be equal or better to the kernel datapath, due to the kernel bypass design of DPDK/AF_XDP, and optimizations in OVS userspace datapath. OVS also translates its datapath flows into HW offload-capable NICs, such as Mellanox CX6. With userspace datapath, HW offload works by using tc-flower (when using AF_XDP netdev) or using rte_flow API, (when using DPDK netdev). We've tried non-triival OVS actions such as conntrack or tunnel actions offloaded into Mellanox card. Moving forward, OVS will have better cross-platform support, better performance, and easier to maintain. So far I haven't seen any virtual switch capable of doing all of the above. Implementation on Windows - It's harder than I thought due to my Linux only background. Sergey and I first need to add meson build support to OVS, in order to make compiling and linking to Windows DPDK library easier[2]. In this patch, we use clang compiler on Windows to compile DPDK and OVS, and OVS links to DPDK static library (Dynamic lib still not supported yet in DPDK Windows). Windows DPDK library hasn't finished all its library/driver porting to Windows. So a couple of DPDK library code used by OVS doesn't compile. For examples: 1) ovs-numa.c: used to detect lcores used by DPDK. 2) open_memstream, fopencookies: used to redirect DPDK logs. 3) vhostuser doesn't support: used to connect VM/container. 4) dpdk-socket-mem not support: configuration I simply remove them in this patch. In the future, I will probably refactor or #ifdef. In addition, only a few DPDK PMD drivers are supported. (please check the DPDK doc[3]) 1) Physical: ice, i40e, mlx5, ixgbe 3) Virtual: none (still work in progress) For ice, i40, ixgbe, you will need additional two Windows drivers, netuio and virt2phys. For mlx5, you will need WINOF-2. I tested this patch using mlx5 pmd on Azure cloud and on-prem and ixgbevf on AWS EC2, using Windows server 2019. And I only tested basic OpenFlow actions such as matching ipv4 headers, drop and output. Future Work --- In priority ordering a. Add CI or Dockerfile for building the code b. Performance numbers, compared with OVS kernel datapath c. Try rte_flow HW offload on Windows d. Resolve all the compiler warnings e. Refactor the vhostuser code Some thoughts: f. With clang support on Windows, can we remove MSVC? so OVS will have less compiler-specific code, ex: include\openvswitch\compiler.h g. DPDK starts to implement pthread in Windows, can OVS uses pthread library from DPDK, instead of pthreads4w? h. Mingw/msys is pretty slow, by switching to meson+clang, what's the improvement of build process? f. How does OVS-DPDK connect to VM/Container in Windows? There is no vhostuser, we should look at netvsc/vmbus. I got lots of help from many people in DPDK community, thanks! Reference - [1] https://dl.acm.org/doi/10.1145/3452296.3472914 [2] http://patchwork.ozlabs.org/project/openvswitch/cover/20210808014931.320242-1-sergey.madami...@gmail.com/ [3] https://doc.dpdk.org/guides/windows_gsg/ [4] Porting OvS-DPDK to Windows with Meson https://github.com/smadaminov/ovs-dpdk-meson-issues Signed-off-by: William Tu --- ovs/config.h.meson | 7 - ovs/include/openvswitch/compiler.h | 4 +- ovs/include/openvswitch/util.h | 2 +- ovs/lib/dpdk.c | 114 +--- ovs/lib/dpif-netdev.c | 4 + ovs/lib/meson.build| 12 +- ovs/lib/netdev-dpdk.c | 934 + ovs/lib/sflow_api.h| 1 + ovs/lib/util.c | 4 - ovs/lib/vlog.c | 7 + ovs/meson.build| 88 ++- ovs/meson_options.txt | 2 + ovs/ofproto/meson.build| 3 + ovs/ovsdb/meson.build | 3 + ovs/utilities/meson.build | 3 + ovs/vswitchd/meson.build | 10 + ovs/vtep/meson.build | 3 + 17 files changed, 140 insertions(+), 1061 deletions(-) diff --git
Re: [ovs-dev] [PATCH ovn] MAINTAINERS: Transition myself to emeritus status.
On Tue, Oct 05, 2021 at 08:06:45PM -0700, William Tu wrote: > On Tue, Oct 5, 2021 at 8:05 PM William Tu wrote: > > > > On Tue, Oct 5, 2021 at 11:33 AM Numan Siddique wrote: > > > > > > On Tue, Oct 5, 2021 at 1:46 PM Han Zhou wrote: > > > > > > > > On Tue, Oct 5, 2021 at 9:39 AM Ben Pfaff wrote: > > > > > > > > > > I have not been actively maintaining OVN for some time now. I don't > > > > expect > > > > > that to change. I think that the responsible thing to do is to > > > > > acknowledge this properly by transitioning to emeritus status. > > > > > > > > > > Signed-off-by: Ben Pfaff > > > > > --- > > > > > MAINTAINERS.rst | 4 ++-- > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/MAINTAINERS.rst b/MAINTAINERS.rst > > > > > index 0d19bd622..fff2cd977 100644 > > > > > --- a/MAINTAINERS.rst > > > > > +++ b/MAINTAINERS.rst > > > > > @@ -41,8 +41,6 @@ This is the current list of active OVN committers: > > > > > > > > > > * - Name > > > > > - Email > > > > > - * - Ben Pfaff > > > > > - - b...@ovn.org > > > > > * - Gurucharan Shetty > > > > > - g...@ovn.org > > > > > * - Han Zhou > > > > > @@ -67,3 +65,5 @@ More information about Emeritus Committers can be > > > > > found > > > > > > > > > > * - Name > > > > > - Email > > > > > + * - Ben Pfaff > > > > > + - b...@ovn.org > > > > > -- > > > > > 2.31.1 > > > > > > > > > > ___ > > > > > dev mailing list > > > > > d...@openvswitch.org > > > > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > > > > > > > Hi Ben, > > > > > > > > The patch LGTM, although I really don't like the solution :( > > > > Thank you so much for building the amazing stuff from scratch! > > > > > > > > > > Agree, Thank you for all your amazing work! > > > > > > Thanks > > > Numan > > > > > > > > > > Acked-by: Han Zhou > > > > Thanks Ben! > > I applied to master. > > William > > and feel free to revert the commit if you change your mind :) Thanks :-) ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] MAINTAINERS: Transition myself to emeritus status.
On Wed, Oct 06, 2021 at 11:20:48AM +0200, Simon Horman wrote: > On Tue, Oct 05, 2021 at 09:32:41AM -0700, Ben Pfaff wrote: > > It has been a long time since I've been able to devote significant time > > to OVS work. I don't expect that to change. I think that the responsible > > thing to do is to transition myself to emeritus status, with this patch. > > > > Signed-off-by: Ben Pfaff > > Thanks for all your hard work Ben. You're welcome! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovn] 21.09.0 release not ready yet?
On Mon, Oct 4, 2021 at 10:06 AM Vladislav Odintsov wrote: > > Hi, > > As far I know OVN 21.09.0 release previously was scheduled for 01.10.2021, > but wasn't released yet. > I’m wonder if my patch series is still scheduled to be in this release: > https://patchwork.ozlabs.org/project/ovn/list/?series=263029 You may have noticed that the 21.09.0 tag is now created and regarding your patch series, since it is still in review, I'm not sure it can be backported to branch-21.09 once it is merged to the main branch. I won't object to the backport if other committers are fine. > > Also, it’d be good if this patch also can be in this release: > https://patchwork.ozlabs.org/project/ovn/patch/20210916173028.9527-1-odiv...@gmail.com/ This one is part of 21.09. Thanks Numan > > Thanks. > > Regards, > Vladislav Odintsov > > ___ > 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
[ovs-dev] [PATCH ovn] ovn-controller: Avoid infinite replying for TCP/ICMP connection reset messages
From: Mohammad Heib
When the ovn controller receives an ip packet that targets a lport that has ACL
rule to reject ip packets, the controller will reply with TCP_RST or icmp4/6
unreachable packet
to notify the sender that the destination is not available.
In turn, the receiver host will receive the notification packet and handle it
as a normal IP packet
and if the receiver host is part of the same logical-switch/port-group or has
IP reject ACL rule
it will send TCP_RST or icmp4/6 unreachable packet replying to the TCP_RST or
icmp4/6 unreachable
packet we received and here we will enter to an infinity loop of replying about
replying which
will consume high CPU.
To avoid such scenarios this patch proposes to drop/ignore TCP_RST or icmp4/6
unreachable packets
that received on lport that has IP reject ACL rules.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1934011
Fixes: 64f8c9e9f ("actions: Add a new OVN action - reject {}.")
Signed-off-by: Mohammad Heib
---
controller/pinctrl.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index cc3edaaf4..eff599d2b 100644
--- a/controller/pinctrl.c
+++ b/controller/pinctrl.c
@@ -1934,11 +1934,40 @@ pinctrl_handle_sctp_abort(struct rconn *swconn, const
struct flow *ip_flow,
dp_packet_uninit();
}
+static bool
+pinctrl_handle_reject_ignore_pkt(const struct flow *ip_flow,
+ struct dp_packet *pkt_in)
+{
+if (ip_flow->nw_proto == IPPROTO_TCP) {
+struct tcp_header *th = dp_packet_l4(pkt_in);
+if (!th || (TCP_FLAGS(th->tcp_ctl) & TCP_RST)) {
+return true;
+}
+} else {
+if (is_icmpv4(ip_flow, NULL)) {
+struct icmp_header *ih = dp_packet_l4(pkt_in);
+if (!ih || (ih->icmp_type == ICMP4_DST_UNREACH)) {
+return true;
+}
+} else if (is_icmpv6(ip_flow, NULL)) {
+struct icmp6_data_header *ih = dp_packet_l4(pkt_in);
+if (!ih || (ih->icmp6_base.icmp6_type == ICMP6_DST_UNREACH)) {
+return true;
+}
+}
+}
+return false;
+}
+
static void
pinctrl_handle_reject(struct rconn *swconn, const struct flow *ip_flow,
struct dp_packet *pkt_in,
const struct match *md, struct ofpbuf *userdata)
{
+if (pinctrl_handle_reject_ignore_pkt(ip_flow, pkt_in)) {
+return;
+}
+
if (ip_flow->nw_proto == IPPROTO_TCP) {
pinctrl_handle_tcp_reset(swconn, ip_flow, pkt_in, md, userdata, true);
} else if (ip_flow->nw_proto == IPPROTO_SCTP) {
--
2.27.0
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovs-ctl: add missing description for --ovs-vswitchd-options and --ovsdb-server-options to usage()
On Tue, Oct 5, 2021 at 12:47 PM wrote:
>
> From: Remi Jouannet
>
> the options commit by fce20b8b73b1 were missing a description in ovs-ctl help
> message
>
> Fixes: fce20b8b73b1 ("ovs-ctl: Permit to specify additional options")
> Signed-off-by: Remi Jouannet
One minor comment, if you (already) registered to patchwork, you can
mark your previous patches as superseded.
https://patchwork.ozlabs.org/project/openvswitch/patch/1632229406-23598-1-git-send-email-remijouan...@gmail.com/
https://patchwork.ozlabs.org/project/openvswitch/patch/1632505719-26741-1-git-send-email-remijouan...@gmail.com/
This saves some OVS maintainers cycles.
Reviewed-by: David Marchand
Thanks.
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v5 3/3] conntrack: limit port clash resolution attempts
From: Paolo Valerio
Date: 2021-10-05 06:04:57
To: we...@ucloud.cn,i.maxim...@ovn.org,acon...@redhat.com
Cc: d...@openvswitch.org
Subject: Re: [PATCH v5 3/3] conntrack: limit port clash resolution attempts>not
a full review, but see some questions/remarks below.
>
>we...@ucloud.cn writes:
>
>> From: wenxu
>>
>> In case almost or all available ports are taken, clash resolution can
>> take a very long time, resulting in pmd hang in conntrack.
>>
>> This can happen when many to-be-natted hosts connect to same
>> destination:port (e.g. a proxy) and all connections pass the same SNAT.
>>
>> Pick a random offset in the acceptable range, then try ever smaller
>> number of adjacent port numbers, until either the limit is reached or a
>> useable port was found. This results in at most 248 attempts
>> (128 + 64 + 32 + 16 + 8, i.e. 4 restarts with new search offset)
>> instead of 64000+.
>>
>> And if thenumber of ip address will limit the max attempts and which
>> will lead the total attempts under 248.
>>
>> Signed-off-by: wenxu
>> ---
>> lib/conntrack.c | 47 +++
>> 1 file changed, 43 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/conntrack.c b/lib/conntrack.c
>> index 52b5211..02bc2b9 100644
>> --- a/lib/conntrack.c
>> +++ b/lib/conntrack.c
>> @@ -2427,7 +2427,11 @@ nat_get_unique_tuple(struct conntrack *ct, const
>> struct conn *conn,
>> uint16_t min_sport, max_sport, curr_sport, orig_sport;
>> bool pat_proto = conn->key.nw_proto == IPPROTO_TCP ||
>> conn->key.nw_proto == IPPROTO_UDP;
>> +unsigned int attempts, max_attempts, min_attempts;
>> uint16_t min_dport, max_dport, curr_dport;
>> +uint16_t range_src, range_dst, range_max;
>> +uint32_t range_addr;
>> +unsigned int i;
>>
>> min_addr = nat_info->min_addr;
>> max_addr = nat_info->max_addr;
>> @@ -2444,6 +2448,19 @@ nat_get_unique_tuple(struct conntrack *ct, const
>> struct conn *conn,
>> set_dport_range(nat_info, >key, hash, _dport,
>> _dport, _dport);
>>
>> +range_src = max_sport - min_sport + 1;
>> +range_dst = max_dport - min_dport + 1;
>> +range_max = range_src > range_dst ? range_src : range_dst;
>> +range_addr = ntohl(max_addr.ipv4) - ntohl(min_addr.ipv4) + 1;
>
>what about ipv6?
>
>> +max_attempts = 128 / range_addr;
>> +if (max_attempts < 1) {
>> +max_attempts = 1;
>> +}
>> +min_attempts = 16 / range_addr;
>> +if (min_attempts < 2) {
>> +min_attempts = 2;
>> +}
>> +
>> another_round:
>> store_addr_to_key(_addr, _conn->rev_key,
>>nat_info->nat_action);
>> @@ -2459,17 +2476,39 @@ another_round:
>>
>> curr_sport = orig_sport;
>>
>> +attempts = range_max;
>> +if (attempts > max_attempts) {
>> +attempts = max_attempts;
>> +}
>> +
>> +another_port_round:
>> +i = 0;
>> FOR_EACH_PORT_IN_RANGE(curr_dport, min_dport, max_dport) {
>> nat_conn->rev_key.src.port = htons(curr_dport);
>> FOR_EACH_PORT_IN_RANGE(curr_sport, min_sport, max_sport) {
>> -nat_conn->rev_key.dst.port = htons(curr_sport);
>> -if (!conn_lookup(ct, _conn->rev_key,
>> - time_msec(), NULL, NULL)) {
>> -return true;
>> +if (i++ < attempts) {
>> +nat_conn->rev_key.dst.port = htons(curr_sport);
>> +if (!conn_lookup(ct, _conn->rev_key,
>> + time_msec(), NULL, NULL)) {
>> +return true;
>> +}
>> +} else {
>> +goto next_attempts;
>> }
>> }
>> }
>
>>
>> +next_attempts:
>> +if (attempts >= range_max || attempts < min_attempts) {
>> +goto next_addr;
>> +}
>> +
>> +attempts /= 2;
>> +curr_dport = min_dport + (random_uint32() % range_dst);
>> +curr_sport = min_sport + (random_uint32() % range_src);
>> +
>> +goto another_port_round;
>> +
>
>here you should be able to spare the "goto next_addr" changing the
>condition of the if and enclosing the four lines above
>
>Just to resume some points raised in previous emails:
>
>I think that your remark about splitting the two port range iterations
>instead of keeping it nested could be a good idea.
>The first visible difference here is that in such case the dst port (of
>course, in case of DNAT) range would have precedence over the src
>manipulation in the resolution. The second is that we could double the
>number of attempts, but that should not be a big deal if we keep the
>maximum number reasonable.
Agree with you. It makes the dnat special case handle individually. So
I will post a new one for this.
>This is what the kernel does, and IMO it could fit our needs too.
>
>The second remark is about IP the range iteration. I wonder if we really
>need it at all for pat_protos. I may be wrong here,
Re: [ovs-dev] [PATCH] ovs-ctl: add missing description for --ovs-vswitchd-options and --ovsdb-server-options to usage()
remijouan...@gmail.com writes:
> From: Remi Jouannet
>
> the options commit by fce20b8b73b1 were missing a description in ovs-ctl help
> message
>
> Fixes: fce20b8b73b1 ("ovs-ctl: Permit to specify additional options")
> Signed-off-by: Remi Jouannet
> ---
Acked-by: Aaron Conole
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [CI] Windows build failures on AppVeyor
Hi Alin, I see that the AppVeyor builds are failing due to some issue with the signtool options (and some warnings that might need to be addressed). Can you have a look? Here is a sample output: C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\signtool.exe sign /ph /sha1 "25C1E579759C692A3BAE65AA567BE4A4C443CFD9" libtool: compile: build-aux/cccl -DHAVE_CONFIG_H -I. -I ./include/windows -I ./datapath-windows/include -Ic:/PTHREADS-BUILT//include -O2 -I ./include -I ./include -I ./lib -I ./lib -IC:/OpenSSL-Win64/include -Wstrict-prototypes -Wall -Wextra -Wno-sign-compare -Wpointer-arith -Wformat -Wformat-security -Wswitch-enum -Wunused-parameter -Wbad-function-cast -Wcast-align -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-field-initializers -Wthread-safety -fno-strict-aliasing -Wswitch-bool -Wlogical-not-parentheses -Wsizeof-array-argument -Wbool-compare -Wshift-negative-value -Wduplicated-cond -Qunused-arguments -Wshadow -Wmultistatement-macros -Wcast-align=strict -Wno-null-pointer-arithmetic -Warray-bounds-pointer-arithmetic -g -c lib/conntrack-other.c 3>SIGNTASK : SignTool error : No file digest algorithm specified. Please specify the digest algorithm with the /fd flag. Using /fd SHA256 is recommended and more secure than SHA1. Calling signtool with /fd sha1 is equivalent to the previous behavior. In order to select the hash algorithm used in the signing certificate's signature, use the /fd certHash option. [c:\openvswitch_compile\datapath-windows\ovsext\ovsext.vcxproj] You can see an example failure at: https://ci.appveyor.com/project/blp/ovs/builds/41038081/job/h8ay65w6d638vs2v Thanks, Aaron ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] MAINTAINERS: Transition myself to emeritus status.
Thanks for everything Ben! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v6] dpdk: Support running PMD threads on any core.
On Tue, Oct 5, 2021 at 12:43 PM Kevin Traynor wrote:
> > @@ -489,6 +498,11 @@ dpdk_init__(const struct smap *ovs_other_config)
> > }
> > }
> >
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> > +unixctl_command_register("dpdk/lcores-list", "", 0, 0,
>
> typo here
Ack.
>
> Just to note as it is DPDK lcore list, it won't show pmd threads after
> RTE_LCORE_MAX has been reached. It might be worth adding note to OVS
> command documentation.
I can add a warning if the lcore-list command notices that the set of
cores in pmd-cpu-mask is larger than list of NON EAL lcores.
>
> Those pmds threads will also not get an lcore when others have been
> removed. Though these items are based on pmds > RTE_LCORE_MAX which is a
> very unlikely corner case.
Good catch!
I'll fix this.
>
> > + dpdk_unixctl_mem_stream, rte_lcore_dump);
> > +#pragma GCC diagnostic pop
> > unixctl_command_register("dpdk/log-list", "", 0, 0,
> >dpdk_unixctl_mem_stream, rte_log_dump);
> > unixctl_command_register("dpdk/log-set", "{level | pattern:level}", 0,
> > @@ -572,11 +586,43 @@ dpdk_available(void)
> > }
> >
> > void
> > -dpdk_set_lcore_id(unsigned cpu)
> > +dpdk_init_thread_context(unsigned cpu)
> > {
> > /* NON_PMD_CORE_ID is reserved for use by non pmd threads. */
> > ovs_assert(cpu != NON_PMD_CORE_ID);
> > -RTE_PER_LCORE(_lcore_id) = cpu;
> > +
> > +if (!dpdk_available()) {
> > +return;
> > +}
> > +
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> > +if (rte_thread_register() < 0) {
> > +#pragma GCC diagnostic pop
> > +VLOG_WARN("This OVS pmd thread will share resources with the
> > non-pmd "
> > + "thread: %s.", rte_strerror(rte_errno));
>
> It would be good to tell the OVS user what the impact is for them here.
I'll reword.
>
> Also, the strerror is low level and it's not really clear from an OVS
> perspective how it relates e.g. it can say "Cannot allocate memory" when
> RTE_LCORE_MAX reached which sounds fatal, but in this case is not for OVS.
DPDK EAL logs already provide some info, I'll drop the error string from dpdk.
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] MAINTAINERS: Transition myself to emeritus status.
On Tue, Oct 05, 2021 at 09:32:41AM -0700, Ben Pfaff wrote: > It has been a long time since I've been able to devote significant time > to OVS work. I don't expect that to change. I think that the responsible > thing to do is to transition myself to emeritus status, with this patch. > > Signed-off-by: Ben Pfaff Thanks for all your hard work Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ipf: release unhandled packets from the batch
On Tue, Oct 5, 2021 at 8:19 PM Aaron Conole wrote:
>
> Since 640d4db788ed ("ipf: Fix a use-after-free error, ...") the ipf
> framework unconditionally allocates a new dp_packet to track
> individual fragments. This prevents a use-after-free. However, an
> additional issue was present - even when the packet buffer is cloned,
> if the ip fragment handling code keeps it, the original buffer is
> leaked during the refill loop. Even in the original processing code,
> the hardcoded dnsteal branches would always leak a packet buffer from
> the refill loop.
>
> This can be confirmed with valgrind:
>
> ==717566== 16,672 (4,480 direct, 12,192 indirect) bytes in 8 blocks are
> definitely lost in loss record 390 of 390
> ==717566==at 0x484086F: malloc (vg_replace_malloc.c:380)
> ==717566==by 0x537BFD: xmalloc__ (util.c:137)
> ==717566==by 0x537BFD: xmalloc (util.c:172)
> ==717566==by 0x46DDD4: dp_packet_new (dp-packet.c:153)
> ==717566==by 0x46DDD4: dp_packet_new_with_headroom (dp-packet.c:163)
> ==717566==by 0x550AA6: netdev_linux_batch_rxq_recv_sock.constprop.0
> (netdev-linux.c:1262)
> ==717566==by 0x5512AF: netdev_linux_rxq_recv (netdev-linux.c:1511)
> ==717566==by 0x4AB7E0: netdev_rxq_recv (netdev.c:727)
> ==717566==by 0x47F00D: dp_netdev_process_rxq_port (dpif-netdev.c:4699)
> ==717566==by 0x47FD13: dpif_netdev_run (dpif-netdev.c:5957)
> ==717566==by 0x4331D2: type_run (ofproto-dpif.c:370)
> ==717566==by 0x41DFD8: ofproto_type_run (ofproto.c:1768)
> ==717566==by 0x40A7FB: bridge_run__ (bridge.c:3245)
> ==717566==by 0x411269: bridge_run (bridge.c:3310)
> ==717566==by 0x406E6C: main (ovs-vswitchd.c:127)
>
> The fix is to delete the original packet when it isn't able to be
> reinserted into the packet batch. Subsequent valgrind runs show that
> the packets are not leaked from the batch any longer.
>
> Fixes: 640d4db788ed ("ipf: Fix a use-after-free error, and remove the
> 'do_not_steal' flag.")
Not sure I would flag this one, since as you explained, the leak was
present from the commit below.
> Fixes: 4ea96698f667 ("Userspace datapath: Add fragmentation handling.")
> Reported-by: Wan Junjie
> Reported-at: https://github.com/openvswitch/ovs-issues/issues/226
> Signed-off-by: Aaron Conole
But in any case, this patch lgtm.
Reviewed-by: David Marchand
--
David Marchand
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn 1/2] northd: Use address sets for ARP responder flows for VIPs.
On 10/6/21 3:01 AM, Numan Siddique wrote: > On Fri, Oct 1, 2021 at 9:47 AM Dumitru Ceara wrote: >> >> Otherwise the S_ROUTER_IN_IP_INPUT aggregated flows that reply to ARP >> requests targeting load balancer VIPs get completely regenerated every >> time a new VIP/LB is added. This affects SB memory usage as RAFT log >> entries are huge. Use an address set instead. Updating an address set >> is incremental, because it's performed with a "mutate" operation. >> >> On a large scale ovn-kubernetes deployment with a high number of >> load balancers (services) this change reduces memory usage of >> ovsdb-servers running the OVN_Southbound cluster by 50%, from ~2GB >> RSS to ~1GB RSS. >> >> Signed-off-by: Dumitru Ceara > > Thanks Dumitru for the patches. > > Both the patches LGTM. I applied both to the main branch. > > Numan > Thanks! ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
