Re: [ovs-dev] [PATCH ovn] Cancel previous runs in the PR when you push new commits

[Igor Zhukov]

Great!

You are welcome!

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

Re: [ovs-dev] [PATCH v4 9/9] debian: Add option to build without DPDK.

[Frode Nordahl]

On Fri, Jul 15, 2022 at 3:45 AM Ilya Maximets  wrote:
>
> On 7/14/22 17:55, Frode Nordahl wrote:
> > From: Ilya Maximets 
> >
> > Signed-off-by: Ilya Maximets 
> > Co-authored-by: Frode Nordahl 
> > Signed-off-by: Frode Nordahl 
> > ---
> >  .ci/linux-build.sh |  6 ++-
> >  .github/workflows/build-and-test.yml   | 12 +-
> >  .gitignore |  1 +
> >  Documentation/intro/install/debian.rst | 27 ++--
> >  debian/.gitignore  | 21 +
> >  debian/automake.mk | 22 +-
> >  debian/clean   |  4 +-
> >  debian/{control => control.in} | 60 +-
> >  debian/rules   |  6 +++
> >  9 files changed, 110 insertions(+), 49 deletions(-)
> >  create mode 100644 debian/.gitignore
> >  rename debian/{control => control.in} (85%)
> >
>
> 
>
> > diff --git a/debian/automake.mk b/debian/automake.mk
> > index a3c2d7289..2f94c2999 100644
> > --- a/debian/automake.mk
> > +++ b/debian/automake.mk
> > @@ -3,6 +3,7 @@ EXTRA_DIST += \
> >   debian/changelog \
> >   debian/clean \
> >   debian/control \
> > + debian/control.in \
> >   debian/copyright \
> >   debian/copyright.in \
> >   debian/dirs \
> > @@ -88,4 +89,23 @@ $(srcdir)/debian/copyright: AUTHORS.rst 
> > debian/copyright.in
> > sed -e '1,/%AUTHORS%/d' $(srcdir)/debian/copyright.in;   \
> >   } > $@
> >
> > -DISTCLEANFILES += debian/copyright
> > +$(srcdir)/debian/control: debian/control.in config.h
> > +if DPDK_NETDEV
> > + sed -e 's/^# DPDK_NETDEV //' \
> > + < $(srcdir)/debian/control.in > $(srcdir)/debian/control
> > +else
> > + grep -v "^# DPDK_NETDEV" \
> > + < $(srcdir)/debian/control.in > $(srcdir)/debian/control
> > +endif
> > +
> > +debian: $(srcdir)/debian/copyright $(srcdir)/debian/control
> > +.PHONY: debian
> > +
> > +
> > +debian-deb: debian
> > + make distclean
> > +if DPDK_NETDEV
> > + DEB_BUILD_OPTIONS="nocheck parallel=`nproc`" fakeroot debian/rules 
> > binary
> > +else
> > + DEB_BUILD_OPTIONS="nocheck parallel=`nproc` nodpdk" fakeroot 
> > debian/rules binary
> > +endif
>
> There are several chicken-and-egg problems with this one patch:
>
> - Since targets for control and copyright files are trying to
>   re-write the file in $(srcdir), the distcheck is failing,
>   because during distcheck, the source directory is read-only.
>
> - Since control file has a dependency on config.h, it is getting
>   re-built during distcheck.  copyright is not, that's why
>   distcheck is not failing without this patch.  But we do need
>   a dependency for control, otherwise it will not be re-built
>   after re-configuration.
>
> - Since control and copyright are auto-generated files, they
>   technically should not be part of the distribution.  If we will
>   remove them from EXTRA_DIST and add to CLEANFILES, they will
>   be cleaned up before packing the source archive and that fixes
>   the distcheck, IIRC (It's been a few hours of experiments, so
>   I don't really remember if that fixed the distcheck).
>
> - However, 'debian/rules binary' requires the source directory
>   to not be configured, so the distclean.  But distclean removes
>   generated control and copyright.  We could copy them, distclean
>   and copy back, but...
>
> - 'make distcean' is really not enough.  Most of the information
>   about the previous build of debian packages is preserved, so
>   some old directories are getting re-used all the time and
>   packages are not really what they are supposed to be.  We have
>   to call 'debian/rules clean', but that will execute distclean
>   and fail on removed control file...
>
> - If we'll add control and copyright back to the distribution,
>   but will allow their generation in the build directory instead
>   of a source directory, that helps with distcheck a bit, but
>   fails at distcleancheck, because files are not cleaned.
>
> - And you need dpdk-dev already installed for ./configure
>   --with-dpdk=shared to succeed.
>
> So, after lots of experiments the only solution that appears to
> work seems to be following:
>
> - Remove control and copyright from the distribution.
> - Add them to CLEANFILES
> - Create files in build directory, not source.
> - In the debian-deb target, call distclean first, then re-generate
>   both control and copyright, then call 'debian/rules clean'.
>   It won't call distclean again, because the directory is not
>   configured after the first distclean.
> - Install libdpdk-dev beforehand in GHA.
> - Add the builddir sanity check as 'make debian-deb' doesn't
>   make a lot of sense if not building from the source directory.
>
> With that schema, by the time we're calling 'debian/rules binary'
> we have all files in place.  And if they are getting generated
> during distcheck, it will be possible to create them and they
> will be correctly cleaned up 

Re: [ovs-dev] [RFC ovn] controller: send GARPs for LSPs in vlan-backed network scenario

[shy liu]

> On 7/13/22 18:07, Lorenzo Bianconi wrote:
>>> On 6/17/22 00:31, Lorenzo Bianconi wrote:
 When using VLAN backed networks and OVN routers leveraging the
 'ovn-chassis-mac-mappings' option, the eth.src field is replaced by the
 chassis mac address in order to not expose the router mac address from
 different nodes and confuse the TOR switch. However doing so the TOR
 switch is not able to learn the port/mac bindings for routed E/W 
 traffic
 and it is force to always flood it. Fix this issue adding the 
 capability
 to send GARP traffic for logical switch ports if the corresponding 
 logical
 switch has the ovn-lsp-garp parameter set to true in the option column.
 More into about the issue can be found here [0].
 
 [0] 
 https://mail.openvswitch.org/pipermail/ovs-discuss/2020-September/050678.html
  
 
 Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2087779 
 
 
 Signed-off-by: Lorenzo Bianconi >>> >
 ---
>>> 
>>> Hi Lorenzo,
>> 
>> Hi Dumitru,
>> 
>> Thanks for reviewing it :)
>> 
>>> 
>>> I have a few concerns with this approach:
>>> 
>>> a. The CMS will have to set this option for all VMs on all logical
>>> switches which will enable periodic GARPs for all of them all the time.
>>> That seems like quite a lot of broadcast traffic in the fabric.
>>> 
>>> b. There's no guarantee that the GARPs are sent in time to prevent the
>>> FDB timeouts on the ToR switches.  At best we could make the interval
>>> configurable but I don't think this is way better either.
>>> 
>>> c. This is not really introduced by your patch but we will be causing
>>> this more often now.  With the topology:
>>> 
>>> (HV1) VM1 -- LS1 --- LR -- LS2 -- VM2 (HV2)
>>>  (VLAN-backed network)
>>> 
>>> HV1 configured with chassis mac mapping HV1-MAC
>>> HV2 configured with chassis mac mapping HV2-MAC
>>> 
>>> We're leaking MAC addresses from LS1's broadcast domain (VM1-MAC) and
>>> from LS2's broadcast domain (VM2-MAC) into the fabric.  I'm not sure
>>> that's OK.
>>> 
>>> I think a proper solution is to change how we run the logical pipelines
>>> in case of vlan-backed networks.  We currently have an assymetry:
>>> 
>>> For packets flowing from VM1 to VM2 we execute:
>>> - on HV1: LS1-ingress, LS1-egress, LR-ingress, LR-egress, LS2-ingress
>>> - on HV2: LS2-egress
>>> 
>>> For packets flowing from VM2 to VM1 we execute:
>>> - on HV2: LS2-ingress, LS2-egress, LR-ingress, LR-egress, LS1-ingress
>>> - on HV1: LS1-egress
>>> 
>>> What if we change this to:
>>> VM1 -> VM2:
>>> - on HV1: LS1-ingress, LS1-egress, LR-ingress
>>> - on HV2: LR-egress, LS2-ingress, LS2-egress
>>> 
>>> VM2 -> VM1:
>>> - on HV2: LS2-ingress, LS2-egress, LR-ingress
>>> - on HV2: LR-egress, LS1-ingress, LS1-egress
>> 
>> I do not know why the current architecture is done this way (any 
>> suggestions??).
>> I guess the approach you suggested should work. Are we introducing any 
>> backward
>> compatibility issue?
> 
> We would probably create a compatibility issue. :)
> 
> I don't know if this approach would even work, I was just trying to
> imagine how traffic from within OVN should be seen on the fabric in this
> case.
> 
> Maybe we need to think some more about other options.
> 
> Regards,
> Dumitru
 Hi Dumitru and Lorenzo, 
>>> 
>>> Hi Shy Liu,
>>> 
 in my opinion, the flood issue maybe caused by the implemention that
 logical_switch always be an arp-proxy for lsp which has known address, 
 but this implemention is not applicable to vlan backed network. Right ?
 
 I have an solution:
 Maybe we can add a option named arp-proxy for logical_switch 
 that always be false if network type is vlan, then disable the 
 logical_switch response the arp for  the lsp which belongs to 
 the vlan backed network.
 
 So that this solution can let the destination MAC address
 always learnt by TOR for vlan backed network.
>>> 
>>> For e/w routed traffic from pod A to pod B, pod A will send an arp request
>>> for the router ip address. Who is going to reply to this request in this 
>>> way?
>> Hi Lorenzo, 
>> sorry that I had not describe it clearly.
>> We can disable arp response for the lsp which type is not router port nor 
>> localport.
>> So the logical_switch still responses the arp request for lrp.
> 
> IIUC what you mean here, this approach will be helpful just if pod A and pod B
> are on the same

Re: [ovs-dev] [PATCH v4 9/9] debian: Add option to build without DPDK.

[Gregory Rose]

On 7/14/2022 6:45 PM, Ilya Maximets wrote:

On 7/14/22 17:55, Frode Nordahl wrote:

From: Ilya Maximets 

Signed-off-by: Ilya Maximets 
Co-authored-by: Frode Nordahl 
Signed-off-by: Frode Nordahl 
---
  .ci/linux-build.sh |  6 ++-
  .github/workflows/build-and-test.yml   | 12 +-
  .gitignore |  1 +
  Documentation/intro/install/debian.rst | 27 ++--
  debian/.gitignore  | 21 +
  debian/automake.mk | 22 +-
  debian/clean   |  4 +-
  debian/{control => control.in} | 60 +-
  debian/rules   |  6 +++
  9 files changed, 110 insertions(+), 49 deletions(-)
  create mode 100644 debian/.gitignore
  rename debian/{control => control.in} (85%)






diff --git a/debian/automake.mk b/debian/automake.mk
index a3c2d7289..2f94c2999 100644
--- a/debian/automake.mk
+++ b/debian/automake.mk
@@ -3,6 +3,7 @@ EXTRA_DIST += \
debian/changelog \
debian/clean \
debian/control \
+   debian/control.in \
debian/copyright \
debian/copyright.in \
debian/dirs \
@@ -88,4 +89,23 @@ $(srcdir)/debian/copyright: AUTHORS.rst debian/copyright.in
  sed -e '1,/%AUTHORS%/d' $(srcdir)/debian/copyright.in;   \
} > $@
  
-DISTCLEANFILES += debian/copyright

+$(srcdir)/debian/control: debian/control.in config.h
+if DPDK_NETDEV
+   sed -e 's/^# DPDK_NETDEV //' \
+   < $(srcdir)/debian/control.in > $(srcdir)/debian/control
+else
+   grep -v "^# DPDK_NETDEV" \
+   < $(srcdir)/debian/control.in > $(srcdir)/debian/control
+endif
+
+debian: $(srcdir)/debian/copyright $(srcdir)/debian/control
+.PHONY: debian
+
+
+debian-deb: debian
+   make distclean
+if DPDK_NETDEV
+   DEB_BUILD_OPTIONS="nocheck parallel=`nproc`" fakeroot debian/rules 
binary
+else
+   DEB_BUILD_OPTIONS="nocheck parallel=`nproc` nodpdk" fakeroot 
debian/rules binary
+endif


There are several chicken-and-egg problems with this one patch:

- Since targets for control and copyright files are trying to
   re-write the file in $(srcdir), the distcheck is failing,
   because during distcheck, the source directory is read-only.

- Since control file has a dependency on config.h, it is getting
   re-built during distcheck.  copyright is not, that's why
   distcheck is not failing without this patch.  But we do need
   a dependency for control, otherwise it will not be re-built
   after re-configuration.

- Since control and copyright are auto-generated files, they
   technically should not be part of the distribution.  If we will
   remove them from EXTRA_DIST and add to CLEANFILES, they will
   be cleaned up before packing the source archive and that fixes
   the distcheck, IIRC (It's been a few hours of experiments, so
   I don't really remember if that fixed the distcheck).

- However, 'debian/rules binary' requires the source directory
   to not be configured, so the distclean.  But distclean removes
   generated control and copyright.  We could copy them, distclean
   and copy back, but...

- 'make distcean' is really not enough.  Most of the information
   about the previous build of debian packages is preserved, so
   some old directories are getting re-used all the time and
   packages are not really what they are supposed to be.  We have
   to call 'debian/rules clean', but that will execute distclean
   and fail on removed control file...

- If we'll add control and copyright back to the distribution,
   but will allow their generation in the build directory instead
   of a source directory, that helps with distcheck a bit, but
   fails at distcleancheck, because files are not cleaned.

- And you need dpdk-dev already installed for ./configure
   --with-dpdk=shared to succeed.

So, after lots of experiments the only solution that appears to
work seems to be following:

- Remove control and copyright from the distribution.
- Add them to CLEANFILES
- Create files in build directory, not source.
- In the debian-deb target, call distclean first, then re-generate
   both control and copyright, then call 'debian/rules clean'.
   It won't call distclean again, because the directory is not
   configured after the first distclean.
- Install libdpdk-dev beforehand in GHA.
- Add the builddir sanity check as 'make debian-deb' doesn't
   make a lot of sense if not building from the source directory.

With that schema, by the time we're calling 'debian/rules binary'
we have all files in place.  And if they are getting generated
during distcheck, it will be possible to create them and they
will be correctly cleaned up in the process.  Also, we're always
performing a clean build, so no need for the documentation note
about 'debian/rules clean'.  And I got a green build in GHA
with it:
   https://github.com/igsilya/ovs/actions/runs/2674107164

See the diff below.  If that make sense (and if

Re: [ovs-dev] [PATCH v4 9/9] debian: Add option to build without DPDK.

[Ilya Maximets]

On 7/14/22 17:55, Frode Nordahl wrote:
> From: Ilya Maximets 
> 
> Signed-off-by: Ilya Maximets 
> Co-authored-by: Frode Nordahl 
> Signed-off-by: Frode Nordahl 
> ---
>  .ci/linux-build.sh |  6 ++-
>  .github/workflows/build-and-test.yml   | 12 +-
>  .gitignore |  1 +
>  Documentation/intro/install/debian.rst | 27 ++--
>  debian/.gitignore  | 21 +
>  debian/automake.mk | 22 +-
>  debian/clean   |  4 +-
>  debian/{control => control.in} | 60 +-
>  debian/rules   |  6 +++
>  9 files changed, 110 insertions(+), 49 deletions(-)
>  create mode 100644 debian/.gitignore
>  rename debian/{control => control.in} (85%)
> 



> diff --git a/debian/automake.mk b/debian/automake.mk
> index a3c2d7289..2f94c2999 100644
> --- a/debian/automake.mk
> +++ b/debian/automake.mk
> @@ -3,6 +3,7 @@ EXTRA_DIST += \
>   debian/changelog \
>   debian/clean \
>   debian/control \
> + debian/control.in \
>   debian/copyright \
>   debian/copyright.in \
>   debian/dirs \
> @@ -88,4 +89,23 @@ $(srcdir)/debian/copyright: AUTHORS.rst debian/copyright.in
> sed -e '1,/%AUTHORS%/d' $(srcdir)/debian/copyright.in;   \
>   } > $@
>  
> -DISTCLEANFILES += debian/copyright
> +$(srcdir)/debian/control: debian/control.in config.h
> +if DPDK_NETDEV
> + sed -e 's/^# DPDK_NETDEV //' \
> + < $(srcdir)/debian/control.in > $(srcdir)/debian/control
> +else
> + grep -v "^# DPDK_NETDEV" \
> + < $(srcdir)/debian/control.in > $(srcdir)/debian/control
> +endif
> +
> +debian: $(srcdir)/debian/copyright $(srcdir)/debian/control
> +.PHONY: debian
> +
> +
> +debian-deb: debian
> + make distclean
> +if DPDK_NETDEV
> + DEB_BUILD_OPTIONS="nocheck parallel=`nproc`" fakeroot debian/rules 
> binary
> +else
> + DEB_BUILD_OPTIONS="nocheck parallel=`nproc` nodpdk" fakeroot 
> debian/rules binary
> +endif

There are several chicken-and-egg problems with this one patch:

- Since targets for control and copyright files are trying to
  re-write the file in $(srcdir), the distcheck is failing,
  because during distcheck, the source directory is read-only.

- Since control file has a dependency on config.h, it is getting
  re-built during distcheck.  copyright is not, that's why
  distcheck is not failing without this patch.  But we do need
  a dependency for control, otherwise it will not be re-built
  after re-configuration.

- Since control and copyright are auto-generated files, they
  technically should not be part of the distribution.  If we will
  remove them from EXTRA_DIST and add to CLEANFILES, they will
  be cleaned up before packing the source archive and that fixes
  the distcheck, IIRC (It's been a few hours of experiments, so
  I don't really remember if that fixed the distcheck).

- However, 'debian/rules binary' requires the source directory
  to not be configured, so the distclean.  But distclean removes
  generated control and copyright.  We could copy them, distclean
  and copy back, but...

- 'make distcean' is really not enough.  Most of the information
  about the previous build of debian packages is preserved, so
  some old directories are getting re-used all the time and
  packages are not really what they are supposed to be.  We have
  to call 'debian/rules clean', but that will execute distclean
  and fail on removed control file...

- If we'll add control and copyright back to the distribution,
  but will allow their generation in the build directory instead
  of a source directory, that helps with distcheck a bit, but
  fails at distcleancheck, because files are not cleaned.

- And you need dpdk-dev already installed for ./configure
  --with-dpdk=shared to succeed.

So, after lots of experiments the only solution that appears to
work seems to be following:

- Remove control and copyright from the distribution.
- Add them to CLEANFILES
- Create files in build directory, not source.
- In the debian-deb target, call distclean first, then re-generate
  both control and copyright, then call 'debian/rules clean'.
  It won't call distclean again, because the directory is not
  configured after the first distclean.
- Install libdpdk-dev beforehand in GHA.
- Add the builddir sanity check as 'make debian-deb' doesn't
  make a lot of sense if not building from the source directory.

With that schema, by the time we're calling 'debian/rules binary'
we have all files in place.  And if they are getting generated
during distcheck, it will be possible to create them and they
will be correctly cleaned up in the process.  Also, we're always
performing a clean build, so no need for the documentation note
about 'debian/rules clean'.  And I got a green build in GHA
with it:
  https://github.com/igsilya/ovs/actions/runs/2674107164

See the diff below.  If that make sense (and if that will

Re: [ovs-dev] [v11 07/10] odp-execute: Add ISA implementation of pop_vlan action.

[Ilya Maximets]

On 7/14/22 19:51, Emma Finn wrote:
> From: Harry van Haaren 
> 
> This commit adds the AVX512 implementation of the
> pop_vlan action.
> 
> Signed-off-by: Emma Finn 
> ---
>  lib/automake.mk   |   4 +
>  lib/odp-execute-avx512.c  | 186 ++
>  lib/odp-execute-private.c |  32 ++-
>  lib/odp-execute-private.h |   4 +
>  4 files changed, 225 insertions(+), 1 deletion(-)
>  create mode 100644 lib/odp-execute-avx512.c
> 
> diff --git a/lib/automake.mk b/lib/automake.mk
> index 5c3b05f6b..a76de6dbf 100644
> --- a/lib/automake.mk
> +++ b/lib/automake.mk
> @@ -45,6 +45,10 @@ lib_libopenvswitchavx512_la_CFLAGS += \
>  lib_libopenvswitchavx512_la_SOURCES += \
>   lib/dpif-netdev-extract-avx512.c \
>   lib/dpif-netdev-lookup-avx512-gather.c
> +if HAVE_GCC_AVX512VL_GOOD
> +lib_libopenvswitchavx512_la_SOURCES += \
> + lib/odp-execute-avx512.c
> +endif # HAVE_GCC_AVX512VL_GOOD
>  endif # HAVE_AVX512VL
>  endif # HAVE_AVX512BW
>  lib_libopenvswitchavx512_la_LDFLAGS = \
> diff --git a/lib/odp-execute-avx512.c b/lib/odp-execute-avx512.c
> new file mode 100644
> index 0..d929abe68
> --- /dev/null
> +++ b/lib/odp-execute-avx512.c
> @@ -0,0 +1,186 @@
> +/*
> + * Copyright (c) 2022 Intel.
> + *
> + * 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.
> + */
> +
> +#ifdef __x86_64__
> +/* Sparse cannot handle the AVX512 instructions. */
> +#if !defined(__CHECKER__)
> +
> +#include 
> +#include 
> +
> +#include "dp-packet.h"
> +#include "immintrin.h"
> +#include "odp-execute-private.h"
> +#include "odp-netlink.h"
> +#include "openvswitch/vlog.h"



> +
> +#endif /* Sparse */
> +
> +#else /* __x86_64__ */
> +
> +#include 
> +#include "odp-execute-private.h"
> +/* Function itself is required to be called, even in e.g. 32-bit builds.
> + * This dummy init function ensures 32-bit builds succeed too.
> + */
> +
> +int
> +action_avx512_init(struct odp_execute_action_impl *self OVS_UNUSED)
> +{
> +  return -ENOTSUP;

The build in CI fails here, since ENOTSUP is not defined in this branch:

lib/odp-execute-avx512.c: In function ‘action_avx512_init’:
lib/odp-execute-avx512.c:183:11: error: ‘ENOTSUP’ undeclared (first use in this 
function)
   return -ENOTSUP;
   ^~~
lib/odp-execute-avx512.c:183:11: note: each undeclared identifier is reported 
only once for each function it appears in
lib/odp-execute-avx512.c:184:1: error: control reaches end of non-void function 
[-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors

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

[ovs-dev] [PATCH V6 5/6] acinclude.m4: Remove support for building the OVS kernel module.

[Greg Rose]

Since the openvswitch project inception it has had support for building
a Linux kernel module to support the OVS kernel datapath.  Since Linux
kernel release 5.8 support for newer kernels has been deprecated.  Now
is the time to fully discontinue support for building the openvswitch
kernel driver. Since Linux 5.9 the Linux built-in openvswitch kernel
driver supports all necessary features and functions of the kernel
datapath and the need to support this additional "out of tree" kernel
module is gone.

Remove the --with-linux configuration support from the acinclude.m4
configuration and warn user it is not supported any longer.

Signed-off-by: Greg Rose 
---
 acinclude.m4 | 810 +--
 1 file changed, 1 insertion(+), 809 deletions(-)

diff --git a/acinclude.m4 b/acinclude.m4
index d15f11a4e..e20d61df4 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -119,133 +119,9 @@ dnl OVS_CHECK_LINUX
 dnl
 dnl Configure linux kernel source tree
 AC_DEFUN([OVS_CHECK_LINUX], [
-  AC_ARG_WITH([linux],
-  [AC_HELP_STRING([--with-linux=/path/to/linux],
-  [Specify the Linux kernel build directory])])
-  AC_ARG_WITH([linux-source],
-  [AC_HELP_STRING([--with-linux-source=/path/to/linux-source],
-  [Specify the Linux kernel source directory
-   (usually figured out automatically from build
-   directory)])])
-
-  # Deprecated equivalents to --with-linux, --with-linux-source.
-  AC_ARG_WITH([l26])
-  AC_ARG_WITH([l26-source])
-
   if test X"$with_linux" != X; then
-KBUILD=$with_linux
-AC_MSG_WARN([--with-linux is deprecated and kernel support is limited to 
5.8 and below])
-  elif test X"$with_l26" != X; then
-KBUILD=$with_l26
-AC_MSG_WARN([--with-l26 is deprecated, please use --with-linux instead])
-  else
-KBUILD=
-  fi
-
-  if test X"$KBUILD" != X; then
-if test X"$with_linux_source" != X; then
-  KSRC=$with_linux_source
-elif test X"$with_l26_source" != X; then
-  KSRC=$with_l26_source
-  AC_MSG_WARN([--with-l26-source is deprecated, please use 
--with-linux-source instead])
-else
-  KSRC=
-fi
-  elif test X"$with_linux_source" != X || test X"$with_l26_source" != X; then
-AC_MSG_ERROR([Linux source directory may not be specified without Linux 
build directory])
-  fi
-
-  if test -n "$KBUILD"; then
-KBUILD=`eval echo "$KBUILD"`
-case $KBUILD in
-/*) ;;
-*) KBUILD=`pwd`/$KBUILD ;;
-esac
-
-# The build directory is what the user provided.
-# Make sure that it exists.
-AC_MSG_CHECKING([for Linux build directory])
-if test -d "$KBUILD"; then
-AC_MSG_RESULT([$KBUILD])
-AC_SUBST(KBUILD)
-else
-AC_MSG_RESULT([no])
-AC_ERROR([source dir $KBUILD doesn't exist])
-fi
-
-# Debian breaks kernel headers into "source" header and "build" headers.
-# We want the source headers, but $KBUILD gives us the "build" headers.
-# Use heuristics to find the source headers.
-AC_MSG_CHECKING([for Linux source directory])
-if test -n "$KSRC"; then
-  KSRC=`eval echo "$KSRC"`
-  case $KSRC in
-  /*) ;;
-  *) KSRC=`pwd`/$KSRC ;;
-  esac
-  if test ! -e $KSRC/include/linux/kernel.h; then
-AC_MSG_ERROR([$KSRC is not a kernel source directory])
-  fi
-else
-  KSRC=$KBUILD
-  if test ! -e $KSRC/include/linux/kernel.h; then
-# Debian kernel build Makefiles tend to include a line of the form:
-# MAKEARGS := -C /usr/src/linux-headers-3.2.0-1-common 
O=/usr/src/linux-headers-3.2.0-1-486
-# First try to extract the source directory from this line.
-KSRC=`sed -n 's/.*-C \([[^ ]]*\).*/\1/p' "$KBUILD"/Makefile`
-if test ! -e "$KSRC"/include/linux/kernel.h; then
-  # Didn't work.  Fall back to name-based heuristics that used to work.
-  case `echo "$KBUILD" | sed 's,/*$,,'` in # (
-*/build)
-  KSRC=`echo "$KBUILD" | sed 's,/build/*$,/source,'`
-  ;; # (
-*)
-  KSRC=`(cd $KBUILD && pwd -P) | sed 's,-[[^-]]*$,-common,'`
-  ;;
-  esac
-fi
-  fi
-  if test ! -e "$KSRC"/include/linux/kernel.h; then
-AC_MSG_ERROR([cannot find source directory (please use 
--with-linux-source)])
-  fi
-fi
-AC_MSG_RESULT([$KSRC])
-
-AC_MSG_CHECKING([for kernel version])
-version=`sed -n 's/^VERSION = //p' "$KSRC/Makefile"`
-patchlevel=`sed -n 's/^PATCHLEVEL = //p' "$KSRC/Makefile"`
-sublevel=`sed -n 's/^SUBLEVEL = //p' "$KSRC/Makefile"`
-if test X"$version" = X || test X"$patchlevel" = X; then
-   AC_ERROR([cannot determine kernel version])
-elif test X"$sublevel" = X; then
-   kversion=$version.$patchlevel
-else
-   kversion=$version.$patchlevel.$sublevel
-fi
-AC_MSG_RESULT([$kversion])

[ovs-dev] [PATCH V6 2/6] rhel: Stop packaging OVS kernel module.

[Greg Rose]

Remove the kernel driver specification for RHEL 6.x, 7.x, 8.x and Fedora.

Reviewed-by: David Marchand 
Signed-off-by: Greg Rose 
---
 Documentation/intro/install/rhel.rst  |  18 --
 Vagrantfile   |  12 +-
 poc/playbook-centos-builder.yml   |   8 -
 poc/playbook-fedora-builder.yml   |  16 --
 rhel/.gitignore   |   4 -
 rhel/automake.mk  |  23 --
 rhel/kmod-openvswitch-rhel6.spec.in   | 123 -
 rhel/openvswitch-dkms.spec.in | 103 
 rhel/openvswitch-fedora.spec.in   |   5 +-
 rhel/openvswitch-kmod-fedora.spec.in  | 152 ---
 rhel/openvswitch.spec.in  |   4 +-
 ...are_openvswitch_scripts_ovs-kmod-manage.sh | 237 --
 12 files changed, 3 insertions(+), 702 deletions(-)
 delete mode 100644 rhel/kmod-openvswitch-rhel6.spec.in
 delete mode 100644 rhel/openvswitch-dkms.spec.in
 delete mode 100644 rhel/openvswitch-kmod-fedora.spec.in
 delete mode 100644 rhel/usr_share_openvswitch_scripts_ovs-kmod-manage.sh

diff --git a/Documentation/intro/install/rhel.rst 
b/Documentation/intro/install/rhel.rst
index b21b274b7..d1fc42021 100644
--- a/Documentation/intro/install/rhel.rst
+++ b/Documentation/intro/install/rhel.rst
@@ -194,24 +194,6 @@ the unit tests, run::
/lib/modules/2.6.32-279.el6.x86_64/build doesn't exist`` or similar, then
the kernel-devel package is missing or buggy.
 
-Kernel Module
-~
-
-On RHEL 6, to build the Open vSwitch kernel module run::
-
-$ rpmbuild -bb rhel/kmod-openvswitch-rhel6.spec
-
-You might have to specify a kernel version and/or variants, e.g.::
-
-$ rpmbuild -bb \
--D "kversion 2.6.32-131.6.1.el6.x86_64" \
--D "kflavors default debug kdump" \
-rhel/kmod-openvswitch-rhel6.spec
-
-This produces an "kmod-openvswitch" RPM for each kernel variant, in this
-example: "kmod-openvswitch", "kmod-openvswitch-debug", and
-"kmod-openvswitch-kdump".
-
 .. _rhel-script-integrations:
 
 Red Hat Network Scripts Integration
diff --git a/Vagrantfile b/Vagrantfile
index 2cd603932..cdca0cf71 100644
--- a/Vagrantfile
+++ b/Vagrantfile
@@ -54,7 +54,7 @@ cd /vagrant
 [ -f Makefile ] && ./configure && make distclean
 mkdir -p ~/build
 cd ~/build
-/vagrant/configure --with-linux=/lib/modules/`uname -r`/build 
--enable-silent-rules
+/vagrant/configure --enable-silent-rules
 SCRIPT
 
 $build_ovs = <

[ovs-dev] [PATCH V6 6/6] Documentation: Remove kernel module documentation.

[Greg Rose]

As of Open vSwitch release 2.18 the OVS kernel module is no longer
supported.  Pull the documentation references.

Reviewed-by: David Marchand 
Signed-off-by: Greg Rose 
---
 Documentation/faq/releases.rst|  4 +-
 .../contributing/backporting-patches.rst  |  7 +++
 Documentation/intro/install/fedora.rst| 24 ---
 Documentation/intro/install/general.rst   | 63 ---
 4 files changed, 10 insertions(+), 88 deletions(-)

diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst
index 8cfe2d392..bf2f3438c 100644
--- a/Documentation/faq/releases.rst
+++ b/Documentation/faq/releases.rst
@@ -75,6 +75,7 @@ Q: What Linux kernel versions does each Open vSwitch release 
work with?
 2.15.x   3.16 to 5.8
 2.16.x   3.16 to 5.8
 2.17.x   3.16 to 5.8
+2.18.x   N/A
  ==
 
 Open vSwitch userspace should also work with the Linux kernel module built
@@ -110,7 +111,8 @@ Q: Are all features available with all datapaths?
 Linux OVS tree
   The datapath implemented by the Linux kernel module distributed with
   the OVS source tree. This datapath is deprecated starting with OVS
-  2.15.x and support capped at Linux kernel version 5.8.
+  2.15.x and support capped at Linux kernel version 5.8. As of OVS 2.18.x
+  the Linux OVS tree is no longer supported.
 
 Userspace
   This datapath supports conventional system devices as well as
diff --git a/Documentation/internals/contributing/backporting-patches.rst 
b/Documentation/internals/contributing/backporting-patches.rst
index 162e9d209..d0a58f8de 100644
--- a/Documentation/internals/contributing/backporting-patches.rst
+++ b/Documentation/internals/contributing/backporting-patches.rst
@@ -119,6 +119,13 @@ userspace changes.
 How to backport kernel patches
 ~~
 
+These instructions only apply to Open vSwitch releases 2.17 and older.
+As of Open vSwitch branch 2.18 the Open vSwitch kernel module is no
+longer supported and only the Linux openvswitch kernel module is used.
+In the case of Open vSwitch releases 2.17 and older, kernel backports
+may be required for bux fixes and feature implementation so these
+instructions are preserved for that reason.
+
 First, the patch should be submitted upstream to `netdev`. When the patch has
 been applied to `net-next`, it is ready to be backported. Starting from the
 Linux tree, use ``git format-patch`` to format each patch that should be
diff --git a/Documentation/intro/install/fedora.rst 
b/Documentation/intro/install/fedora.rst
index 06a0bd3d5..02481597f 100644
--- a/Documentation/intro/install/fedora.rst
+++ b/Documentation/intro/install/fedora.rst
@@ -132,36 +132,12 @@ tests.  This can take several minutes.
 $ make rpm-fedora RPMBUILD_OPT="--with check"
 
 
-Kernel OVS Tree Datapath RPM
-
-
-To build the Open vSwitch kernel module for the currently running kernel
-version, run:
-
-::
-
-$ make rpm-fedora-kmod
-
-To build the Open vSwitch kernel module for another kernel version, the desired
-kernel version can be specified via the `kversion` macro.  For example:
-
-::
-
-$ make rpm-fedora-kmod \
- RPMBUILD_OPT='-D "kversion 4.3.4-300.fc23.x86_64"'
-
 Installing
 --
 
 RPM packages can be installed by using the command ``rpm -i``. Package
 installation requires superuser privileges.
 
-The `openvswitch-kmod` RPM should be installed first if the Linux OVS tree
-datapath module is to be used. The `openvswitch-kmod` RPM should not be
-installed if only the in-tree Linux datapath or user-space datapath is needed.
-Refer to the :doc:`/faq/index` for more information about the various Open
-vSwitch datapath options.
-
 In most cases only the `openvswitch` RPM will need to be installed. The
 `python3-openvswitch`, `openvswitch-test`, `openvswitch-devel`, and
 `openvswitch-debuginfo` RPMs are optional unless required for a specific
diff --git a/Documentation/intro/install/general.rst 
b/Documentation/intro/install/general.rst
index a297aadac..c2208bbed 100644
--- a/Documentation/intro/install/general.rst
+++ b/Documentation/intro/install/general.rst
@@ -302,24 +302,6 @@ example::
 
 $ ./configure CFLAGS="-g -O2 -fsanitize=address -fno-omit-frame-pointer 
-fno-common"
 
-To build the Linux kernel module, so that you can run the kernel-based switch,
-pass the location of the kernel build directory on ``--with-linux``. For
-example, to build for a running instance of Linux::
-
-$ ./configure --with-linux=/lib/modules/$(uname -r)/build
-
-.. note::
-  If ``--with-linux`` requests building for an unsupported version of Linux,
-  then ``configure`` will fail with an error message. Refer to the
-  :doc:`/faq/index` for advice in that case.
-
-If you wish to build the kernel module for an architecture other than the
-architecture of the machine used for the build, you may specify the kernel
-architecture stri

[ovs-dev] [PATCH V6 0/6] Remove OVS kernel driver

[Greg Rose]

It is time to remove support for the ovs kernel driver and push
towards use of the upstream linux openvswitch kernel driver
in it's place [1].

1.  https://mail.openvswitch.org/pipermail/ovs-dev/2022-april/393292.html

Changes in V2:
* Removed the Linux datapath and fixed up various Makefiles to adjust
* Moved openvswitch.h from datapath/linux/compat/include to include/linux
  and fixed up the Makefiles to adjust
* Removed further instances in utilities and auxiliary files where the
  --with-linux configuration command was still being used.
* Changed order of patches to (hopefully) fix up some robot auto-test
  errors

Changes in V3:
* Squashed the two patches removing rhel specs due to interdependence
  between the two that caused build errors between application of each
  of the patches
* Moved the changes to acinclude.m4 towards the end of the series

Changes in V4:
* Changed up the order of the patches again to fix robot errors
* Added back most of the tests in .github/workflows/build-and-test.yml
* Removed xenserver and related documentation, test scripts and makefile
  dependencies

Changes in V5:
* Squashed two patches from previous series into a single patch. There
  was no good reason to separate changes to auxiliary and utilities
  from the removal of the Linux datapath and the two patches had a
  tricky dependency between them.  Best to combine them.
* Various cleanups, title changes and amended commit messages as
  suggested by David Marchand in his reviews.
* Drops the xenserver removal patch - this patch causes 'make  check'
  failures and there is no reason why it can't  be submitted separately.

Changes in V6:
* Applied Ilya's suggested patch to fix up the robot error caused by
  missing all-distfiles.  We'll see if that fixup stops the robot from
  complaining.
* With these changes the github workflows build and test work without
  errors:
https://github.com/gvrose8192/ovs-experimental/runs/7347904715?check_suite_focus=true

Still to do:
* Submit the patch to remove xenserver separately once I figure out why
  the removal causes 'make check' errors for a few interface reconfiguration
  tests.

Greg Rose (6):
  ci: Stop building OVS kernel module.
  rhel: Stop packaging OVS kernel module.
  tests: Remove support for check-kmod test.
  Make: Remove the Linux datapath.
  acinclude.m4: Remove support for building the OVS kernel module.
  Documentation: Remove kernel module documentation.

 .ci/linux-build.sh|   33 +-
 .github/workflows/build-and-test.yml  |   20 -
 .gitignore|1 -
 Documentation/faq/releases.rst|4 +-
 .../contributing/backporting-patches.rst  |7 +
 Documentation/intro/install/fedora.rst|   24 -
 Documentation/intro/install/general.rst   |   63 -
 Documentation/intro/install/rhel.rst  |   18 -
 Documentation/topics/testing.rst  |7 -
 Makefile.am   |   23 +-
 Vagrantfile   |   12 +-
 acinclude.m4  |  810 +---
 build-aux/initial-tab-allowed-files   |1 -
 configure.ac  |6 +-
 datapath-windows/include/automake.mk  |2 +-
 datapath/.gitignore   |7 -
 datapath/Makefile.am  |   60 -
 datapath/Modules.mk   |   58 -
 datapath/actions.c| 1587 
 datapath/compat.h |   92 -
 datapath/conntrack.c  | 2413 ---
 datapath/conntrack.h  |  113 -
 datapath/datapath.c   | 2707 -
 datapath/datapath.h   |  283 --
 datapath/dp_notify.c  |  102 -
 datapath/flow.c   |  972 -
 datapath/flow.h   |  297 --
 datapath/flow_netlink.c   | 3519 -
 datapath/flow_netlink.h   |   85 -
 datapath/flow_table.c |  988 -
 datapath/flow_table.h |  102 -
 datapath/linux/.gitignore |8 -
 datapath/linux/Kbuild.in  |   27 -
 datapath/linux/Makefile.in|9 -
 datapath/linux/Makefile.main.in   |  107 -
 datapath/linux/Modules.mk |  123 -
 .../compat/build-aux/export-check-allow-list  |1 -
 datapath/linux/compat/dev-openvswitch.c   |   83 -
 datapath/linux/compat/dst_cache.c |  173 -
 datapath/linux/compat/exthdrs_core.c  |  129 -
 datapath/linux/compat/genetlink-openvswitch.c |   55 -
 datapath/linux/compat/geneve.c| 1854 -
 datapath/linux/compat/gre.c   |  239 --
 datapath/linux/compat/gso.c   |  317 --
 datapath/linux/

[ovs-dev] [PATCH V6 3/6] tests: Remove support for check-kmod test.

[Greg Rose]

The OVS kernel module is no longer supported as of OVS 2.18

Reviewed-by: David Marchand 
Signed-off-by: Greg Rose 
---
 Documentation/topics/testing.rst | 7 ---
 tests/automake.mk| 6 --
 2 files changed, 13 deletions(-)

diff --git a/Documentation/topics/testing.rst b/Documentation/topics/testing.rst
index c15d5b38f..d4df656d0 100644
--- a/Documentation/topics/testing.rst
+++ b/Documentation/topics/testing.rst
@@ -428,13 +428,6 @@ your system, run::
 
 $ make check-kernel
 
-To install the kernel module from the current build directory and run the
-testsuite against that kernel module::
-
-$ make check-kmod
-
-The results of the testsuite are in ``tests/system-kmod-testsuite.dir``.
-
 All the features documented under `Unit Tests`_ are available for the kernel
 datapath testsuite.
 
diff --git a/tests/automake.mk b/tests/automake.mk
index b29cb783e..3496f9002 100644
--- a/tests/automake.mk
+++ b/tests/automake.mk
@@ -343,12 +343,6 @@ check-kernel: all
set $(SHELL) '$(SYSTEM_KMOD_TESTSUITE)' -C tests  
AUTOTEST_PATH='$(AUTOTEST_PATH)'; \
"$$@" $(TESTSUITEFLAGS) -j1 || (test X'$(RECHECK)' = Xyes && "$$@" 
--recheck)
 
-# Testing the out of tree Kernel module
-check-kmod: all
-   $(MAKE) modules_install
-   modprobe -r -a vport-geneve vport-gre vport-lisp vport-stt vport-vxlan 
openvswitch
-   $(MAKE) check-kernel
-
 check-system-userspace: all
set $(SHELL) '$(SYSTEM_USERSPACE_TESTSUITE)' -C tests  
AUTOTEST_PATH='$(AUTOTEST_PATH)'; \
"$$@" $(TESTSUITEFLAGS) -j1 || (test X'$(RECHECK)' = Xyes && "$$@" 
--recheck)
-- 
2.17.1

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

[ovs-dev] [PATCH V6 1/6] ci: Stop building OVS kernel module.

[Greg Rose]

Remove kernel based github workflows since the OVS kernel driver is
no longer supported since Release 2.18

Co-authored-by: David Marchand 
Signed-off-by: David Marchand 
Signed-off-by: Greg Rose 
---
 .ci/linux-build.sh   | 33 +++-
 .github/workflows/build-and-test.yml | 20 -
 2 files changed, 3 insertions(+), 50 deletions(-)

diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 9963fb810..7b659fede 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -91,9 +91,6 @@ function install_kernel()
 sudo sed -i '/^# define __always_inline .*/i # undef __always_inline' \
 /usr/include/x86_64-linux-gnu/sys/cdefs.h || true
 EXTRA_OPTS="${EXTRA_OPTS} --enable-afxdp"
-else
-EXTRA_OPTS="${EXTRA_OPTS} --with-linux=$(pwd)"
-echo "Installed kernel source in $(pwd)"
 fi
 popd
 }
@@ -187,20 +184,10 @@ function configure_ovs()
 
 function build_ovs()
 {
-local KERNEL=$1
-
 configure_ovs $OPTS
 make selinux-policy
 
-# Only build datapath if we are testing kernel w/o running testsuite and
-# AF_XDP support.
-if [ "${KERNEL}" ] && ! [ "$AFXDP" ]; then
-pushd datapath
-make -j4
-popd
-else
-make -j4
-fi
+make -j4
 }
 
 if [ "$DEB_PACKAGE" ]; then
@@ -256,8 +243,7 @@ if [ "$UBSAN" ]; then
 CFLAGS_FOR_OVS="${CFLAGS_FOR_OVS} ${CFLAGS_UBSAN}"
 fi
 
-save_OPTS="${OPTS} $*"
-OPTS="${EXTRA_OPTS} ${save_OPTS}"
+OPTS="${EXTRA_OPTS} ${OPTS} $*"
 
 if [ "$TESTSUITE" ]; then
 # 'distcheck' will reconfigure with required options.
@@ -268,20 +254,7 @@ if [ "$TESTSUITE" ]; then
 make distcheck -j4 CFLAGS="${CFLAGS_FOR_OVS}" \
 TESTSUITEFLAGS=-j4 RECHECK=yes
 else
-if [ -z "${KERNEL_LIST}" ]; then build_ovs ${KERNEL};
-else
-save_EXTRA_OPTS="${EXTRA_OPTS}"
-for KERNEL in ${KERNEL_LIST}; do
-echo "=="
-echo "Building with kernel ${KERNEL}"
-echo "=="
-EXTRA_OPTS="${save_EXTRA_OPTS}"
-install_kernel ${KERNEL}
-OPTS="${EXTRA_OPTS} ${save_OPTS}"
-build_ovs ${KERNEL}
-make distclean
-done
-fi
+build_ovs
 fi
 
 exit 0
diff --git a/.github/workflows/build-and-test.yml 
b/.github/workflows/build-and-test.yml
index 9e3583781..aecaafb39 100644
--- a/.github/workflows/build-and-test.yml
+++ b/.github/workflows/build-and-test.yml
@@ -9,17 +9,13 @@ jobs:
 automake libtool gcc bc libjemalloc1 libjemalloc-dev\
 libssl-dev llvm-dev libelf-dev libnuma-dev libpcap-dev  \
 ninja-build selinux-policy-dev
-  deb_dependencies: |
-linux-headers-$(uname -r) build-essential fakeroot devscripts equivs
   AFXDP:   ${{ matrix.afxdp }}
   ASAN:${{ matrix.asan }}
   UBSAN:   ${{ matrix.ubsan }}
   CC:  ${{ matrix.compiler }}
-  DEB_PACKAGE: ${{ matrix.deb_package }}
   DPDK:${{ matrix.dpdk }}
   DPDK_SHARED: ${{ matrix.dpdk_shared }}
   KERNEL:  ${{ matrix.kernel }}
-  KERNEL_LIST: ${{ matrix.kernel_list }}
   LIBS:${{ matrix.libs }}
   M32: ${{ matrix.m32 }}
   OPTS:${{ matrix.opts }}
@@ -40,14 +36,11 @@ jobs:
 
   - compiler: gcc
 testsuite:test
-kernel:   3.16
   - compiler: clang
 testsuite:test
-kernel:   3.16
 asan: asan
   - compiler: clang
 testsuite:test
-kernel:   3.16
 ubsan:ubsan
 
   - compiler: gcc
@@ -71,16 +64,6 @@ jobs:
 testsuite:test
 libs: -ljemalloc
 
-  - compiler: gcc
-kernel_list:  5.8 5.5 5.4 4.19
-  - compiler: clang
-kernel_list:  5.8 5.5 5.4 4.19
-
-  - compiler: gcc
-kernel_list:  4.14 4.9 4.4 3.16
-  - compiler: clang
-kernel_list:  4.14 4.9 4.4 3.16
-
   - compiler: gcc
 afxdp:afxdp
 kernel:   5.3
@@ -111,9 +94,6 @@ jobs:
 m32:  m32
 opts: --disable-ssl
 
-  - compiler: gcc
-deb_package:  deb
-
 steps:
 - name: checkout
   uses: actions/checkout@v2
-- 
2.17.1

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

Re: [ovs-dev] [PATCH ovn] ci: Use CFLAGS instead of OVS_CFLAGS

[Numan Siddique]

On Tue, Jul 12, 2022 at 4:04 PM Mark Michelson  wrote:
>
> Thanks Ales.
>
> Acked-by: Mark Michelson 

Thanks.  I applied this patch to the main branch.

Numan

>
> On 7/12/22 02:30, Ales Musil wrote:
> > The OVS_CFLAGS variable is for internal use only.
> > Use regular CFLAGS instead. This also has the effect
> > of correctly propagating the flags, when the OVS_CFLAGS
> > variable was used the -O1 was in the overwritten by
> > autoconf defaulting to -O2.
> >
> > Signed-off-by: Ales Musil 
> > ---
> >   .ci/linux-build.sh | 24 +++-
> >   .github/workflows/test.yml |  2 --
> >   2 files changed, 11 insertions(+), 15 deletions(-)
> >
> > diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
> > index 8c6d751dc..dc32564fa 100755
> > --- a/.ci/linux-build.sh
> > +++ b/.ci/linux-build.sh
> > @@ -3,15 +3,15 @@
> >   set -o errexit
> >   set -x
> >
> > -CFLAGS=""
> > +COMMON_CFLAGS=""
> >   OVN_CFLAGS=""
> > -SPARSE_FLAGS=""
> >   EXTRA_OPTS="--enable-Werror"
> >
> >   function configure_ovs()
> >   {
> >   pushd ovs
> > -./boot.sh && ./configure $* || { cat config.log; exit 1; }
> > +./boot.sh && ./configure CFLAGS="${COMMON_CFLAGS}" $* || \
> > +{ cat config.log; exit 1; }
> >   make -j4 || { cat config.log; exit 1; }
> >   popd
> >   }
> > @@ -19,9 +19,7 @@ function configure_ovs()
> >   function configure_ovn()
> >   {
> >   configure_ovs $*
> > -
> > -export OVS_CFLAGS="${OVS_CFLAGS} ${OVN_CFLAGS}"
> > -./boot.sh && ./configure $* || \
> > +./boot.sh && ./configure CFLAGS="${COMMON_CFLAGS} ${OVN_CFLAGS}" $* || 
> > \
> >   { cat config.log; exit 1; }
> >   }
> >
> > @@ -33,21 +31,19 @@ OPTS="${EXTRA_OPTS} ${save_OPTS}"
> >   # OVS, to make sanitizer reports user friendly.
> >   if [ "$SANITIZERS" ]; then
> >   # Use the default options configured in tests/atlocal.in, in 
> > UBSAN_OPTIONS.
> > -CFLAGS="-O1 -fno-omit-frame-pointer -fno-common -g"
> > -CFLAGS_SANITIZERS="-fsanitize=address,undefined"
> > -OVN_CFLAGS="${OVN_CFLAGS} ${CFLAGS_SANITIZERS}"
> > +COMMON_CFLAGS="${COMMON_CFLAGS} -O1 -fno-omit-frame-pointer 
> > -fno-common -g"
> > +OVN_CFLAGS="${OVN_CFLAGS} -fsanitize=address,undefined"
> >   fi
> >
> >   if [ "$CC" = "clang" ]; then
> > -export OVS_CFLAGS="$CFLAGS -Wno-error=unused-command-line-argument"
> > +COMMON_CFLAGS="${COMMON_CFLAGS} 
> > -Wno-error=unused-command-line-argument"
> >   elif [ "$M32" ]; then
> >   # Not using sparse for 32bit builds on 64bit machine.
> > -# Adding m32 flag directly to CC to avoid any posiible issues with 
> > API/ABI
> > +# Adding m32 flag directly to CC to avoid any possible issues with 
> > API/ABI
> >   # difference on 'configure' and 'make' stages.
> >   export CC="$CC -m32"
> >   else
> >   OPTS="$OPTS --enable-sparse"
> > -export OVS_CFLAGS="$CFLAGS $SPARSE_FLAGS"
> >   fi
> >
> >   if [ "$TESTSUITE" ]; then
> > @@ -65,7 +61,9 @@ if [ "$TESTSUITE" ]; then
> >   configure_ovn
> >
> >   export DISTCHECK_CONFIGURE_FLAGS="$OPTS"
> > -if ! make distcheck -j4 TESTSUITEFLAGS="-j4" RECHECK=yes; then
> > +if ! make distcheck CFLAGS="${COMMON_CFLAGS} ${OVN_CFLAGS}" -j4 \
> > +TESTSUITEFLAGS="-j4" RECHECK=yes
> > +then
> >   # testsuite.log is necessary for debugging.
> >   cat */_build/sub/tests/testsuite.log
> >   exit 1
> > diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
> > index e0de7c60e..71541503d 100644
> > --- a/.github/workflows/test.yml
> > +++ b/.github/workflows/test.yml
> > @@ -21,7 +21,6 @@ jobs:
> > OPTS:${{ matrix.opts }}
> > TESTSUITE:   ${{ matrix.testsuite }}
> > SANITIZERS:  ${{ matrix.sanitizers }}
> > -  CFLAGS:  ${{ matrix.cflags }}
> >
> >   name: linux ${{ join(matrix.*, ' ') }}
> >   runs-on: ubuntu-20.04
> > @@ -42,7 +41,6 @@ jobs:
> > - compiler: clang
> >   testsuite:test
> >   sanitizers:   sanitizers
> > -cflags:   -g
> >
> > - compiler: gcc
> >   testsuite:test
> >
>
> ___
> 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] Cancel previous runs in the PR when you push new commits

[Numan Siddique]

On Wed, Jul 13, 2022 at 6:53 AM Ales Musil  wrote:
>
> Ok, thanks.
>
> Acked-by: Ales Musil 
>

Thanks.  I applied this patch to the main branch.

Numan

> On Wed, Jul 13, 2022 at 1:50 PM Igor Zhukov  wrote:
>
> > Yes, as far as I understand.
> > I found some github repos also use it:
> > https://github.com/TeamAmaze/AmazeFileManager/blob/release/3.7/.github/workflows/android-feature.yml#L10-L12
> >
> > > Hi Igor,
> > >
> > > IIUC this applies only to PR right? I mean there's no harm in having that
> > >
> > > just to be sure.
> > >
> > > Thanks,
> > >
> > > Ales
> > >
> > > On Wed, Jul 13, 2022 at 1:25 PM Igor Zhukov  wrote:
> > >
> > >> From: Igor Zhukov 
> > >>
> > >> While implementing https://github.com/ovn-org/ovn/pull/139 I sometimes
> > pushed
> > >>
> > >> several commits quickly and after that I noticed that previous run was
> > still in
> > >>
> > >> progress and the most recent run was waiting in line.
> > >>
> > >> I googled some solutions and
> > >>
> > >> I found the answer: https://stackoverflow.com/a/72408109/4544798
> > >>
> > >> Github docs:
> > https://docs.github.com/en/actions/using-jobs/using-concurrency
> > >>
> > >> Signed-off-by: Igor Zhukov 
> > >>
> > >> Submitted-at: https://github.com/ovn-org/ovn/pull/145
> > >>
> > >> ---
> > >>
> > >> .github/workflows/ovn-kubernetes.yml | 4 
> > >>
> > >> .github/workflows/test.yml | 4 
> > >>
> > >> 2 files changed, 8 insertions(+)
> > >>
> > >> diff --git a/.github/workflows/ovn-kubernetes.yml
> > b/.github/workflows/ovn-kubernetes.yml
> > >>
> > >> index c05bbd3f9..431e47660 100644
> > >>
> > >> --- a/.github/workflows/ovn-kubernetes.yml
> > >>
> > >> +++ b/.github/workflows/ovn-kubernetes.yml
> > >>
> > >> @@ -8,6 +8,10 @@ on:
> > >>
> > >> # Run Sunday at midnight
> > >>
> > >> - cron: '0 0 * * 0'
> > >>
> > >> +concurrency:
> > >>
> > >> + group: ${{ github.workflow }}-${{ github.event.pull_request.number ||
> > github.ref }}
> > >>
> > >> + cancel-in-progress: true
> > >>
> > >> +
> > >>
> > >> env:
> > >>
> > >> GO_VERSION: "1.17.6"
> > >>
> > >> K8S_VERSION: v1.23.3
> > >>
> > >> diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
> > >>
> > >> index e0de7c60e..56e8ba870 100644
> > >>
> > >> --- a/.github/workflows/test.yml
> > >>
> > >> +++ b/.github/workflows/test.yml
> > >>
> > >> @@ -7,6 +7,10 @@ on:
> > >>
> > >> # Run Sunday at midnight
> > >>
> > >> - cron: '0 0 * * 0'
> > >>
> > >> +concurrency:
> > >>
> > >> + group: ${{ github.workflow }}-${{ github.event.pull_request.number ||
> > github.ref }}
> > >>
> > >> + cancel-in-progress: true
> > >>
> > >> +
> > >>
> > >> jobs:
> > >>
> > >> build-linux:
> > >>
> > >> env:
> > >>
> > >> --
> > >>
> > >> 2.30.2
> > >>
> > >> ___
> > >>
> > >> dev mailing list
> > >>
> > >> d...@openvswitch.org
> > >>
> > >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> > >
> > > --
> > >
> > > Ales Musil
> > >
> > > Senior Software Engineer - OVN Core
> > >
> > > Red Hat EMEA
> > >
> > > amu...@redhat.com
> > >
> > > IM: amusil
> >
> >
>
> --
>
> Ales Musil
>
> Senior Software Engineer - OVN Core
>
> Red Hat EMEA 
>
> amu...@redhat.comIM: amusil
> 
> ___
> 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] [RFC ovn] controller: send GARPs for LSPs in vlan-backed network scenario

[Dumitru Ceara]

On 7/14/22 17:35, Numan Siddique wrote:
> On Thu, Jul 14, 2022 at 3:36 AM Lorenzo Bianconi
>  wrote:
>>
>>> On 7/13/22 18:07, Lorenzo Bianconi wrote:
> On 6/17/22 00:31, Lorenzo Bianconi wrote:
>> When using VLAN backed networks and OVN routers leveraging the
>> 'ovn-chassis-mac-mappings' option, the eth.src field is replaced by the
>> chassis mac address in order to not expose the router mac address from
>> different nodes and confuse the TOR switch. However doing so the TOR
>> switch is not able to learn the port/mac bindings for routed E/W traffic
>> and it is force to always flood it. Fix this issue adding the capability
>> to send GARP traffic for logical switch ports if the corresponding 
>> logical
>> switch has the ovn-lsp-garp parameter set to true in the option column.
>> More into about the issue can be found here [0].
>>
>> [0] 
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-September/050678.html
>> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2087779
>>
>> Signed-off-by: Lorenzo Bianconi 
>> ---
>
> Hi Lorenzo,

 Hi Dumitru,

 Thanks for reviewing it :)

>
> I have a few concerns with this approach:
>
> a. The CMS will have to set this option for all VMs on all logical
> switches which will enable periodic GARPs for all of them all the time.
> That seems like quite a lot of broadcast traffic in the fabric.
>
> b. There's no guarantee that the GARPs are sent in time to prevent the
> FDB timeouts on the ToR switches.  At best we could make the interval
> configurable but I don't think this is way better either.
>
> c. This is not really introduced by your patch but we will be causing
> this more often now.  With the topology:
>
> (HV1) VM1 -- LS1 --- LR -- LS2 -- VM2 (HV2)
> (VLAN-backed network)
>
> HV1 configured with chassis mac mapping HV1-MAC
> HV2 configured with chassis mac mapping HV2-MAC
>
> We're leaking MAC addresses from LS1's broadcast domain (VM1-MAC) and
> from LS2's broadcast domain (VM2-MAC) into the fabric.  I'm not sure
> that's OK.
> 
> I'm not sure I understood what you mean here.
> Let's say we have 2 VMs - VM1 and VM3 connected to the same VLAN
> logical switch LS1
> and if VM1 is on chassis HV1 and VM3 is on chassis HV3,  the fabric
> will learn VM1's and VM3's mac
> when they both communicate right ?   Please note that logical switch
> LS1 is a vlan tenant network with
> a localnet port (so no geneve tunnels are used for the traffic from VM1 to 
> VM3).
> 
> 

You're right, I misread the logical/physical topologies.  The MACs will
only be visible in the VLANs corresponding to the localnet port of each
of the logical switches.  Please ignore this part.

>
> I think a proper solution is to change how we run the logical pipelines
> in case of vlan-backed networks.  We currently have an assymetry:
>
> For packets flowing from VM1 to VM2 we execute:
> - on HV1: LS1-ingress, LS1-egress, LR-ingress, LR-egress, LS2-ingress
> - on HV2: LS2-egress
>
> For packets flowing from VM2 to VM1 we execute:
> - on HV2: LS2-ingress, LS2-egress, LR-ingress, LR-egress, LS1-ingress
> - on HV1: LS1-egress
>
> What if we change this to:
> VM1 -> VM2:
> - on HV1: LS1-ingress, LS1-egress, LR-ingress
> - on HV2: LR-egress, LS2-ingress, LS2-egress
>
> VM2 -> VM1:
> - on HV2: LS2-ingress, LS2-egress, LR-ingress
> - on HV2: LR-egress, LS1-ingress, LS1-egress

> 
> I'm not sure how easy it would be to run the pipeline as you suggested
> when ovn-chassis-mac-mappings is configured.

Indeed it doesn't seem possible as we have no knowledge about what
happened prior to the packet being received on the vlan, it could've
been already processed by an ovn node.

> However OVN does support centralized routing if a logical router has a
> distributed gateway port (connecting to the provider network)
> and the other logical router ports connecting to the tenant VLAN
> networks have the option - reside-on-redirect-chassis configured.
> 
> So in a way CMS can use the centralized routing to avoid this issue.
> However if we want to fix this issue for distributed routing,  looks
> to me
> the proposed RFC patch is the only way to fix it.  And with the proper
> documentation CMS can know the benefits and drawbacks of both the
> options.
> 

I still think that's potentially a lot of broadcast traffic.

Can we find a way of forcing the VMs to send some unicast L2 traffic on
the VLAN network?  Would it be possible to periodically send an ICMP
packet from ovn-controller (with dl_src=chassis-mac) towards the IP of
all non-local VIFs attached to the logical switch.  This is more work
than sending GARPs but should result in less traffic.  The CMS will
still have to configure this feature on the logical routers.

I'm not

Re: [ovs-dev] [v11 07/10] odp-execute: Add ISA implementation of pop_vlan action.

[0-day Robot]

Bleep bloop.  Greetings Emma Finn, 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 Harry van Haaren  needs to sign off.
WARNING: Unexpected sign-offs from developers who are not authors or co-authors 
or committers: Emma Finn 
Lines checked: 307, 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] [v11 06/10] odp-execute: Add ISA implementation of actions.

[0-day Robot]

Bleep bloop.  Greetings Emma Finn, 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: Unexpected sign-offs from developers who are not authors or co-authors 
or committers: Harry van Haaren 
Lines checked: 255, 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] [v11 10/10] odp-execute: Add ISA implementation of set_masked IPv4 action

[Emma Finn]

This commit adds support for the AVX512 implementation of the
ipv4_set_addrs action as well as an AVX512 implementation of
updating the checksums.

Signed-off-by: Emma Finn 
---
 lib/odp-execute-avx512.c | 216 +++
 1 file changed, 216 insertions(+)

diff --git a/lib/odp-execute-avx512.c b/lib/odp-execute-avx512.c
index 02e26cf26..2e0bc32a9 100644
--- a/lib/odp-execute-avx512.c
+++ b/lib/odp-execute-avx512.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 
+#include "csum.h"
 #include "dp-packet.h"
 #include "immintrin.h"
 #include "odp-execute.h"
@@ -58,6 +59,22 @@ BUILD_ASSERT_DECL(offsetof(struct ovs_key_ethernet, eth_src) 
+
   MEMBER_SIZEOF(struct ovs_key_ethernet, eth_src) ==
   offsetof(struct ovs_key_ethernet, eth_dst));
 
+BUILD_ASSERT_DECL(offsetof(struct ovs_key_ipv4, ipv4_src) +
+  MEMBER_SIZEOF(struct ovs_key_ipv4, ipv4_src) ==
+  offsetof(struct ovs_key_ipv4, ipv4_dst));
+
+BUILD_ASSERT_DECL(offsetof(struct ovs_key_ipv4, ipv4_dst) +
+  MEMBER_SIZEOF(struct ovs_key_ipv4, ipv4_dst) ==
+  offsetof(struct ovs_key_ipv4, ipv4_proto));
+
+BUILD_ASSERT_DECL(offsetof(struct ovs_key_ipv4, ipv4_proto) +
+  MEMBER_SIZEOF(struct ovs_key_ipv4, ipv4_proto) ==
+  offsetof(struct ovs_key_ipv4, ipv4_tos));
+
+BUILD_ASSERT_DECL(offsetof(struct ovs_key_ipv4, ipv4_tos) +
+  MEMBER_SIZEOF(struct ovs_key_ipv4, ipv4_tos) ==
+  offsetof(struct ovs_key_ipv4, ipv4_ttl));
+
 /* Array of callback functions, one for each masked operation. */
 odp_execute_action_cb impl_set_masked_funcs[__OVS_KEY_ATTR_MAX];
 
@@ -278,6 +295,204 @@ action_avx512_eth_set_addrs(struct dp_packet_batch *batch,
 }
 }
 
+static inline uint16_t ALWAYS_INLINE
+avx512_get_delta(__m256i old_header, __m256i new_header)
+{
+__m256i v_zeros = _mm256_setzero_si256();
+uint16_t delta;
+
+/* These two shuffle masks, v_swap16a and v_swap16b, are to shuffle the
+ * old and new header to add padding after each 16-bit value for the
+ * following carry over addition. */
+__m256i v_swap16a = _mm256_setr_epi16(0x0100, 0x, 0x0302, 0x,
+  0x0504, 0x, 0x0706, 0x,
+  0x0100, 0x, 0x0302, 0x,
+  0x, 0x, 0x, 0x);
+__m256i v_swap16b = _mm256_setr_epi16(0x0908, 0x, 0x0B0A, 0x,
+  0x0D0C, 0x, 0x0F0E, 0x,
+  0x, 0x, 0x, 0x,
+  0x, 0x, 0x, 0x);
+__m256i v_shuf_old1 = _mm256_shuffle_epi8(old_header, v_swap16a);
+__m256i v_shuf_old2 = _mm256_shuffle_epi8(old_header, v_swap16b);
+__m256i v_shuf_new1 = _mm256_shuffle_epi8(new_header, v_swap16a);
+__m256i v_shuf_new2 = _mm256_shuffle_epi8(new_header, v_swap16b);
+
+/* Add each part of the old and new headers together. */
+__m256i v_delta1 = _mm256_add_epi32(v_shuf_old1, v_shuf_new1);
+__m256i v_delta2 = _mm256_add_epi32(v_shuf_old2, v_shuf_new2);
+
+/* Add old and new header. */
+__m256i v_delta = _mm256_add_epi32(v_delta1, v_delta2);
+
+/* Perform horizontal add to go from 8x32-bits to 2x32-bits. */
+v_delta = _mm256_hadd_epi32(v_delta, v_zeros);
+v_delta = _mm256_hadd_epi32(v_delta, v_zeros);
+
+/* Shuffle 32-bit value from 3rd lane into first lane for final
+ * horizontal add. */
+__m256i v_swap32a = _mm256_setr_epi32(0x0, 0x4, 0xF, 0xF,
+  0xF, 0xF, 0xF, 0xF);
+v_delta = _mm256_permutexvar_epi32(v_swap32a, v_delta);
+
+v_delta = _mm256_hadd_epi32(v_delta, v_zeros);
+v_delta = _mm256_hadd_epi16(v_delta, v_zeros);
+
+/* Extract delta value. */
+delta = _mm256_extract_epi16(v_delta, 0);
+
+return delta;
+}
+
+/* This function will calculate the csum delta for the IPv4 addresses in the
+ * new_header and old_header, assuming the csum field on the new_header was
+ * updated. */
+static inline uint16_t ALWAYS_INLINE
+avx512_ipv4_addr_csum_delta(__m256i old_header, __m256i new_header)
+{
+__m256i v_zeros = _mm256_setzero_si256();
+uint16_t delta;
+
+/* Set the v_ones register to all one's. */
+__m256i v_ones = _mm256_cmpeq_epi16(v_zeros, v_zeros);
+
+/* Combine the old and new header, i.e. adding in the new IP addresses
+ * in the old header (oh). This is done by using the 0x03C 16-bit mask,
+ * picking 16-bit word 7 till 10.  */
+__m256i v_blend_new = _mm256_mask_blend_epi16(0x03C0, old_header,
+  new_header);
+
+/* Invert the old_header register. */
+old_header =_mm256_andnot_si256(old_header, v_ones);
+
+/* Calculate the delta between the old and new header. */
+delta = avx512

[ovs-dev] [v11 07/10] odp-execute: Add ISA implementation of pop_vlan action.

[Emma Finn]

From: Harry van Haaren 

This commit adds the AVX512 implementation of the
pop_vlan action.

Signed-off-by: Emma Finn 
---
 lib/automake.mk   |   4 +
 lib/odp-execute-avx512.c  | 186 ++
 lib/odp-execute-private.c |  32 ++-
 lib/odp-execute-private.h |   4 +
 4 files changed, 225 insertions(+), 1 deletion(-)
 create mode 100644 lib/odp-execute-avx512.c

diff --git a/lib/automake.mk b/lib/automake.mk
index 5c3b05f6b..a76de6dbf 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -45,6 +45,10 @@ lib_libopenvswitchavx512_la_CFLAGS += \
 lib_libopenvswitchavx512_la_SOURCES += \
lib/dpif-netdev-extract-avx512.c \
lib/dpif-netdev-lookup-avx512-gather.c
+if HAVE_GCC_AVX512VL_GOOD
+lib_libopenvswitchavx512_la_SOURCES += \
+   lib/odp-execute-avx512.c
+endif # HAVE_GCC_AVX512VL_GOOD
 endif # HAVE_AVX512VL
 endif # HAVE_AVX512BW
 lib_libopenvswitchavx512_la_LDFLAGS = \
diff --git a/lib/odp-execute-avx512.c b/lib/odp-execute-avx512.c
new file mode 100644
index 0..d929abe68
--- /dev/null
+++ b/lib/odp-execute-avx512.c
@@ -0,0 +1,186 @@
+/*
+ * Copyright (c) 2022 Intel.
+ *
+ * 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.
+ */
+
+#ifdef __x86_64__
+/* Sparse cannot handle the AVX512 instructions. */
+#if !defined(__CHECKER__)
+
+#include 
+#include 
+
+#include "dp-packet.h"
+#include "immintrin.h"
+#include "odp-execute-private.h"
+#include "odp-netlink.h"
+#include "openvswitch/vlog.h"
+
+VLOG_DEFINE_THIS_MODULE(odp_execute_avx512);
+
+/* The below three build asserts make sure that l2_5_ofs, l3_ofs, and l4_ofs
+ * fields remain in the same order and offset to l2_padd_size. This is needed
+ * as the avx512_dp_packet_resize_l2() function will manipulate those fields at
+ * a fixed memory index based on the l2_padd_size offset. */
+BUILD_ASSERT_DECL(offsetof(struct dp_packet, l2_pad_size) +
+  MEMBER_SIZEOF(struct dp_packet, l2_pad_size) ==
+  offsetof(struct dp_packet, l2_5_ofs));
+
+BUILD_ASSERT_DECL(offsetof(struct dp_packet, l2_5_ofs) +
+  MEMBER_SIZEOF(struct dp_packet, l2_5_ofs) ==
+  offsetof(struct dp_packet, l3_ofs));
+
+BUILD_ASSERT_DECL(offsetof(struct dp_packet, l3_ofs) +
+   MEMBER_SIZEOF(struct dp_packet, l3_ofs) ==
+   offsetof(struct dp_packet, l4_ofs));
+
+/* The below build assert makes sure it's safe to read/write 128-bits starting
+ * at the l2_pad_size location. */
+BUILD_ASSERT_DECL(sizeof(struct dp_packet) -
+  offsetof(struct dp_packet, l2_pad_size) >= sizeof(__m128i));
+
+static inline void ALWAYS_INLINE
+avx512_dp_packet_resize_l2(struct dp_packet *b, int resize_by_bytes)
+{
+/* Update packet size/data pointers, same as the scalar implementation. */
+if (resize_by_bytes >= 0) {
+dp_packet_push_uninit(b, resize_by_bytes);
+} else {
+dp_packet_pull(b, -resize_by_bytes);
+}
+
+/* The next step is to update the l2_5_ofs, l3_ofs and l4_ofs fields which
+ * the scalar implementation does with the  dp_packet_adjust_layer_offset()
+ * function. */
+
+/* Set the v_zero register to all zero's. */
+const __m128i v_zeros = _mm_setzero_si128();
+
+/* Set the v_u16_max register to all one's. */
+const __m128i v_u16_max = _mm_cmpeq_epi16(v_zeros, v_zeros);
+
+/* Each lane represents 16 bits in a 12-bit register. In this case the
+ * first three 16-bit values, which will map to the l2_5_ofs, l3_ofs and
+ * l4_ofs fields. */
+const uint8_t k_lanes = 0b1110;
+
+/* Set all 16-bit words in the 128-bits v_offset register to the value we
+ * need to add/substract from the l2_5_ofs, l3_ofs, and l4_ofs fields. */
+__m128i v_offset = _mm_set1_epi16(abs(resize_by_bytes));
+
+/* Load 128 bits from the dp_packet structure starting at the l2_pad_size
+ * offset. */
+void *adjust_ptr = &b->l2_pad_size;
+__m128i v_adjust_src = _mm_loadu_si128(adjust_ptr);
+
+/* Here is the tricky part, we only need to update the value of the three
+ * fields if they are not UINT16_MAX. The following function will return
+ * a mask of lanes (read fields) that are not UINT16_MAX. It will do this
+ * by comparing only the lanes we requested, k_lanes, and if they match
+ * v_u16_max, the bit will be set. */
+__mmask8 k_cmp = _mm_mask_cmpneq_epu16_mask(k_lanes, v_adjust_src,
+

[ovs-dev] [v11 09/10] odp-execute: Add ISA implementation of set_masked ETH

[Emma Finn]

This commit includes infrastructure changes for enabling set_masked_X
actions and also adds support for the AVX512 implementation of the
eth_set_addrs action.

Signed-off-by: Emma Finn 
---
 lib/odp-execute-avx512.c  | 90 +++
 lib/odp-execute-private.c | 14 ++
 lib/odp-execute-private.h |  3 ++
 lib/odp-execute.c | 49 +++--
 lib/odp-execute.h |  3 ++
 5 files changed, 137 insertions(+), 22 deletions(-)

diff --git a/lib/odp-execute-avx512.c b/lib/odp-execute-avx512.c
index 90a5a7416..02e26cf26 100644
--- a/lib/odp-execute-avx512.c
+++ b/lib/odp-execute-avx512.c
@@ -23,6 +23,7 @@
 
 #include "dp-packet.h"
 #include "immintrin.h"
+#include "odp-execute.h"
 #include "odp-execute-private.h"
 #include "odp-netlink.h"
 #include "openvswitch/vlog.h"
@@ -50,6 +51,16 @@ BUILD_ASSERT_DECL(offsetof(struct dp_packet, l3_ofs) +
 BUILD_ASSERT_DECL(sizeof(struct dp_packet) -
   offsetof(struct dp_packet, l2_pad_size) >= sizeof(__m128i));
 
+/* The below build assert makes sure the order of the fields needed by
+ * the set masked functions shuffle operations do not change. This should not
+ * happen as these are defined under the Linux uapi. */
+BUILD_ASSERT_DECL(offsetof(struct ovs_key_ethernet, eth_src) +
+  MEMBER_SIZEOF(struct ovs_key_ethernet, eth_src) ==
+  offsetof(struct ovs_key_ethernet, eth_dst));
+
+/* Array of callback functions, one for each masked operation. */
+odp_execute_action_cb impl_set_masked_funcs[__OVS_KEY_ATTR_MAX];
+
 static inline void ALWAYS_INLINE
 avx512_dp_packet_resize_l2(struct dp_packet *b, int resize_by_bytes)
 {
@@ -206,6 +217,80 @@ action_avx512_push_vlan(struct dp_packet_batch *batch, 
const struct nlattr *a)
 }
 }
 
+/* This function performs the same operation on each packet in the batch as
+ * the scalar odp_eth_set_addrs() function. */
+static void
+action_avx512_eth_set_addrs(struct dp_packet_batch *batch,
+const struct nlattr *a)
+{
+const struct ovs_key_ethernet *key, *mask;
+struct dp_packet *packet;
+
+a = nl_attr_get(a);
+key = nl_attr_get(a);
+mask = odp_get_key_mask(a, struct ovs_key_ethernet);
+
+/* Read the content of the key(src) and mask in the respective registers.
+ * We only load the src and dest addresses, which is only 96-bits and not
+ * 128-bits. */
+__m128i v_src = _mm_maskz_loadu_epi32(0x7,(void *) key);
+__m128i v_mask = _mm_maskz_loadu_epi32(0x7, (void *) mask);
+
+
+/* These shuffle masks are used below, and each position tells where to
+ * move the bytes to. So here, the fourth sixth byte in
+ * ovs_key_ethernet is moved to byte location 0 in v_src/v_mask.
+ * The seventh is moved to 1, etc., etc.
+ * This swap is needed to move the src and dest MAC addresses in the
+ * same order as in the ethernet packet. */
+static const uint8_t eth_shuffle[16] = {
+6, 7, 8, 9, 10, 11, 0, 1,
+2, 3, 4, 5, 0xFF, 0xFF, 0xFF, 0xFF
+};
+
+/* Load the shuffle mask in v_shuf. */
+__m128i v_shuf = _mm_loadu_si128((void *) eth_shuffle);
+
+/* Swap the key/mask src and dest addresses to the ethernet order. */
+v_src = _mm_shuffle_epi8(v_src, v_shuf);
+v_mask = _mm_shuffle_epi8(v_mask, v_shuf);
+
+DP_PACKET_BATCH_FOR_EACH (i, packet, batch) {
+
+struct eth_header *eh = dp_packet_eth(packet);
+
+if (!eh) {
+continue;
+}
+
+/* Load the first 128-bits of the packet into the v_ether register. */
+__m128i v_dst = _mm_loadu_si128((void *) eh);
+
+/* AND the v_mask to the packet data (v_dst). */
+__m128i dst_masked = _mm_andnot_si128(v_mask, v_dst);
+
+/* OR the new addresses (v_src) with the masked packet addresses
+ * (dst_masked). */
+__m128i res = _mm_or_si128(v_src, dst_masked);
+
+/* Write back the modified ethernet addresses. */
+_mm_storeu_si128((void *) eh, res);
+}
+}
+
+static void
+action_avx512_set_masked(struct dp_packet_batch *batch, const struct nlattr *a)
+{
+const struct nlattr *mask = nl_attr_get(a);
+enum ovs_key_attr attr_type = nl_attr_type(mask);
+
+if (attr_type <= OVS_KEY_ATTR_MAX && impl_set_masked_funcs[attr_type]) {
+impl_set_masked_funcs[attr_type](batch, a);
+} else {
+odp_execute_scalar_action(batch, a);
+}
+}
+
 int
 action_avx512_init(struct odp_execute_action_impl *self OVS_UNUSED)
 {
@@ -217,6 +302,11 @@ action_avx512_init(struct odp_execute_action_impl *self 
OVS_UNUSED)
  * are identified by OVS_ACTION_ATTR_*. */
 self->funcs[OVS_ACTION_ATTR_POP_VLAN] = action_avx512_pop_vlan;
 self->funcs[OVS_ACTION_ATTR_PUSH_VLAN] = action_avx512_push_vlan;
+self->funcs[OVS_ACTION_ATTR_SET_MASKED] = action_avx512_set_masked;
+
+/* Set function pointers for the individual operations supported by the
+ * SET_MASKED action. */
+impl_set_m

[ovs-dev] [v11 08/10] odp-execute: Add ISA implementation of push_vlan action.

[Emma Finn]

This commit adds the AVX512 implementation of the
push_vlan action.

Signed-off-by: Emma Finn 
Acked-by: Eelco Chaudron 
---
 lib/odp-execute-avx512.c | 54 
 lib/odp-execute.c| 22 +---
 2 files changed, 67 insertions(+), 9 deletions(-)

diff --git a/lib/odp-execute-avx512.c b/lib/odp-execute-avx512.c
index d929abe68..90a5a7416 100644
--- a/lib/odp-execute-avx512.c
+++ b/lib/odp-execute-avx512.c
@@ -154,6 +154,58 @@ action_avx512_pop_vlan(struct dp_packet_batch *batch,
 }
 }
 
+/* This function performs the same operation on each packet in the batch as
+ * the scalar eth_push_vlan() function. */
+static void
+action_avx512_push_vlan(struct dp_packet_batch *batch, const struct nlattr *a)
+{
+struct dp_packet *packet;
+const struct ovs_action_push_vlan *vlan = nl_attr_get(a);
+ovs_be16 tpid, tci;
+
+/* This shuffle mask is used below, and each position tells where to
+ * move the bytes to. So here, the fourth byte in v_ether is moved to
+ * byte location 0 in v_shift. The fifth is moved to 1, etc., etc.
+ * The 0xFF is special it tells to fill that position with 0. */
+static const uint8_t vlan_push_shuffle_mask[16] = {
+4, 5, 6, 7, 8, 9, 10, 11,
+12, 13, 14, 15, 0xFF, 0xFF, 0xFF, 0xFF
+};
+
+/* Load the shuffle mask in v_index. */
+__m128i v_index = _mm_loadu_si128((void *) vlan_push_shuffle_mask);
+
+DP_PACKET_BATCH_FOR_EACH (i, packet, batch) {
+tpid = vlan->vlan_tpid;
+tci = vlan->vlan_tci;
+
+/* As we are about to insert the VLAN_HEADER we now need to adjust all
+ * the offsets. */
+avx512_dp_packet_resize_l2(packet, VLAN_HEADER_LEN);
+
+char *pkt_data = (char *) dp_packet_data(packet);
+
+/* Build up the VLAN TCI/TPID in a single uint32_t. */
+const uint32_t tci_proc = tci & htons(~VLAN_CFI);
+const uint32_t tpid_tci = (tci_proc << 16) | tpid;
+
+/* Load the first 128-bits of the packet into the v_ether register.
+ * Note that this includes the 4 unused bytes (VLAN_HEADER_LEN). */
+__m128i v_ether = _mm_loadu_si128((void *) pkt_data);
+
+/* Move(shuffle) the veth_dst and veth_src data to create room for
+ * the vlan header. */
+__m128i v_shift = _mm_shuffle_epi8(v_ether, v_index);
+
+/* Copy(insert) the 32-bit VLAN header, tpid_tci, at the 3rd 32-bit
+ * word offset, i.e. ofssetof(vlan_eth_header, veth_type) */
+__m128i v_vlan_hdr = _mm_insert_epi32(v_shift, tpid_tci, 3);
+
+/* Write back the modified ethernet header. */
+_mm_storeu_si128((void *) pkt_data, v_vlan_hdr);
+}
+}
+
 int
 action_avx512_init(struct odp_execute_action_impl *self OVS_UNUSED)
 {
@@ -164,6 +216,8 @@ action_avx512_init(struct odp_execute_action_impl *self 
OVS_UNUSED)
 /* Set function pointers for actions that can be applied directly, these
  * are identified by OVS_ACTION_ATTR_*. */
 self->funcs[OVS_ACTION_ATTR_POP_VLAN] = action_avx512_pop_vlan;
+self->funcs[OVS_ACTION_ATTR_PUSH_VLAN] = action_avx512_push_vlan;
+
 return 0;
 }
 
diff --git a/lib/odp-execute.c b/lib/odp-execute.c
index ff16e9bf3..a65110138 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -846,6 +846,17 @@ action_pop_vlan(struct dp_packet_batch *batch,
 }
 }
 
+static void
+action_push_vlan(struct dp_packet_batch *batch, const struct nlattr *a)
+{
+struct dp_packet *packet;
+const struct ovs_action_push_vlan *vlan = nl_attr_get(a);
+
+DP_PACKET_BATCH_FOR_EACH (i, packet, batch) {
+eth_push_vlan(packet, vlan->vlan_tpid, vlan->vlan_tci);
+}
+}
+
 /* Implementation of the scalar actions impl init function. Build up the
  * array of func ptrs here. */
 int
@@ -854,6 +865,7 @@ odp_action_scalar_init(struct odp_execute_action_impl *self)
 /* Set function pointers for actions that can be applied directly, these
  * are identified by OVS_ACTION_ATTR_*. */
 self->funcs[OVS_ACTION_ATTR_POP_VLAN] = action_pop_vlan;
+self->funcs[OVS_ACTION_ATTR_PUSH_VLAN] = action_push_vlan;
 
 return 0;
 }
@@ -1051,15 +1063,6 @@ odp_execute_actions(void *dp, struct dp_packet_batch 
*batch, bool steal,
 break;
 }
 
-case OVS_ACTION_ATTR_PUSH_VLAN: {
-const struct ovs_action_push_vlan *vlan = nl_attr_get(a);
-
-DP_PACKET_BATCH_FOR_EACH (i, packet, batch) {
-eth_push_vlan(packet, vlan->vlan_tpid, vlan->vlan_tci);
-}
-break;
-}
-
 case OVS_ACTION_ATTR_PUSH_MPLS: {
 const struct ovs_action_push_mpls *mpls = nl_attr_get(a);
 
@@ -1212,6 +1215,7 @@ odp_execute_actions(void *dp, struct dp_packet_batch 
*batch, bool steal,
 case __OVS_ACTION_ATTR_MAX:
 /* The following actions are handled by the scalar implementation. */
 case OVS_ACTION_ATTR_POP_VLAN:
+case OVS_ACTION_ATTR_PUSH_VLAN:

[ovs-dev] [v11 02/10] odp-execute: Add function pointer for pop_vlan action.

[Emma Finn]

This commit removes the pop_vlan action from the large switch
and creates a separate function for batched processing. A function
pointer is also added to call the new batched function for the pop_vlan
action.

Signed-off-by: Emma Finn 
Acked-by: Harry van Haaren 
Acked-by: Eelco Chaudron 
---
 lib/odp-execute-private.c | 16 +++-
 lib/odp-execute-private.h |  4 
 lib/odp-execute.c | 31 +--
 3 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/lib/odp-execute-private.c b/lib/odp-execute-private.c
index ba4aee09b..47cc1b4bc 100644
--- a/lib/odp-execute-private.c
+++ b/lib/odp-execute-private.c
@@ -33,7 +33,7 @@ static struct odp_execute_action_impl action_impls[] = {
 [ACTION_IMPL_SCALAR] = {
 .available = false,
 .name = "scalar",
-.init_func = NULL,
+.init_func = odp_action_scalar_init,
 },
 };
 
@@ -87,5 +87,19 @@ odp_execute_action_init(void)
 
 VLOG_INFO("Action implementation %s (available: %s)",
   action_impls[i].name, avail ? "Yes" : "No");
+
+/* The following is a run-time check to make sure a scalar
+ * implementation exists for the given ISA implementation. This is to
+ * make sure the autovalidator works as expected. */
+if (avail && i != ACTION_IMPL_SCALAR) {
+for (int j = 0; j < __OVS_ACTION_ATTR_MAX; j++) {
+/* No ovs_assert(), as it can be compiled out. */
+if (action_impls[ACTION_IMPL_SCALAR].funcs[j] == NULL
+&& action_impls[i].funcs[j] != NULL) {
+ovs_assert_failure(OVS_SOURCE_LOCATOR, __func__,
+   "Missing scalar action function!");
+}
+}
+}
 }
 }
diff --git a/lib/odp-execute-private.h b/lib/odp-execute-private.h
index 25a003e3d..f890e0cf1 100644
--- a/lib/odp-execute-private.h
+++ b/lib/odp-execute-private.h
@@ -66,6 +66,10 @@ BUILD_ASSERT_DECL(ACTION_IMPL_SCALAR == 0);
  * initializing the scalar/generic codepath. */
 void odp_execute_action_init(void);
 
+/* Init functions for the action implementations. Initializes the function
+ * pointers for optimized action types. */
+int odp_action_scalar_init(struct odp_execute_action_impl *self);
+
 struct odp_execute_action_impl * odp_execute_action_set(const char *name);
 
 #endif /* ODP_EXTRACT_PRIVATE */
diff --git a/lib/odp-execute.c b/lib/odp-execute.c
index 8a120223e..4ef82da76 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -834,6 +834,29 @@ requires_datapath_assistance(const struct nlattr *a)
 return false;
 }
 
+static void
+action_pop_vlan(struct dp_packet_batch *batch,
+const struct nlattr *a OVS_UNUSED)
+{
+struct dp_packet *packet;
+
+DP_PACKET_BATCH_FOR_EACH (i, packet, batch) {
+eth_pop_vlan(packet);
+}
+}
+
+/* Implementation of the scalar actions impl init function. Build up the
+ * array of func ptrs here. */
+int
+odp_action_scalar_init(struct odp_execute_action_impl *self)
+{
+/* Set function pointers for actions that can be applied directly, these
+ * are identified by OVS_ACTION_ATTR_*. */
+self->funcs[OVS_ACTION_ATTR_POP_VLAN] = action_pop_vlan;
+
+return 0;
+}
+
 /* The active function pointers on the datapath. ISA optimized implementations
  * are enabled by plugging them into this static arary, which is consulted when
  * applying actions on the datapath. */
@@ -989,12 +1012,6 @@ odp_execute_actions(void *dp, struct dp_packet_batch 
*batch, bool steal,
 break;
 }
 
-case OVS_ACTION_ATTR_POP_VLAN:
-DP_PACKET_BATCH_FOR_EACH (i, packet, batch) {
-eth_pop_vlan(packet);
-}
-break;
-
 case OVS_ACTION_ATTR_PUSH_MPLS: {
 const struct ovs_action_push_mpls *mpls = nl_attr_get(a);
 
@@ -1145,6 +1162,8 @@ odp_execute_actions(void *dp, struct dp_packet_batch 
*batch, bool steal,
 case OVS_ACTION_ATTR_CT:
 case OVS_ACTION_ATTR_UNSPEC:
 case __OVS_ACTION_ATTR_MAX:
+/* The following actions are handled by the scalar implementation. */
+case OVS_ACTION_ATTR_POP_VLAN:
 OVS_NOT_REACHED();
 }
 
-- 
2.32.0

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

[ovs-dev] [v11 06/10] odp-execute: Add ISA implementation of actions.

[Emma Finn]

This commit adds the AVX512 implementation of the action functionality.

Usage:
  $ ovs-appctl odp-execute/action-impl-set avx512

Signed-off-by: Emma Finn 
Signed-off-by: Harry van Haaren 
---
 Documentation/topics/dpdk/bridge.rst | 30 
 Documentation/topics/testing.rst | 24 ++
 NEWS |  1 +
 acinclude.m4 |  1 +
 lib/cpu.c|  1 +
 lib/cpu.h|  1 +
 lib/odp-execute-private.c|  8 
 lib/odp-execute-private.h| 12 +++
 m4/openvswitch.m4| 29 +++
 9 files changed, 99 insertions(+), 8 deletions(-)

diff --git a/Documentation/topics/dpdk/bridge.rst 
b/Documentation/topics/dpdk/bridge.rst
index 1f626c7c2..354f1ced1 100644
--- a/Documentation/topics/dpdk/bridge.rst
+++ b/Documentation/topics/dpdk/bridge.rst
@@ -321,3 +321,33 @@ following command::
 ``scalar`` can be selected on core ``3`` by the following command::
 
 $ ovs-appctl dpif-netdev/miniflow-parser-set -pmd 3 scalar
+
+
+Actions Implementations (Experimental)
+--
+
+Actions describe what processing or modification should be performed on a
+packet when it matches a given flow. Similar to the datapath interface,
+DPCLS and MFEX (see above), the implementation of these actions can be
+accelerated using SIMD instructions, resulting in improved performance.
+
+OVS provides multiple implementations of the actions, however some
+implementations requiring a CPU capable of executing the required SIMD
+instructions.
+
+Available implementations can be listed with the following command::
+
+$ ovs-appctl odp-execute/action-impl-show
+Available Actions implementations:
+scalar (available: Yes, active: Yes)
+autovalidator (available: Yes, active: No)
+avx512 (available: Yes, active: No)
+
+By default, ``scalar`` is used.  Implementations can be selected by
+name::
+
+$ ovs-appctl odp-execute/action-impl-set avx512
+Action implementation set to avx512.
+
+$ ovs-appctl odp-execute/action-impl-set scalar
+Action implementation set to scalar.
diff --git a/Documentation/topics/testing.rst b/Documentation/topics/testing.rst
index c15d5b38f..a6c747b18 100644
--- a/Documentation/topics/testing.rst
+++ b/Documentation/topics/testing.rst
@@ -361,12 +361,12 @@ testsuite.
 Userspace datapath: Testing and Validation of CPU-specific Optimizations
 
 
-As multiple versions of the datapath classifier and packet parsing functions
-can co-exist, each with different CPU ISA optimizations, it is important to
-validate that they all give the exact same results.  To easily test all the
-implementations, an ``autovalidator`` implementation of them exists.  This
-implementation runs all other available implementations, and verifies that the
-results are identical.
+As multiple versions of the datapath classifier, packet parsing functions and
+actions can co-exist, each with different CPU ISA optimizations, it is
+important to validate that they all give the exact same results.  To easily
+test all the implementations, an ``autovalidator`` implementation of them
+exists. This implementation runs all other available implementations, and
+verifies that the results are identical.
 
 Running the OVS unit tests with the autovalidator enabled ensures all
 implementations provide the same results.  Note that the performance of the
@@ -382,18 +382,26 @@ To set the autovalidator for the packet parser, use this 
command::
 
 $ ovs-appctl dpif-netdev/miniflow-parser-set autovalidator
 
+To set the autovalidator for actions, use this command::
+
+$ ovs-appctl odp-execute/action-impl-set autovalidator
+
 To run the OVS unit test suite with the autovalidator as the default
 implementation, it is required to recompile OVS.  During the recompilation,
 the default priority of the `autovalidator` implementation is set to the
-maximum priority, ensuring every test will be run with every implementation::
+maximum priority, ensuring every test will be run with every implementation.
+Priority is only related to mfex autovalidator and not the actions
+autovalidator.::
 
-$ ./configure --enable-autovalidator --enable-mfex-default-autovalidator
+$ ./configure --enable-autovalidator --enable-mfex-default-autovalidator \
+--enable-actions-default-autovalidator
 
 The following line should be seen in the configuration log when the above
 options are used::
 
 checking whether DPCLS Autovalidator is default implementation... yes
 checking whether MFEX Autovalidator is default implementation... yes
+checking whether actions Autovalidator is default implementation... yes
 
 Compile OVS in debug mode to have `ovs_assert` statements error out if
 there is a mis-match in the data

[ovs-dev] [v11 05/10] acinclude: Add configure option to enable actions autovalidator at build time.

[Emma Finn]

From: Kumar Amber 

This commit adds a new command to allow the user to enable the
actions autovalidator by default at build time thus allowing for
running unit test by default.

 $ ./configure --enable-actions-default-autovalidator

Signed-off-by: Kumar Amber 
Acked-by: Harry van Haaren 
Acked-by: Eelco Chaudron 
---
 NEWS  |  2 ++
 acinclude.m4  | 20 
 configure.ac  |  1 +
 lib/odp-execute.c |  4 
 4 files changed, 27 insertions(+)

diff --git a/NEWS b/NEWS
index 0b95c0bf2..cf8e8a290 100644
--- a/NEWS
+++ b/NEWS
@@ -59,6 +59,8 @@ Post-v2.17.0
implementations against default implementation.
  * Add command line option to switch between different actions
implementations available at run time.
+ * Add build time configure command to enable auto-validator as default
+   actions implementation at build time.
- Linux datapath:
  * Add offloading meter tc police.
  * Add support for offloading the check_pkt_len action.
diff --git a/acinclude.m4 b/acinclude.m4
index d15f11a4e..21c505fbd 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -14,6 +14,26 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
+dnl Set OVS Actions Autovalidator as the default action implementation
+dnl at compile time. This enables automatically running all unit tests
+dnl with all actions implementations.
+AC_DEFUN([OVS_CHECK_ACTIONS_AUTOVALIDATOR], [
+  AC_ARG_ENABLE([actions-default-autovalidator],
+[AC_HELP_STRING([--enable-actions-default-autovalidator],
+[Enable actions autovalidator as default
+ ovs actions implementation.])],
+[autovalidator=yes],[autovalidator=no])
+  AC_MSG_CHECKING([whether actions Autovalidator is default implementation])
+  if test "$autovalidator" != yes; then
+AC_MSG_RESULT([no])
+  else
+AC_DEFINE([ACTIONS_AUTOVALIDATOR_DEFAULT], [1],
+  [Autovalidator for actions is a default implementation.])
+AC_MSG_RESULT([yes])
+  fi
+])
+
+
 dnl Set OVS MFEX Autovalidator as default miniflow extract at compile time?
 dnl This enables automatically running all unit tests with all MFEX
 dnl implementations.
diff --git a/configure.ac b/configure.ac
index 6f8679d7c..6c51e48ce 100644
--- a/configure.ac
+++ b/configure.ac
@@ -184,6 +184,7 @@ OVS_CONDITIONAL_CC_OPTION([-Wno-unused-parameter], 
[HAVE_WNO_UNUSED_PARAMETER])
 OVS_ENABLE_WERROR_TOP
 OVS_ENABLE_SPARSE
 OVS_CTAGS_IDENTIFIERS
+OVS_CHECK_ACTIONS_AUTOVALIDATOR
 OVS_CHECK_DPCLS_AUTOVALIDATOR
 OVS_CHECK_DPIF_AVX512_DEFAULT
 OVS_CHECK_MFEX_AUTOVALIDATOR
diff --git a/lib/odp-execute.c b/lib/odp-execute.c
index 2a6239aaf..ff16e9bf3 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -926,7 +926,11 @@ odp_execute_init(void)
 static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
 if (ovsthread_once_start(&once)) {
 odp_execute_action_init();
+#ifdef ACTIONS_AUTOVALIDATOR_DEFAULT
+odp_actions_impl_set("autovalidator");
+#else
 odp_actions_impl_set("scalar");
+#endif
 odp_execute_unixctl_init();
 ovsthread_once_done(&once);
 }
-- 
2.32.0

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

[ovs-dev] [v11 04/10] odp-execute: Add command to switch action implementation.

[Emma Finn]

This commit adds a new command to allow the user to switch
the active action implementation at runtime.

Usage:
  $ ovs-appctl odp-execute/action-impl-set scalar

This commit also adds a new command to retrieve the list of available
action implementations. This can be used by to check what implementations
of actions are available and what implementation is active during runtime.

Usage:
   $ ovs-appctl odp-execute/action-impl-show

Added separate test-case for ovs-actions show/set commands:
odp-execute - actions implementation

Signed-off-by: Emma Finn 
Signed-off-by: Kumar Amber 
Signed-off-by: Sunil Pai G 
Co-authored-by: Kumar Amber 
Co-authored-by: Sunil Pai G 
Acked-by: Harry van Haaren 
---
 NEWS|  2 ++
 lib/automake.mk |  1 +
 lib/odp-execute-private.c   | 12 ++
 lib/odp-execute-private.h   |  2 ++
 lib/odp-execute-unixctl.man | 10 +
 lib/odp-execute.c   | 44 +
 tests/odp.at| 39 
 vswitchd/ovs-vswitchd.8.in  |  1 +
 8 files changed, 111 insertions(+)
 create mode 100644 lib/odp-execute-unixctl.man

diff --git a/NEWS b/NEWS
index 311c23e0c..0b95c0bf2 100644
--- a/NEWS
+++ b/NEWS
@@ -57,6 +57,8 @@ Post-v2.17.0
The old variant is kept for backward compatibility.
  * Add actions auto-validator function to compare different actions
implementations against default implementation.
+ * Add command line option to switch between different actions
+   implementations available at run time.
- Linux datapath:
  * Add offloading meter tc police.
  * Add support for offloading the check_pkt_len action.
diff --git a/lib/automake.mk b/lib/automake.mk
index 23ba4fab0..5c3b05f6b 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -584,6 +584,7 @@ MAN_FRAGMENTS += \
lib/netdev-dpdk-unixctl.man \
lib/dpif-netdev-unixctl.man \
lib/dpif-netlink-unixctl.man \
+   lib/odp-execute-unixctl.man \
lib/ofp-version.man \
lib/ovs.tmac \
lib/ovs-replay.man \
diff --git a/lib/odp-execute-private.c b/lib/odp-execute-private.c
index 604855b1b..60f202cad 100644
--- a/lib/odp-execute-private.c
+++ b/lib/odp-execute-private.c
@@ -67,6 +67,18 @@ odp_execute_action_set(const char *name)
 return NULL;
 }
 
+void
+odp_execute_action_get_info(struct ds *string)
+{
+ds_put_cstr(string, "Available Actions implementations:\n");
+for (int i = 0; i < ACTION_IMPL_MAX; i++) {
+ds_put_format(string, "  %s (available: %s, active: %s)\n",
+  action_impls[i].name,
+  action_impls[i].available ? "Yes" : "No",
+  i == active_action_impl_index ? "Yes" : "No");
+}
+}
+
 void
 odp_execute_action_init(void)
 {
diff --git a/lib/odp-execute-private.h b/lib/odp-execute-private.h
index a155d534f..8c2ec3854 100644
--- a/lib/odp-execute-private.h
+++ b/lib/odp-execute-private.h
@@ -78,4 +78,6 @@ struct odp_execute_action_impl * odp_execute_action_set(const 
char *name);
 
 int action_autoval_init(struct odp_execute_action_impl *self);
 
+void odp_execute_action_get_info(struct ds *name);
+
 #endif /* ODP_EXTRACT_PRIVATE */
diff --git a/lib/odp-execute-unixctl.man b/lib/odp-execute-unixctl.man
new file mode 100644
index 0..82d51e1d3
--- /dev/null
+++ b/lib/odp-execute-unixctl.man
@@ -0,0 +1,10 @@
+.SS "ODP-EXECUTE COMMANDS"
+These commands manage the "odp-execute" component.
+
+.IP "\fBodp-execute/action-impl-show\fR
+Lists the actions implementations that are available and highlights the
+currently enabled one.
+.
+.IP "\fBodp-execute/action-impl-set\fR \fIaction_impl\fR"
+Sets the action implementation to any available implementation. By default
+"scalar" is used.
diff --git a/lib/odp-execute.c b/lib/odp-execute.c
index 4ef82da76..2a6239aaf 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -39,6 +39,7 @@
 #include "csum.h"
 #include "conntrack.h"
 #include "openvswitch/vlog.h"
+#include "unixctl.h"
 
 VLOG_DEFINE_THIS_MODULE(odp_execute);
 COVERAGE_DEFINE(datapath_drop_sample_error);
@@ -877,6 +878,48 @@ odp_actions_impl_set(const char *name)
 
 }
 
+static void
+action_impl_set(struct unixctl_conn *conn, int argc OVS_UNUSED,
+const char *argv[], void *aux OVS_UNUSED)
+{
+struct ds reply = DS_EMPTY_INITIALIZER;
+
+int err = odp_actions_impl_set(argv[1]);
+if (err) {
+ds_put_format(&reply,
+  "Error: unknown action implementation, %s, specified!",
+  argv[1]);
+unixctl_command_reply_error(conn, ds_cstr(&reply));
+} else {
+ds_put_format(&reply, "Action implementation set to %s.", argv[1]);
+unixctl_command_reply(conn, ds_cstr(&reply));
+}
+
+ds_destroy(&reply);
+}
+
+static void
+action_impl_show(struct unixctl_conn *conn, int argc OVS_UNUSED,
+const char *argv[] OVS_UNUSED, void *aux OVS_UNUSED)
+{
+str

[ovs-dev] [v11 03/10] odp-execute: Add auto validation function for actions.

[Emma Finn]

This commit introduced the auto-validation function which
allows users to compare the batch of packets obtained from
different action implementations against the linear
action implementation.

The autovalidator function can be triggered at runtime using the
following command:

$ ovs-appctl odp-execute/action-impl-set autovalidator

Signed-off-by: Emma Finn 
Acked-by: Harry van Haaren 
Acked-by: Eelco Chaudron 
---
 NEWS  |  2 +
 lib/dp-packet.c   | 24 ++
 lib/dp-packet.h   |  4 ++
 lib/odp-execute-private.c | 98 +++
 lib/odp-execute-private.h |  6 +++
 5 files changed, 134 insertions(+)

diff --git a/NEWS b/NEWS
index 403cc7fb3..311c23e0c 100644
--- a/NEWS
+++ b/NEWS
@@ -55,6 +55,8 @@ Post-v2.17.0
  * 'dpif-netdev/subtable-lookup-prio-get' appctl command renamed to
'dpif-netdev/subtable-lookup-info-get' to better reflect its purpose.
The old variant is kept for backward compatibility.
+ * Add actions auto-validator function to compare different actions
+   implementations against default implementation.
- Linux datapath:
  * Add offloading meter tc police.
  * Add support for offloading the check_pkt_len action.
diff --git a/lib/dp-packet.c b/lib/dp-packet.c
index 35c72542a..4538d2a61 100644
--- a/lib/dp-packet.c
+++ b/lib/dp-packet.c
@@ -506,3 +506,27 @@ dp_packet_resize_l2(struct dp_packet *b, int increment)
 dp_packet_adjust_layer_offset(&b->l2_5_ofs, increment);
 return dp_packet_data(b);
 }
+
+bool
+dp_packet_compare_offsets(struct dp_packet *b1, struct dp_packet *b2,
+  struct ds *err_str)
+{
+if ((b1->l2_pad_size != b2->l2_pad_size) ||
+(b1->l2_5_ofs != b2->l2_5_ofs) ||
+(b1->l3_ofs != b2->l3_ofs) ||
+(b1->l4_ofs != b2->l4_ofs)) {
+if (err_str) {
+ds_put_format(err_str, "Packet offset comparison failed\n");
+ds_put_format(err_str, "Buffer 1 offsets: l2_pad_size %u,"
+  " l2_5_ofs : %u l3_ofs %u, l4_ofs %u\n",
+  b1->l2_pad_size, b1->l2_5_ofs,
+  b1->l3_ofs, b1->l4_ofs);
+ds_put_format(err_str, "Buffer 2 offsets: l2_pad_size %u,"
+  " l2_5_ofs : %u l3_ofs %u, l4_ofs %u\n",
+  b2->l2_pad_size, b2->l2_5_ofs,
+  b2->l3_ofs, b2->l4_ofs);
+}
+return false;
+}
+return true;
+}
diff --git a/lib/dp-packet.h b/lib/dp-packet.h
index eea5a9215..55eeaab2c 100644
--- a/lib/dp-packet.h
+++ b/lib/dp-packet.h
@@ -236,6 +236,10 @@ void *dp_packet_steal_data(struct dp_packet *);
 static inline bool dp_packet_equal(const struct dp_packet *,
const struct dp_packet *);
 
+bool dp_packet_compare_offsets(struct dp_packet *good,
+   struct dp_packet *test,
+   struct ds *err_str);
+
 
 /* Frees memory that 'b' points to, as well as 'b' itself. */
 static inline void
diff --git a/lib/odp-execute-private.c b/lib/odp-execute-private.c
index 47cc1b4bc..604855b1b 100644
--- a/lib/odp-execute-private.c
+++ b/lib/odp-execute-private.c
@@ -30,6 +30,12 @@ VLOG_DEFINE_THIS_MODULE(odp_execute_impl);
 static int active_action_impl_index;
 
 static struct odp_execute_action_impl action_impls[] = {
+[ACTION_IMPL_AUTOVALIDATOR] = {
+.available = false,
+.name = "autovalidator",
+.init_func = action_autoval_init,
+},
+
 [ACTION_IMPL_SCALAR] = {
 .available = false,
 .name = "scalar",
@@ -103,3 +109,95 @@ odp_execute_action_init(void)
 }
 }
 }
+
+/* Init sequence required to be scalar first to pick up the default scalar
+ * implementations, allowing over-riding of the optimized functions later. */
+BUILD_ASSERT_DECL(ACTION_IMPL_SCALAR == 0);
+BUILD_ASSERT_DECL(ACTION_IMPL_AUTOVALIDATOR == 1);
+
+/* Loop over packets, and validate each one for the given action. */
+static void
+action_autoval_generic(struct dp_packet_batch *batch, const struct nlattr *a)
+{
+struct odp_execute_action_impl *scalar = &action_impls[ACTION_IMPL_SCALAR];
+enum ovs_action_attr attr_type = nl_attr_type(a);
+struct dp_packet_batch original_batch;
+bool failed = false;
+
+dp_packet_batch_clone(&original_batch, batch);
+
+scalar->funcs[attr_type](batch, a);
+
+for (int impl = ACTION_IMPL_BEGIN; impl < ACTION_IMPL_MAX; impl++) {
+/* Clone original batch and execute implementation under test. */
+struct dp_packet_batch test_batch;
+
+dp_packet_batch_clone(&test_batch, &original_batch);
+action_impls[impl].funcs[attr_type](&test_batch, a);
+
+/* Loop over implementations, checking each one. */
+for (int pidx = 0; pidx < original_batch.count; pidx++) {
+struct dp_packet *good_pkt = batch->packets[pidx];
+struct dp_packet *test_pkt = te

[ovs-dev] [v11 00/10] Actions Infrastructure + Optimizations

[Emma Finn]

This patchset introduces actions infrastructure changes which allows
the user to choose between different action implementations based on
CPU ISA by using different commands.  The infrastructure also
provides a way to check the correctness of the ISA optimized action
version against the scalar version.
This series also introduces optimized versions of the following
actions:
 - push_vlan
 - pop_vlan
 - set_masked eth
 - set_masked ipv4
Below is a table indicating some relative performance benefits for
these actions.
+---+---+-+
| Actions   | Scalar with series|AVX with 
series |
+---+---+-+
| mod_dl_dst| 1.01x |1.13x  
 |
+---+---+-+
| push_vlan | 1.01x |1.10x  
 |
+---+---+-+
| strip_vlan| 1.01x |1.11x  
 |
+---+---+-+
| mod_ipv4 1 x field| 1.01x |1.02x  
 |
+---+---+-+
| mod_ipv4 4 x fields   | 1.01x |1.21x  
 |
+---+---+-+
| strip_vlan + mod_dl_dst + mod_ipv4 4 x fields | 1.01x |1.36x  
 |
+---+---+-+

---
v11:
- Moved unit test to opd.at
- Refactored avx probe/init
- renamed variables for avx implementation of ipv4 action
- added atomic read and store of active impl function pointer
---
v10;
- Fixed CI build issue on OSX around AVX512 linking (jenkins CI)
- Moved docs and reworded sections (thanks Ilya for feedback)
- Reworked one instance of <= OVS_ATTR_MAX back to original form(Eelco)
---
v9:
- Moved avx512 probe and init functions to later patch.
- Dependency on userspace datapath has been resolved.
- Fixed up comments from Sunil as posted on v8
- Note: Harry is sending this patchset, but it is Emma's rework,
   except for rebasing to lastest git, and very minor fixups.
---
v8
- First patch changing unit tests has been removed from series.
- AVX checksum implementation has been reworked.
---
v7:
- Fix review comments from Eelco.
---
v6:
- Rebase to master
- Add ISA implementation of set_masked eth and ipv4 actions
- Fix incorrect checksums in input packets for ofproto-dpif unit
tests
---
v5:
- Rebase to master
- Minor change to variable names
- Added Tags from Harry.
---
v4:
- Rebase to master
- Add ISA implementation of push_vlan action
---
v3:
- Refactored to fix unit test failures
- Removed some sign-off on commits
---
v2:
- Fix the CI build issues
---


Emma Finn (8):
  odp-execute: Add function pointers to odp-execute for different action
implementations.
  odp-execute: Add function pointer for pop_vlan action.
  odp-execute: Add auto validation function for actions.
  odp-execute: Add command to switch action implementation.
  odp-execute: Add ISA implementation of actions.
  odp-execute: Add ISA implementation of push_vlan action.
  odp-execute: Add ISA implementation of set_masked ETH
  odp-execute: Add ISA implementation of set_masked IPv4 action

Harry van Haaren (1):
  odp-execute: Add ISA implementation of pop_vlan action.

Kumar Amber (1):
  acinclude: Add configure option to enable actions autovalidator at
build time.

 Documentation/topics/dpdk/bridge.rst |  30 ++
 Documentation/topics/testing.rst |  24 +-
 NEWS |   7 +
 acinclude.m4 |  21 ++
 configure.ac |   1 +
 lib/automake.mk  |   7 +
 lib/cpu.c|   1 +
 lib/cpu.h|   1 +
 lib/dp-packet.c  |  24 ++
 lib/dp-packet.h  |   4 +
 lib/odp-execute-avx512.c | 546 +++
 lib/odp-execute-private.c| 267 +
 lib/odp-execute-private.h| 102 +
 lib/odp-execute-unixctl.man  |  10 +
 lib/odp-execute.c| 208 --
 lib/odp-execute.h|  10 +
 m4/openvswitch.m4|  29 ++
 tests/odp.at |  39 ++
 tests/ofproto-macros.at  |   1 +
 vswitchd/bridge.c|   3 +
 vswitchd/ovs-vswitchd.8.in   |   1 +
 21 files changed, 1290 insertions(+), 46 deletions(-)
 create mode 100644 lib/odp-execute-avx512.c
 create mode 100644 lib/odp-execute-private.c
 create

[ovs-dev] [v11 01/10] odp-execute: Add function pointers to odp-execute for different action implementations.

[Emma Finn]

This commit introduces the initial infrastructure required to allow
different implementations for OvS actions. The patch introduces action
function pointers which allows user to switch between different action
implementations available. This will allow for more performance and flexibility
so the user can choose the action implementation to best suite their use case.

Signed-off-by: Emma Finn 
Acked-by: Harry van Haaren 

---

v10:
- switch from < __OVS_ATTR_MAX back to <= OVS_ATTR_MAX (Eelco)

v9:
- rebase conflicts on NEWS
- As Actions is initialized in vswitchd/bridge.c now, logs are output on
  startup, which have been added to the tests/ofproto-macros.
---
 lib/automake.mk   |  2 +
 lib/odp-execute-private.c | 91 +++
 lib/odp-execute-private.h | 71 ++
 lib/odp-execute.c | 58 -
 lib/odp-execute.h |  7 +++
 tests/ofproto-macros.at   |  1 +
 vswitchd/bridge.c |  3 ++
 7 files changed, 232 insertions(+), 1 deletion(-)
 create mode 100644 lib/odp-execute-private.c
 create mode 100644 lib/odp-execute-private.h

diff --git a/lib/automake.mk b/lib/automake.mk
index 1d00cfa20..23ba4fab0 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -216,6 +216,8 @@ lib_libopenvswitch_la_SOURCES = \
lib/object-collection.h \
lib/odp-execute.c \
lib/odp-execute.h \
+   lib/odp-execute-private.c \
+   lib/odp-execute-private.h \
lib/odp-util.c \
lib/odp-util.h \
lib/ofp-actions.c \
diff --git a/lib/odp-execute-private.c b/lib/odp-execute-private.c
new file mode 100644
index 0..ba4aee09b
--- /dev/null
+++ b/lib/odp-execute-private.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2022 Intel.
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "dpdk.h"
+#include "dp-packet.h"
+#include "odp-execute-private.h"
+#include "odp-netlink.h"
+#include "odp-util.h"
+#include "openvswitch/vlog.h"
+
+VLOG_DEFINE_THIS_MODULE(odp_execute_impl);
+static int active_action_impl_index;
+
+static struct odp_execute_action_impl action_impls[] = {
+[ACTION_IMPL_SCALAR] = {
+.available = false,
+.name = "scalar",
+.init_func = NULL,
+},
+};
+
+static void
+action_impl_copy_funcs(struct odp_execute_action_impl *dest,
+   const struct odp_execute_action_impl *src)
+{
+for (int i = 0; i < __OVS_ACTION_ATTR_MAX; i++) {
+atomic_store_relaxed(&dest->funcs[i], src->funcs[i]);
+}
+}
+
+struct odp_execute_action_impl *
+odp_execute_action_set(const char *name)
+{
+for (int i = 0; i < ACTION_IMPL_MAX; i++) {
+/* String compare, and set ptrs atomically. */
+if (!strcmp(action_impls[i].name, name)) {
+active_action_impl_index = i;
+
+VLOG_INFO("Action implementation set to %s", name);
+return &action_impls[i];
+}
+}
+return NULL;
+}
+
+void
+odp_execute_action_init(void)
+{
+/* Each impl's function array is initialized to reflect the scalar
+ * implementation. This simplifies adding optimized implementations,
+ * as the autovalidator can always compare all actions.
+ *
+ * Below will check if impl is available and copies the scalar functions
+ * to all other implementations. */
+for (int i = 0; i < ACTION_IMPL_MAX; i++) {
+bool avail = true;
+
+if (i != ACTION_IMPL_SCALAR) {
+action_impl_copy_funcs(&action_impls[i],
+   &action_impls[ACTION_IMPL_SCALAR]);
+}
+
+if (action_impls[i].init_func) {
+/* Return zero is success, non-zero means error. */
+avail = (action_impls[i].init_func(&action_impls[i]) == 0);
+}
+
+action_impls[i].available = avail;
+
+VLOG_INFO("Action implementation %s (available: %s)",
+  action_impls[i].name, avail ? "Yes" : "No");
+}
+}
diff --git a/lib/odp-execute-private.h b/lib/odp-execute-private.h
new file mode 100644
index 0..25a003e3d
--- /dev/null
+++ b/lib/odp-execute-private.h
@@ -0,0 +1,71 @@
+/*
+ * Copyright (c) 2022 Intel.
+ *
+ * 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
+ *
+ * U

Re: [ovs-dev] [PATCH 1/2] netdev-offload-tc: Fix ignoring unknown tunnel keys.

[Roi Dayan via dev]

On 2022-07-14 4:18 PM, Ilya Maximets wrote:

On 7/14/22 15:13, Roi Dayan wrote:



On 2022-07-14 4:01 PM, Roi Dayan wrote:



On 2022-07-14 3:52 PM, Roi Dayan wrote:



On 2022-07-14 3:37 PM, Roi Dayan wrote:



On 2022-07-13 7:28 PM, Ilya Maximets wrote:

On 7/13/22 12:11, Roi Dayan wrote:



On 2022-07-13 12:01 PM, Roi Dayan wrote:



On 2022-07-06 4:58 PM, Roi Dayan wrote:



On 2022-07-05 1:45 AM, Ilya Maximets wrote:

Current offloading code supports only limited number of tunnel keys
and silently ignores everything it doesn't understand.  This is
causing, for example, offloaded ERSPAN tunnels to not work, because
flow is offloaded, but ERSPAN options are not provided to TC.

There is a number of tunnel keys, which are supported by the userspace,
but silently ignored during offloading:

     OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT
     OVS_TUNNEL_KEY_ATTR_OAM
     OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS
     OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS

OVS_TUNNEL_KEY_ATTR_CSUM is kind of supported, but only for actions
and for some reason is set from the tunnel port instead of the
provided action, and not currently supported for the tunnel key in
the match.

Addig a default case to fail offloading of unknown attributes.  For
now explicitly allowing incorrect behavior for the DONT_FRAGMENT flag,
otherwise we'll break all tunnel offloading by default.  VXLAN and
ERSPAN options has to fail offloading, because the tunnel will not
work otherwise.  OAM is not a default configurations, so failing it
as well. The missing DONT_FRAGMENT flag though should, probably,
cause frequent flow revalidation, but that is not new with this patch.

Same for the 'match' key, only clearing masks that was actually
consumed, except for the DONT_FRAGMENT and CSUM flags, which are
explicitly allowed and highlighted as broken.

Also, ttl and tos were incorrectly checked by the value instead of a
mask during the flow key dump. Destination port as well as CSUM
configuration for unknown reason was not taken from the actions list
and were passed via HW offload info.

Reported-at: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-dev%2F2022-July%2F395522.html&data=05%7C01%7Croid%40nvidia.com%7Cd5529f26731846561c5108da659b57a3%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637934015121728988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=s9utolIUQDeF7SP0gwe6PucT%2FUzp99uHNpV3W9b0Z6M%3D&reserved=0
Reported-by: Eelco Chaudron 
Fixes: 8f283af89298 ("netdev-tc-offloads: Implement netdev flow put using tc 
interface")
Signed-off-by: Ilya Maximets 
---
    lib/dpif-netlink.c  | 14 +-
    lib/netdev-offload-tc.c | 57 ++---
    lib/netdev-offload.h    |  3 ---
    3 files changed, 49 insertions(+), 25 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 06e1e8ca0..1e116b4ad 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -2237,8 +2237,6 @@ parse_flow_put(struct dpif_netlink *dpif, struct 
dpif_flow_put *put)
    size_t left;
    struct netdev *dev;
    struct offload_info info;
-    ovs_be16 dst_port = 0;
-    uint8_t csum_on = false;
    int err;
    info.tc_modify_flow_deleted = false;
@@ -2258,10 +2256,9 @@ parse_flow_put(struct dpif_netlink *dpif, struct 
dpif_flow_put *put)
    return EOPNOTSUPP;
    }
-    /* Get tunnel dst port */
+    /* Check the output port for a tunnel. */
    NL_ATTR_FOR_EACH(nla, left, put->actions, put->actions_len) {
    if (nl_attr_type(nla) == OVS_ACTION_ATTR_OUTPUT) {
-    const struct netdev_tunnel_config *tnl_cfg;
    struct netdev *outdev;
    odp_port_t out_port;
@@ -2271,19 +2268,10 @@ parse_flow_put(struct dpif_netlink *dpif, struct 
dpif_flow_put *put)
    err = EOPNOTSUPP;
    goto out;
    }
-    tnl_cfg = netdev_get_tunnel_config(outdev);
-    if (tnl_cfg && tnl_cfg->dst_port != 0) {
-    dst_port = tnl_cfg->dst_port;
-    }
-    if (tnl_cfg) {
-    csum_on = tnl_cfg->csum;
-    }
    netdev_close(outdev);
    }
    }
-    info.tp_dst_port = dst_port;
-    info.tunnel_csum_on = csum_on;
    info.recirc_id_shared_with_tc = (dpif->user_features
     & OVS_DP_F_TC_RECIRC_SHARING);
    err = netdev_flow_put(dev, &match,
diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
index 262faf3c6..e62687c82 100644
--- a/lib/netdev-offload-tc.c
+++ b/lib/netdev-offload-tc.c
@@ -805,11 +805,11 @@ parse_tc_flower_to_match(struct tc_flower *flower,
&flower->key.tunnel.ipv6.ipv6_src,
&flower->mask.tunnel.ipv6.ipv6_src);
    }
-    if (flower->key.tunnel.tos) {
+    if (flower->mask.tunnel.tos) {
    match_set_tun_tos_masked(match, flower->key.tunnel.tos,
 

[ovs-dev] [PATCH v4 9/9] debian: Add option to build without DPDK.

[Frode Nordahl]

From: Ilya Maximets 

Signed-off-by: Ilya Maximets 
Co-authored-by: Frode Nordahl 
Signed-off-by: Frode Nordahl 
---
 .ci/linux-build.sh |  6 ++-
 .github/workflows/build-and-test.yml   | 12 +-
 .gitignore |  1 +
 Documentation/intro/install/debian.rst | 27 ++--
 debian/.gitignore  | 21 +
 debian/automake.mk | 22 +-
 debian/clean   |  4 +-
 debian/{control => control.in} | 60 +-
 debian/rules   |  6 +++
 9 files changed, 110 insertions(+), 49 deletions(-)
 create mode 100644 debian/.gitignore
 rename debian/{control => control.in} (85%)

diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index a8c437aaf..8dcfbdcea 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -204,9 +204,13 @@ function build_ovs()
 }
 
 if [ "$DEB_PACKAGE" ]; then
+if [ -n "$DPDK" ]; then
+DPDK=no
+fi
+./boot.sh && ./configure --with-dpdk=$DPDK && make debian
 mk-build-deps --install --root-cmd sudo --remove debian/control
 dpkg-checkbuilddeps
-DEB_BUILD_OPTIONS='parallel=4 nocheck' fakeroot debian/rules binary
+make debian-deb
 packages=$(ls $(pwd)/../*.deb)
 deps=""
 for pkg in $packages; do
diff --git a/.github/workflows/build-and-test.yml 
b/.github/workflows/build-and-test.yml
index 90fe17377..419ef0def 100644
--- a/.github/workflows/build-and-test.yml
+++ b/.github/workflows/build-and-test.yml
@@ -216,11 +216,19 @@ jobs:
   deb_dependencies: |
 linux-headers-$(uname -r) build-essential fakeroot devscripts equivs
   DEB_PACKAGE: yes
+  DPDK:${{ matrix.dpdk }}
 
-name: linux deb
+name: linux deb ${{ matrix.dpdk }} dpdk
 runs-on: ubuntu-22.04
 timeout-minutes: 30
 
+strategy:
+  fail-fast: false
+  matrix:
+include:
+  - dpdk: no
+  - dpdk: shared
+
 steps:
 - name: checkout
   uses: actions/checkout@v2
@@ -244,5 +252,5 @@ jobs:
 - name: upload deb packages
   uses: actions/upload-artifact@v2
   with:
-name: deb-packages
+name: deb-packages-${{ matrix.dpdk }}-dpdk
 path: '/home/runner/work/ovs/*.deb'
diff --git a/.gitignore b/.gitignore
index f1cdcf124..b0098f46a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -68,6 +68,7 @@ TAGS
 cscope.*
 tags
 _debian
+_dpdk
 odp-netlink.h
 odp-netlink-macros.h
 OvsDpInterface.h
diff --git a/Documentation/intro/install/debian.rst 
b/Documentation/intro/install/debian.rst
index 4024dc07a..888b17723 100644
--- a/Documentation/intro/install/debian.rst
+++ b/Documentation/intro/install/debian.rst
@@ -58,27 +58,28 @@ You do not need to be the superuser to build the Debian 
packages.
top level directory.
 
 3. Install the build dependencies listed under "Build-Depends:" near the top of
-   ``debian/control``. You can install these any way you like, e.g.  with
+   ``debian/control.in``. You can install these any way you like, e.g.  with
``apt-get install``.
 
-Check your work by running ``dpkg-checkbuilddeps`` in the top level of your OVS
-directory. If you've installed all the dependencies properly,
-``dpkg-checkbuilddeps`` will exit without printing anything. If you forgot to
-install some dependencies, it will tell you which ones.
+4. Prepare the package source.
+
+   If you want to build the package with DPDK support execute the following
+   command::
 
-4. Build the package::
+   $ ./boot.sh && ./configure --with-dpdk=shared && make debian
 
-   $ fakeroot debian/rules binary
+   If not::
 
-   This will do a serial build that runs the unit tests. This will take
-   approximately 8 to 10 minutes. If you prefer, you can run a faster parallel
-   build::
+   $ ./boot.sh && ./configure && make debian
 
-   $ DEB_BUILD_OPTIONS='parallel=8' fakeroot debian/rules binary
+Check your work by running ``dpkg-checkbuilddeps`` in the top level of your OVS
+directory. If you've installed all the dependencies properly,
+``dpkg-checkbuilddeps`` will exit without printing anything. If you forgot to
+install some dependencies, it will tell you which ones.
 
-   If you are in a big hurry, you can even skip the unit tests::
+5. Build the package::
 
-   $ DEB_BUILD_OPTIONS='parallel=8 nocheck' fakeroot debian/rules binary
+   $ make debian-deb
 
 .. note::
 
diff --git a/debian/.gitignore b/debian/.gitignore
new file mode 100644
index 0..0523941c6
--- /dev/null
+++ b/debian/.gitignore
@@ -0,0 +1,21 @@
+*.debhelper
+*.debhelper.log
+*.substvars
+/autoreconf.after
+/autoreconf.before
+/control
+/copyright
+/debhelper-build-stamp
+/files
+/openvswitch-common
+/openvswitch-doc
+/openvswitch-ipsec
+/openvswitch-pki
+/openvswitch-source
+/openvswitch-switch
+/openvswitch-switch-dpdk
+/openvswitch-test
+/openvswitch-testcontroller
+/openvswitch-vtep
+/python3-openvswitch
+/tmp
diff --git a/debian/automake.mk b/

[ovs-dev] [PATCH v4 8/9] docs: Update package references in debian/ubuntu related docs.

[Frode Nordahl]

On the back of changing the debian/ubuntu packaging, update the
docs to refer to existing packages.

Signed-off-by: Frode Nordahl 
---
 Documentation/intro/install/distributions.rst | 22 ---
 Documentation/tutorials/ipsec.rst | 19 +++-
 2 files changed, 12 insertions(+), 29 deletions(-)

diff --git a/Documentation/intro/install/distributions.rst 
b/Documentation/intro/install/distributions.rst
index b68a764d1..ce75ac45c 100644
--- a/Documentation/intro/install/distributions.rst
+++ b/Documentation/intro/install/distributions.rst
@@ -33,24 +33,20 @@ architectures.
   The packaged version available with distributions may not be latest
   Open vSwitch release.
 
-Debian

+Debian / Ubuntu
+---
 
 You can use ``apt-get`` or ``aptitude`` to install the .deb packages and must
 be superuser.
 
-1. Debian has ``openvswitch-switch`` and ``openvswitch-common`` .deb packages
-that includes the core userspace components of the switch.
-
-2. For kernel datapath, ``openvswitch-datapath-dkms`` can be installed to
-automatically build and install Open vSwitch kernel module for your running
-kernel.  This package is only available when the .deb packages are built from
-the Open vSwitch repository; it is not downstream in Debian or Ubuntu releases.
+1. Debian and Ubuntu has ``openvswitch-switch`` and ``openvswitch-common``
+packages that includes the core userspace components of the switch.  Extra
+packages for documentation, ipsec, pki, VTEP and Python support are also
+available.  The Open vSwitch kernel datapath is maintained as part of the
+upstream kernel available in the distribution.
 
-3. For fast userspace switching, Open vSwitch with DPDK support is
-bundled in the package ``openvswitch-switch-dpdk``.  This package is only
-available in the Ubuntu distribution; it is not upstream in the Open vSwitch
-repository or downstream in Debian.
+2. For fast userspace switching, Open vSwitch with DPDK support is
+bundled in the package ``openvswitch-switch-dpdk``.
 
 Fedora
 --
diff --git a/Documentation/tutorials/ipsec.rst 
b/Documentation/tutorials/ipsec.rst
index 7088f9036..9d6cc7779 100644
--- a/Documentation/tutorials/ipsec.rst
+++ b/Documentation/tutorials/ipsec.rst
@@ -42,28 +42,15 @@ Installing OVS and IPsec Packages
 -
 
 OVS IPsec has .deb and .rpm packages. You should use the right package
-based on your Linux distribution. This tutorial uses Ubuntu 16.04 and Fedora 32
+based on your Linux distribution. This tutorial uses Ubuntu 22.04 and Fedora 32
 as examples.
 
 Ubuntu
 ~~
 
-1. Follow :doc:`/intro/install/debian` to build debian packages.
+1. Install the related packages::
 
-   .. note::
-
- If you have already installed OVS, then you only need to install
- openvswitch-pki_*.deb and openvswitch-ipsec_*.deb in the following step.
- If your kernel version is below v4.13.0, update your kernel to v4.13.0 or
- above.
-
-2. Install the related packages::
-
-   # apt-get install dkms strongswan
-   # dpkg -i libopenvswitch_*.deb openvswitch-common_*.deb \
- openvswitch-switch_*.deb openvswitch-datapath-dkms_*.deb \
- python-openvswitch_*.deb openvswitch-pki_*.deb \
- openvswitch-ipsec_*.deb
+   # apt-get install openvswitch-ipsec
 
If the installation is successful, you should be able to see the
ovs-monitor-ipsec daemon is running in your system.
-- 
2.36.1

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

[ovs-dev] [PATCH v4 6/9] debian: Fix build of python json C extension.

[Frode Nordahl]

Signed-off-by: Frode Nordahl 
---
 debian/control |  3 ++-
 debian/rules   | 13 +
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/debian/control b/debian/control
index a813d7cc7..0ff894461 100644
--- a/debian/control
+++ b/debian/control
@@ -278,11 +278,12 @@ Description: Open vSwitch VTEP utilities
  VTEP-configured database and a VTEP emulator.
 
 Package: python3-openvswitch
-Architecture: all
+Architecture: linux-any
 Section: python
 Depends:
  ${misc:Depends},
  ${python3:Depends},
+ ${shlibs:Depends},
 Description: Python 3 bindings for Open vSwitch
  Open vSwitch is a production quality, multilayer, software-based,
  Ethernet virtual switch. It is designed to enable massive network
diff --git a/debian/rules b/debian/rules
index f24801d14..9a2f8ac1c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -85,10 +85,15 @@ override_dh_auto_install:
 
 execute_after_dh_install:
set -e && for pyvers in $(PYTHON3S); do \
-   cd python && python$$pyvers setup.py install 
--install-layout=deb \
-   --root $(CURDIR)/debian/python3-openvswitch; cd ..; \
+   cd python && \
+   enable_shared=no \
+   CFLAGS=-I$(CURDIR)/debian/tmp/usr/include \
+   LDFLAGS=$(CURDIR)/debian/tmp/usr/lib/libopenvswitch.a \
+   python$$pyvers setup.py install --install-layout=deb \
+   --root $(CURDIR)/debian/python3-openvswitch; \
+   cd ..; \
mkdir -p 
$(CURDIR)/debian/openvswitch-test/usr/lib/python$$pyvers/dist-packages/ovstest; 
\
-   install -v -D -m 644 python/ovstest/*.py \
+   install -v -D python/ovstest/*.py \

$(CURDIR)/debian/openvswitch-test/usr/lib/python$$pyvers/dist-packages/ovstest; 
\
done
 
@@ -108,7 +113,7 @@ override_dh_strip:
dh_strip --dbgsym-migration='openvswitch-dbg (<< 2.17~)'
 
 override_dh_python3:
-   dh_python3 --shebang=/usr/bin/python3
+   DEB_HOST_ARCH=$(DEB_HOST_ARCH) dh_python3 --shebang=/usr/bin/python3
 
 # Helper target for creating snapshots from upstream git
 DATE=$(shell date +%Y%m%d)
-- 
2.36.1

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

[ovs-dev] [PATCH v4 7/9] debian: Fix generation of copyright file.

[Frode Nordahl]

The recipe for inserting authors from AUTHORS.rst is wrong.

Fixes: 3deca69b08f2 ("doc: Convert AUTHORS to rST")
Signed-off-by: Frode Nordahl 
---
 debian/automake.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/automake.mk b/debian/automake.mk
index afba5b0e4..a3c2d7289 100644
--- a/debian/automake.mk
+++ b/debian/automake.mk
@@ -83,9 +83,9 @@ DIST_HOOKS += check-debian-changelog-version
 $(srcdir)/debian/copyright: AUTHORS.rst debian/copyright.in
$(AM_V_GEN) \
{ sed -n -e '/%AUTHORS%/q' -e p < $(srcdir)/debian/copyright.in;   \
- sed '34,/^$$/d' $(srcdir)/AUTHORS.rst  |  
   \
+ tail -n +28 $(srcdir)/AUTHORS.rst | sed '1,/^$$/d' | \
sed -n -e '/^$$/q' -e 's/^/  /p';  \
- sed -e '34,/%AUTHORS%/d' $(srcdir)/debian/copyright.in;  \
+ sed -e '1,/%AUTHORS%/d' $(srcdir)/debian/copyright.in;   \
} > $@
 
 DISTCLEANFILES += debian/copyright
-- 
2.36.1

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

[ovs-dev] [PATCH v4 5/9] python: Allow building json C extension with static OVS library.

[Frode Nordahl]

Allow caller of setup.py to pass in libopenvswitch.a as an object
for linking through the use of LDFLAGS environment variable when
not building a shared openvswitch library.

To accomplish this set the `enable_shared` environment variable to
'no'.

Example:
LDFLAGS=lib/libopenvswitch.a enable_shared=no setup.py install

Signed-off-by: Frode Nordahl 
---
 python/setup.py | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/python/setup.py b/python/setup.py
index cfe01763f..369110531 100644
--- a/python/setup.py
+++ b/python/setup.py
@@ -10,6 +10,7 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
+import os
 import sys
 
 from distutils.command.build_ext import build_ext
@@ -63,6 +64,15 @@ class try_build_ext(build_ext):
 raise BuildFailed()
 
 
+# allow caller of setup.py to pass in libopenvswitch.a as an object for linking
+# through the use of LDFLAGS environment variable when not building a shared
+# openvswitch library.
+if os.environ.get('enable_shared', '') == 'no':
+json_libraries = []
+else:
+json_libraries = ['openvswitch']
+
+
 setup_args = dict(
 name='ovs',
 description='Open vSwitch library',
@@ -85,7 +95,7 @@ setup_args = dict(
 'Programming Language :: Python :: 3.5',
 ],
 ext_modules=[setuptools.Extension("ovs._json", sources=["ovs/_json.c"],
-  libraries=['openvswitch'])],
+  libraries=json_libraries)],
 cmdclass={'build_ext': try_build_ext},
 install_requires=['sortedcontainers'],
 extras_require={':sys_platform == "win32"': ['pywin32 >= 1.0']},
-- 
2.36.1

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

[ovs-dev] [PATCH v4 4/9] ci: Separate job for debs, ensure built pkg is tested.

[Frode Nordahl]

Use a separate GitHub Actions job for deb test so that we can
control base image for package test.

The CI deb package test code currently attempts to use `apt` to
install local packages.  That may not produce the expected result.

Explicitly install the local packages with `dpkg` after installing
dependencies from `apt` instead.

Also enable test installation of ipsec deb package.

Signed-off-by: Frode Nordahl 
---
 .ci/linux-build.sh   | 21 +---
 .github/workflows/build-and-test.yml | 50 
 2 files changed, 53 insertions(+), 18 deletions(-)

diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 9963fb810..a8c437aaf 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -207,10 +207,23 @@ if [ "$DEB_PACKAGE" ]; then
 mk-build-deps --install --root-cmd sudo --remove debian/control
 dpkg-checkbuilddeps
 DEB_BUILD_OPTIONS='parallel=4 nocheck' fakeroot debian/rules binary
-# Not trying to install ipsec package as there are issues with system-wide
-# installed python3-openvswitch package and the pyenv used by Travis.
-packages=$(ls $(pwd)/../*.deb | grep -v ipsec)
-sudo apt install ${packages}
+packages=$(ls $(pwd)/../*.deb)
+deps=""
+for pkg in $packages; do
+_ifs=$IFS
+IFS=","
+for dep in $(dpkg-deb -f $pkg Depends); do
+dep_name=$(echo "$dep"|awk '{print$1}')
+# Don't install internal package inter-dependencies from apt
+echo $dep_name | grep -q openvswitch && continue
+deps+=" $dep_name"
+done
+IFS=$_ifs
+done
+# install package dependencies from apt
+echo $deps | xargs sudo apt -y install
+# install the locally built openvswitch packages
+sudo dpkg -i $packages
 exit 0
 fi
 
diff --git a/.github/workflows/build-and-test.yml 
b/.github/workflows/build-and-test.yml
index ec34a9b0d..90fe17377 100644
--- a/.github/workflows/build-and-test.yml
+++ b/.github/workflows/build-and-test.yml
@@ -9,13 +9,10 @@ jobs:
 automake libtool gcc bc libjemalloc1 libjemalloc-dev\
 libssl-dev llvm-dev libelf-dev libnuma-dev libpcap-dev  \
 ninja-build selinux-policy-dev
-  deb_dependencies: |
-linux-headers-$(uname -r) build-essential fakeroot devscripts equivs
   AFXDP:   ${{ matrix.afxdp }}
   ASAN:${{ matrix.asan }}
   UBSAN:   ${{ matrix.ubsan }}
   CC:  ${{ matrix.compiler }}
-  DEB_PACKAGE: ${{ matrix.deb_package }}
   DPDK:${{ matrix.dpdk }}
   DPDK_SHARED: ${{ matrix.dpdk_shared }}
   KERNEL:  ${{ matrix.kernel }}
@@ -148,11 +145,7 @@ jobs:
 - name: update APT cache
   run:  sudo apt update || true
 - name: install common dependencies
-  if:   matrix.deb_package == ''
   run:  sudo apt install -y ${{ env.dependencies }}
-- name: install dependencies for debian packages
-  if:   matrix.deb_package != ''
-  run:  sudo apt install -y ${{ env.deb_dependencies }}
 - name: install libunbound libunwind
   if:   matrix.m32 == ''
   run:  sudo apt install -y libunbound-dev libunwind-dev
@@ -163,13 +156,6 @@ jobs:
 - name: build
   run:  ./.ci/linux-build.sh
 
-- name: upload deb packages
-  if:   matrix.deb_package != ''
-  uses: actions/upload-artifact@v2
-  with:
-name: deb-packages
-path: '/home/runner/work/ovs/*.deb'
-
 - name: copy logs on failure
   if: failure() || cancelled()
   run: |
@@ -224,3 +210,39 @@ jobs:
   with:
 name: logs-osx-clang---disable-ssl
 path: config.log
+
+  build-linux-deb:
+env:
+  deb_dependencies: |
+linux-headers-$(uname -r) build-essential fakeroot devscripts equivs
+  DEB_PACKAGE: yes
+
+name: linux deb
+runs-on: ubuntu-22.04
+timeout-minutes: 30
+
+steps:
+- name: checkout
+  uses: actions/checkout@v2
+
+- name: update PATH
+  run:  |
+echo "$HOME/bin">> $GITHUB_PATH
+echo "$HOME/.local/bin" >> $GITHUB_PATH
+
+- name: update APT cache
+  run:  sudo apt update || true
+- name: install dependencies for debian packages
+  run:  sudo apt install -y ${{ env.deb_dependencies }}
+
+- name: prepare
+  run:  ./.ci/linux-prepare.sh
+
+- name: build
+  run:  ./.ci/linux-build.sh
+
+- name: upload deb packages
+  uses: actions/upload-artifact@v2
+  with:
+name: deb-packages
+path: '/home/runner/work/ovs/*.deb'
-- 
2.36.1

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

[ovs-dev] [PATCH v4 1/9] debian: Archive debian packaging source.

[Frode Nordahl]

The packaging source in the OVS repository has drifted away from
what is currently in Debian and Ubuntu.  This state is problematic
because from time to time someone tries to build packages from the
upstream OVS debian package source and then expect that package to
work with up-/down-grades from-/to/ distro versions.

To support the on-going work to remove the out of tree OVS kernel
driver from the repository [0], an update to the debian packaging
is also required.  On the back of the discussion in [0] we agreed
that replacing the current version with what Debian and Ubuntu
is currently converging on would be preferable.

This commit is a first in a series to update the upstream OVS
debian packaging source to be up to date with what is currently
in Debian and Ubuntu.

0: https://mail.openvswitch.org/pipermail/ovs-dev/2022-June/394634.html

Signed-off-by: Frode Nordahl 
---
 .github/workflows/build-and-test.yml  |   3 -
 debian/.gitignore |  27 -
 debian/automake.mk|  82 +-
 debian/compat |   1 -
 debian/control| 266 ---
 debian/control.modules.in |  20 -
 debian/copyright.in   | 711 --
 debian/dirs   |   2 -
 debian/dkms.conf.in   |  11 -
 debian/ifupdown.sh| 107 ---
 debian/libopenvswitch-dev.install |  19 -
 debian/libopenvswitch.install |   5 -
 debian/openvswitch-common.dirs|   1 -
 debian/openvswitch-common.docs|   0
 debian/openvswitch-common.install |  11 -
 debian/openvswitch-common.manpages|   7 -
 debian/openvswitch-datapath-dkms.postinst |  21 -
 debian/openvswitch-datapath-dkms.prerm|  15 -
 ...atapath-module-_KVERS_.postinst.modules.in |  27 -
 .../openvswitch-datapath-source.README.Debian |  31 -
 debian/openvswitch-datapath-source.copyright  |  15 -
 debian/openvswitch-datapath-source.dirs   |   1 -
 debian/openvswitch-datapath-source.install|   5 -
 debian/openvswitch-ipsec.dirs |   1 -
 debian/openvswitch-ipsec.init | 181 -
 debian/openvswitch-ipsec.install  |   1 -
 debian/openvswitch-pki.dirs   |   1 -
 debian/openvswitch-pki.postinst   |  41 -
 debian/openvswitch-pki.postrm |  43 --
 debian/openvswitch-switch.README.Debian   | 316 
 debian/openvswitch-switch.dirs|   2 -
 debian/openvswitch-switch.init| 147 
 debian/openvswitch-switch.install |  18 -
 debian/openvswitch-switch.links   |   2 -
 debian/openvswitch-switch.logrotate   |  16 -
 debian/openvswitch-switch.manpages|  13 -
 debian/openvswitch-switch.postinst|  60 --
 debian/openvswitch-switch.postrm  |  48 --
 debian/openvswitch-switch.template|   8 -
 debian/openvswitch-test.dirs  |   1 -
 debian/openvswitch-test.install   |   3 -
 debian/openvswitch-test.manpages  |   1 -
 .../openvswitch-testcontroller.README.Debian  |  12 -
 debian/openvswitch-testcontroller.default |  29 -
 debian/openvswitch-testcontroller.dirs|   1 -
 debian/openvswitch-testcontroller.init| 278 ---
 debian/openvswitch-testcontroller.install |   1 -
 debian/openvswitch-testcontroller.manpages|   1 -
 debian/openvswitch-testcontroller.postinst|  52 --
 debian/openvswitch-testcontroller.postrm  |  44 --
 debian/openvswitch-vtep.default   |   4 -
 debian/openvswitch-vtep.dirs  |   1 -
 debian/openvswitch-vtep.init  |  78 --
 debian/openvswitch-vtep.install   |   3 -
 debian/openvswitch-vtep.manpages  |   1 -
 debian/python3-openvswitch.dirs   |   2 -
 debian/python3-openvswitch.install|   1 -
 debian/rules  |  94 ---
 debian/rules.modules  |  39 -
 debian/source/format  |   1 -
 60 files changed, 1 insertion(+), 2932 deletions(-)
 delete mode 100644 debian/.gitignore
 delete mode 100644 debian/compat
 delete mode 100644 debian/control
 delete mode 100644 debian/control.modules.in
 delete mode 100644 debian/copyright.in
 delete mode 100644 debian/dirs
 delete mode 100644 debian/dkms.conf.in
 delete mode 100755 debian/ifupdown.sh
 delete mode 100644 debian/libopenvswitch-dev.install
 delete mode 100644 debian/libopenvswitch.install
 delete mode 100644 debian/openvswitch-common.dirs
 delete mode 100644 debian/openvswitch-common.docs
 delete mode 100644 debian/openvswitch-common.install
 delete mode 100644 debian/openvswitch-common.manpages
 delete mode 100644 debian/openvswitch-datapath-dkms.postinst
 delete mode 100644 debian/

[ovs-dev] [PATCH v4 2/9] checkpatch: Ignore line length and leading whitespace for debian/*.

[Frode Nordahl]

Signed-off-by: Frode Nordahl 
---
 utilities/checkpatch.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/utilities/checkpatch.py b/utilities/checkpatch.py
index 8c02ac3ce..de2420e1f 100755
--- a/utilities/checkpatch.py
+++ b/utilities/checkpatch.py
@@ -194,12 +194,12 @@ skip_signoff_check = False
 #
 # Python isn't checked as flake8 performs these checks during build.
 line_length_ignore_list = re.compile(
-r'\.(am|at|etc|in|m4|mk|patch|py)$|debian/rules')
+r'\.(am|at|etc|in|m4|mk|patch|py)$|^debian/.*$')
 
 # Don't enforce a requirement that leading whitespace be all spaces on
 # files that include these characters in their name, since these kinds
 # of files need lines with leading tabs.
-leading_whitespace_ignore_list = re.compile(r'\.(mk|am|at)$|debian/rules')
+leading_whitespace_ignore_list = re.compile(r'\.(mk|am|at)$|^debian/.*$')
 
 
 def is_subtracted_line(line):
-- 
2.36.1

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

Re: [ovs-dev] [PATCH v3 3/8] debian: Update packaging source from Debian/Ubuntu.

[Frode Nordahl]

On Thu, Jul 14, 2022 at 12:17 PM Ilya Maximets  wrote:
>
> On 7/14/22 08:19, Frode Nordahl wrote:
> > On Tue, Jul 12, 2022 at 12:59 AM Ilya Maximets  wrote:
> >>
> >> On 7/11/22 20:12, Ilya Maximets wrote:
> >>> On 7/7/22 19:42, Frode Nordahl wrote:
>  diff --git a/debian/control b/debian/control
>  new file mode 100644
>  index 0..7a79d1ff0
>  --- /dev/null
>  +++ b/debian/control
>  @@ -0,0 +1,298 @@
>  +Source: openvswitch
>  +Section: net
>  +Priority: optional
>  +Maintainer: Open vSwitch developers 
>  +Uploaders:
>  + Simon Horman ,
>  + Thomas Goirand ,
>  + Michal Arbet ,
>  + Luca Boccassi ,
>  + Christian Ehrhardt ,
>  +Build-Depends:
>  + autoconf (>= 2.64),
>  + automake (>= 1.10),
>  + bzip2,
>  + debhelper-compat (= 13),
>  + dh-exec,
>  + dh-python,
>  + dh-sequence-python3,
>  + dh-sequence-sphinxdoc,
>  + graphviz,
>  + iproute2,
>  + libcap-ng-dev,
>  + libdbus-1-dev [amd64 i386 ppc64el arm64],
>  + libdpdk-dev (>= 21.11) [amd64 i386 ppc64el arm64],
> >>>
> >>> The DPDK dependency is one of the most worrying one, since
> >>> it significantly limits the number of systems this package
> >>> can be built for.  For example, we can't build the package
> >>> for Ubuntu older than 22.04, IIUC.   There is also no
> >>> straightforward way to build DPDK package from sources, so
> >>> it will be tricky to fulfill that dependency if not available.
> >>>
> >>> Can it be made optional somehow?  Or maybe some environment
> >>> variable to disable build of openvswitch-switch-dpdk package?
> >>>
> >>> I guess, some 'ifneq' can be added to debian/rules to not
> >>> configure with DPDK, e.g. 'nodpdk' for DEB_BUILD_OPTIONS.
> >>> But I'm not sure if the same can be done for debian/control
> >>> and list of packages and dependencies.
> >
> > debian/rules is indeed flexible and you're right about debian/control
> > being more static. Generating it along the lines of what you proposed
> > below could work.
> >
> >>> It's also interesting in terms of migrating to new versions
> >>> of DPDK.  For example, will there be an Ubuntu image with
> >>> DPDK 22.11 available when it is released?  We will need it
> >>> for GHA when OVS will upgrade to a new version of DPDK.
> >
> > We tend to track DPDK also in the interim Ubuntu releases, for example
> > DPDK 20.11 was made available in the development branch of Ubuntu
> > 21.04 at the end of 2020/beginning of 2021. OVS picked up DPDK 20.11
> > around May 2021 [1], which also would be after the official release.
> >
> > We can of course not guarantee that it will always be available by the
> > time OVS wants to update, but so far we appear to be in a good shape.
> > When doing the initial breakout of the "linux deb" job [2] I made use
> > of available GHA images, the interim releases will of course not be
> > available there. What we could do instead is to run the test within a
> > LXD container on GHA, as those images are published even before the
> > official release, this would also allow us to expand the matrix to
> > cover building on Debian if we want to. I would like to defer this to
> > a future change if that is alright with you, what do you think?
>
> Yes, I agree.  We don't need to decide on that right now, we have
> to to deal with it before the next DPDK upgrade.  I also used
> the 'container:' configuration of GHA before for preparing a job
> that builds fedora rpms, it works fine (I have a patch somewhere,
> but I never actually sent it).
>
> >
> > 0: https://launchpad.net/ubuntu/+source/dpdk/20.11-1
> > 1: 
> > https://github.com/openvswitch/ovs/commit/b45958bf75db121a05cb8aa07825f23a771130b9
> > 2: 
> > http://patchwork.ozlabs.org/project/openvswitch/patch/20220707174223.923183-4-frode.nord...@canonical.com/
> >
> >
> >> I have some stupid solution for this problem below.  Not a full
> >> solution, as we will likely not be able to build with DPDK in
> >> CI once new version of DPDK is out and OVS updated to use it.
> >> But the change gives user a choice to build with DPDK or without
> >> by simply forcing them to choose the variant of a control file.
> >> So, we'll be able to just disable one of the targets in a matrix
> >> if needed.
> >>
> >> With that applied I was able to successfully build packages
> >> on my Ubuntu 20.04 machine.  I had to lower the compat version
> >> down to 10, and we don't seem to use any functionality from
> >> higher versions.  I understand why distributions want to have
> >> a specific version, but for upstream it makes sense to relax the
> >> requirement a little bit.  This way we can support building on
> >> older versions of Ubuntu, for example.
> >>
> >> While playing with that I also fixed broken dh_clean target
> >> (missing '/' for directories), and re-introduced updated
> >> .gitignore file that we still need.
> >>
> >> One step forward might be to wrap everything into a 'make'
> >> target

Re: [ovs-dev] [RFC ovn] controller: send GARPs for LSPs in vlan-backed network scenario

[Numan Siddique]

On Thu, Jul 14, 2022 at 3:36 AM Lorenzo Bianconi
 wrote:
>
> > On 7/13/22 18:07, Lorenzo Bianconi wrote:
> > >> On 6/17/22 00:31, Lorenzo Bianconi wrote:
> > >>> When using VLAN backed networks and OVN routers leveraging the
> > >>> 'ovn-chassis-mac-mappings' option, the eth.src field is replaced by the
> > >>> chassis mac address in order to not expose the router mac address from
> > >>> different nodes and confuse the TOR switch. However doing so the TOR
> > >>> switch is not able to learn the port/mac bindings for routed E/W traffic
> > >>> and it is force to always flood it. Fix this issue adding the capability
> > >>> to send GARP traffic for logical switch ports if the corresponding 
> > >>> logical
> > >>> switch has the ovn-lsp-garp parameter set to true in the option column.
> > >>> More into about the issue can be found here [0].
> > >>>
> > >>> [0] 
> > >>> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-September/050678.html
> > >>> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2087779
> > >>>
> > >>> Signed-off-by: Lorenzo Bianconi 
> > >>> ---
> > >>
> > >> Hi Lorenzo,
> > >
> > > Hi Dumitru,
> > >
> > > Thanks for reviewing it :)
> > >
> > >>
> > >> I have a few concerns with this approach:
> > >>
> > >> a. The CMS will have to set this option for all VMs on all logical
> > >> switches which will enable periodic GARPs for all of them all the time.
> > >> That seems like quite a lot of broadcast traffic in the fabric.
> > >>
> > >> b. There's no guarantee that the GARPs are sent in time to prevent the
> > >> FDB timeouts on the ToR switches.  At best we could make the interval
> > >> configurable but I don't think this is way better either.
> > >>
> > >> c. This is not really introduced by your patch but we will be causing
> > >> this more often now.  With the topology:
> > >>
> > >> (HV1) VM1 -- LS1 --- LR -- LS2 -- VM2 (HV2)
> > >> (VLAN-backed network)
> > >>
> > >> HV1 configured with chassis mac mapping HV1-MAC
> > >> HV2 configured with chassis mac mapping HV2-MAC
> > >>
> > >> We're leaking MAC addresses from LS1's broadcast domain (VM1-MAC) and
> > >> from LS2's broadcast domain (VM2-MAC) into the fabric.  I'm not sure
> > >> that's OK.

I'm not sure I understood what you mean here.
Let's say we have 2 VMs - VM1 and VM3 connected to the same VLAN
logical switch LS1
and if VM1 is on chassis HV1 and VM3 is on chassis HV3,  the fabric
will learn VM1's and VM3's mac
when they both communicate right ?   Please note that logical switch
LS1 is a vlan tenant network with
a localnet port (so no geneve tunnels are used for the traffic from VM1 to VM3).


> > >>
> > >> I think a proper solution is to change how we run the logical pipelines
> > >> in case of vlan-backed networks.  We currently have an assymetry:
> > >>
> > >> For packets flowing from VM1 to VM2 we execute:
> > >> - on HV1: LS1-ingress, LS1-egress, LR-ingress, LR-egress, LS2-ingress
> > >> - on HV2: LS2-egress
> > >>
> > >> For packets flowing from VM2 to VM1 we execute:
> > >> - on HV2: LS2-ingress, LS2-egress, LR-ingress, LR-egress, LS1-ingress
> > >> - on HV1: LS1-egress
> > >>
> > >> What if we change this to:
> > >> VM1 -> VM2:
> > >> - on HV1: LS1-ingress, LS1-egress, LR-ingress
> > >> - on HV2: LR-egress, LS2-ingress, LS2-egress
> > >>
> > >> VM2 -> VM1:
> > >> - on HV2: LS2-ingress, LS2-egress, LR-ingress
> > >> - on HV2: LR-egress, LS1-ingress, LS1-egress
> > >

I'm not sure how easy it would be to run the pipeline as you suggested
when ovn-chassis-mac-mappings is configured.
However OVN does support centralized routing if a logical router has a
distributed gateway port (connecting to the provider network)
and the other logical router ports connecting to the tenant VLAN
networks have the option - reside-on-redirect-chassis configured.

So in a way CMS can use the centralized routing to avoid this issue.
However if we want to fix this issue for distributed routing,  looks
to me
the proposed RFC patch is the only way to fix it.  And with the proper
documentation CMS can know the benefits and drawbacks of both the
options.

Thanks
Numan


> > > I do not know why the current architecture is done this way (any 
> > > suggestions??).
> > > I guess the approach you suggested should work. Are we introducing any 
> > > backward
> > > compatibility issue?
> >
> > We would probably create a compatibility issue. :)
> >
> > I don't know if this approach would even work, I was just trying to
> > imagine how traffic from within OVN should be seen on the fabric in this
> > case.
> >
> > Maybe we need to think some more about other options.
>
> Thinking again about this approach we are implementing some kind of L2 
> natting,
> right? How can we implement dnat to swap HV2-MAC with proper destination
> mac address (let's say pod B)?
>
> Regards,
> Lorenzo
>
> >
> > Regards,
> > Dumitru
> >
> > >
> > > Regards,
> > > Lorenzo
> > >
> > >>
> > >> Would this we ensure that we always only use ovn-chassis-mac-mappi

Re: [ovs-dev] [PATCH v10 00/10] Actions Infrastructure + Optimizations

[Finn, Emma]

> -Original Message-
> From: Eelco Chaudron 
> Sent: Thursday 14 July 2022 15:37
> To: Van Haaren, Harry 
> Cc: Ilya Maximets ; Finn, Emma
> ; d...@openvswitch.org; Amber, Kumar
> ; Pai G, Sunil ; Stokes, Ian
> ; Flavio Leitner 
> Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
> 
> 
> 
> On 14 Jul 2022, at 16:22, Van Haaren, Harry wrote:
> 
> >> -Original Message-
> >> From: Ilya Maximets 
> >> Sent: Thursday, July 14, 2022 3:10 PM
> >> To: Finn, Emma ; Eelco Chaudron
> >> ; Van Haaren, Harry
> 
> >> Cc: i.maxim...@ovn.org; d...@openvswitch.org; Amber, Kumar
> >> ; Pai G, Sunil ;
> >> Stokes, Ian ; Flavio Leitner 
> >> Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
> >>
> >> On 7/14/22 16:03, Finn, Emma wrote:
> >>>
> >>>
>  -Original Message-
>  From: Eelco Chaudron 
>  Sent: Thursday 14 July 2022 14:27
>  To: Van Haaren, Harry 
>  Cc: Finn, Emma ; d...@openvswitch.org;
>  i.maxim...@ovn.org; Amber, Kumar ; Pai
> G,
>  Sunil ; Stokes, Ian 
>  Subject: Re: [PATCH v10 00/10] Actions Infrastructure +
>  Optimizations
> 
> 
> 
>  On 14 Jul 2022, at 15:04, Van Haaren, Harry wrote:
> 
> >> -Original Message-
> >> From: Eelco Chaudron 
> >> Sent: Thursday, July 14, 2022 1:55 PM
> >> To: Van Haaren, Harry ; Finn, Emma
> >> 
> >> Cc: d...@openvswitch.org; i.maxim...@ovn.org; Amber, Kumar
> >> ; Pai G, Sunil ;
> >> Stokes, Ian 
> >> Subject: Re: [PATCH v10 00/10] Actions Infrastructure +
> >> Optimizations
> >
> > 
> >
> >>> V10;
> >>> - Fixed CI build issue on OSX around AVX512 linking (jenkins CI)
> >>> - Moved docs and reworded sections (thanks Ilya for feedback)
> >>> - Reworked one instance of <= OVS_ATTR_MAX back to original
> >>> form(Eelco)
> >>
> >> I’ve just finished my review purely based on visual inspection
> >> and compile success, and I will send out some minor comments
> >> after the break ;)
> >
> > Sure - please keep in mind that theres few working hours before
> > merge window ends, so unless absolutely critical to fix *before*
> > merge, we can
>  fixup things next week.
> >
> > To be very clear; if there a genuine issue, yes lets fix. Variable
> > renames, tidys etc, can all be handled starting from next week.
> >
> >> After that, I will do the actual functional testing on an AVX512
> >> machine and let you know the results. This will give you time to
> >> fix/discuss the comment while I’m testing.
> >
> > Looking forward!
> 
>  They should be in your inbox, most of them can be changed quickly,
>  just sent out the v11 once done, as I need time to test this anyway
>  before I can give my final ACKs.
> 
>  My plan is to test v10 (or v11 if it’s there) tomorrow.
> 
>  //Eelco
> >>>
> >>> Thanks for the comments Eelco. As Harry mentioned above, next
> >>> revision will only
> >> include critical fixes. Comment tidy ups and variable renaming will
> >> be left out until next week.
> >>>
> >>> Things I will fix for next revision:
> >>>   01/10 - Atomic store refactor.
> >>>   07/10 - Refactor of avx init/probe functions.
> >>>   09/10 - Swap OVS_ACTION_ATTR_MAX tobe first in check.
> >>>
> >>> Comments that will be addressed next week:
> >>>   01/10 - comment clean up
> >>>   02/10 - comment clean up
> >>>   04/10 - 2x  remove the trailing \n
> >>>   - Move unit test to odp.at
> >>>   05/10 - comment clean up
> >>>   06/10 - comment clean up
> >>>   09/10 - indentation if off
> >>>   10/10 - renaming variable/functions
> >>
> >> These are fairly trivial, can we fix them as well, please?
> >> Submission next weak will mean backports of these cosmetic changes or
> >> conflicts with later backports of bug fixes.
> >
> > I'll leave this to Emma to decide.
> 
> I agree with Ilya here, we should get all of this in one patch, should not be
> too much work. And it safes a lot afterwards…
> 

Sure, I will address all comments for next revisions. 



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

Re: [ovs-dev] [PATCH v10 00/10] Actions Infrastructure + Optimizations

[Eelco Chaudron]

On 14 Jul 2022, at 16:22, Van Haaren, Harry wrote:

>> -Original Message-
>> From: Ilya Maximets 
>> Sent: Thursday, July 14, 2022 3:10 PM
>> To: Finn, Emma ; Eelco Chaudron
>> ; Van Haaren, Harry 
>> Cc: i.maxim...@ovn.org; d...@openvswitch.org; Amber, Kumar
>> ; Pai G, Sunil ; Stokes, Ian
>> ; Flavio Leitner 
>> Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
>>
>> On 7/14/22 16:03, Finn, Emma wrote:
>>>
>>>
 -Original Message-
 From: Eelco Chaudron 
 Sent: Thursday 14 July 2022 14:27
 To: Van Haaren, Harry 
 Cc: Finn, Emma ; d...@openvswitch.org;
 i.maxim...@ovn.org; Amber, Kumar ; Pai G, Sunil
 ; Stokes, Ian 
 Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations



 On 14 Jul 2022, at 15:04, Van Haaren, Harry wrote:

>> -Original Message-
>> From: Eelco Chaudron 
>> Sent: Thursday, July 14, 2022 1:55 PM
>> To: Van Haaren, Harry ; Finn, Emma
>> 
>> Cc: d...@openvswitch.org; i.maxim...@ovn.org; Amber, Kumar
>> ; Pai G, Sunil ;
>> Stokes, Ian 
>> Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
>
> 
>
>>> V10;
>>> - Fixed CI build issue on OSX around AVX512 linking (jenkins CI)
>>> - Moved docs and reworded sections (thanks Ilya for feedback)
>>> - Reworked one instance of <= OVS_ATTR_MAX back to original
>>> form(Eelco)
>>
>> I’ve just finished my review purely based on visual inspection and
>> compile success, and I will send out some minor comments after the
>> break ;)
>
> Sure - please keep in mind that theres few working hours before merge
> window ends, so unless absolutely critical to fix *before* merge, we can
 fixup things next week.
>
> To be very clear; if there a genuine issue, yes lets fix. Variable
> renames, tidys etc, can all be handled starting from next week.
>
>> After that, I will do the actual functional testing on an AVX512
>> machine and let you know the results. This will give you time to
>> fix/discuss the comment while I’m testing.
>
> Looking forward!

 They should be in your inbox, most of them can be changed quickly, just 
 sent
 out the v11 once done, as I need time to test this anyway before I can give
 my final ACKs.

 My plan is to test v10 (or v11 if it’s there) tomorrow.

 //Eelco
>>>
>>> Thanks for the comments Eelco. As Harry mentioned above, next revision will 
>>> only
>> include critical fixes. Comment tidy ups and variable renaming will be left 
>> out until
>> next week.
>>>
>>> Things I will fix for next revision:
>>> 01/10 - Atomic store refactor.
>>> 07/10 - Refactor of avx init/probe functions.
>>> 09/10 - Swap OVS_ACTION_ATTR_MAX tobe first in check.
>>>
>>> Comments that will be addressed next week:
>>> 01/10 - comment clean up
>>> 02/10 - comment clean up
>>> 04/10 - 2x  remove the trailing \n
>>> - Move unit test to odp.at
>>> 05/10 - comment clean up
>>> 06/10 - comment clean up
>>> 09/10 - indentation if off
>>> 10/10 - renaming variable/functions
>>
>> These are fairly trivial, can we fix them as well, please?
>> Submission next weak will mean backports of these cosmetic
>> changes or conflicts with later backports of bug fixes.
>
> I'll leave this to Emma to decide.

I agree with Ilya here, we should get all of this in one patch, should not be 
too much work. And it safes a lot afterwards…

>> Also, please reply to questions in patches 9/10 and 10/10
>> regarding the load of potentially non-existent memory, which
>> are remaining unanswered.  And there is also one performance
>> related question.
>
> Hah, I was literally typing up responses as your email arrived.
> Replies sent to both questions "at the speed I can type replies" 😊
>
> loading/k-masks: 
> https://mail.openvswitch.org/pipermail/ovs-dev/2022-July/396201.html
> performance: 
> https://mail.openvswitch.org/pipermail/ovs-dev/2022-July/396203.html
>
>> Best regards, Ilya Maximets.
>
> Regards, -Harry

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

Re: [ovs-dev] [PATCH v10 10/10] odp-execute: Add ISA implementation of set_masked IPv4 action

[Eelco Chaudron]

On 14 Jul 2022, at 16:18, Van Haaren, Harry wrote:

>> -Original Message-
>> From: Eelco Chaudron 
>> Sent: Thursday, July 14, 2022 2:25 PM
>> To: Van Haaren, Harry 
>> Cc: d...@openvswitch.org; i.maxim...@ovn.org; Amber, Kumar
>> ; Pai G, Sunil ; Finn, Emma
>> ; Stokes, Ian 
>> Subject: Re: [PATCH v10 10/10] odp-execute: Add ISA implementation of 
>> set_masked
>> IPv4 action
>>
>>> From: Emma Finn 
>>>
>>> This commit adds support for the AVX512 implementation of the
>>> ipv4_set_addrs action as well as an AVX512 implementation of
>>> updating the checksums.
>
> 
>
>>> +/* Update the IP checksum based on updated IP values. */
>>> +uint16_t delta = avx512_ipv4_update_csum(v_res, v_packet);
>>> +uint32_t new_csum = old_csum + delta;
>>> +delta = csum_finish(new_csum);
>>> +
>>> +/* Insert new checksum. */
>>> +v_res = _mm256_insert_epi16(v_res, delta, 5);
>>> +
>>> +/* If ip_src or ip_dst has been modified, L4 checksum needs to
>>> + * be updated too. */
>>> +if (mask->ipv4_src || mask->ipv4_dst) {
>>> +
>>> +uint16_t delta_checksum = avx512_l4_update_csum(v_packet, 
>>> v_res);
>>> +
>>
>> Wondering if all this AVX code being executed really is faster than 
>> recalc_csum32(uh-
>>> udp_csum, old_addr, new_addr)?
>
> Ultimately, measuring is worth more than talking about it. In our 
> measurements here,
> yes absolutely it is, our measurements are available in the cover letter of 
> the patchset.

I was not referring to the entire AVX implementation, but only the checksum 
update for the L4 portion.

> Note that the code here is compute-bound, its juggling values between 
> registers, and
> with XMM/YMM registers, SIMD IPC of 3 can be achieved. That means that in 
> theory,
> the SIMD code executes ~3 intrinsics *per cycle*, but in practice the IPC is 
> often *more*
> due to interleaved scalar code, and Out-of-Order execution capabilities of 
> the CPU.
>
> Although the code is verbose (lots of typing) the resulting instruction 
> stream is generally
> optimized very well by the compiler, and reduced to very small, dense and hot 
> loops.

So we might be fine here with the AVX overhead, was just curious here if we 
could further speed up.

> I recommend using "perf top" to investigate the hotspots, for those unaware 
> of tools
> and methods, a DPDK Userspace presentation covers exactly this using OVS 
> DPCLS as
> the examples code! https://youtu.be/ZmwOKR5JyPk

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

Re: [ovs-dev] [PATCH v10 09/10] odp-execute: Add ISA implementation of set_masked ETH

[Eelco Chaudron]

On 14 Jul 2022, at 16:11, Van Haaren, Harry wrote:

>> -Original Message-
>> From: Eelco Chaudron 
>> Sent: Thursday, July 14, 2022 2:24 PM
>> To: Van Haaren, Harry 
>> Cc: d...@openvswitch.org; i.maxim...@ovn.org; Amber, Kumar
>> ; Pai G, Sunil ; Finn, Emma
>> ; Stokes, Ian 
>> Subject: Re: [PATCH v10 09/10] odp-execute: Add ISA implementation of 
>> set_masked
>> ETH
>
> 
>
>>> +/* Read the content of the key(src) and mask in the respective 
>>> registers.
>>> + * We only load the src and dest addresses, which is only 96-bits and 
>>> not
>>> + * 128-bits. */
>>> +__m128i v_src = _mm_maskz_loadu_epi32(0x7,(void *) key);
>>> +__m128i v_mask = _mm_maskz_loadu_epi32(0x7, (void *) mask);
>>
>> One question here I asked throughout the various revisions but got not 
>> answered:
>>
>> "The second load, loads 128 bits of data, but there are only 12 bytes to 
>> load. What
>> happens if the memory at the remaining 6 bytes are not mapped in memory 
>> (i.e. a
>> page does not exist/can't be loaded)? Will we crash!?
>
> AVX512 has some very nice features for handling scenarios where "not full" 
> SIMD is
> required. This feature is known as "k-masks", and in short allows "turning 
> off" part of
> the SIMD instruction from having an effect.
>
> In this case, the "maskz" part of the intrinsic means that the k-mask becomes 
> active.
> An extra parameter is added to any k-mask instruction (_mm_maskz_*), which 
> indicates
> what lanes to enable/disable. Note that the *size* of each lane is determined 
> by the
> end of the intrinsic, so _epi32() indicates 32-bit lanes. A worked example 
> below:
>
> _mm_maskz_loadu_epi32(0x7, (void *) mask);
>
> kmask is 0x7, or "111" in binary, so lowest 3 lanes (visualize them on the 
> right) are active.
> As the instruction targets 32-bit ints, each lane size is 4 bytes, so 3 * 4 = 
> 12 bytes "active".
> As a result, only 12 bytes are loaded from memory here. Even if the next byte 
> was on a new
> page, and not mapped into our virtual address range, there would be no crash 
> here due to
> the k-mask handling the load.
>
> 

Thanks, that really answers my question! I guess I should better read the 
pseudo code on the intrinsics guide :)

//Eelco

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

Re: [ovs-dev] [PATCH] netdev-linux: Fix leak of a tc police get/del reply.

[Ilya Maximets]

On 7/14/22 16:24, Simon Horman wrote:
> On Thu, Jul 14, 2022 at 03:22:24PM +0200, Ilya Maximets wrote:
>> On 7/14/22 15:05, Simon Horman wrote:
>>> On Thu, Jul 14, 2022 at 11:44:53AM +0200, Ilya Maximets wrote:
 On 7/14/22 07:33, Simon Horman wrote:
> On Wed, Jul 13, 2022 at 04:30:41PM +0200, Ilya Maximets wrote:
>>  Direct leak of 64 byte(s) in 1 object(s) allocated from:
>>0 0x51b1d8 in malloc (vswitchd/ovs-vswitchd+0x51b1d8)
>>1 0xc81ded in xmalloc__ lib/util.c:137:15
>>2 0xc81ded in xmalloc lib/util.c:172:12
>>3 0xb32153 in ofpbuf_new lib/ofpbuf.c:168:24
>>4 0xd563e4 in nl_sock_transact lib/netlink-socket.c:1113:34
>>5 0xd56261 in nl_transact lib/netlink-socket.c:1812:13
>>6 0xd5e096 in tc_transact lib/tc.c:238:17
>>7 0xd01622 in tc_del_policer_action lib/netdev-linux.c:5807:13
>>8 0xd2e681 in meter_tc_del_policer lib/netdev-offload-tc.c:2827:15
>>9 0x94ec21 in meter_offload_del lib/netdev-offload.c:245:23
>>   10 0xcc86c4 in dpif_netlink_meter_del lib/dpif-netlink.c:4288:9
>>   11 0x86c595 in dpif_meter_del lib/dpif.c:2014:13
>>   12 0x663439 in free_meter_id ofproto/ofproto-dpif.c:6789:5
>>   13 0xb47518 in ovsrcu_call_postponed lib/ovs-rcu.c:346:13
>>   14 0xb48031 in ovsrcu_postpone_thread lib/ovs-rcu.c:362:14
>>   15 0xb5015a in ovsthread_wrapper lib/ovs-thread.c:422:12
>>   16 0x7f86af4081ce in start_thread (/lib64/libpthread.so.0+0x81ce)
>>
>> Fixes: 5c039ddc64ff ("netdev-linux: Add functions to manipulate tc 
>> police action")
>> Signed-off-by: Ilya Maximets 
>
> Acked-by: Simon Horman 
>
> I'd also be happy to apply this patch if that was your intention.

 Feel free to apply these 3 fixes, if you have time.  Thanks!
 The one about misaligned access in pedit action will also need
 a backport to stable branches.

 Best regards, Ilya Maximets.
>>>
>>> Thanks, all patches applied to master.
>>>
>>> The pedit action fix was also applied back to branch-2.13.
>>> Let me know if you'd like me to backport it further back.
>>
>> Thanks!  We don't need to backport further as we don't support
>> older branches.   And the fix is not critical anyway.
> 
> Thanks, got it.
> 
>> But it seems you missed the branch-2.14.  Could you, please, recheck?
> 
> Oops, sorry about that.
> It was not intentional.
> And I have pushed it now.

No problem.  Thanks for taking care of them!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] Fix spelling error exposed in binaries.

[Frode Nordahl]

On Thu, Jul 14, 2022 at 4:20 PM Ilya Maximets  wrote:
>
> On 7/8/22 08:53, Frode Nordahl wrote:
> > As reported by Debian lintinan.
> >
> > Signed-off-by: Frode Nordahl 
> > ---
> >  lib/daemon-unix.c| 4 ++--
> >  lib/ovsdb-idl.c  | 2 +-
> >  lib/perf-counter.c   | 2 +-
> >  ofproto/ofproto-dpif-sflow.c | 2 +-
> >  4 files changed, 5 insertions(+), 5 deletions(-)
>
> s/lintinan/lintian/ :)

Some level of poetic justice to that :)

> Applied, thanks!

Thank you!

-- 
Frode Nordahl

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

Re: [ovs-dev] [PATCH] netdev-linux: Fix leak of a tc police get/del reply.

[Simon Horman]

On Thu, Jul 14, 2022 at 03:22:24PM +0200, Ilya Maximets wrote:
> On 7/14/22 15:05, Simon Horman wrote:
> > On Thu, Jul 14, 2022 at 11:44:53AM +0200, Ilya Maximets wrote:
> >> On 7/14/22 07:33, Simon Horman wrote:
> >>> On Wed, Jul 13, 2022 at 04:30:41PM +0200, Ilya Maximets wrote:
>   Direct leak of 64 byte(s) in 1 object(s) allocated from:
> 0 0x51b1d8 in malloc (vswitchd/ovs-vswitchd+0x51b1d8)
> 1 0xc81ded in xmalloc__ lib/util.c:137:15
> 2 0xc81ded in xmalloc lib/util.c:172:12
> 3 0xb32153 in ofpbuf_new lib/ofpbuf.c:168:24
> 4 0xd563e4 in nl_sock_transact lib/netlink-socket.c:1113:34
> 5 0xd56261 in nl_transact lib/netlink-socket.c:1812:13
> 6 0xd5e096 in tc_transact lib/tc.c:238:17
> 7 0xd01622 in tc_del_policer_action lib/netdev-linux.c:5807:13
> 8 0xd2e681 in meter_tc_del_policer lib/netdev-offload-tc.c:2827:15
> 9 0x94ec21 in meter_offload_del lib/netdev-offload.c:245:23
>    10 0xcc86c4 in dpif_netlink_meter_del lib/dpif-netlink.c:4288:9
>    11 0x86c595 in dpif_meter_del lib/dpif.c:2014:13
>    12 0x663439 in free_meter_id ofproto/ofproto-dpif.c:6789:5
>    13 0xb47518 in ovsrcu_call_postponed lib/ovs-rcu.c:346:13
>    14 0xb48031 in ovsrcu_postpone_thread lib/ovs-rcu.c:362:14
>    15 0xb5015a in ovsthread_wrapper lib/ovs-thread.c:422:12
>    16 0x7f86af4081ce in start_thread (/lib64/libpthread.so.0+0x81ce)
> 
>  Fixes: 5c039ddc64ff ("netdev-linux: Add functions to manipulate tc 
>  police action")
>  Signed-off-by: Ilya Maximets 
> >>>
> >>> Acked-by: Simon Horman 
> >>>
> >>> I'd also be happy to apply this patch if that was your intention.
> >>
> >> Feel free to apply these 3 fixes, if you have time.  Thanks!
> >> The one about misaligned access in pedit action will also need
> >> a backport to stable branches.
> >>
> >> Best regards, Ilya Maximets.
> > 
> > Thanks, all patches applied to master.
> > 
> > The pedit action fix was also applied back to branch-2.13.
> > Let me know if you'd like me to backport it further back.
> 
> Thanks!  We don't need to backport further as we don't support
> older branches.   And the fix is not critical anyway.

Thanks, got it.

> But it seems you missed the branch-2.14.  Could you, please, recheck?

Oops, sorry about that.
It was not intentional.
And I have pushed it now.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] Please help add me to AUTHORS

[Ilya Maximets]

On 6/2/22 17:14, Alin-Gabriel Serdean wrote:
> Hi,
> 
> Do you mind sending a patch to the ML adding yourself to the AUTHORS.rst
> 
> I can apply it later on.
> 
> Thank you,
> Alin.
> 
> -Original Message-
> From: dev  On Behalf Of jinjun gao
> Sent: Thursday, June 2, 2022 5:38 PM
> To: d...@openvswitch.org
> Subject: [ovs-dev] Please help add me to AUTHORS
> 
> Hi guys,
> I'm a contributor in datapath-windows part with jinj...@vmware.com. Can you
> please help add me to the AUTHORS? Thanks!

There is no real reason to submit a separate patch, so
I just added an entry myself.  No problem.  Thanks for
your contributions!

Best regards, Ilya Maximets.

> 
> Name: Jinjun Gao
> Mail: gjin...@gmail.com
> --
> Best Regards,
> Jinjun Gao
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v10 00/10] Actions Infrastructure + Optimizations

[Van Haaren, Harry]

> -Original Message-
> From: Ilya Maximets 
> Sent: Thursday, July 14, 2022 3:10 PM
> To: Finn, Emma ; Eelco Chaudron
> ; Van Haaren, Harry 
> Cc: i.maxim...@ovn.org; d...@openvswitch.org; Amber, Kumar
> ; Pai G, Sunil ; Stokes, Ian
> ; Flavio Leitner 
> Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
> 
> On 7/14/22 16:03, Finn, Emma wrote:
> >
> >
> >> -Original Message-
> >> From: Eelco Chaudron 
> >> Sent: Thursday 14 July 2022 14:27
> >> To: Van Haaren, Harry 
> >> Cc: Finn, Emma ; d...@openvswitch.org;
> >> i.maxim...@ovn.org; Amber, Kumar ; Pai G, Sunil
> >> ; Stokes, Ian 
> >> Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
> >>
> >>
> >>
> >> On 14 Jul 2022, at 15:04, Van Haaren, Harry wrote:
> >>
>  -Original Message-
>  From: Eelco Chaudron 
>  Sent: Thursday, July 14, 2022 1:55 PM
>  To: Van Haaren, Harry ; Finn, Emma
>  
>  Cc: d...@openvswitch.org; i.maxim...@ovn.org; Amber, Kumar
>  ; Pai G, Sunil ;
>  Stokes, Ian 
>  Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
> >>>
> >>> 
> >>>
> > V10;
> > - Fixed CI build issue on OSX around AVX512 linking (jenkins CI)
> > - Moved docs and reworded sections (thanks Ilya for feedback)
> > - Reworked one instance of <= OVS_ATTR_MAX back to original
> > form(Eelco)
> 
>  I’ve just finished my review purely based on visual inspection and
>  compile success, and I will send out some minor comments after the
>  break ;)
> >>>
> >>> Sure - please keep in mind that theres few working hours before merge
> >>> window ends, so unless absolutely critical to fix *before* merge, we can
> >> fixup things next week.
> >>>
> >>> To be very clear; if there a genuine issue, yes lets fix. Variable
> >>> renames, tidys etc, can all be handled starting from next week.
> >>>
>  After that, I will do the actual functional testing on an AVX512
>  machine and let you know the results. This will give you time to
>  fix/discuss the comment while I’m testing.
> >>>
> >>> Looking forward!
> >>
> >> They should be in your inbox, most of them can be changed quickly, just 
> >> sent
> >> out the v11 once done, as I need time to test this anyway before I can give
> >> my final ACKs.
> >>
> >> My plan is to test v10 (or v11 if it’s there) tomorrow.
> >>
> >> //Eelco
> >
> > Thanks for the comments Eelco. As Harry mentioned above, next revision will 
> > only
> include critical fixes. Comment tidy ups and variable renaming will be left 
> out until
> next week.
> >
> > Things I will fix for next revision:
> > 01/10 - Atomic store refactor.
> > 07/10 - Refactor of avx init/probe functions.
> > 09/10 - Swap OVS_ACTION_ATTR_MAX tobe first in check.
> >
> > Comments that will be addressed next week:
> > 01/10 - comment clean up
> > 02/10 - comment clean up
> > 04/10 - 2x  remove the trailing \n
> > - Move unit test to odp.at
> > 05/10 - comment clean up
> > 06/10 - comment clean up
> > 09/10 - indentation if off
> > 10/10 - renaming variable/functions
> 
> These are fairly trivial, can we fix them as well, please?
> Submission next weak will mean backports of these cosmetic
> changes or conflicts with later backports of bug fixes.

I'll leave this to Emma to decide.

> Also, please reply to questions in patches 9/10 and 10/10
> regarding the load of potentially non-existent memory, which
> are remaining unanswered.  And there is also one performance
> related question.

Hah, I was literally typing up responses as your email arrived.
Replies sent to both questions "at the speed I can type replies" 😊

loading/k-masks: 
https://mail.openvswitch.org/pipermail/ovs-dev/2022-July/396201.html
performance: 
https://mail.openvswitch.org/pipermail/ovs-dev/2022-July/396203.html

> Best regards, Ilya Maximets.

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

Re: [ovs-dev] [PATCH] ovsdb/TODO: Update the list of tasks.

[Ilya Maximets]

On 7/14/22 09:53, Dumitru Ceara wrote:
> On 7/13/22 21:50, Ilya Maximets wrote:
>> Some of the work is already done, e.g. 'diff' file format
>> and DNS support.
>>
>> Added more items collected over time including relay and
>> local_config items.
>>
>> Signed-off-by: Ilya Maximets 
>> ---
> 
> Looks good to me, thanks!
> 
> Acked-by: Dumitru Ceara 
> 

Applied, thanks!

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

Re: [ovs-dev] [PATCH] man: Fix various typos across manual pages

[Ilya Maximets]

On 7/8/22 08:53, Frode Nordahl wrote:
> As reported by Debian lintian.
> 
> Signed-off-by: Frode Nordahl 
> ---
>  lib/db-ctl-base.man  | 2 +-
>  lib/dpctl.man| 2 +-
>  ovsdb/ovsdb-tool.1.in| 6 +++---
>  utilities/ovs-ofctl.8.in | 6 +++---
>  utilities/ovs-vsctl.8.in | 2 +-
>  vswitchd/vswitch.xml | 4 ++--
>  6 files changed, 11 insertions(+), 11 deletions(-)

Applied, thanks!

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

Re: [ovs-dev] [PATCH] Fix spelling error exposed in binaries.

[Ilya Maximets]

On 7/8/22 08:53, Frode Nordahl wrote:
> As reported by Debian lintinan.
> 
> Signed-off-by: Frode Nordahl 
> ---
>  lib/daemon-unix.c| 4 ++--
>  lib/ovsdb-idl.c  | 2 +-
>  lib/perf-counter.c   | 2 +-
>  ofproto/ofproto-dpif-sflow.c | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)

s/lintinan/lintian/ :)

Applied, thanks!

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

Re: [ovs-dev] [PATCH v10 10/10] odp-execute: Add ISA implementation of set_masked IPv4 action

[Van Haaren, Harry]

> -Original Message-
> From: Eelco Chaudron 
> Sent: Thursday, July 14, 2022 2:25 PM
> To: Van Haaren, Harry 
> Cc: d...@openvswitch.org; i.maxim...@ovn.org; Amber, Kumar
> ; Pai G, Sunil ; Finn, Emma
> ; Stokes, Ian 
> Subject: Re: [PATCH v10 10/10] odp-execute: Add ISA implementation of 
> set_masked
> IPv4 action
> 
> > From: Emma Finn 
> >
> > This commit adds support for the AVX512 implementation of the
> > ipv4_set_addrs action as well as an AVX512 implementation of
> > updating the checksums.



> > +/* Update the IP checksum based on updated IP values. */
> > +uint16_t delta = avx512_ipv4_update_csum(v_res, v_packet);
> > +uint32_t new_csum = old_csum + delta;
> > +delta = csum_finish(new_csum);
> > +
> > +/* Insert new checksum. */
> > +v_res = _mm256_insert_epi16(v_res, delta, 5);
> > +
> > +/* If ip_src or ip_dst has been modified, L4 checksum needs to
> > + * be updated too. */
> > +if (mask->ipv4_src || mask->ipv4_dst) {
> > +
> > +uint16_t delta_checksum = avx512_l4_update_csum(v_packet, 
> > v_res);
> > +
> 
> Wondering if all this AVX code being executed really is faster than 
> recalc_csum32(uh-
> >udp_csum, old_addr, new_addr)?

Ultimately, measuring is worth more than talking about it. In our measurements 
here,
yes absolutely it is, our measurements are available in the cover letter of the 
patchset.

Note that the code here is compute-bound, its juggling values between 
registers, and
with XMM/YMM registers, SIMD IPC of 3 can be achieved. That means that in 
theory,
the SIMD code executes ~3 intrinsics *per cycle*, but in practice the IPC is 
often *more*
due to interleaved scalar code, and Out-of-Order execution capabilities of the 
CPU.

Although the code is verbose (lots of typing) the resulting instruction stream 
is generally
optimized very well by the compiler, and reduced to very small, dense and hot 
loops.

I recommend using "perf top" to investigate the hotspots, for those unaware of 
tools
and methods, a DPDK Userspace presentation covers exactly this using OVS DPCLS 
as
the examples code! https://youtu.be/ZmwOKR5JyPk

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

Re: [ovs-dev] [PATCH ovn 1/3] actions: introduce commit_ecmp_nh action

[Dumitru Ceara]

On 7/14/22 15:20, Lorenzo Bianconi wrote:
>> Hi Lorenzo, I have a few comments below.
>>
>> On 7/13/22 08:44, Lorenzo Bianconi wrote:
>>> commit_ecmp_nh action translates to an openflow "learn" action that
>>> inserts two new flows in the OFTABLE_ECMP_NH_MAC and OFTABLE_ECMP_NH
>>> tables. These new flows are used to match on the the 5-tuple and the
>>> expected next-hop mac address and set REGBIT_KNOWN_ECMP_NH.
>>> commit_ecmp_nh action will be used to improve ECMP symmetric routing
>>> reliability.
>>>
>>> Signed-off-by: Lorenzo Bianconi 
>>> ---
>>>   controller/lflow.h   |   2 +
>>>   include/ovn/actions.h|   7 ++
>>>   include/ovn/logical-fields.h |   3 +
>>>   lib/actions.c| 176 +++
>>>   ovn-sb.xml   |  34 +++
>>>   utilities/ovn-trace.c|   2 +
>>>   6 files changed, 224 insertions(+)
>>>
>>> diff --git a/controller/lflow.h b/controller/lflow.h
>>> index 342967917..543d3cd96 100644
>>> --- a/controller/lflow.h
>>> +++ b/controller/lflow.h
>>> @@ -79,6 +79,8 @@ struct uuid;
>>>   #define OFTABLE_CHK_IN_PORT_SEC  73
>>>   #define OFTABLE_CHK_IN_PORT_SEC_ND   74
>>>   #define OFTABLE_CHK_OUT_PORT_SEC 75
>>> +#define OFTABLE_ECMP_NH_MAC  76
>>> +#define OFTABLE_ECMP_NH  77
>>>   enum ref_type {
>>>   REF_TYPE_ADDRSET,
>>> diff --git a/include/ovn/actions.h b/include/ovn/actions.h
>>> index 33c319f1c..cef930e1a 100644
>>> --- a/include/ovn/actions.h
>>> +++ b/include/ovn/actions.h
>>> @@ -118,6 +118,7 @@ struct ovn_extend_table;
>>>   OVNACT(LOOKUP_FDB,ovnact_lookup_fdb)  \
>>>   OVNACT(CHECK_IN_PORT_SEC,  ovnact_result) \
>>>   OVNACT(CHECK_OUT_PORT_SEC, ovnact_result) \
>>> +OVNACT(COMMIT_ECMP_NH,ovnact_commit_ecmp_nh)  \
>>>   /* enum ovnact_type, with a member OVNACT_ for each action. */
>>>   enum OVS_PACKED_ENUM ovnact_type {
>>> @@ -453,6 +454,12 @@ struct ovnact_lookup_fdb {
>>>   struct expr_field dst; /* 1-bit destination field. */
>>>   };
>>> +/* OVNACT_COMMIT_ECMP_NH. */
>>> +struct ovnact_commit_ecmp_nh {
>>> +struct ovnact ovnact;
>>> +bool ipv6;
>>> +};
>>> +
>>>   /* Internal use by the helpers below. */
>>>   void ovnact_init(struct ovnact *, enum ovnact_type, size_t len);
>>>   void *ovnact_put(struct ofpbuf *, enum ovnact_type, size_t len);
>>> diff --git a/include/ovn/logical-fields.h b/include/ovn/logical-fields.h
>>> index bfb07ebef..3db7265e4 100644
>>> --- a/include/ovn/logical-fields.h
>>> +++ b/include/ovn/logical-fields.h
>>> @@ -70,6 +70,7 @@ enum mff_log_flags_bits {
>>>   MLF_LOCALPORT_BIT = 10,
>>>   MLF_USE_SNAT_ZONE = 11,
>>>   MLF_CHECK_PORT_SEC_BIT = 12,
>>> +MLF_LOOKUP_COMMIT_ECMP_NH_BIT = 13,
>>>   };
>>>   /* MFF_LOG_FLAGS_REG flag assignments */
>>> @@ -113,6 +114,8 @@ enum mff_log_flags {
>>>   /* Indicate the packet has been received from a localport */
>>>   MLF_LOCALPORT = (1 << MLF_LOCALPORT_BIT),
>>> +
>>> +MLF_LOOKUP_COMMIT_ECMP_NH = (1 << MLF_LOOKUP_COMMIT_ECMP_NH_BIT),
>>>   };
>>>   /* OVN logical fields
>>> diff --git a/lib/actions.c b/lib/actions.c
>>> index aab044306..132c63228 100644
>>> --- a/lib/actions.c
>>> +++ b/lib/actions.c
>>> @@ -41,6 +41,7 @@
>>>   #include "uuid.h"
>>>   #include "socket-util.h"
>>>   #include "lib/ovn-util.h"
>>> +#include "controller/lflow.h"
>>>   VLOG_DEFINE_THIS_MODULE(actions);
>>>   
>>> @@ -4278,6 +4279,179 @@ encode_CHECK_OUT_PORT_SEC(const struct 
>>> ovnact_result *dl,
>>>  MLF_CHECK_PORT_SEC_BIT, ofpacts);
>>>   }
>>> +static void
>>> +parse_commit_ecmp_nh(struct action_context *ctx,
>>> + struct ovnact_commit_ecmp_nh *ecmp_nh)
>>> +{
>>> +bool ipv6;
>>> +
>>> +lexer_force_match(ctx->lexer, LEX_T_LPAREN); /* Skip '('. */
>>> +if (!lexer_match_id(ctx->lexer, "ipv6")) {
>>> +lexer_syntax_error(ctx->lexer, "invalid parameter");
>>> +return;
>>> +}
>>> +if (!lexer_force_match(ctx->lexer, LEX_T_EQUALS)) {
>>> +lexer_syntax_error(ctx->lexer, "invalid parameter");
>>> +return;
>>> +}
>>> +if (lexer_match_string(ctx->lexer, "true") ||
>>> +lexer_match_id(ctx->lexer, "true")) {
>>> +ipv6 = true;
>>> +} else if (lexer_match_string(ctx->lexer, "false") ||
>>> +   lexer_match_id(ctx->lexer, "false")) {
>>> +ipv6 = false;
>>> +} else {
>>> +lexer_syntax_error(ctx->lexer,
>>> +   "expecting true or false");
>>> +return;
>>> +}
>>> +lexer_force_match(ctx->lexer, LEX_T_SEMICOLON);
>>> +
>>> +lexer_force_match(ctx->lexer, LEX_T_RPAREN); /* Skip ')'. */
>>> +
>>> +ecmp_nh->ipv6 = ipv6;
>>> +}
>>> +
>>> +static void
>>> +format_COMMIT_ECMP_NH(const struct ovnact_commit_ecmp_nh *ecmp_nh,
>>> +  struct ds *s)
>>> +{
>>> +ds_put_format(s, "commit_ecmp_nh(ipv6=%s;);",
>>> +  ecm

Re: [ovs-dev] [PATCH v10 09/10] odp-execute: Add ISA implementation of set_masked ETH

[Van Haaren, Harry]

> -Original Message-
> From: Eelco Chaudron 
> Sent: Thursday, July 14, 2022 2:24 PM
> To: Van Haaren, Harry 
> Cc: d...@openvswitch.org; i.maxim...@ovn.org; Amber, Kumar
> ; Pai G, Sunil ; Finn, Emma
> ; Stokes, Ian 
> Subject: Re: [PATCH v10 09/10] odp-execute: Add ISA implementation of 
> set_masked
> ETH



> > +/* Read the content of the key(src) and mask in the respective 
> > registers.
> > + * We only load the src and dest addresses, which is only 96-bits and 
> > not
> > + * 128-bits. */
> > +__m128i v_src = _mm_maskz_loadu_epi32(0x7,(void *) key);
> > +__m128i v_mask = _mm_maskz_loadu_epi32(0x7, (void *) mask);
> 
> One question here I asked throughout the various revisions but got not 
> answered:
> 
> "The second load, loads 128 bits of data, but there are only 12 bytes to 
> load. What
> happens if the memory at the remaining 6 bytes are not mapped in memory (i.e. 
> a
> page does not exist/can't be loaded)? Will we crash!?

AVX512 has some very nice features for handling scenarios where "not full" SIMD 
is 
required. This feature is known as "k-masks", and in short allows "turning off" 
part of
the SIMD instruction from having an effect.

In this case, the "maskz" part of the intrinsic means that the k-mask becomes 
active.
An extra parameter is added to any k-mask instruction (_mm_maskz_*), which 
indicates
what lanes to enable/disable. Note that the *size* of each lane is determined 
by the
end of the intrinsic, so _epi32() indicates 32-bit lanes. A worked example 
below:

_mm_maskz_loadu_epi32(0x7, (void *) mask);

kmask is 0x7, or "111" in binary, so lowest 3 lanes (visualize them on the 
right) are active.
As the instruction targets 32-bit ints, each lane size is 4 bytes, so 3 * 4 = 
12 bytes "active".
As a result, only 12 bytes are loaded from memory here. Even if the next byte 
was on a new
page, and not mapped into our virtual address range, there would be no crash 
here due to
the k-mask handling the load.


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

Re: [ovs-dev] [PATCH v10 00/10] Actions Infrastructure + Optimizations

[Ilya Maximets]

On 7/14/22 16:03, Finn, Emma wrote:
> 
> 
>> -Original Message-
>> From: Eelco Chaudron 
>> Sent: Thursday 14 July 2022 14:27
>> To: Van Haaren, Harry 
>> Cc: Finn, Emma ; d...@openvswitch.org;
>> i.maxim...@ovn.org; Amber, Kumar ; Pai G, Sunil
>> ; Stokes, Ian 
>> Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
>>
>>
>>
>> On 14 Jul 2022, at 15:04, Van Haaren, Harry wrote:
>>
 -Original Message-
 From: Eelco Chaudron 
 Sent: Thursday, July 14, 2022 1:55 PM
 To: Van Haaren, Harry ; Finn, Emma
 
 Cc: d...@openvswitch.org; i.maxim...@ovn.org; Amber, Kumar
 ; Pai G, Sunil ;
 Stokes, Ian 
 Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
>>>
>>> 
>>>
> V10;
> - Fixed CI build issue on OSX around AVX512 linking (jenkins CI)
> - Moved docs and reworded sections (thanks Ilya for feedback)
> - Reworked one instance of <= OVS_ATTR_MAX back to original
> form(Eelco)

 I’ve just finished my review purely based on visual inspection and
 compile success, and I will send out some minor comments after the
 break ;)
>>>
>>> Sure - please keep in mind that theres few working hours before merge
>>> window ends, so unless absolutely critical to fix *before* merge, we can
>> fixup things next week.
>>>
>>> To be very clear; if there a genuine issue, yes lets fix. Variable
>>> renames, tidys etc, can all be handled starting from next week.
>>>
 After that, I will do the actual functional testing on an AVX512
 machine and let you know the results. This will give you time to
 fix/discuss the comment while I’m testing.
>>>
>>> Looking forward!
>>
>> They should be in your inbox, most of them can be changed quickly, just sent
>> out the v11 once done, as I need time to test this anyway before I can give
>> my final ACKs.
>>
>> My plan is to test v10 (or v11 if it’s there) tomorrow.
>>
>> //Eelco
> 
> Thanks for the comments Eelco. As Harry mentioned above, next revision will 
> only include critical fixes. Comment tidy ups and variable renaming will be 
> left out until next week. 
> 
> Things I will fix for next revision:
>   01/10 - Atomic store refactor.
>   07/10 - Refactor of avx init/probe functions.
>   09/10 - Swap OVS_ACTION_ATTR_MAX tobe first in check.
> 
> Comments that will be addressed next week:
>   01/10 - comment clean up
>   02/10 - comment clean up
>   04/10 - 2x  remove the trailing \n
>   - Move unit test to odp.at
>   05/10 - comment clean up
>   06/10 - comment clean up
>   09/10 - indentation if off  
>   10/10 - renaming variable/functions

These are fairly trivial, can we fix them as well, please?
Submission next weak will mean backports of these cosmetic
changes or conflicts with later backports of bug fixes. 

Also, please reply to questions in patches 9/10 and 10/10
regarding the load of potentially non-existent memory, which
are remaining unanswered.  And there is also one performance
related question.

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

Re: [ovs-dev] [PATCH v10 00/10] Actions Infrastructure + Optimizations

[Finn, Emma]

> -Original Message-
> From: Eelco Chaudron 
> Sent: Thursday 14 July 2022 14:27
> To: Van Haaren, Harry 
> Cc: Finn, Emma ; d...@openvswitch.org;
> i.maxim...@ovn.org; Amber, Kumar ; Pai G, Sunil
> ; Stokes, Ian 
> Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
> 
> 
> 
> On 14 Jul 2022, at 15:04, Van Haaren, Harry wrote:
> 
> >> -Original Message-
> >> From: Eelco Chaudron 
> >> Sent: Thursday, July 14, 2022 1:55 PM
> >> To: Van Haaren, Harry ; Finn, Emma
> >> 
> >> Cc: d...@openvswitch.org; i.maxim...@ovn.org; Amber, Kumar
> >> ; Pai G, Sunil ;
> >> Stokes, Ian 
> >> Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
> >
> > 
> >
> >>> V10;
> >>> - Fixed CI build issue on OSX around AVX512 linking (jenkins CI)
> >>> - Moved docs and reworded sections (thanks Ilya for feedback)
> >>> - Reworked one instance of <= OVS_ATTR_MAX back to original
> >>> form(Eelco)
> >>
> >> I’ve just finished my review purely based on visual inspection and
> >> compile success, and I will send out some minor comments after the
> >> break ;)
> >
> > Sure - please keep in mind that theres few working hours before merge
> > window ends, so unless absolutely critical to fix *before* merge, we can
> fixup things next week.
> >
> > To be very clear; if there a genuine issue, yes lets fix. Variable
> > renames, tidys etc, can all be handled starting from next week.
> >
> >> After that, I will do the actual functional testing on an AVX512
> >> machine and let you know the results. This will give you time to
> >> fix/discuss the comment while I’m testing.
> >
> > Looking forward!
> 
> They should be in your inbox, most of them can be changed quickly, just sent
> out the v11 once done, as I need time to test this anyway before I can give
> my final ACKs.
> 
> My plan is to test v10 (or v11 if it’s there) tomorrow.
> 
> //Eelco

Thanks for the comments Eelco. As Harry mentioned above, next revision will 
only include critical fixes. Comment tidy ups and variable renaming will be 
left out until next week. 

Things I will fix for next revision:
01/10 - Atomic store refactor.
07/10 - Refactor of avx init/probe functions.
09/10 - Swap OVS_ACTION_ATTR_MAX tobe first in check.

Comments that will be addressed next week:
01/10 - comment clean up
02/10 - comment clean up
04/10 - 2x  remove the trailing \n
- Move unit test to odp.at
05/10 - comment clean up
06/10 - comment clean up
09/10 - indentation if off  
10/10 - renaming variable/functions 

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

Re: [ovs-dev] [PATCH v10 04/10] odp-execute: Add command to switch action implementation.

[Ilya Maximets]

On 7/14/22 15:20, Eelco Chaudron wrote:
> On 13 Jul 2022, at 20:28, Harry van Haaren wrote:
> 
>> +++ b/tests/pmd.at
>> @@ -1192,3 +1192,42 @@ ovs-appctl: ovs-vswitchd: server returned an error
>>
>>  OVS_VSWITCHD_STOP
>>  AT_CLEANUP
>> +
>> +AT_SETUP([PMD - ovs-actions configuration])
>> +OVS_VSWITCHD_START([], [], [], [--dummy-numa 0,0])
>> +AT_CHECK([ovs-vsctl add-port br0 p1 -- set Interface p1 type=dummy-pmd])
>> +
> 
> These tests are not PMD related, so I think we should move them to odp.at 
> (and change the banner)? Ilya any thoughts?

I agree.  The test also doesn't need the dummy numa nor any ports added.

It can be added to odp.at with:

AT_BANNER([datapath actions in userspace])
AT_SETUP([odp-execute - actions implementation])

or something like that.

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

Re: [ovs-dev] [RFC ovn] controller: send GARPs for LSPs in vlan-backed network scenario

[Lorenzo Bianconi]

> 
> 
> > 2022年7月14日 下午4:32，Lorenzo Bianconi  写道：
> > 
> >>> 
> >>> On 7/13/22 18:07, Lorenzo Bianconi wrote:
> > On 6/17/22 00:31, Lorenzo Bianconi wrote:
> >> When using VLAN backed networks and OVN routers leveraging the
> >> 'ovn-chassis-mac-mappings' option, the eth.src field is replaced by the
> >> chassis mac address in order to not expose the router mac address from
> >> different nodes and confuse the TOR switch. However doing so the TOR
> >> switch is not able to learn the port/mac bindings for routed E/W 
> >> traffic
> >> and it is force to always flood it. Fix this issue adding the 
> >> capability
> >> to send GARP traffic for logical switch ports if the corresponding 
> >> logical
> >> switch has the ovn-lsp-garp parameter set to true in the option column.
> >> More into about the issue can be found here [0].
> >> 
> >> [0] 
> >> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-September/050678.html
> >>  
> >> 
> >> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2087779 
> >> 
> >> 
> >> Signed-off-by: Lorenzo Bianconi  >> >
> >> ---
> > 
> > Hi Lorenzo,
>  
>  Hi Dumitru,
>  
>  Thanks for reviewing it :)
>  
> > 
> > I have a few concerns with this approach:
> > 
> > a. The CMS will have to set this option for all VMs on all logical
> > switches which will enable periodic GARPs for all of them all the time.
> > That seems like quite a lot of broadcast traffic in the fabric.
> > 
> > b. There's no guarantee that the GARPs are sent in time to prevent the
> > FDB timeouts on the ToR switches.  At best we could make the interval
> > configurable but I don't think this is way better either.
> > 
> > c. This is not really introduced by your patch but we will be causing
> > this more often now.  With the topology:
> > 
> > (HV1) VM1 -- LS1 --- LR -- LS2 -- VM2 (HV2)
> >   (VLAN-backed network)
> > 
> > HV1 configured with chassis mac mapping HV1-MAC
> > HV2 configured with chassis mac mapping HV2-MAC
> > 
> > We're leaking MAC addresses from LS1's broadcast domain (VM1-MAC) and
> > from LS2's broadcast domain (VM2-MAC) into the fabric.  I'm not sure
> > that's OK.
> > 
> > I think a proper solution is to change how we run the logical pipelines
> > in case of vlan-backed networks.  We currently have an assymetry:
> > 
> > For packets flowing from VM1 to VM2 we execute:
> > - on HV1: LS1-ingress, LS1-egress, LR-ingress, LR-egress, LS2-ingress
> > - on HV2: LS2-egress
> > 
> > For packets flowing from VM2 to VM1 we execute:
> > - on HV2: LS2-ingress, LS2-egress, LR-ingress, LR-egress, LS1-ingress
> > - on HV1: LS1-egress
> > 
> > What if we change this to:
> > VM1 -> VM2:
> > - on HV1: LS1-ingress, LS1-egress, LR-ingress
> > - on HV2: LR-egress, LS2-ingress, LS2-egress
> > 
> > VM2 -> VM1:
> > - on HV2: LS2-ingress, LS2-egress, LR-ingress
> > - on HV2: LR-egress, LS1-ingress, LS1-egress
>  
>  I do not know why the current architecture is done this way (any 
>  suggestions??).
>  I guess the approach you suggested should work. Are we introducing any 
>  backward
>  compatibility issue?
> >>> 
> >>> We would probably create a compatibility issue. :)
> >>> 
> >>> I don't know if this approach would even work, I was just trying to
> >>> imagine how traffic from within OVN should be seen on the fabric in this
> >>> case.
> >>> 
> >>> Maybe we need to think some more about other options.
> >>> 
> >>> Regards,
> >>> Dumitru
> >> Hi Dumitru and Lorenzo, 
> > 
> > Hi Shy Liu,
> > 
> >> in my opinion, the flood issue maybe caused by the implemention that
> >> logical_switch always be an arp-proxy for lsp which has known address, 
> >> but this implemention is not applicable to vlan backed network. Right ?
> >> 
> >> I have an solution:
> >> Maybe we can add a option named arp-proxy for logical_switch 
> >> that always be false if network type is vlan, then disable the 
> >> logical_switch response the arp for  the lsp which belongs to 
> >> the vlan backed network.
> >> 
> >> So that this solution can let the destination MAC address
> >> always learnt by TOR for vlan backed network.
> > 
> > For e/w routed traffic from pod A to pod B, pod A will send an arp request
> > for the router ip address. Who is going to reply to this request in this 
> > way?
> Hi Lorenzo, 
> sorry that I had not describe it clearly.
> We can disable arp response for the lsp which type is not router port nor 
> localport.
> So the logical_switch still responses the arp request for lrp.

IIUC what you mean here, this approach will

Re: [ovs-dev] [PATCH V5 4/6] Make: Remove the Linux datapath.

[Aaron Conole]

Ilya Maximets  writes:

> On 7/14/22 01:05, 0-day Robot wrote:
>> 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.
>> 
>> 
>> build:
>> mv tests/testsuite.tmp tests/testsuite
>> /bin/sh
>> /var/lib/jenkins/jobs/0day_robot_upstream_build_from_pw/workspace/build-aux/missing
>> autom4te --language=autotest -I '.' -o
>> tests/system-kmod-testsuite.tmp tests/system-kmod-testsuite.at
>> mv tests/system-kmod-testsuite.tmp tests/system-kmod-testsuite
>> /bin/sh
>> /var/lib/jenkins/jobs/0day_robot_upstream_build_from_pw/workspace/build-aux/missing
>> autom4te --language=autotest -I '.' -o
>> tests/system-userspace-testsuite.tmp
>> tests/system-userspace-testsuite.at
>> mv tests/system-userspace-testsuite.tmp tests/system-userspace-testsuite
>> /bin/sh
>> /var/lib/jenkins/jobs/0day_robot_upstream_build_from_pw/workspace/build-aux/missing
>> autom4te --language=autotest -I '.' -o
>> tests/system-tso-testsuite.tmp tests/system-tso-testsuite.at
>> mv tests/system-tso-testsuite.tmp tests/system-tso-testsuite
>> /bin/sh
>> /var/lib/jenkins/jobs/0day_robot_upstream_build_from_pw/workspace/build-aux/missing
>> autom4te --language=autotest -I '.' -o
>> tests/system-afxdp-testsuite.tmp tests/system-afxdp-testsuite.at
>> mv tests/system-afxdp-testsuite.tmp tests/system-afxdp-testsuite
>> /bin/sh
>> /var/lib/jenkins/jobs/0day_robot_upstream_build_from_pw/workspace/build-aux/missing
>> autom4te --language=autotest -I '.' -o
>> tests/system-offloads-testsuite.tmp
>> tests/system-offloads-testsuite.at
>> mv tests/system-offloads-testsuite.tmp tests/system-offloads-testsuite
>> /bin/sh
>> /var/lib/jenkins/jobs/0day_robot_upstream_build_from_pw/workspace/build-aux/missing
>> autom4te --language=autotest -I '.' -o
>> tests/system-dpdk-testsuite.tmp tests/system-dpdk-testsuite.at
>> mv tests/system-dpdk-testsuite.tmp tests/system-dpdk-testsuite
>> /bin/sh
>> /var/lib/jenkins/jobs/0day_robot_upstream_build_from_pw/workspace/build-aux/missing
>> autom4te --language=autotest -I '.' -o
>> tests/ovsdb-cluster-testsuite.tmp tests/ovsdb-cluster-testsuite.at
>> mv tests/ovsdb-cluster-testsuite.tmp tests/ovsdb-cluster-testsuite
>> (printf '\043 Generated automatically -- do not modify!  -*-
>> buffer-read-only: t -*-\n' && sed -e 's,[@]VERSION[@],2.17.90,g') <
>> ./rhel/openvswitch.spec.in > openvswitch.spec.tmp || exit 1; if cmp
>> -s openvswitch.spec.tmp rhel/openvswitch.spec; then touch
>> rhel/openvswitch.spec; rm openvswitch.spec.tmp; else mv
>> openvswitch.spec.tmp rhel/openvswitch.spec; fi
>> (printf '\043 Generated automatically -- do not modify!  -*-
>> buffer-read-only: t -*-\n' && sed -e 's,[@]VERSION[@],2.17.90,g') <
>> ./rhel/openvswitch-fedora.spec.in > openvswitch-fedora.spec.tmp ||
>> exit 1; if cmp -s openvswitch-fedora.spec.tmp
>> rhel/openvswitch-fedora.spec; then touch
>> rhel/openvswitch-fedora.spec; rm openvswitch-fedora.spec.tmp; else
>> mv openvswitch-fedora.spec.tmp rhel/openvswitch-fedora.spec; fi
>> (printf '\043 Generated automatically -- do not modify!  -*-
>> buffer-read-only: t -*-\n' && sed -e 's,[@]VERSION[@],2.17.90,g') \
>>  < ./xenserver/openvswitch-xen.spec.in > openvswitch-xen.spec.tmp || 
>> exit 1; \
>> if cmp -s openvswitch-xen.spec.tmp xenserver/openvswitch-xen.spec;
>> then touch xenserver/openvswitch-xen.spec; rm
>> openvswitch-xen.spec.tmp; else mv openvswitch-xen.spec.tmp
>> xenserver/openvswitch-xen.spec; fi
>> The following files are in git but not the distribution:
>> include/linux/openvswitch.h
>> make[1]: *** [dist-hook-git] Error 1
>
> Robot is giving some misleading errors here.
>
> The real error should be 'no such file or directory' for the
> all-distfiles file, but it looks like there is an old one on
> a filesystem, so it complains about the new file which is not
> in the outdated all-distfiles.
>
> @Aaron, maybe robot should call 'make [dist]clean'
> before/after each test or clean up files in some other way? 

I'll look into it after next week.

> Interestingly, failure of the dist-hook-git due to failure
> of the comm and grep doesn't fail the build... The GHA build
> succeeded even with the issue present:
>   
> https://github.com/ovsrobot/ovs/runs/7330779128?check_suite_focus=true#step:12:6206
>
> @Greg, we need to compare the content of 'distfiles' with
> 'all-gitfiles' now, since the 'all-distfiles' is no longer
> generated.  The following change should fix the issue:
>
> diff --git a/.gitignore b/.gitignore
> index f1cdcf124..c70f41129 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -34,7 +34,6 @@
>  /Makefile
>  /Makefile.in
>  /aclocal.m4
> -/all-distfiles
>  /all-gitfiles
>  /autom4te.cache
>  /build-arch-stamp
> diff --git a/Makefile.am b/Makefile.am
> index ede07d1cb..fff98564a 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -200,19 +200,19 @@ dist-hook-git: distfiles
>   (cd $(srcdir) && git ls-files) | grep

Re: [ovs-dev] [PATCH ovn 0/3] improve ECMP symmetric routing reliability

[Lorenzo Bianconi]

> Hi Lorenzo,

Hi Mark,

thx for the review.

> 
> As a general note on this changeset, I think that more tests should be
> added. At this point, the only test here is the augmentation of the existing
> ECMP symmetric reply tests. This is great since it gives us a good
> end-to-end test. However, there are two issues here:
> 
> 1) It proves the results, but it doesn't prove that the results happen for
> the reasons we might expect.

sorry, I did not get you here, can you please elaborate on this?

> 
> 2) If something causes the test to break, trying to figure out what is
> causing the failure is going to be difficult.
> 
> I suggest that several more tests be added
> 
> 1) Add tests to the "action parsing" tests that ensure that the new actions
> that have been added to OVN encode as expected.

ack, I will do

> 
> 2) Add a test to ensure that the flows added in table 76 and 77 by the
> learn() action are what we expect.

ack, I will do

> 
> 3) Ensure that the flows in table 76 and 77 are removed after the hard
> timeout. You can probably just add this onto the ECMP symmetric replies test
> in system-ovn.at.

ack, I will do

Regards,
Lorenzo

> 
> On 7/13/22 08:44, Lorenzo Bianconi wrote:
> > Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2096233
> > 
> > Lorenzo Bianconi (3):
> >actions: introduce commit_ecmp_nh action
> >actions: introduce chk_ecmp_nh and chk_ecmp_nh_mac actions
> >northd: rely on new actions for ecmp-symmetric routing
> > 
> >   controller/lflow.h   |   2 +
> >   include/ovn/actions.h|   9 ++
> >   include/ovn/logical-fields.h |   3 +
> >   lib/actions.c| 230 +++
> >   northd/northd.c  |  46 +--
> >   northd/ovn-northd.8.xml  |  25 ++--
> >   ovn-sb.xml   |  54 
> >   tests/ovn-northd.at  |   4 +-
> >   tests/ovn.at |   4 +-
> >   tests/system-ovn.at  |  52 
> >   utilities/ovn-trace.c|   6 +
> >   11 files changed, 410 insertions(+), 25 deletions(-)
> > 
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v10 00/10] Actions Infrastructure + Optimizations

[Eelco Chaudron]

On 14 Jul 2022, at 15:04, Van Haaren, Harry wrote:

>> -Original Message-
>> From: Eelco Chaudron 
>> Sent: Thursday, July 14, 2022 1:55 PM
>> To: Van Haaren, Harry ; Finn, Emma
>> 
>> Cc: d...@openvswitch.org; i.maxim...@ovn.org; Amber, Kumar
>> ; Pai G, Sunil ; Stokes, Ian
>> 
>> Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations
>
> 
>
>>> V10;
>>> - Fixed CI build issue on OSX around AVX512 linking (jenkins CI)
>>> - Moved docs and reworded sections (thanks Ilya for feedback)
>>> - Reworked one instance of <= OVS_ATTR_MAX back to original form(Eelco)
>>
>> I’ve just finished my review purely based on visual inspection and compile 
>> success,
>> and I will send out some minor comments after the break ;)
>
> Sure - please keep in mind that theres few working hours before merge window 
> ends,
> so unless absolutely critical to fix *before* merge, we can fixup things next 
> week.
>
> To be very clear; if there a genuine issue, yes lets fix. Variable renames, 
> tidys etc,
> can all be handled starting from next week.
>
>> After that, I will do the actual functional testing on an AVX512 machine and 
>> let you
>> know the results. This will give you time to fix/discuss the comment while 
>> I’m
>> testing.
>
> Looking forward!

They should be in your inbox, most of them can be changed quickly, just sent 
out the v11 once done, as I need time to test this anyway before I can give my 
final ACKs.

My plan is to test v10 (or v11 if it’s there) tomorrow.

//Eelco

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

Re: [ovs-dev] [PATCH v10 10/10] odp-execute: Add ISA implementation of set_masked IPv4 action

[Eelco Chaudron]

> From: Emma Finn 
>
> This commit adds support for the AVX512 implementation of the
> ipv4_set_addrs action as well as an AVX512 implementation of
> updating the checksums.
>
> Signed-off-by: Emma Finn 
> ---
>  lib/odp-execute-avx512.c | 208 +++
>  1 file changed, 208 insertions(+)
>
> diff --git a/lib/odp-execute-avx512.c b/lib/odp-execute-avx512.c
> index 8ecdaecf6..a0c97f312 100644
> --- a/lib/odp-execute-avx512.c
> +++ b/lib/odp-execute-avx512.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>
> +#include "csum.h"
>  #include "dp-packet.h"
>  #include "immintrin.h"
>  #include "odp-execute.h"
> @@ -58,6 +59,22 @@ BUILD_ASSERT_DECL(offsetof(struct ovs_key_ethernet, 
> eth_src) +
>MEMBER_SIZEOF(struct ovs_key_ethernet, eth_src) ==
>offsetof(struct ovs_key_ethernet, eth_dst));
>
> +BUILD_ASSERT_DECL(offsetof(struct ovs_key_ipv4, ipv4_src) +
> +  MEMBER_SIZEOF(struct ovs_key_ipv4, ipv4_src) ==
> +  offsetof(struct ovs_key_ipv4, ipv4_dst));
> +
> +BUILD_ASSERT_DECL(offsetof(struct ovs_key_ipv4, ipv4_dst) +
> +  MEMBER_SIZEOF(struct ovs_key_ipv4, ipv4_dst) ==
> +  offsetof(struct ovs_key_ipv4, ipv4_proto));
> +
> +BUILD_ASSERT_DECL(offsetof(struct ovs_key_ipv4, ipv4_proto) +
> +  MEMBER_SIZEOF(struct ovs_key_ipv4, ipv4_proto) ==
> +  offsetof(struct ovs_key_ipv4, ipv4_tos));
> +
> +BUILD_ASSERT_DECL(offsetof(struct ovs_key_ipv4, ipv4_tos) +
> +  MEMBER_SIZEOF(struct ovs_key_ipv4, ipv4_tos) ==
> +  offsetof(struct ovs_key_ipv4, ipv4_ttl));
> +
>  /* Array of callback functions, one for each masked operation. */
>  odp_execute_action_cb impl_set_masked_funcs[__OVS_KEY_ATTR_MAX];
>
> @@ -279,6 +296,196 @@ action_avx512_eth_set_addrs(struct dp_packet_batch 
> *batch,
>  }
>  }
>
> +static inline uint16_t ALWAYS_INLINE
> +avx512_get_delta(__m256i old_header, __m256i res)

Can we renamed res to new_header, and also make sure we use the same order
in all three functions?

> +{
> +__m256i v_zeros = _mm256_setzero_si256();
> +uint16_t delta;
> +
> +/* These two shuffle masks, v_swap16a and v_swap16b, are to shuffle the
> + * old and new header to add padding after each 16-bit value for the
> + * following carry over addition. */
> +__m256i v_swap16a = _mm256_setr_epi16(0x0100, 0x, 0x0302, 0x,
> +  0x0504, 0x, 0x0706, 0x,
> +  0x0100, 0x, 0x0302, 0x,
> +  0x, 0x, 0x, 0x);
> +__m256i v_swap16b = _mm256_setr_epi16(0x0908, 0x, 0x0B0A, 0x,
> +  0x0D0C, 0x, 0x0F0E, 0x,
> +  0x, 0x, 0x, 0x,
> +  0x, 0x, 0x, 0x);
> +__m256i v_shuf_old1 = _mm256_shuffle_epi8(old_header, v_swap16a);
> +__m256i v_shuf_old2 = _mm256_shuffle_epi8(old_header, v_swap16b);
> +__m256i v_shuf_new1 = _mm256_shuffle_epi8(res, v_swap16a);
> +__m256i v_shuf_new2 = _mm256_shuffle_epi8(res, v_swap16b);
> +
> +/* Add each part of the old and new headers together. */
> +__m256i v_delta1 = _mm256_add_epi32(v_shuf_old1, v_shuf_new1);
> +__m256i v_delta2 = _mm256_add_epi32(v_shuf_old2, v_shuf_new2);
> +
> +/* Add old and new header. */
> +__m256i v_delta = _mm256_add_epi32(v_delta1, v_delta2);
> +
> +/* Perform horizontal add to go from 8x32-bits to 2x32-bits. */
> +v_delta = _mm256_hadd_epi32(v_delta, v_zeros);
> +v_delta = _mm256_hadd_epi32(v_delta, v_zeros);
> +
> +/* Shuffle 32-bit value from 3rd lane into first lane for final
> + * horizontal add. */
> +__m256i v_swap32a = _mm256_setr_epi32(0x0, 0x4, 0xF, 0xF,
> +  0xF, 0xF, 0xF, 0xF);
> +v_delta = _mm256_permutexvar_epi32(v_swap32a, v_delta);
> +
> +v_delta = _mm256_hadd_epi32(v_delta, v_zeros);
> +v_delta = _mm256_hadd_epi16(v_delta, v_zeros);
> +
> +/* Extract delta value. */
> +delta = _mm256_extract_epi16(v_delta, 0);
> +
> +return delta;
> +}
> +
> +static inline uint16_t ALWAYS_INLINE
> +avx512_l4_update_csum(__m256i old_header, __m256i res)

This function does not really update the ipv4 csum, so it should probably be 
renamed to something like, avx512_ipv4_addr_csum_delta().

Also the "res" name does not make sense, maybe something like, new_header?
And some help before the function!?

/* This function will calculate the csum delta for the IPv4 addresses in the
 * new_header and old_header, assuming the csum field on the new_header was
 * updated. */

> +{
> +__m256i v_zeros = _mm256_setzero_si256();
> +uint16_t delta;
> +
> +/* Set the v_ones register to all one's. */
> +__m256i v_ones = _mm256_cmpeq_epi16(

Re: [ovs-dev] [PATCH ovn 2/3] actions: introduce chk_ecmp_nh and chk_ecmp_nh_mac actions

[Lorenzo Bianconi]

> Hi Lorenzo, I only have a couple of minor grammatical suggestions for the
> docs. See below.

ack, I will fix them in v2.

Regards,
Lorenzo

> 
> On 7/13/22 08:44, Lorenzo Bianconi wrote:
> > check_ecmp_nh_mac/check_ecmp_nh actions check if the packet under
> > consideration matches the any flow in table
> > OFTABLE_ECMP_NH_MAC/OFTABLE_ECMP_NH. If it is so, then the 1-bit
> > destination register is set to 1.
> > chk_ecmp_nh and chk_ecmp_nh_mac will be used to improve ECMP symmetric
> > routing reliability.
> > 
> > Signed-off-by: Lorenzo Bianconi 
> > ---
> >   include/ovn/actions.h |  2 ++
> >   lib/actions.c | 54 +++
> >   ovn-sb.xml| 20 
> >   utilities/ovn-trace.c |  4 
> >   4 files changed, 80 insertions(+)
> > 
> > diff --git a/include/ovn/actions.h b/include/ovn/actions.h
> > index cef930e1a..4a3b9195a 100644
> > --- a/include/ovn/actions.h
> > +++ b/include/ovn/actions.h
> > @@ -119,6 +119,8 @@ struct ovn_extend_table;
> >   OVNACT(CHECK_IN_PORT_SEC,  ovnact_result) \
> >   OVNACT(CHECK_OUT_PORT_SEC, ovnact_result) \
> >   OVNACT(COMMIT_ECMP_NH,ovnact_commit_ecmp_nh)  \
> > +OVNACT(CHK_ECMP_NH_MAC,   ovnact_result)  \
> > +OVNACT(CHK_ECMP_NH,   ovnact_result)  \
> >   /* enum ovnact_type, with a member OVNACT_ for each action. */
> >   enum OVS_PACKED_ENUM ovnact_type {
> > diff --git a/lib/actions.c b/lib/actions.c
> > index 132c63228..e941f3cb4 100644
> > --- a/lib/actions.c
> > +++ b/lib/actions.c
> > @@ -4452,6 +4452,52 @@ encode_COMMIT_ECMP_NH(const struct 
> > ovnact_commit_ecmp_nh *ecmp_nh,
> >commit_ecmp_learn_action(ofpacts, false, ecmp_nh->ipv6);
> >   }
> > +static void
> > +parse_chk_ecmp_nh_mac(struct action_context *ctx, const struct expr_field 
> > *dst,
> > +  struct ovnact_result *res)
> > +{
> > +parse_ovnact_result(ctx, "chk_ecmp_nh_mac", NULL, dst, res);
> > +}
> > +
> > +static void
> > +format_CHK_ECMP_NH_MAC(const struct ovnact_result *res, struct ds *s)
> > +{
> > +expr_field_format(&res->dst, s);
> > +ds_put_cstr(s, " = chk_ecmp_nh_mac();");
> > +}
> > +
> > +static void
> > +encode_CHK_ECMP_NH_MAC(const struct ovnact_result *res,
> > +   const struct ovnact_encode_params *ep OVS_UNUSED,
> > +   struct ofpbuf *ofpacts)
> > +{
> > +encode_result_action__(res, OFTABLE_ECMP_NH_MAC,
> > +   MLF_LOOKUP_COMMIT_ECMP_NH_BIT, ofpacts);
> > +}
> > +
> > +static void
> > +parse_chk_ecmp_nh(struct action_context *ctx, const struct expr_field *dst,
> > +  struct ovnact_result *res)
> > +{
> > +parse_ovnact_result(ctx, "chk_ecmp_nh", NULL, dst, res);
> > +}
> > +
> > +static void
> > +format_CHK_ECMP_NH(const struct ovnact_result *res, struct ds *s)
> > +{
> > +expr_field_format(&res->dst, s);
> > +ds_put_cstr(s, " = chk_ecmp_nh();");
> > +}
> > +
> > +static void
> > +encode_CHK_ECMP_NH(const struct ovnact_result *res,
> > +   const struct ovnact_encode_params *ep OVS_UNUSED,
> > +   struct ofpbuf *ofpacts)
> > +{
> > +encode_result_action__(res, OFTABLE_ECMP_NH,
> > +   MLF_LOOKUP_COMMIT_ECMP_NH_BIT, ofpacts);
> > +}
> > +
> >   /* Parses an assignment or exchange or put_dhcp_opts action. */
> >   static void
> >   parse_set_action(struct action_context *ctx)
> > @@ -4528,6 +4574,14 @@ parse_set_action(struct action_context *ctx)
> >  && lexer_lookahead(ctx->lexer) == LEX_T_LPAREN) {
> >   parse_check_out_port_sec(
> >   ctx, &lhs, ovnact_put_CHECK_OUT_PORT_SEC(ctx->ovnacts));
> > +} else if (!strcmp(ctx->lexer->token.s, "chk_ecmp_nh_mac")
> > +   && lexer_lookahead(ctx->lexer) == LEX_T_LPAREN) {
> > +parse_chk_ecmp_nh_mac(ctx, &lhs,
> > +ovnact_put_CHK_ECMP_NH_MAC(ctx->ovnacts));
> > +} else if (!strcmp(ctx->lexer->token.s, "chk_ecmp_nh")
> > +   && lexer_lookahead(ctx->lexer) == LEX_T_LPAREN) {
> > +parse_chk_ecmp_nh(ctx, &lhs,
> > +ovnact_put_CHK_ECMP_NH(ctx->ovnacts));
> >   } else {
> >   parse_assignment_action(ctx, false, &lhs);
> >   }
> > diff --git a/ovn-sb.xml b/ovn-sb.xml
> > index ef5586020..dfed06e95 100644
> > --- a/ovn-sb.xml
> > +++ b/ovn-sb.xml
> > @@ -2607,6 +2607,26 @@ tcp.flags = RST;
> >   if it is routed via an ECMP route
> > 
> >   
> > +
> > +R = check_ecmp_nh_mac();
> > +
> > +  
> > +This action checks if the packet under consideration matches
> > +the any flow in table OFTABLE_ECMP_NH_MAC.
> 
> s/the //
> 
> > +If it is so, then the 1-bit destination register R
> > +is set to 1.
> > +  
> > +
> > +
> > +R = check_e

Re: [ovs-dev] [PATCH v10 09/10] odp-execute: Add ISA implementation of set_masked ETH

[Eelco Chaudron]

> From: Emma Finn 
>
> This commit includes infrastructure changes for enabling set_masked_X
> actions and also adds support for the AVX512 implementation of the
> eth_set_addrs action.
>
> Signed-off-by: Emma Finn 
> ---
>  lib/odp-execute-avx512.c  | 90 +++
>  lib/odp-execute-private.c | 14 ++
>  lib/odp-execute-private.h |  3 ++
>  lib/odp-execute.c | 49 +++--
>  lib/odp-execute.h |  3 ++
>  5 files changed, 137 insertions(+), 22 deletions(-)
>
> diff --git a/lib/odp-execute-avx512.c b/lib/odp-execute-avx512.c
> index 3449acff7..8ecdaecf6 100644
> --- a/lib/odp-execute-avx512.c
> +++ b/lib/odp-execute-avx512.c
> @@ -23,6 +23,7 @@
>
>  #include "dp-packet.h"
>  #include "immintrin.h"
> +#include "odp-execute.h"
>  #include "odp-execute-private.h"
>  #include "odp-netlink.h"
>  #include "openvswitch/vlog.h"
> @@ -50,6 +51,16 @@ BUILD_ASSERT_DECL(offsetof(struct dp_packet, l3_ofs) +
>  BUILD_ASSERT_DECL(sizeof(struct dp_packet) -
>offsetof(struct dp_packet, l2_pad_size) >= 
> sizeof(__m128i));
>
> +/* The below build assert makes sure the order of the fields needed by
> + * the set masked functions shuffle operations do not change. This should not
> + * happen as these are defined under the Linux uapi. */
> +BUILD_ASSERT_DECL(offsetof(struct ovs_key_ethernet, eth_src) +
> +  MEMBER_SIZEOF(struct ovs_key_ethernet, eth_src) ==
> +  offsetof(struct ovs_key_ethernet, eth_dst));
> +
> +/* Array of callback functions, one for each masked operation. */
> +odp_execute_action_cb impl_set_masked_funcs[__OVS_KEY_ATTR_MAX];
> +
>  static inline void ALWAYS_INLINE
>  avx512_dp_packet_resize_l2(struct dp_packet *b, int resize_by_bytes)
>  {
> @@ -207,6 +218,80 @@ action_avx512_push_vlan(struct dp_packet_batch *batch, 
> const struct nlattr *a)
>  }
>  }
>
> +/* This function performs the same operation on each packet in the batch as
> + * the scalar odp_eth_set_addrs() function. */
> +static void
> +action_avx512_eth_set_addrs(struct dp_packet_batch *batch,
> +const struct nlattr *a)
> +{
> +const struct ovs_key_ethernet *key, *mask;
> +struct dp_packet *packet;
> +
> +a = nl_attr_get(a);
> +key = nl_attr_get(a);
> +mask = odp_get_key_mask(a, struct ovs_key_ethernet);
> +
> +/* Read the content of the key(src) and mask in the respective registers.
> + * We only load the src and dest addresses, which is only 96-bits and not
> + * 128-bits. */
> +__m128i v_src = _mm_maskz_loadu_epi32(0x7,(void *) key);
> +__m128i v_mask = _mm_maskz_loadu_epi32(0x7, (void *) mask);

One question here I asked throughout the various revisions but got not answered:

"The second load, loads 128 bits of data, but there are only 12 bytes to load. 
What happens if the memory at the remaining 6 bytes are not mapped in memory 
(i.e. a page does not exist/can't be loaded)? Will we crash!?
Guess the key is fine, as we will read some bytes of the mask data."




> +void
> +odp_execute_scalar_action(struct dp_packet_batch *batch,
> +  const struct nlattr *action)
> +{
> +enum ovs_action_attr type = nl_attr_type(action);
> +
> +if (action_impls[ACTION_IMPL_SCALAR].funcs[type] &&
> +type <= OVS_ACTION_ATTR_MAX) {

Guess the two checks above need to be reversed, i.e. the type <= 
OVS_ACTION_ATTR_MAX should be first.
> +
> +action_impls[ACTION_IMPL_SCALAR].funcs[type](batch, action);
> +}
> +}



> +static void
> +action_set_masked(struct dp_packet_batch *batch, const struct nlattr *a)
> +{
> +   const struct nlattr *key = nl_attr_get(a);
> +   struct dp_packet *packet;
> +
> +DP_PACKET_BATCH_FOR_EACH (i, packet, batch) {
> +odp_execute_masked_set_action(packet, key);
> +}

Indentation is off here.



The rest of the patch looks good to me.

//Eelco

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

Re: [ovs-dev] [PATCH v10 08/10] odp-execute: Add ISA implementation of push_vlan action.

[Eelco Chaudron]

On 13 Jul 2022, at 20:28, Harry van Haaren wrote:

> From: Emma Finn 
>
> This commit adds the AVX512 implementation of the
> push_vlan action.
>
> Signed-off-by: Emma Finn 

Changes look good to me, thanks for incorporating all my feedback!

Acked-by: Eelco Chaudron 

//Eelco

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

Re: [ovs-dev] [PATCH v10 07/10] odp-execute: Add ISA implementation of pop_vlan action.

[Eelco Chaudron]

On 13 Jul 2022, at 20:28, Harry van Haaren wrote:

> This commit adds the AVX512 implementation of the
> pop_vlan action.
>
> Signed-off-by: Emma Finn 
>
> ---
>
> v10:
> - Improved ISA checks to fix CI build
> ---



> +#include 
> +#include "odp-execute-private.h"
> +/* Function itself is required to be called, even in e.g. 32-bit builds.
> + * This dummy init function ensures 32-bit builds succeed too.
> + */
> +
> +int
> +action_avx512_init(struct odp_execute_action_impl *self OVS_UNUSED)
> +{
> +  return 0;

See notes below, on init, but in this case it should return -ENOTSUP;

> +}
> +
> +#endif
> diff --git a/lib/odp-execute-private.c b/lib/odp-execute-private.c
> index 3591da2e5..2fabf6c62 100644
> --- a/lib/odp-execute-private.c
> +++ b/lib/odp-execute-private.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>
> +#include "cpu.h"
>  #include "dpdk.h"
>  #include "dp-packet.h"
>  #include "odp-execute-private.h"
> @@ -29,6 +30,36 @@
>  VLOG_DEFINE_THIS_MODULE(odp_execute_impl);
>  static int active_action_impl_index;
>
> +#if ACTION_IMPL_AVX512_CHECK
> +/* Probe functions to check ISA requirements. */
> +static bool
> +action_avx512_isa_probe(void)
> +{
> +static enum ovs_cpu_isa isa_required[] = {
> +OVS_CPU_ISA_X86_AVX512F,
> +OVS_CPU_ISA_X86_AVX512BW,
> +OVS_CPU_ISA_X86_BMI2,
> +OVS_CPU_ISA_X86_AVX512VL,
> +};
> +for (int i = 0; i < ARRAY_SIZE(isa_required); i++) {
> +if (!cpu_has_isa(isa_required[i])) {
> +return false;
> +}
> +}
> +return true;
> +}
> +static int
> +action_avx512_probe(struct odp_execute_action_impl *self)
> +{
> +if (!action_avx512_isa_probe()) {
> +return -ENOTSUP;
> +} else {
> +action_avx512_init(self);

I do not like this design, see below, but here it should be "return 
action_avx512_init(self);".

> +}
> +return 0;
> +}
> +#endif
> +
>  static struct odp_execute_action_impl action_impls[] = {
>  [ACTION_IMPL_AUTOVALIDATOR] = {
>  .available = false,
> @@ -46,7 +77,7 @@ static struct odp_execute_action_impl action_impls[] = {
>  [ACTION_IMPL_AVX512] = {
>  .available = false,
>  .name = "avx512",
> -.init_func = NULL,
> +.init_func = action_avx512_probe,

Do not really understand why the action_avx512_probe() becomes the init 
function? The previous design was way more clear, i.e. init_func was 
action_avx512_init(), and that function would call action_avx512_isa_probe().

I guess it's because of the patch done by David, but maybe we can still do 
something like this (not tested at all):

diff --git a/lib/odp-execute-private.c b/lib/odp-execute-private.c
index 2fabf6c62..373c90ea3 100644
--- a/lib/odp-execute-private.c
+++ b/lib/odp-execute-private.c
@@ -49,14 +49,11 @@ action_avx512_isa_probe(void)
 return true;
 }
 static int
-action_avx512_probe(struct odp_execute_action_impl *self)
+#else
+static bool
+action_avx512_isa_probe(void)
 {
-if (!action_avx512_isa_probe()) {
-return -ENOTSUP;
-} else {
-action_avx512_init(self);
-}
-return 0;
+retrun false;
 }
 #endif

@@ -77,7 +74,7 @@ static struct odp_execute_action_impl action_impls[] = {
 [ACTION_IMPL_AVX512] = {
 .available = false,
 .name = "avx512",
-.init_func = action_avx512_probe,
+.init_func = action_avx512_init,
 },
 #endif
 };

And just export the action_avx512_isa_probe() function.

>  },
>  #endif
>  };
> diff --git a/lib/odp-execute-private.h b/lib/odp-execute-private.h
> index 1943eb600..f66e6e6d1 100644
> --- a/lib/odp-execute-private.h
> +++ b/lib/odp-execute-private.h
> @@ -96,6 +96,8 @@ struct odp_execute_action_impl * 
> odp_execute_action_set(const char *name);
>
>  int action_autoval_init(struct odp_execute_action_impl *self);
>
> +int action_avx512_init(struct odp_execute_action_impl *self);
> +
>  void odp_execute_action_get_info(struct ds *name);
>
>  #endif /* ODP_EXTRACT_PRIVATE */
> -- 
> 2.32.0

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

Re: [ovs-dev] [PATCH] netdev-linux: Fix leak of a tc police get/del reply.

[Ilya Maximets]

On 7/14/22 15:05, Simon Horman wrote:
> On Thu, Jul 14, 2022 at 11:44:53AM +0200, Ilya Maximets wrote:
>> On 7/14/22 07:33, Simon Horman wrote:
>>> On Wed, Jul 13, 2022 at 04:30:41PM +0200, Ilya Maximets wrote:
  Direct leak of 64 byte(s) in 1 object(s) allocated from:
0 0x51b1d8 in malloc (vswitchd/ovs-vswitchd+0x51b1d8)
1 0xc81ded in xmalloc__ lib/util.c:137:15
2 0xc81ded in xmalloc lib/util.c:172:12
3 0xb32153 in ofpbuf_new lib/ofpbuf.c:168:24
4 0xd563e4 in nl_sock_transact lib/netlink-socket.c:1113:34
5 0xd56261 in nl_transact lib/netlink-socket.c:1812:13
6 0xd5e096 in tc_transact lib/tc.c:238:17
7 0xd01622 in tc_del_policer_action lib/netdev-linux.c:5807:13
8 0xd2e681 in meter_tc_del_policer lib/netdev-offload-tc.c:2827:15
9 0x94ec21 in meter_offload_del lib/netdev-offload.c:245:23
   10 0xcc86c4 in dpif_netlink_meter_del lib/dpif-netlink.c:4288:9
   11 0x86c595 in dpif_meter_del lib/dpif.c:2014:13
   12 0x663439 in free_meter_id ofproto/ofproto-dpif.c:6789:5
   13 0xb47518 in ovsrcu_call_postponed lib/ovs-rcu.c:346:13
   14 0xb48031 in ovsrcu_postpone_thread lib/ovs-rcu.c:362:14
   15 0xb5015a in ovsthread_wrapper lib/ovs-thread.c:422:12
   16 0x7f86af4081ce in start_thread (/lib64/libpthread.so.0+0x81ce)

 Fixes: 5c039ddc64ff ("netdev-linux: Add functions to manipulate tc police 
 action")
 Signed-off-by: Ilya Maximets 
>>>
>>> Acked-by: Simon Horman 
>>>
>>> I'd also be happy to apply this patch if that was your intention.
>>
>> Feel free to apply these 3 fixes, if you have time.  Thanks!
>> The one about misaligned access in pedit action will also need
>> a backport to stable branches.
>>
>> Best regards, Ilya Maximets.
> 
> Thanks, all patches applied to master.
> 
> The pedit action fix was also applied back to branch-2.13.
> Let me know if you'd like me to backport it further back.

Thanks!  We don't need to backport further as we don't support
older branches.   And the fix is not critical anyway.

But it seems you missed the branch-2.14.  Could you, please, recheck?

> 
> I'll also reply to the other two patches for the record.

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

Re: [ovs-dev] [PATCH v10 06/10] odp-execute: Add ISA implementation of actions.

[Eelco Chaudron]

On 13 Jul 2022, at 20:28, Harry van Haaren wrote:

> From: Emma Finn 
>
> This commit adds the AVX512 implementation of the action functionality.
>
> Usage:
>   $ ovs-appctl odp-execute/action-impl-set avx512
>
> Signed-off-by: Emma Finn 
> Signed-off-by: Harry van Haaren 
>
> ---



> diff --git a/lib/odp-execute-private.h b/lib/odp-execute-private.h
> index d6eebbf37..1943eb600 100644
> --- a/lib/odp-execute-private.h
> +++ b/lib/odp-execute-private.h
> @@ -22,6 +22,15 @@
>  #include "odp-netlink.h"
>  #include "ovs-atomic.h"
>
> +/* Combine all required ISA and Linker checks into a single #define
> + * for readability and simplicity where the checks are needed. Note
> + * that it is always #defined, so code must use the #if preprocesor
> + * directive (not #ifdef).
> + */

Please end comment on same line.

> +#define ACTION_IMPL_AVX512_CHECK (__x86_64__ && HAVE_AVX512F \
> +&& HAVE_LD_AVX512_GOOD && __SSE4_2__ && HAVE_AVX512BW && HAVE_AVX512VL \
> +&& HAVE_GCC_AVX512VL_GOOD)
> +



Rest looks good to me. Also seems the actual ISA init code was moved to patch 7.

//Eelco

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

Re: [ovs-dev] [PATCH v10 05/10] acinclude: Add configure option to enable actions autovalidator at build time.

[Eelco Chaudron]

On 13 Jul 2022, at 20:28, Harry van Haaren wrote:

> From: Kumar Amber 
>
> This commit adds a new command to allow the user to enable the
> actions autovalidator by default at build time thus allowing for
> running unit test by default.
>
>  $ ./configure --enable-actions-default-autovalidator
>
> Signed-off-by: Kumar Amber 
> Acked-by: Harry van Haaren 



> index d15f11a4e..84fad425c 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -14,6 +14,26 @@
>  # See the License for the specific language governing permissions and
>  # limitations under the License.
>
> +dnl Set OVS Actions Autovalidator as the default action implementation
> +dnl at compile time This enables automatically running all unit tests

Need a dot after "at compile time".

> +dnl with all actions implementations.



One small change, if this is the only change in the next rev, please add my ACK.

//Eelco

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

Re: [ovs-dev] [PATCH v10 04/10] odp-execute: Add command to switch action implementation.

[Eelco Chaudron]

On 13 Jul 2022, at 20:28, Harry van Haaren wrote:

> From: Emma Finn 
>
> This commit adds a new command to allow the user to switch
> the active action implementation at runtime.
>
> Usage:
>   $ ovs-appctl odp-execute/action-impl-set scalar
>
> This commit also adds a new command to retrieve the list of available
> action implementations. This can be used by to check what implementations
> of actions are available and what implementation is active during runtime.
>
> Usage:
>$ ovs-appctl odp-execute/action-impl-show
>
> Added separate test-case for ovs-actions show/set commands:
> PMD - ovs-actions configuration
>
> Signed-off-by: Emma Finn 
> Signed-off-by: Kumar Amber 
> Signed-off-by: Sunil Pai G 
> Co-authored-by: Kumar Amber 
> Co-authored-by: Sunil Pai G 
> Acked-by: Harry van Haaren 
>
> ---



> @@ -879,6 +880,48 @@ odp_actions_impl_set(const char *name)
>
>  }
>
> +static void
> +action_impl_set(struct unixctl_conn *conn, int argc OVS_UNUSED,
> +const char *argv[] OVS_UNUSED, void *aux OVS_UNUSED)
> +{
> +struct ds reply = DS_EMPTY_INITIALIZER;
> +
> +int err = odp_actions_impl_set(argv[1]);
> +if (err) {
> +ds_put_format(&reply,
> +  "Error: unknown action implementation, %s, 
> specified!\n",

On the v7 I asked to remove the trailing \n, any reason why this was not done?

> +  argv[1]);
> +unixctl_command_reply_error(conn, ds_cstr(&reply));
> +} else {
> +ds_put_format(&reply, "Action implementation set to %s.\n", argv[1]);

Same as above.

> +unixctl_command_reply(conn, ds_cstr(&reply));
> +}
> +
> +ds_destroy(&reply);



> +++ b/tests/pmd.at
> @@ -1192,3 +1192,42 @@ ovs-appctl: ovs-vswitchd: server returned an error
>
>  OVS_VSWITCHD_STOP
>  AT_CLEANUP
> +
> +AT_SETUP([PMD - ovs-actions configuration])
> +OVS_VSWITCHD_START([], [], [], [--dummy-numa 0,0])
> +AT_CHECK([ovs-vsctl add-port br0 p1 -- set Interface p1 type=dummy-pmd])
> +

These tests are not PMD related, so I think we should move them to odp.at (and 
change the banner)? Ilya any thoughts?



Everything else looks good to me.

//Eelco

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

Re: [ovs-dev] [PATCH ovn 1/3] actions: introduce commit_ecmp_nh action

[Lorenzo Bianconi]

> Hi Lorenzo, I have a few comments below.
> 
> On 7/13/22 08:44, Lorenzo Bianconi wrote:
> > commit_ecmp_nh action translates to an openflow "learn" action that
> > inserts two new flows in the OFTABLE_ECMP_NH_MAC and OFTABLE_ECMP_NH
> > tables. These new flows are used to match on the the 5-tuple and the
> > expected next-hop mac address and set REGBIT_KNOWN_ECMP_NH.
> > commit_ecmp_nh action will be used to improve ECMP symmetric routing
> > reliability.
> > 
> > Signed-off-by: Lorenzo Bianconi 
> > ---
> >   controller/lflow.h   |   2 +
> >   include/ovn/actions.h|   7 ++
> >   include/ovn/logical-fields.h |   3 +
> >   lib/actions.c| 176 +++
> >   ovn-sb.xml   |  34 +++
> >   utilities/ovn-trace.c|   2 +
> >   6 files changed, 224 insertions(+)
> > 
> > diff --git a/controller/lflow.h b/controller/lflow.h
> > index 342967917..543d3cd96 100644
> > --- a/controller/lflow.h
> > +++ b/controller/lflow.h
> > @@ -79,6 +79,8 @@ struct uuid;
> >   #define OFTABLE_CHK_IN_PORT_SEC  73
> >   #define OFTABLE_CHK_IN_PORT_SEC_ND   74
> >   #define OFTABLE_CHK_OUT_PORT_SEC 75
> > +#define OFTABLE_ECMP_NH_MAC  76
> > +#define OFTABLE_ECMP_NH  77
> >   enum ref_type {
> >   REF_TYPE_ADDRSET,
> > diff --git a/include/ovn/actions.h b/include/ovn/actions.h
> > index 33c319f1c..cef930e1a 100644
> > --- a/include/ovn/actions.h
> > +++ b/include/ovn/actions.h
> > @@ -118,6 +118,7 @@ struct ovn_extend_table;
> >   OVNACT(LOOKUP_FDB,ovnact_lookup_fdb)  \
> >   OVNACT(CHECK_IN_PORT_SEC,  ovnact_result) \
> >   OVNACT(CHECK_OUT_PORT_SEC, ovnact_result) \
> > +OVNACT(COMMIT_ECMP_NH,ovnact_commit_ecmp_nh)  \
> >   /* enum ovnact_type, with a member OVNACT_ for each action. */
> >   enum OVS_PACKED_ENUM ovnact_type {
> > @@ -453,6 +454,12 @@ struct ovnact_lookup_fdb {
> >   struct expr_field dst; /* 1-bit destination field. */
> >   };
> > +/* OVNACT_COMMIT_ECMP_NH. */
> > +struct ovnact_commit_ecmp_nh {
> > +struct ovnact ovnact;
> > +bool ipv6;
> > +};
> > +
> >   /* Internal use by the helpers below. */
> >   void ovnact_init(struct ovnact *, enum ovnact_type, size_t len);
> >   void *ovnact_put(struct ofpbuf *, enum ovnact_type, size_t len);
> > diff --git a/include/ovn/logical-fields.h b/include/ovn/logical-fields.h
> > index bfb07ebef..3db7265e4 100644
> > --- a/include/ovn/logical-fields.h
> > +++ b/include/ovn/logical-fields.h
> > @@ -70,6 +70,7 @@ enum mff_log_flags_bits {
> >   MLF_LOCALPORT_BIT = 10,
> >   MLF_USE_SNAT_ZONE = 11,
> >   MLF_CHECK_PORT_SEC_BIT = 12,
> > +MLF_LOOKUP_COMMIT_ECMP_NH_BIT = 13,
> >   };
> >   /* MFF_LOG_FLAGS_REG flag assignments */
> > @@ -113,6 +114,8 @@ enum mff_log_flags {
> >   /* Indicate the packet has been received from a localport */
> >   MLF_LOCALPORT = (1 << MLF_LOCALPORT_BIT),
> > +
> > +MLF_LOOKUP_COMMIT_ECMP_NH = (1 << MLF_LOOKUP_COMMIT_ECMP_NH_BIT),
> >   };
> >   /* OVN logical fields
> > diff --git a/lib/actions.c b/lib/actions.c
> > index aab044306..132c63228 100644
> > --- a/lib/actions.c
> > +++ b/lib/actions.c
> > @@ -41,6 +41,7 @@
> >   #include "uuid.h"
> >   #include "socket-util.h"
> >   #include "lib/ovn-util.h"
> > +#include "controller/lflow.h"
> >   VLOG_DEFINE_THIS_MODULE(actions);
> >   
> > @@ -4278,6 +4279,179 @@ encode_CHECK_OUT_PORT_SEC(const struct 
> > ovnact_result *dl,
> >  MLF_CHECK_PORT_SEC_BIT, ofpacts);
> >   }
> > +static void
> > +parse_commit_ecmp_nh(struct action_context *ctx,
> > + struct ovnact_commit_ecmp_nh *ecmp_nh)
> > +{
> > +bool ipv6;
> > +
> > +lexer_force_match(ctx->lexer, LEX_T_LPAREN); /* Skip '('. */
> > +if (!lexer_match_id(ctx->lexer, "ipv6")) {
> > +lexer_syntax_error(ctx->lexer, "invalid parameter");
> > +return;
> > +}
> > +if (!lexer_force_match(ctx->lexer, LEX_T_EQUALS)) {
> > +lexer_syntax_error(ctx->lexer, "invalid parameter");
> > +return;
> > +}
> > +if (lexer_match_string(ctx->lexer, "true") ||
> > +lexer_match_id(ctx->lexer, "true")) {
> > +ipv6 = true;
> > +} else if (lexer_match_string(ctx->lexer, "false") ||
> > +   lexer_match_id(ctx->lexer, "false")) {
> > +ipv6 = false;
> > +} else {
> > +lexer_syntax_error(ctx->lexer,
> > +   "expecting true or false");
> > +return;
> > +}
> > +lexer_force_match(ctx->lexer, LEX_T_SEMICOLON);
> > +
> > +lexer_force_match(ctx->lexer, LEX_T_RPAREN); /* Skip ')'. */
> > +
> > +ecmp_nh->ipv6 = ipv6;
> > +}
> > +
> > +static void
> > +format_COMMIT_ECMP_NH(const struct ovnact_commit_ecmp_nh *ecmp_nh,
> > +  struct ds *s)
> > +{
> > +ds_put_format(s, "commit_ecmp_nh(ipv6=%s;);",
> > +  ecmp_nh->ipv6 ? "true" : "false");
> > +}
> >

Re: [ovs-dev] [PATCH v10 03/10] odp-execute: Add auto validation function for actions.

[Eelco Chaudron]

On 13 Jul 2022, at 20:28, Harry van Haaren wrote:

> From: Emma Finn 
>
> This commit introduced the auto-validation function which
> allows users to compare the batch of packets obtained from
> different action implementations against the linear
> action implementation.
>
> The autovalidator function can be triggered at runtime using the
> following command:
>
> $ ovs-appctl odp-execute/action-impl-set autovalidator
>
> Signed-off-by: Emma Finn 
> Acked-by: Harry van Haaren 

Thanks for adding all the suggested changes!

Acked-by: Eelco Chaudron 

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

Re: [ovs-dev] [PATCH v10 02/10] odp-execute: Add function pointer for pop_vlan action.

[Eelco Chaudron]

On 13 Jul 2022, at 20:27, Harry van Haaren wrote:

> From: Emma Finn 
>
> This commit removes the pop_vlan action from the large switch
> and creates a separate function for batched processing. A function
> pointer is also added to call the new batched function for the pop_vlan
> action.
>
> Signed-off-by: Emma Finn 
> Acked-by: Harry van Haaren 

Thanks for adding all the suggested changes, here and in the first patch.

Acked-by: Eelco Chaudron 


One small nit, maybe can be fixed at commit time? But we need a v11 anyway, so 
you could add it there.
> --- a/lib/odp-execute-private.h
> +++ b/lib/odp-execute-private.h
> @@ -71,6 +71,11 @@ BUILD_ASSERT_DECL(ACTION_IMPL_SCALAR == 0);
>   */
>  void odp_execute_action_init(void);
>
> +/* Init functions for the action implementations. Initializes the function
> + * pointers for optimized action types.
> + */

The comment ending should be on the last line.

//Eelco


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

Re: [ovs-dev] [PATCH v10 01/10] odp-execute: Add function pointers to odp-execute for different action implementations.

[Eelco Chaudron]

On 13 Jul 2022, at 20:27, Harry van Haaren wrote:

> From: Emma Finn 
>
> This commit introduces the initial infrastructure required to allow
> different implementations for OvS actions. The patch introduces action
> function pointers which allows user to switch between different action
> implementations available. This will allow for more performance and 
> flexibility
> so the user can choose the action implementation to best suite their use case.
>
> Signed-off-by: Emma Finn 
> Acked-by: Harry van Haaren 
>
> ---



> +/* The active function pointers on the datapath. ISA optimized 
> implementations
> + * are enabled by plugging them into this static arary, which is consulted 
> when
> + * applying actions on the datapath.
> + */

The comment ending should be on the same line. Please fix this in all places of 
this patch.

> +static struct odp_execute_action_impl *actions_active_impl;
> +
> +static int
> +odp_actions_impl_set(const char *name)
> +{
> +struct odp_execute_action_impl *active;
> +active = odp_execute_action_set(name);
> +if (!active) {
> +VLOG_ERR("Failed setting action implementation to %s", name);
> +return 1;
> +}
> +
> +actions_active_impl = active;

This should be an atomic store.

> +return 0;
> +
> +}
> +



> @@ -879,8 +913,20 @@ odp_execute_actions(void *dp, struct dp_packet_batch 
> *batch, bool steal,
>  continue;
>  }
>
> -switch ((enum ovs_action_attr) type) {
> +/* If type is set in the active actions implementation, call the
> + * function-pointer and continue to the next action.
> + */
> +if (actions_active_impl->funcs[attr_type] &&

The actions_active_impl pointer should have been read atomically.
Looks like I also missed this in the previous patches...

> +attr_type <= OVS_ACTION_ATTR_MAX) {
> +actions_active_impl->funcs[attr_type](batch, a);
> +continue;
> +}

Those are the only comments I have on this patch, the rest looks good.

//Eelco

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

Re: [ovs-dev] [PATCH 1/2] netdev-offload-tc: Fix ignoring unknown tunnel keys.

[Ilya Maximets]

On 7/14/22 15:13, Roi Dayan wrote:
> 
> 
> On 2022-07-14 4:01 PM, Roi Dayan wrote:
>>
>>
>> On 2022-07-14 3:52 PM, Roi Dayan wrote:
>>>
>>>
>>> On 2022-07-14 3:37 PM, Roi Dayan wrote:


 On 2022-07-13 7:28 PM, Ilya Maximets wrote:
> On 7/13/22 12:11, Roi Dayan wrote:
>>
>>
>> On 2022-07-13 12:01 PM, Roi Dayan wrote:
>>>
>>>
>>> On 2022-07-06 4:58 PM, Roi Dayan wrote:


 On 2022-07-05 1:45 AM, Ilya Maximets wrote:
> Current offloading code supports only limited number of tunnel keys
> and silently ignores everything it doesn't understand.  This is
> causing, for example, offloaded ERSPAN tunnels to not work, because
> flow is offloaded, but ERSPAN options are not provided to TC.
>
> There is a number of tunnel keys, which are supported by the 
> userspace,
> but silently ignored during offloading:
>
>     OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT
>     OVS_TUNNEL_KEY_ATTR_OAM
>     OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS
>     OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS
>
> OVS_TUNNEL_KEY_ATTR_CSUM is kind of supported, but only for actions
> and for some reason is set from the tunnel port instead of the
> provided action, and not currently supported for the tunnel key in
> the match.
>
> Addig a default case to fail offloading of unknown attributes.  For
> now explicitly allowing incorrect behavior for the DONT_FRAGMENT flag,
> otherwise we'll break all tunnel offloading by default.  VXLAN and
> ERSPAN options has to fail offloading, because the tunnel will not
> work otherwise.  OAM is not a default configurations, so failing it
> as well. The missing DONT_FRAGMENT flag though should, probably,
> cause frequent flow revalidation, but that is not new with this patch.
>
> Same for the 'match' key, only clearing masks that was actually
> consumed, except for the DONT_FRAGMENT and CSUM flags, which are
> explicitly allowed and highlighted as broken.
>
> Also, ttl and tos were incorrectly checked by the value instead of a
> mask during the flow key dump. Destination port as well as CSUM
> configuration for unknown reason was not taken from the actions list
> and were passed via HW offload info.
>
> Reported-at: 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-dev%2F2022-July%2F395522.html&data=05%7C01%7Croid%40nvidia.com%7Cba6998f8523f4fcf52eb08da64ecba35%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637933265159187181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QDm8f%2FFzZE0X7q26i09UI8zaGK0UkD9tcEChI2XYNZ4%3D&reserved=0
> Reported-by: Eelco Chaudron 
> Fixes: 8f283af89298 ("netdev-tc-offloads: Implement netdev flow put 
> using tc interface")
> Signed-off-by: Ilya Maximets 
> ---
>    lib/dpif-netlink.c  | 14 +-
>    lib/netdev-offload-tc.c | 57 
> ++---
>    lib/netdev-offload.h    |  3 ---
>    3 files changed, 49 insertions(+), 25 deletions(-)
>
> diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
> index 06e1e8ca0..1e116b4ad 100644
> --- a/lib/dpif-netlink.c
> +++ b/lib/dpif-netlink.c
> @@ -2237,8 +2237,6 @@ parse_flow_put(struct dpif_netlink *dpif, 
> struct dpif_flow_put *put)
>    size_t left;
>    struct netdev *dev;
>    struct offload_info info;
> -    ovs_be16 dst_port = 0;
> -    uint8_t csum_on = false;
>    int err;
>    info.tc_modify_flow_deleted = false;
> @@ -2258,10 +2256,9 @@ parse_flow_put(struct dpif_netlink *dpif, 
> struct dpif_flow_put *put)
>    return EOPNOTSUPP;
>    }
> -    /* Get tunnel dst port */
> +    /* Check the output port for a tunnel. */
>    NL_ATTR_FOR_EACH(nla, left, put->actions, put->actions_len) {
>    if (nl_attr_type(nla) == OVS_ACTION_ATTR_OUTPUT) {
> -    const struct netdev_tunnel_config *tnl_cfg;
>    struct netdev *outdev;
>    odp_port_t out_port;
> @@ -2271,19 +2268,10 @@ parse_flow_put(struct dpif_netlink *dpif, 
> struct dpif_flow_put *put)
>    err = EOPNOTSUPP;
>    goto out;
>    }
> -    tnl_cfg = netdev_get_tunnel_config(outdev);
> -    if (tnl_cfg && tnl_cfg->dst_port != 0) {
> -    dst_port = tnl_cfg->dst_port;
> -    }
> -   

Re: [ovs-dev] [PATCH v5 0/3] DPDK shared mempool config.

[Stokes, Ian]

> This patchset optimizes for two cases when using shared mempools.
> 
> If there are ports with different MTUs, that usually leads
> to multiple shared mempools being created because mempool
> mbuf size and hence creation is based from MTU.
> 
> In fact, a port with a smaller MTU could share a mempool with
> mbuf sizes that can accomodate larger MTUs (assuming same NUMA).
> So instead of multiple shared mempools being created based on MTU,
> the ports can use a single shared mempool.
> 
> Another issue optimized for is that if there is an intended MTU
> for ports of say 9000, but the port is initially added without
> MTU specified, then it will fall back to a default MTU of 1500.
> 
> As it is not mandatory for the user to set MTU, it cannot be assumed
> that a new MTU will be set after a port is added, so mempools based
> on an MTU of 1500 are used.
> 
> When the MTU is subsequently set to 9000, the 1500 mempool will
> not be needed and may be freed, but during the in-between time
> both mempools are required.
> 
> Both these cases can be optimized for. However, to just switch to
> increased mbuf size based mempools automatically could lead to
> increased memory consumption and break upgrades depending on config.
> 
> So the user should give a hint about the MTUs they want the mempool
> mbufs size to be based on. While it is flexible for multiple sizes
> and numa, it would most likely be used with a single value. e.g.
> 
>  $ ovs-vsctl --no-wait set Open_vSwitch . \
>other_config:shared-mempool-config=9000
> 
> With this all dpdk ports will share mempools on the relevant NUMA
> with an mbuf size based on MTU 9000.

Thanks for the series Kevin, given that this was already under discussion prior 
to the soft freeze I've merged it to master for the 2.18 release.

There are so follow up items that could be addressed (i.e. expansion of the 
unit tests) but I see no reason to block on that for the moment.

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

Re: [ovs-dev] [PATCH 1/2] netdev-offload-tc: Fix ignoring unknown tunnel keys.

[Roi Dayan via dev]

On 2022-07-14 4:01 PM, Roi Dayan wrote:



On 2022-07-14 3:52 PM, Roi Dayan wrote:



On 2022-07-14 3:37 PM, Roi Dayan wrote:



On 2022-07-13 7:28 PM, Ilya Maximets wrote:

On 7/13/22 12:11, Roi Dayan wrote:



On 2022-07-13 12:01 PM, Roi Dayan wrote:



On 2022-07-06 4:58 PM, Roi Dayan wrote:



On 2022-07-05 1:45 AM, Ilya Maximets wrote:

Current offloading code supports only limited number of tunnel keys
and silently ignores everything it doesn't understand.  This is
causing, for example, offloaded ERSPAN tunnels to not work, because
flow is offloaded, but ERSPAN options are not provided to TC.

There is a number of tunnel keys, which are supported by the 
userspace,

but silently ignored during offloading:

    OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT
    OVS_TUNNEL_KEY_ATTR_OAM
    OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS
    OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS

OVS_TUNNEL_KEY_ATTR_CSUM is kind of supported, but only for actions
and for some reason is set from the tunnel port instead of the
provided action, and not currently supported for the tunnel key in
the match.

Addig a default case to fail offloading of unknown attributes.  For
now explicitly allowing incorrect behavior for the DONT_FRAGMENT 
flag,

otherwise we'll break all tunnel offloading by default.  VXLAN and
ERSPAN options has to fail offloading, because the tunnel will not
work otherwise.  OAM is not a default configurations, so failing it
as well. The missing DONT_FRAGMENT flag though should, probably,
cause frequent flow revalidation, but that is not new with this 
patch.


Same for the 'match' key, only clearing masks that was actually
consumed, except for the DONT_FRAGMENT and CSUM flags, which are
explicitly allowed and highlighted as broken.

Also, ttl and tos were incorrectly checked by the value instead 
of a

mask during the flow key dump. Destination port as well as CSUM
configuration for unknown reason was not taken from the actions 
list

and were passed via HW offload info.

Reported-at: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-dev%2F2022-July%2F395522.html&data=05%7C01%7Croid%40nvidia.com%7Cba6998f8523f4fcf52eb08da64ecba35%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637933265159187181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QDm8f%2FFzZE0X7q26i09UI8zaGK0UkD9tcEChI2XYNZ4%3D&reserved=0

Reported-by: Eelco Chaudron 
Fixes: 8f283af89298 ("netdev-tc-offloads: Implement netdev flow 
put using tc interface")

Signed-off-by: Ilya Maximets 
---
   lib/dpif-netlink.c  | 14 +-
   lib/netdev-offload-tc.c | 57 
++---

   lib/netdev-offload.h    |  3 ---
   3 files changed, 49 insertions(+), 25 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 06e1e8ca0..1e116b4ad 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -2237,8 +2237,6 @@ parse_flow_put(struct dpif_netlink *dpif, 
struct dpif_flow_put *put)

   size_t left;
   struct netdev *dev;
   struct offload_info info;
-    ovs_be16 dst_port = 0;
-    uint8_t csum_on = false;
   int err;
   info.tc_modify_flow_deleted = false;
@@ -2258,10 +2256,9 @@ parse_flow_put(struct dpif_netlink *dpif, 
struct dpif_flow_put *put)

   return EOPNOTSUPP;
   }
-    /* Get tunnel dst port */
+    /* Check the output port for a tunnel. */
   NL_ATTR_FOR_EACH(nla, left, put->actions, 
put->actions_len) {

   if (nl_attr_type(nla) == OVS_ACTION_ATTR_OUTPUT) {
-    const struct netdev_tunnel_config *tnl_cfg;
   struct netdev *outdev;
   odp_port_t out_port;
@@ -2271,19 +2268,10 @@ parse_flow_put(struct dpif_netlink 
*dpif, struct dpif_flow_put *put)

   err = EOPNOTSUPP;
   goto out;
   }
-    tnl_cfg = netdev_get_tunnel_config(outdev);
-    if (tnl_cfg && tnl_cfg->dst_port != 0) {
-    dst_port = tnl_cfg->dst_port;
-    }
-    if (tnl_cfg) {
-    csum_on = tnl_cfg->csum;
-    }
   netdev_close(outdev);
   }
   }
-    info.tp_dst_port = dst_port;
-    info.tunnel_csum_on = csum_on;
   info.recirc_id_shared_with_tc = (dpif->user_features
    & 
OVS_DP_F_TC_RECIRC_SHARING);

   err = netdev_flow_put(dev, &match,
diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
index 262faf3c6..e62687c82 100644
--- a/lib/netdev-offload-tc.c
+++ b/lib/netdev-offload-tc.c
@@ -805,11 +805,11 @@ parse_tc_flower_to_match(struct tc_flower 
*flower,

&flower->key.tunnel.ipv6.ipv6_src,
&flower->mask.tunnel.ipv6.ipv6_src);
   }
-    if (flower->key.tunnel.tos) {
+    if (flower->mask.tunnel.tos) {
   match_set_tun_tos_masked(match, 
flower->key.tunnel.tos,

    flower->mask.tunnel.tos);
   }
-    if (f

Re: [ovs-dev] [PATCH] tc: Fix misaligned access to struct tcf_t for police action.

[Simon Horman]

On Thu, Jul 14, 2022 at 07:34:08AM +0200, Simon Horman wrote:
> On Wed, Jul 13, 2022 at 04:32:44PM +0200, Ilya Maximets wrote:
> >   lib/tc.c:1334:44: runtime error: member access within misaligned address
> >   0x6210001f5a2c for type 'const struct tcf_t', which requires 8 byte 
> > alignment
> >   0x6210001f5a2c: note: pointer points here
> >   24 00 06 00 c3 00 00 00  00 00 00 00 c3 00 00 00 ...
> >   ^
> >  0 0xd7c7ea in nl_parse_tcf lib/tc.c:1334:44
> >  1 0xd7bd3a in nl_parse_act_police lib/tc.c:1433:9
> >  2 0xd68b1a in nl_parse_single_action lib/tc.c:1922:9
> >  3 0xd62c7e in nl_parse_flower_actions lib/tc.c:1992:19
> >  4 0xd62c7e in nl_parse_flower_options lib/tc.c:2107:12
> >  5 0xd5fa32 in parse_netlink_to_tc_flower lib/tc.c:2155:12
> >  6 0xd21760 in netdev_tc_flow_dump_next lib/netdev-offload-tc.c:1158:13
> >  7 0x94f442 in netdev_flow_dump_next lib/netdev-offload.c:301:14
> >  8 0xcba2f6 in dpif_netlink_flow_dump_next lib/dpif-netlink.c:1901:20
> >  9 0x8665b6 in dpif_flow_dump_next lib/dpif.c:1135:9
> > 10 0xee5f0f in dpctl_dump_flows lib/dpctl.c:1106:12
> > 11 0xee27a3 in dpctl_unixctl_handler lib/dpctl.c:3035:17
> > 12 0xc7f78b in process_command lib/unixctl.c:310:13
> > 13 0xc7f78b in run_connection lib/unixctl.c:344:17
> > 14 0xc7f78b in unixctl_server_run lib/unixctl.c:395:21
> > 15 0x59acb4 in main vswitchd/ovs-vswitchd.c:130:9
> > 16 0x7f1be043acf2 in __libc_start_main (/lib64/libc.so.6+0x3acf2)
> > 17 0x47e91d in _start (vswitchd/ovs-vswitchd+0x47e91d)
> > 
> > Fixes: a9b8cdde69de ("tc: Add support parsing tc police action")
> > Signed-off-by: Ilya Maximets 
> 
> Acked-by: Simon Horman 
> 
> I'd also be happy to apply this patch if that was your intention.

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

Re: [ovs-dev] [PATCH] tc: Fix misaligned access while creating pedit actions.

[Simon Horman]

On Thu, Jul 14, 2022 at 07:34:29AM +0200, Simon Horman wrote:
> On Wed, Jul 13, 2022 at 04:35:31PM +0200, Ilya Maximets wrote:
> > calc_offsets() function returns 'data' and 'mask' pointers, which
> > are pointers somewhere inside struct tc_flower_key, and they are not
> > aligned, causing misaligned memory access.  For example:
> > 
> >   ipv6.rewrite_hlimit is at 148 byte offset inside the struct
> >   tc_flower_key.  While the actual field is in the 7th byte of
> >   the IPv6 header in the actual packet.  So, pedit will need
> >   to write the last byte of the [4-7] range to the actual packet.
> >   So, data pointer is positioned to 145th byte inside the tc_flower_key
> >   with the 00FF mask.  Obviously, 145th byte inside the structure
> >   is not 4-byte aligned.
> > 
> >  lib/tc.c:2879:34: runtime error:
> >load of misaligned address 0x7f2802eaa321 for type 'ovs_be32' (aka
> >'unsigned int'), which requires 4 byte alignment
> >0x7f2802eaa321: note: pointer points here
> >  00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ...
> >   ^
> >  0 0xd7f2fb in nl_msg_put_flower_rewrite_pedits lib/tc.c:2879:34
> >  1 0xd7f2fb in nl_msg_put_flower_acts lib/tc.c:3141:25
> >  2 0xd6ae5a in nl_msg_put_flower_options lib/tc.c:3445:12
> >  3 0xd6a2be in tc_replace_flower lib/tc.c:3712:17
> >  4 0xd2bf25 in netdev_tc_flow_put lib/netdev-offload-tc.c:2224:11
> >  5 0x94f6b7 in netdev_flow_put lib/netdev-offload.c:316:14
> >  6 0xcbd19e in parse_flow_put lib/dpif-netlink.c:2289:11
> >  7 0xcbd19e in try_send_to_netdev lib/dpif-netlink.c:2376:15
> >  8 0xcbd19e in dpif_netlink_operate lib/dpif-netlink.c:2447:23
> >  9 0x86536e in dpif_operate lib/dpif.c:1372:13
> > 10 0x6bc289 in handle_upcalls ofproto/ofproto-dpif-upcall.c:1654:5
> > 11 0x6bc289 in recv_upcalls ofproto/ofproto-dpif-upcall.c:892:9
> > 12 0x6b766a in udpif_upcall_handler ofproto/ofproto-dpif-upcall.c:792:13
> > 13 0xb5015a in ovsthread_wrapper lib/ovs-thread.c:422:12
> > 14 0x7f280b2081ce in start_thread (/lib64/libpthread.so.0+0x81ce)
> > 15 0x7f2809e39dd2 in clone (/lib64/libc.so.6+0x39dd2)
> > 
> > Fix misaligned read by using appropriate functions.
> > 
> > Fixes: 8ada482bbe19 ("tc: Add header rewrite using tc pedit action")
> > Signed-off-by: Ilya Maximets 
> 
> Acked-by: Simon Horman 
> 
> I'd also be happy to apply this patch if that was your intention.

Applied to master, and backported to branches back to branch-2.13.
Let me know if you'd like me to backport it further back.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] netdev-linux: Fix leak of a tc police get/del reply.

[Simon Horman]

On Thu, Jul 14, 2022 at 11:44:53AM +0200, Ilya Maximets wrote:
> On 7/14/22 07:33, Simon Horman wrote:
> > On Wed, Jul 13, 2022 at 04:30:41PM +0200, Ilya Maximets wrote:
> >>  Direct leak of 64 byte(s) in 1 object(s) allocated from:
> >>0 0x51b1d8 in malloc (vswitchd/ovs-vswitchd+0x51b1d8)
> >>1 0xc81ded in xmalloc__ lib/util.c:137:15
> >>2 0xc81ded in xmalloc lib/util.c:172:12
> >>3 0xb32153 in ofpbuf_new lib/ofpbuf.c:168:24
> >>4 0xd563e4 in nl_sock_transact lib/netlink-socket.c:1113:34
> >>5 0xd56261 in nl_transact lib/netlink-socket.c:1812:13
> >>6 0xd5e096 in tc_transact lib/tc.c:238:17
> >>7 0xd01622 in tc_del_policer_action lib/netdev-linux.c:5807:13
> >>8 0xd2e681 in meter_tc_del_policer lib/netdev-offload-tc.c:2827:15
> >>9 0x94ec21 in meter_offload_del lib/netdev-offload.c:245:23
> >>   10 0xcc86c4 in dpif_netlink_meter_del lib/dpif-netlink.c:4288:9
> >>   11 0x86c595 in dpif_meter_del lib/dpif.c:2014:13
> >>   12 0x663439 in free_meter_id ofproto/ofproto-dpif.c:6789:5
> >>   13 0xb47518 in ovsrcu_call_postponed lib/ovs-rcu.c:346:13
> >>   14 0xb48031 in ovsrcu_postpone_thread lib/ovs-rcu.c:362:14
> >>   15 0xb5015a in ovsthread_wrapper lib/ovs-thread.c:422:12
> >>   16 0x7f86af4081ce in start_thread (/lib64/libpthread.so.0+0x81ce)
> >>
> >> Fixes: 5c039ddc64ff ("netdev-linux: Add functions to manipulate tc police 
> >> action")
> >> Signed-off-by: Ilya Maximets 
> > 
> > Acked-by: Simon Horman 
> > 
> > I'd also be happy to apply this patch if that was your intention.
> 
> Feel free to apply these 3 fixes, if you have time.  Thanks!
> The one about misaligned access in pedit action will also need
> a backport to stable branches.
> 
> Best regards, Ilya Maximets.

Thanks, all patches applied to master.

The pedit action fix was also applied back to branch-2.13.
Let me know if you'd like me to backport it further back.

I'll also reply to the other two patches for the record.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v10 00/10] Actions Infrastructure + Optimizations

[Van Haaren, Harry]

> -Original Message-
> From: Eelco Chaudron 
> Sent: Thursday, July 14, 2022 1:55 PM
> To: Van Haaren, Harry ; Finn, Emma
> 
> Cc: d...@openvswitch.org; i.maxim...@ovn.org; Amber, Kumar
> ; Pai G, Sunil ; Stokes, Ian
> 
> Subject: Re: [PATCH v10 00/10] Actions Infrastructure + Optimizations



> > V10;
> > - Fixed CI build issue on OSX around AVX512 linking (jenkins CI)
> > - Moved docs and reworded sections (thanks Ilya for feedback)
> > - Reworked one instance of <= OVS_ATTR_MAX back to original form(Eelco)
> 
> I’ve just finished my review purely based on visual inspection and compile 
> success,
> and I will send out some minor comments after the break ;)

Sure - please keep in mind that theres few working hours before merge window 
ends,
so unless absolutely critical to fix *before* merge, we can fixup things next 
week.

To be very clear; if there a genuine issue, yes lets fix. Variable renames, 
tidys etc,
can all be handled starting from next week.

> After that, I will do the actual functional testing on an AVX512 machine and 
> let you
> know the results. This will give you time to fix/discuss the comment while I’m
> testing.

Looking forward!

> Cheers,
> 
> Eelco

Thanks for keeping us updated to progress, -Harry
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] netdev-offload-tc: Fix ignoring unknown tunnel keys.

[Roi Dayan via dev]

On 2022-07-14 3:52 PM, Roi Dayan wrote:



On 2022-07-14 3:37 PM, Roi Dayan wrote:



On 2022-07-13 7:28 PM, Ilya Maximets wrote:

On 7/13/22 12:11, Roi Dayan wrote:



On 2022-07-13 12:01 PM, Roi Dayan wrote:



On 2022-07-06 4:58 PM, Roi Dayan wrote:



On 2022-07-05 1:45 AM, Ilya Maximets wrote:

Current offloading code supports only limited number of tunnel keys
and silently ignores everything it doesn't understand.  This is
causing, for example, offloaded ERSPAN tunnels to not work, because
flow is offloaded, but ERSPAN options are not provided to TC.

There is a number of tunnel keys, which are supported by the 
userspace,

but silently ignored during offloading:

    OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT
    OVS_TUNNEL_KEY_ATTR_OAM
    OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS
    OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS

OVS_TUNNEL_KEY_ATTR_CSUM is kind of supported, but only for actions
and for some reason is set from the tunnel port instead of the
provided action, and not currently supported for the tunnel key in
the match.

Addig a default case to fail offloading of unknown attributes.  For
now explicitly allowing incorrect behavior for the DONT_FRAGMENT 
flag,

otherwise we'll break all tunnel offloading by default.  VXLAN and
ERSPAN options has to fail offloading, because the tunnel will not
work otherwise.  OAM is not a default configurations, so failing it
as well. The missing DONT_FRAGMENT flag though should, probably,
cause frequent flow revalidation, but that is not new with this 
patch.


Same for the 'match' key, only clearing masks that was actually
consumed, except for the DONT_FRAGMENT and CSUM flags, which are
explicitly allowed and highlighted as broken.

Also, ttl and tos were incorrectly checked by the value instead of a
mask during the flow key dump. Destination port as well as CSUM
configuration for unknown reason was not taken from the actions list
and were passed via HW offload info.

Reported-at: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-dev%2F2022-July%2F395522.html&data=05%7C01%7Croid%40nvidia.com%7Cba6998f8523f4fcf52eb08da64ecba35%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637933265159187181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QDm8f%2FFzZE0X7q26i09UI8zaGK0UkD9tcEChI2XYNZ4%3D&reserved=0

Reported-by: Eelco Chaudron 
Fixes: 8f283af89298 ("netdev-tc-offloads: Implement netdev flow 
put using tc interface")

Signed-off-by: Ilya Maximets 
---
   lib/dpif-netlink.c  | 14 +-
   lib/netdev-offload-tc.c | 57 
++---

   lib/netdev-offload.h    |  3 ---
   3 files changed, 49 insertions(+), 25 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 06e1e8ca0..1e116b4ad 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -2237,8 +2237,6 @@ parse_flow_put(struct dpif_netlink *dpif, 
struct dpif_flow_put *put)

   size_t left;
   struct netdev *dev;
   struct offload_info info;
-    ovs_be16 dst_port = 0;
-    uint8_t csum_on = false;
   int err;
   info.tc_modify_flow_deleted = false;
@@ -2258,10 +2256,9 @@ parse_flow_put(struct dpif_netlink *dpif, 
struct dpif_flow_put *put)

   return EOPNOTSUPP;
   }
-    /* Get tunnel dst port */
+    /* Check the output port for a tunnel. */
   NL_ATTR_FOR_EACH(nla, left, put->actions, put->actions_len) {
   if (nl_attr_type(nla) == OVS_ACTION_ATTR_OUTPUT) {
-    const struct netdev_tunnel_config *tnl_cfg;
   struct netdev *outdev;
   odp_port_t out_port;
@@ -2271,19 +2268,10 @@ parse_flow_put(struct dpif_netlink *dpif, 
struct dpif_flow_put *put)

   err = EOPNOTSUPP;
   goto out;
   }
-    tnl_cfg = netdev_get_tunnel_config(outdev);
-    if (tnl_cfg && tnl_cfg->dst_port != 0) {
-    dst_port = tnl_cfg->dst_port;
-    }
-    if (tnl_cfg) {
-    csum_on = tnl_cfg->csum;
-    }
   netdev_close(outdev);
   }
   }
-    info.tp_dst_port = dst_port;
-    info.tunnel_csum_on = csum_on;
   info.recirc_id_shared_with_tc = (dpif->user_features
    & 
OVS_DP_F_TC_RECIRC_SHARING);

   err = netdev_flow_put(dev, &match,
diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
index 262faf3c6..e62687c82 100644
--- a/lib/netdev-offload-tc.c
+++ b/lib/netdev-offload-tc.c
@@ -805,11 +805,11 @@ parse_tc_flower_to_match(struct tc_flower 
*flower,

&flower->key.tunnel.ipv6.ipv6_src,
&flower->mask.tunnel.ipv6.ipv6_src);
   }
-    if (flower->key.tunnel.tos) {
+    if (flower->mask.tunnel.tos) {
   match_set_tun_tos_masked(match, 
flower->key.tunnel.tos,

    flower->mask.tunnel.tos);
   }
-    if (flower->key.tunnel.ttl) {
+    if (flower->mas

Re: [ovs-dev] [PATCH v10 00/10] Actions Infrastructure + Optimizations

[Eelco Chaudron]

On 13 Jul 2022, at 20:27, Harry van Haaren wrote:

> This patchset introduces actions infrastructure changes which allows
> the user to choose between different action implementations based on
> CPU ISA by using different commands.  The infrastructure also
> provides a way to check the correctness of the ISA optimized action
> version against the scalar version.
>
> This series also introduces optimized versions of the following
> actions:
>  - push_vlan
>  - pop_vlan
>  - set_masked eth
>  - set_masked ipv4
>
> Below is a table indicating some relative performance benefits for
> these actions.
> +---+---+-+
> | Actions   | Scalar with series| AVX 
> with series |
> +---+---+-+
> | mod_dl_dst| 1.01x | 1.13x   
> |
> +---+---+-+
> | push_vlan | 1.01x | 1.10x   
> |
> +---+---+-+
> | strip_vlan| 1.01x | 1.11x   
> |
> +---+---+-+
> | mod_ipv4 1 x field| 1.01x | 1.02x   
> |
> +---+---+-+
> | mod_ipv4 4 x fields   | 1.01x | 1.21x   
> |
> +---+---+-+
> | strip_vlan + mod_dl_dst + mod_ipv4 4 x fields | 1.01x | 1.36x   
> |
> +---+---+-+
>
> ---
> V10;
> - Fixed CI build issue on OSX around AVX512 linking (jenkins CI)
> - Moved docs and reworded sections (thanks Ilya for feedback)
> - Reworked one instance of <= OVS_ATTR_MAX back to original form(Eelco)

I’ve just finished my review purely based on visual inspection and compile 
success, and I will send out some minor comments after the break ;)

After that, I will do the actual functional testing on an AVX512 machine and 
let you know the results. This will give you time to fix/discuss the comment 
while I’m testing.

Cheers,

Eelco

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

Re: [ovs-dev] [PATCH 1/2] netdev-offload-tc: Fix ignoring unknown tunnel keys.

[Roi Dayan via dev]

On 2022-07-14 3:37 PM, Roi Dayan wrote:



On 2022-07-13 7:28 PM, Ilya Maximets wrote:

On 7/13/22 12:11, Roi Dayan wrote:



On 2022-07-13 12:01 PM, Roi Dayan wrote:



On 2022-07-06 4:58 PM, Roi Dayan wrote:



On 2022-07-05 1:45 AM, Ilya Maximets wrote:

Current offloading code supports only limited number of tunnel keys
and silently ignores everything it doesn't understand.  This is
causing, for example, offloaded ERSPAN tunnels to not work, because
flow is offloaded, but ERSPAN options are not provided to TC.

There is a number of tunnel keys, which are supported by the 
userspace,

but silently ignored during offloading:

    OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT
    OVS_TUNNEL_KEY_ATTR_OAM
    OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS
    OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS

OVS_TUNNEL_KEY_ATTR_CSUM is kind of supported, but only for actions
and for some reason is set from the tunnel port instead of the
provided action, and not currently supported for the tunnel key in
the match.

Addig a default case to fail offloading of unknown attributes.  For
now explicitly allowing incorrect behavior for the DONT_FRAGMENT 
flag,

otherwise we'll break all tunnel offloading by default.  VXLAN and
ERSPAN options has to fail offloading, because the tunnel will not
work otherwise.  OAM is not a default configurations, so failing it
as well. The missing DONT_FRAGMENT flag though should, probably,
cause frequent flow revalidation, but that is not new with this 
patch.


Same for the 'match' key, only clearing masks that was actually
consumed, except for the DONT_FRAGMENT and CSUM flags, which are
explicitly allowed and highlighted as broken.

Also, ttl and tos were incorrectly checked by the value instead of a
mask during the flow key dump. Destination port as well as CSUM
configuration for unknown reason was not taken from the actions list
and were passed via HW offload info.

Reported-at: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-dev%2F2022-July%2F395522.html&data=05%7C01%7Croid%40nvidia.com%7Cba6998f8523f4fcf52eb08da64ecba35%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637933265159187181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QDm8f%2FFzZE0X7q26i09UI8zaGK0UkD9tcEChI2XYNZ4%3D&reserved=0

Reported-by: Eelco Chaudron 
Fixes: 8f283af89298 ("netdev-tc-offloads: Implement netdev flow 
put using tc interface")

Signed-off-by: Ilya Maximets 
---
   lib/dpif-netlink.c  | 14 +-
   lib/netdev-offload-tc.c | 57 
++---

   lib/netdev-offload.h    |  3 ---
   3 files changed, 49 insertions(+), 25 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 06e1e8ca0..1e116b4ad 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -2237,8 +2237,6 @@ parse_flow_put(struct dpif_netlink *dpif, 
struct dpif_flow_put *put)

   size_t left;
   struct netdev *dev;
   struct offload_info info;
-    ovs_be16 dst_port = 0;
-    uint8_t csum_on = false;
   int err;
   info.tc_modify_flow_deleted = false;
@@ -2258,10 +2256,9 @@ parse_flow_put(struct dpif_netlink *dpif, 
struct dpif_flow_put *put)

   return EOPNOTSUPP;
   }
-    /* Get tunnel dst port */
+    /* Check the output port for a tunnel. */
   NL_ATTR_FOR_EACH(nla, left, put->actions, put->actions_len) {
   if (nl_attr_type(nla) == OVS_ACTION_ATTR_OUTPUT) {
-    const struct netdev_tunnel_config *tnl_cfg;
   struct netdev *outdev;
   odp_port_t out_port;
@@ -2271,19 +2268,10 @@ parse_flow_put(struct dpif_netlink *dpif, 
struct dpif_flow_put *put)

   err = EOPNOTSUPP;
   goto out;
   }
-    tnl_cfg = netdev_get_tunnel_config(outdev);
-    if (tnl_cfg && tnl_cfg->dst_port != 0) {
-    dst_port = tnl_cfg->dst_port;
-    }
-    if (tnl_cfg) {
-    csum_on = tnl_cfg->csum;
-    }
   netdev_close(outdev);
   }
   }
-    info.tp_dst_port = dst_port;
-    info.tunnel_csum_on = csum_on;
   info.recirc_id_shared_with_tc = (dpif->user_features
    & 
OVS_DP_F_TC_RECIRC_SHARING);

   err = netdev_flow_put(dev, &match,
diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
index 262faf3c6..e62687c82 100644
--- a/lib/netdev-offload-tc.c
+++ b/lib/netdev-offload-tc.c
@@ -805,11 +805,11 @@ parse_tc_flower_to_match(struct tc_flower 
*flower,

&flower->key.tunnel.ipv6.ipv6_src,
&flower->mask.tunnel.ipv6.ipv6_src);
   }
-    if (flower->key.tunnel.tos) {
+    if (flower->mask.tunnel.tos) {
   match_set_tun_tos_masked(match, 
flower->key.tunnel.tos,

    flower->mask.tunnel.tos);
   }
-    if (flower->key.tunnel.ttl) {
+    if (flower->mask.tunnel.ttl) {
   match_set_tu

Re: [ovs-dev] [PATCH 1/2] netdev-offload-tc: Fix ignoring unknown tunnel keys.

[Roi Dayan via dev]

On 2022-07-13 7:28 PM, Ilya Maximets wrote:

On 7/13/22 12:11, Roi Dayan wrote:



On 2022-07-13 12:01 PM, Roi Dayan wrote:



On 2022-07-06 4:58 PM, Roi Dayan wrote:



On 2022-07-05 1:45 AM, Ilya Maximets wrote:

Current offloading code supports only limited number of tunnel keys
and silently ignores everything it doesn't understand.  This is
causing, for example, offloaded ERSPAN tunnels to not work, because
flow is offloaded, but ERSPAN options are not provided to TC.

There is a number of tunnel keys, which are supported by the userspace,
but silently ignored during offloading:

    OVS_TUNNEL_KEY_ATTR_DONT_FRAGMENT
    OVS_TUNNEL_KEY_ATTR_OAM
    OVS_TUNNEL_KEY_ATTR_VXLAN_OPTS
    OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS

OVS_TUNNEL_KEY_ATTR_CSUM is kind of supported, but only for actions
and for some reason is set from the tunnel port instead of the
provided action, and not currently supported for the tunnel key in
the match.

Addig a default case to fail offloading of unknown attributes.  For
now explicitly allowing incorrect behavior for the DONT_FRAGMENT flag,
otherwise we'll break all tunnel offloading by default.  VXLAN and
ERSPAN options has to fail offloading, because the tunnel will not
work otherwise.  OAM is not a default configurations, so failing it
as well. The missing DONT_FRAGMENT flag though should, probably,
cause frequent flow revalidation, but that is not new with this patch.

Same for the 'match' key, only clearing masks that was actually
consumed, except for the DONT_FRAGMENT and CSUM flags, which are
explicitly allowed and highlighted as broken.

Also, ttl and tos were incorrectly checked by the value instead of a
mask during the flow key dump. Destination port as well as CSUM
configuration for unknown reason was not taken from the actions list
and were passed via HW offload info.

Reported-at: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openvswitch.org%2Fpipermail%2Fovs-dev%2F2022-July%2F395522.html&data=05%7C01%7Croid%40nvidia.com%7Cba6998f8523f4fcf52eb08da64ecba35%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637933265159187181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QDm8f%2FFzZE0X7q26i09UI8zaGK0UkD9tcEChI2XYNZ4%3D&reserved=0
Reported-by: Eelco Chaudron 
Fixes: 8f283af89298 ("netdev-tc-offloads: Implement netdev flow put using tc 
interface")
Signed-off-by: Ilya Maximets 
---
   lib/dpif-netlink.c  | 14 +-
   lib/netdev-offload-tc.c | 57 ++---
   lib/netdev-offload.h    |  3 ---
   3 files changed, 49 insertions(+), 25 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 06e1e8ca0..1e116b4ad 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -2237,8 +2237,6 @@ parse_flow_put(struct dpif_netlink *dpif, struct 
dpif_flow_put *put)
   size_t left;
   struct netdev *dev;
   struct offload_info info;
-    ovs_be16 dst_port = 0;
-    uint8_t csum_on = false;
   int err;
   info.tc_modify_flow_deleted = false;
@@ -2258,10 +2256,9 @@ parse_flow_put(struct dpif_netlink *dpif, struct 
dpif_flow_put *put)
   return EOPNOTSUPP;
   }
-    /* Get tunnel dst port */
+    /* Check the output port for a tunnel. */
   NL_ATTR_FOR_EACH(nla, left, put->actions, put->actions_len) {
   if (nl_attr_type(nla) == OVS_ACTION_ATTR_OUTPUT) {
-    const struct netdev_tunnel_config *tnl_cfg;
   struct netdev *outdev;
   odp_port_t out_port;
@@ -2271,19 +2268,10 @@ parse_flow_put(struct dpif_netlink *dpif, struct 
dpif_flow_put *put)
   err = EOPNOTSUPP;
   goto out;
   }
-    tnl_cfg = netdev_get_tunnel_config(outdev);
-    if (tnl_cfg && tnl_cfg->dst_port != 0) {
-    dst_port = tnl_cfg->dst_port;
-    }
-    if (tnl_cfg) {
-    csum_on = tnl_cfg->csum;
-    }
   netdev_close(outdev);
   }
   }
-    info.tp_dst_port = dst_port;
-    info.tunnel_csum_on = csum_on;
   info.recirc_id_shared_with_tc = (dpif->user_features
    & OVS_DP_F_TC_RECIRC_SHARING);
   err = netdev_flow_put(dev, &match,
diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
index 262faf3c6..e62687c82 100644
--- a/lib/netdev-offload-tc.c
+++ b/lib/netdev-offload-tc.c
@@ -805,11 +805,11 @@ parse_tc_flower_to_match(struct tc_flower *flower,
&flower->key.tunnel.ipv6.ipv6_src,
&flower->mask.tunnel.ipv6.ipv6_src);
   }
-    if (flower->key.tunnel.tos) {
+    if (flower->mask.tunnel.tos) {
   match_set_tun_tos_masked(match, flower->key.tunnel.tos,
    flower->mask.tunnel.tos);
   }
-    if (flower->key.tunnel.ttl) {
+    if (flower->mask.tunnel.ttl) {
   match_set_tun_ttl_masked(match, flower->key.tunnel.ttl,
  

Re: [ovs-dev] [PATCH 2/2] tc: Support masks for tunnel destination ports.

[Ilya Maximets]

On 7/14/22 14:23, Roi Dayan wrote:
> 
> 
> On 2022-07-13 7:46 PM, Ilya Maximets wrote:
>> On 7/12/22 11:47, Roi Dayan wrote:
>>>
>>>
>>> On 2022-07-12 12:23 PM, Ilya Maximets wrote:
 On 7/7/22 09:01, Roi Dayan wrote:
>
>
> On 2022-07-07 9:48 AM, Roi Dayan wrote:
>>
>>
>> On 2022-07-06 5:00 PM, Roi Dayan wrote:
>>>
>>>
>>> On 2022-07-06 3:34 PM, Roi Dayan wrote:


 On 2022-07-06 1:26 PM, Eelco Chaudron wrote:
>
>
> On 5 Jul 2022, at 0:45, Ilya Maximets wrote:
>
>> TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK is supported by TC, and OVS may
>> create a masked match on this field.
>>
>> This change is important as we're not clearing the masks which wasn't
>> really used, so if OVS requests match on ports, we should use the
>> mask and clear, otherwise offloading will fail.
>>
>> Signed-off-by: Ilya Maximets 
>
> Changes look good to me, and all system-traffic.at tests that were 
> passing without the change are still passing, including the failing 
> ERSPAN ones.
>
> Acked-by: Eelco Chaudron 
>

 can we postpone to merge this?
 After this patch simple vxlan rules won't have enc dst port on decap
 rules and currently mlx5 driver must have enc dst port to do the
 offload of the decap rule.
 I'm checking about this limitation and if we can remove it but
 if we can postpone a bit so we won't break users with our nics..

 thanks,
 Roi
>>>
>>>
>>> I finished with the testing and checking I needed.
>>> I don't have a problem with the patch. if something else will raise i'll
>>> start a different discussion.
>>>
>>> Acked-by: Roi Dayan 
>>
>>
>> I have a concern now. today for an offload driver to offload
>> a tunnel decap rule it registers to TC indirect callback.
>>
>> Adding a TC rule on a tunnel device calls all registered drivers
>> to offload the rule.
>> With a single tunnel on a device this is ok but if a system have 
>> multiple tunnels with same src/dst ip but different enc dst port,
>> adding a tc rule on one of the tunnel devices without matching
>> enc dst port will call a driver to offload such a rule in the hw,
>> but that rule is potentially matching all sw tunnels. a driver
>> will have to match implicit on the the enc_dst_port to distinguish
>> between the tunnels.
>>
>> OVS doesn't match explicit on enc_dst_port also when having multiple
>> tunnels as the in SW the packets will be on the correct
>> tunnel device and then pass tc or ovs datapath.
>>
>> After this patch offload drivers must to implicit match the
>> enc_dst_port to avoid having hw rule matching all the tunnels
>> with same src/dst ip. taking the tunnel maybe.
>> e.g. for vxlan tunnel from vxlan->cfg.dst_port
>>
>> What do you think?
>
> to support what i said about implicit match for geneve and mpls for
> example will require kernel change to actually expose their struct
> in a header file.

 But the match contains the input port (tunnel port) right?  And that
 should be sufficient to distinguish tunnels.  Does it mean that HW
 offload in the kernel ignores that match?  Or am I reading that wrong?

>>>
>>> in sw the matching of the rules is done after the packet is already
>>> placed on the sw port. so rule on vxlan1 will patch only packets on
>>> vxlan1.
>>>
>>> for offloaded rule, the input port is ignored for tunnels as once
>>> offloaded, the hw match an incoming packet and is not aware of the
>>> sw ports (tunnels).
>>
>> Sounds like an architectural bug in the kernel.  Should the driver
>> reject offload of rules with non-exact match on tunnel dst port in
>> this case?
> 
> The drivers do reject such rules to avoid the issue described.

So the behavior is correct, it just won't be offloaded.  OK.

> 
>>
>> OTOH, doesn't the original flow that is matching on the tunnel
>> packet have a match on tp_dst?  I'm not 100% sure that is always
>> true though, but it probably is in most cases.
>>
> 
> I didn't understand the question. what original flow?
> with this commit the match doesn't pass tp_dst match to tc.

I meant 'tp_dst' match in the first datapath flow that matches
on the encapsulated packet and sends it to a tunnel port for
decapsulation.  The second flow that matches on tunnel metadata
after decapsulation will have tunnel metadata tp_dst with a zero
mask, while the first flow will likely have an exact match on
the tp_dst, because it was used to decide to which tunnel port
this packet should go for decapsulation.

I just was thinking that if the driver/HW can view these two
flows as one, there should be sufficient data to not swallow
the unrelated traffic.  But I don't really know 

Re: [ovs-dev] [PATCH 2/2] tc: Support masks for tunnel destination ports.

[Roi Dayan via dev]

On 2022-07-13 7:46 PM, Ilya Maximets wrote:

On 7/12/22 11:47, Roi Dayan wrote:



On 2022-07-12 12:23 PM, Ilya Maximets wrote:

On 7/7/22 09:01, Roi Dayan wrote:



On 2022-07-07 9:48 AM, Roi Dayan wrote:



On 2022-07-06 5:00 PM, Roi Dayan wrote:



On 2022-07-06 3:34 PM, Roi Dayan wrote:



On 2022-07-06 1:26 PM, Eelco Chaudron wrote:



On 5 Jul 2022, at 0:45, Ilya Maximets wrote:


TCA_FLOWER_KEY_ENC_UDP_DST_PORT_MASK is supported by TC, and OVS may
create a masked match on this field.

This change is important as we're not clearing the masks which wasn't
really used, so if OVS requests match on ports, we should use the
mask and clear, otherwise offloading will fail.

Signed-off-by: Ilya Maximets 


Changes look good to me, and all system-traffic.at tests that were passing 
without the change are still passing, including the failing ERSPAN ones.

Acked-by: Eelco Chaudron 



can we postpone to merge this?
After this patch simple vxlan rules won't have enc dst port on decap
rules and currently mlx5 driver must have enc dst port to do the
offload of the decap rule.
I'm checking about this limitation and if we can remove it but
if we can postpone a bit so we won't break users with our nics..

thanks,
Roi



I finished with the testing and checking I needed.
I don't have a problem with the patch. if something else will raise i'll
start a different discussion.

Acked-by: Roi Dayan 



I have a concern now. today for an offload driver to offload
a tunnel decap rule it registers to TC indirect callback.

Adding a TC rule on a tunnel device calls all registered drivers
to offload the rule.
With a single tunnel on a device this is ok but if a system have multiple 
tunnels with same src/dst ip but different enc dst port,
adding a tc rule on one of the tunnel devices without matching
enc dst port will call a driver to offload such a rule in the hw,
but that rule is potentially matching all sw tunnels. a driver
will have to match implicit on the the enc_dst_port to distinguish
between the tunnels.

OVS doesn't match explicit on enc_dst_port also when having multiple
tunnels as the in SW the packets will be on the correct
tunnel device and then pass tc or ovs datapath.

After this patch offload drivers must to implicit match the
enc_dst_port to avoid having hw rule matching all the tunnels
with same src/dst ip. taking the tunnel maybe.
e.g. for vxlan tunnel from vxlan->cfg.dst_port

What do you think?


to support what i said about implicit match for geneve and mpls for
example will require kernel change to actually expose their struct
in a header file.


But the match contains the input port (tunnel port) right?  And that
should be sufficient to distinguish tunnels.  Does it mean that HW
offload in the kernel ignores that match?  Or am I reading that wrong?



in sw the matching of the rules is done after the packet is already
placed on the sw port. so rule on vxlan1 will patch only packets on
vxlan1.

for offloaded rule, the input port is ignored for tunnels as once
offloaded, the hw match an incoming packet and is not aware of the
sw ports (tunnels).


Sounds like an architectural bug in the kernel.  Should the driver
reject offload of rules with non-exact match on tunnel dst port in
this case?


The drivers do reject such rules to avoid the issue described.



OTOH, doesn't the original flow that is matching on the tunnel
packet have a match on tp_dst?  I'm not 100% sure that is always
true though, but it probably is in most cases.



I didn't understand the question. what original flow?
with this commit the match doesn't pass tp_dst match to tc.





I think we should keep ovs TC to keep explicit match on enc_dst_port.
We can add a comment explaining why.





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

Re: [ovs-dev] [PATCH ovn v5] controller: Add delay after multicast ARP packet

[Dumitru Ceara]

On 7/14/22 12:37, Ales Musil wrote:
> The ovn-controller had a race condition over MAC
> binding table with other controllers. When multiple
> controllers received GARP from single source usually
> the one who was able to win the race put it into SB.
> The others got transaction error which triggered
> full recompute even if it's not needed.
> 
> In order to reduce the chance of multiple controllers
> trying to insert same row at the same time add slight
> delay to the MAC binding processing. This delay
> is random interval between 1-50 in ms. This greatly
> reduces the chance that multiple controllers will try
> to add MAC binding at exactly the same time. This applies
> only to multicast ARP request which applies only to GARP
> that is sent to broadcast address.
> 
> Local testing with this delay vs without show significantly
> reduced chance of hitting the transaction error.
> 
> During the testing 10 GARPs was sent to two controllers
> at the same time. Without proposed fix at least one controller
> had multiple transaction errors present every test iteration.
> 
> With the proposed fix the transaction error was reduced to a
> single one when it happened which was usually in less than
> 10% of the iterations.
> 
> As was mentioned before the race condition can still happen,
> but the chance is greatly reduced.
> 
> Suggested-by: Daniel Alvarez Sanchez 
> Signed-off-by: Ales Musil 
> ---
> v3: Rebase on top of current main.
> Change the delay to be per ARP request instead of
> single delay for everything. This allows the possibility
> to delay only multicast/broadcast AP as suggested by Han.
> v4,v5: Address comments from Dumitru.
> ---

Thanks for this new revision!

I have two very small comments but I don't think you need to send a v6
for this, let's see if the maintainers require that or if the
suggestions can be incorporated when the patch is accepted.

Acked-by: Dumitru Ceara 

>  controller/mac-learn.c | 41 +
>  controller/mac-learn.h |  9 +++--
>  controller/pinctrl.c   | 27 ++-
>  tests/ovn.at   |  6 +++---
>  4 files changed, 61 insertions(+), 22 deletions(-)
> 
> diff --git a/controller/mac-learn.c b/controller/mac-learn.c
> index 27634dca8..a27607016 100644
> --- a/controller/mac-learn.c
> +++ b/controller/mac-learn.c
> @@ -18,14 +18,18 @@
>  #include "mac-learn.h"
>  
>  /* OpenvSwitch lib includes. */
> +#include "openvswitch/poll-loop.h"
>  #include "openvswitch/vlog.h"
>  #include "lib/packets.h"
> +#include "lib/random.h"
>  #include "lib/smap.h"
> +#include "lib/timeval.h"
>  
>  VLOG_DEFINE_THIS_MODULE(mac_learn);
>  
>  #define MAX_MAC_BINDINGS 1000
>  #define MAX_FDB_ENTRIES  1000
> +#define MAX_MAC_BINDING_DELAY_MSEC 50
>  
>  static size_t mac_binding_hash(uint32_t dp_key, uint32_t port_key,
> struct in6_addr *);
> @@ -46,25 +50,19 @@ ovn_mac_bindings_init(struct hmap *mac_bindings)
>  }
>  
>  void
> -ovn_mac_bindings_flush(struct hmap *mac_bindings)
> +ovn_mac_bindings_destroy(struct hmap *mac_bindings)
>  {
>  struct mac_binding *mb;
>  HMAP_FOR_EACH_POP (mb, hmap_node, mac_bindings) {
>  free(mb);
>  }
> -}
> -
> -void
> -ovn_mac_bindings_destroy(struct hmap *mac_bindings)
> -{
> -ovn_mac_bindings_flush(mac_bindings);
>  hmap_destroy(mac_bindings);
>  }
>  
>  struct mac_binding *
>  ovn_mac_binding_add(struct hmap *mac_bindings, uint32_t dp_key,
>  uint32_t port_key, struct in6_addr *ip,
> -struct eth_addr mac)
> +struct eth_addr mac, bool is_unicast)
>  {
>  uint32_t hash = mac_binding_hash(dp_key, port_key, ip);
>  
> @@ -75,10 +73,13 @@ ovn_mac_binding_add(struct hmap *mac_bindings, uint32_t 
> dp_key,
>  return NULL;
>  }
>  
> +uint32_t delay = is_unicast
> +? 0 : random_range(MAX_MAC_BINDING_DELAY_MSEC) + 1;

Nit: the coding-style doesn't seem to be extremely specific but the way
I read it this should be indented a bit differently:

uint32_t delay = is_unicast
 ? 0 : random_range(MAX_MAC_BINDING_DELAY_MSEC) + 1;

Or maybe cleaner:

uint32_t delay = !is_unicast
 ? random_range(MAX_MAC_BINDING_DELAY_MSEC) + 1
 : 0;

>  mb = xmalloc(sizeof *mb);
>  mb->dp_key = dp_key;
>  mb->port_key = port_key;
>  mb->ip = *ip;
> +mb->commit_at_ms = time_msec() + delay;
>  hmap_insert(mac_bindings, &mb->hmap_node, hash);
>  }
>  mb->mac = mac;
> @@ -86,6 +87,30 @@ ovn_mac_binding_add(struct hmap *mac_bindings, uint32_t 
> dp_key,
>  return mb;
>  }
>  
> +/* This is called from ovn-controller main context */
> +void
> +ovn_mac_binding_wait(struct hmap *mac_bindings)
> +{
> +struct mac_binding *mb;
> +
> +HMAP_FOR_EACH (mb, hmap_node, mac_bindings) {
> +poll_timer_wait_until(mb->commit_at_ms);
> +}
> +}
> +
> +void

Re: [ovs-dev] [PATCH ovn v3] pinctrl.c: Add delay after ARP packet

[Ales Musil]

On Thu, Jul 14, 2022 at 11:02 AM Dumitru Ceara  wrote:

> On 7/14/22 10:15, Ales Musil wrote:
> > Hi,
> >
>
> Hi Ales,
>

Hi Dumitru,

posted v5.


>
> > thank you for the review, I have posted v4. See also my replies inline.
> >
> > On Wed, Jul 13, 2022 at 10:02 PM Dumitru Ceara 
> wrote:
> >
> >> On 7/13/22 14:36, Ales Musil wrote:
> >>> The ovn-controller had a race condition over MAC
> >>> binding table with other controllers. When multiple
> >>> controllers received GARP from single source usually
> >>> the one who was able to win the race put it into SB.
> >>> The others got transaction error which triggered
> >>> full recompute even if it's not needed.
> >>>
> >>> In order to reduce the chance of multiple controllers
> >>> trying to insert same row at the same time add slight
> >>> delay to the MAC binding processing. This delay
> >>> is random interval between 1-50 in ms. This greatly
> >>> reduces the chance that multiple controllers will try
> >>> to add MAC binding at exactly the same time. This applies
> >>> only to multicast ARP request which applies only to GARP
> >>> that is sent to broadcast address.
> >>>
> >>> Local testing with this delay vs without show significantly
> >>> reduced chance of hitting the transaction error.
> >>>
> >>> During the testing 10 GARPs was sent to two controllers
> >>> at the same time. Without proposed fix at least one controller
> >>> had multiple transaction errors present every test iteration.
> >>>
> >>> With the proposed fix the transaction error was reduced to a
> >>> single one when it happened which was usually in less than
> >>> 10% of the iterations.
> >>>
> >>> As was mentioned before the race condition can still happen,
> >>> but the chance is greatly reduced.
> >>>
> >>> Suggested-by: Daniel Alvarez Sanchez 
> >>> Signed-off-by: Ales Musil 
> >>> ---
> >>
> >> Hi Ales,
> >>
> >> Thanks for this revision!  In general it makes sense but I have some
> >> comments here and there.
> >>
> >>> v3: Rebase on top of current main.
> >>> Change the delay to be per ARP request instead of
> >>> single delay for everything. This allows the possibility
> >>> to delay only multicast/broadcast AP as suggested by Han.
> >>> ---
> >>>  controller/mac-learn.c | 23 ++-
> >>>  controller/mac-learn.h |  7 ++-
> >>>  controller/pinctrl.c   | 33 -
> >>>  tests/ovn.at   |  7 +++
> >>>  4 files changed, 59 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/controller/mac-learn.c b/controller/mac-learn.c
> >>> index 27634dca8..b7b392bb1 100644
> >>> --- a/controller/mac-learn.c
> >>> +++ b/controller/mac-learn.c
> >>> @@ -20,12 +20,15 @@
> >>>  /* OpenvSwitch lib includes. */
> >>>  #include "openvswitch/vlog.h"
> >>>  #include "lib/packets.h"
> >>> +#include "lib/random.h"
> >>>  #include "lib/smap.h"
> >>> +#include "lib/timeval.h"
> >>>
> >>>  VLOG_DEFINE_THIS_MODULE(mac_learn);
> >>>
> >>>  #define MAX_MAC_BINDINGS 1000
> >>>  #define MAX_FDB_ENTRIES  1000
> >>> +#define MAX_MAC_BINDING_DELAY_MSEC 50
> >>>
> >>>  static size_t mac_binding_hash(uint32_t dp_key, uint32_t port_key,
> >>> struct in6_addr *);
> >>> @@ -64,7 +67,7 @@ ovn_mac_bindings_destroy(struct hmap *mac_bindings)
> >>>  struct mac_binding *
> >>>  ovn_mac_binding_add(struct hmap *mac_bindings, uint32_t dp_key,
> >>>  uint32_t port_key, struct in6_addr *ip,
> >>> -struct eth_addr mac)
> >>> +struct eth_addr mac, bool is_delayed)
> >>
> >> What if we pass 'int max_delay_ms' instead of 'bool is_delayed'?
> >>
> >
> > This kinda breaks the encapsulation a bit. Why would the code outside
> > need to know what is the max delay? I am still inclined to have it as a
> > bool.
> >
>
> It's arguable in my opinion.  The code outside (pinctrl) uses the delay
> value already.  Anyhow, it's probably fine to leave it as is.
>

I have encapsulated the check so the delay/commit_at is not exposed
outside.


>
> >
> >>
> >>>  {
> >>>  uint32_t hash = mac_binding_hash(dp_key, port_key, ip);
> >>>
> >>> @@ -79,6 +82,11 @@ ovn_mac_binding_add(struct hmap *mac_bindings,
> >> uint32_t dp_key,
> >>>  mb->dp_key = dp_key;
> >>>  mb->port_key = port_key;
> >>>  mb->ip = *ip;
> >>> +mb->delay = 0;
> >>> +mb->created = time_msec();
> >>> +if (is_delayed) {
> >>> +mb->delay = random_range(MAX_MAC_BINDING_DELAY_MSEC) + 1;
> >>> +}
> >>
> >> This could become:
> >>
> >> mb->delay = max_delay_ms ? random_range(max_delay_ms) + 1 : 0;
> >>
> >
> > Done
> >
> >
> >>
> >>>  hmap_insert(mac_bindings, &mb->hmap_node, hash);
> >>>  }
> >>>  mb->mac = mac;
> >>> @@ -86,6 +94,19 @@ ovn_mac_binding_add(struct hmap *mac_bindings,
> >> uint32_t dp_key,
> >>>  return mb;
> >>>  }
> >>>
> >>> +long long
> >>> +ovn_mac_binding_shortest_delay(struct hmap *mac_bindings)
> >>> +{
> >>> +lo

Re: [ovs-dev] [PATCH] ovsdb: Add missing ovs-thread include.

[Dumitru Ceara]

On 7/14/22 12:22, Ilya Maximets wrote:
> On 7/14/22 09:42, Dumitru Ceara wrote:
>> On 7/13/22 22:38, Ilya Maximets wrote:
>>> MSVC doesn't have pthread_t defined by default as other compilers,
>>> so the build fails without the header.
>>>
>>> Fixes: 3cd2cbd684e0 ("ovsdb: Prepare snapshot JSON in a separate thread.")
>>> Signed-off-by: Ilya Maximets 
>>> ---
>>>
>>> Not sure how I missed that.  Sorry.
>>>
>>
>> It can happen. :)
>>
>> Acked-by: Dumitru Ceara 
>>
>>>  ovsdb/ovsdb.h | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/ovsdb/ovsdb.h b/ovsdb/ovsdb.h
>>> index 2f77821e0..d05e7c64a 100644
>>> --- a/ovsdb/ovsdb.h
>>> +++ b/ovsdb/ovsdb.h
>>> @@ -21,6 +21,7 @@
>>>  #include "openvswitch/list.h"
>>>  #include "openvswitch/shash.h"
>>>  #include "openvswitch/uuid.h"
>>> +#include "ovs-thread.h"
>>>  
>>>  struct json;
>>>  struct ovsdb_log;
>>
>> If you agree, I'd also remove the '#include "ovs-thread.h"' from all
>> files that already include "ovsdb.h".  But it's not a must.
> 
> Every file should include what it is actually using.
> It's not obvious why inclusion of ovsdb.h should give
> access to ovs-thread functions.  So, I kept it as is.
> 

Fair point.

> Thanks for review!  Applied.
> 

Cool.

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

[ovs-dev] [PATCH ovn v5] controller: Add delay after multicast ARP packet

[Ales Musil]

The ovn-controller had a race condition over MAC
binding table with other controllers. When multiple
controllers received GARP from single source usually
the one who was able to win the race put it into SB.
The others got transaction error which triggered
full recompute even if it's not needed.

In order to reduce the chance of multiple controllers
trying to insert same row at the same time add slight
delay to the MAC binding processing. This delay
is random interval between 1-50 in ms. This greatly
reduces the chance that multiple controllers will try
to add MAC binding at exactly the same time. This applies
only to multicast ARP request which applies only to GARP
that is sent to broadcast address.

Local testing with this delay vs without show significantly
reduced chance of hitting the transaction error.

During the testing 10 GARPs was sent to two controllers
at the same time. Without proposed fix at least one controller
had multiple transaction errors present every test iteration.

With the proposed fix the transaction error was reduced to a
single one when it happened which was usually in less than
10% of the iterations.

As was mentioned before the race condition can still happen,
but the chance is greatly reduced.

Suggested-by: Daniel Alvarez Sanchez 
Signed-off-by: Ales Musil 
---
v3: Rebase on top of current main.
Change the delay to be per ARP request instead of
single delay for everything. This allows the possibility
to delay only multicast/broadcast AP as suggested by Han.
v4,v5: Address comments from Dumitru.
---
 controller/mac-learn.c | 41 +
 controller/mac-learn.h |  9 +++--
 controller/pinctrl.c   | 27 ++-
 tests/ovn.at   |  6 +++---
 4 files changed, 61 insertions(+), 22 deletions(-)

diff --git a/controller/mac-learn.c b/controller/mac-learn.c
index 27634dca8..a27607016 100644
--- a/controller/mac-learn.c
+++ b/controller/mac-learn.c
@@ -18,14 +18,18 @@
 #include "mac-learn.h"
 
 /* OpenvSwitch lib includes. */
+#include "openvswitch/poll-loop.h"
 #include "openvswitch/vlog.h"
 #include "lib/packets.h"
+#include "lib/random.h"
 #include "lib/smap.h"
+#include "lib/timeval.h"
 
 VLOG_DEFINE_THIS_MODULE(mac_learn);
 
 #define MAX_MAC_BINDINGS 1000
 #define MAX_FDB_ENTRIES  1000
+#define MAX_MAC_BINDING_DELAY_MSEC 50
 
 static size_t mac_binding_hash(uint32_t dp_key, uint32_t port_key,
struct in6_addr *);
@@ -46,25 +50,19 @@ ovn_mac_bindings_init(struct hmap *mac_bindings)
 }
 
 void
-ovn_mac_bindings_flush(struct hmap *mac_bindings)
+ovn_mac_bindings_destroy(struct hmap *mac_bindings)
 {
 struct mac_binding *mb;
 HMAP_FOR_EACH_POP (mb, hmap_node, mac_bindings) {
 free(mb);
 }
-}
-
-void
-ovn_mac_bindings_destroy(struct hmap *mac_bindings)
-{
-ovn_mac_bindings_flush(mac_bindings);
 hmap_destroy(mac_bindings);
 }
 
 struct mac_binding *
 ovn_mac_binding_add(struct hmap *mac_bindings, uint32_t dp_key,
 uint32_t port_key, struct in6_addr *ip,
-struct eth_addr mac)
+struct eth_addr mac, bool is_unicast)
 {
 uint32_t hash = mac_binding_hash(dp_key, port_key, ip);
 
@@ -75,10 +73,13 @@ ovn_mac_binding_add(struct hmap *mac_bindings, uint32_t 
dp_key,
 return NULL;
 }
 
+uint32_t delay = is_unicast
+? 0 : random_range(MAX_MAC_BINDING_DELAY_MSEC) + 1;
 mb = xmalloc(sizeof *mb);
 mb->dp_key = dp_key;
 mb->port_key = port_key;
 mb->ip = *ip;
+mb->commit_at_ms = time_msec() + delay;
 hmap_insert(mac_bindings, &mb->hmap_node, hash);
 }
 mb->mac = mac;
@@ -86,6 +87,30 @@ ovn_mac_binding_add(struct hmap *mac_bindings, uint32_t 
dp_key,
 return mb;
 }
 
+/* This is called from ovn-controller main context */
+void
+ovn_mac_binding_wait(struct hmap *mac_bindings)
+{
+struct mac_binding *mb;
+
+HMAP_FOR_EACH (mb, hmap_node, mac_bindings) {
+poll_timer_wait_until(mb->commit_at_ms);
+}
+}
+
+void
+ovn_mac_binding_remove(struct mac_binding *mb, struct hmap *mac_bindings)
+{
+hmap_remove(mac_bindings, &mb->hmap_node);
+free(mb);
+}
+
+bool
+ovn_mac_binding_can_commit(const struct mac_binding *mb, long long now)
+{
+return now >= mb->commit_at_ms;
+}
+
 /* fdb functions. */
 void
 ovn_fdb_init(struct hmap *fdbs)
diff --git a/controller/mac-learn.h b/controller/mac-learn.h
index e7e8ba2d3..57c50c58b 100644
--- a/controller/mac-learn.h
+++ b/controller/mac-learn.h
@@ -31,16 +31,21 @@ struct mac_binding {
 
 /* Value. */
 struct eth_addr mac;
+
+/* Timestamp when to commit to SB. */
+long long commit_at_ms;
 };
 
 void ovn_mac_bindings_init(struct hmap *mac_bindings);
-void ovn_mac_bindings_flush(struct hmap *mac_bindings);
 void ovn_mac_bindings_destroy(struct hmap *mac_bindings);
+void ovn_mac_binding_wait(struct hmap *mac_bindings);
+void ovn_mac_binding_remo

Re: [ovs-dev] [PATCH] ovsdb: Add missing ovs-thread include.

[Ilya Maximets]

On 7/14/22 09:42, Dumitru Ceara wrote:
> On 7/13/22 22:38, Ilya Maximets wrote:
>> MSVC doesn't have pthread_t defined by default as other compilers,
>> so the build fails without the header.
>>
>> Fixes: 3cd2cbd684e0 ("ovsdb: Prepare snapshot JSON in a separate thread.")
>> Signed-off-by: Ilya Maximets 
>> ---
>>
>> Not sure how I missed that.  Sorry.
>>
> 
> It can happen. :)
> 
> Acked-by: Dumitru Ceara 
> 
>>  ovsdb/ovsdb.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/ovsdb/ovsdb.h b/ovsdb/ovsdb.h
>> index 2f77821e0..d05e7c64a 100644
>> --- a/ovsdb/ovsdb.h
>> +++ b/ovsdb/ovsdb.h
>> @@ -21,6 +21,7 @@
>>  #include "openvswitch/list.h"
>>  #include "openvswitch/shash.h"
>>  #include "openvswitch/uuid.h"
>> +#include "ovs-thread.h"
>>  
>>  struct json;
>>  struct ovsdb_log;
> 
> If you agree, I'd also remove the '#include "ovs-thread.h"' from all
> files that already include "ovsdb.h".  But it's not a must.

Every file should include what it is actually using.
It's not obvious why inclusion of ovsdb.h should give
access to ovs-thread functions.  So, I kept it as is.

Thanks for review!  Applied.

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

Re: [ovs-dev] [PATCH v3 3/8] debian: Update packaging source from Debian/Ubuntu.

[Ilya Maximets]

On 7/14/22 08:19, Frode Nordahl wrote:
> On Tue, Jul 12, 2022 at 12:59 AM Ilya Maximets  wrote:
>>
>> On 7/11/22 20:12, Ilya Maximets wrote:
>>> On 7/7/22 19:42, Frode Nordahl wrote:
 diff --git a/debian/control b/debian/control
 new file mode 100644
 index 0..7a79d1ff0
 --- /dev/null
 +++ b/debian/control
 @@ -0,0 +1,298 @@
 +Source: openvswitch
 +Section: net
 +Priority: optional
 +Maintainer: Open vSwitch developers 
 +Uploaders:
 + Simon Horman ,
 + Thomas Goirand ,
 + Michal Arbet ,
 + Luca Boccassi ,
 + Christian Ehrhardt ,
 +Build-Depends:
 + autoconf (>= 2.64),
 + automake (>= 1.10),
 + bzip2,
 + debhelper-compat (= 13),
 + dh-exec,
 + dh-python,
 + dh-sequence-python3,
 + dh-sequence-sphinxdoc,
 + graphviz,
 + iproute2,
 + libcap-ng-dev,
 + libdbus-1-dev [amd64 i386 ppc64el arm64],
 + libdpdk-dev (>= 21.11) [amd64 i386 ppc64el arm64],
>>>
>>> The DPDK dependency is one of the most worrying one, since
>>> it significantly limits the number of systems this package
>>> can be built for.  For example, we can't build the package
>>> for Ubuntu older than 22.04, IIUC.   There is also no
>>> straightforward way to build DPDK package from sources, so
>>> it will be tricky to fulfill that dependency if not available.
>>>
>>> Can it be made optional somehow?  Or maybe some environment
>>> variable to disable build of openvswitch-switch-dpdk package?
>>>
>>> I guess, some 'ifneq' can be added to debian/rules to not
>>> configure with DPDK, e.g. 'nodpdk' for DEB_BUILD_OPTIONS.
>>> But I'm not sure if the same can be done for debian/control
>>> and list of packages and dependencies.
> 
> debian/rules is indeed flexible and you're right about debian/control
> being more static. Generating it along the lines of what you proposed
> below could work.
> 
>>> It's also interesting in terms of migrating to new versions
>>> of DPDK.  For example, will there be an Ubuntu image with
>>> DPDK 22.11 available when it is released?  We will need it
>>> for GHA when OVS will upgrade to a new version of DPDK.
> 
> We tend to track DPDK also in the interim Ubuntu releases, for example
> DPDK 20.11 was made available in the development branch of Ubuntu
> 21.04 at the end of 2020/beginning of 2021. OVS picked up DPDK 20.11
> around May 2021 [1], which also would be after the official release.
> 
> We can of course not guarantee that it will always be available by the
> time OVS wants to update, but so far we appear to be in a good shape.
> When doing the initial breakout of the "linux deb" job [2] I made use
> of available GHA images, the interim releases will of course not be
> available there. What we could do instead is to run the test within a
> LXD container on GHA, as those images are published even before the
> official release, this would also allow us to expand the matrix to
> cover building on Debian if we want to. I would like to defer this to
> a future change if that is alright with you, what do you think?

Yes, I agree.  We don't need to decide on that right now, we have
to to deal with it before the next DPDK upgrade.  I also used
the 'container:' configuration of GHA before for preparing a job
that builds fedora rpms, it works fine (I have a patch somewhere,
but I never actually sent it).

> 
> 0: https://launchpad.net/ubuntu/+source/dpdk/20.11-1
> 1: 
> https://github.com/openvswitch/ovs/commit/b45958bf75db121a05cb8aa07825f23a771130b9
> 2: 
> http://patchwork.ozlabs.org/project/openvswitch/patch/20220707174223.923183-4-frode.nord...@canonical.com/
> 
> 
>> I have some stupid solution for this problem below.  Not a full
>> solution, as we will likely not be able to build with DPDK in
>> CI once new version of DPDK is out and OVS updated to use it.
>> But the change gives user a choice to build with DPDK or without
>> by simply forcing them to choose the variant of a control file.
>> So, we'll be able to just disable one of the targets in a matrix
>> if needed.
>>
>> With that applied I was able to successfully build packages
>> on my Ubuntu 20.04 machine.  I had to lower the compat version
>> down to 10, and we don't seem to use any functionality from
>> higher versions.  I understand why distributions want to have
>> a specific version, but for upstream it makes sense to relax the
>> requirement a little bit.  This way we can support building on
>> older versions of Ubuntu, for example.
>>
>> While playing with that I also fixed broken dh_clean target
>> (missing '/' for directories), and re-introduced updated
>> .gitignore file that we still need.
>>
>> One step forward might be to wrap everything into a 'make'
>> target like we do for 'make rpm-fedora', but doesn't seem very
>> important.
>>
>> What do you think about the change below?  Does it make sense?
>> Is there a better way?
> 
> Thank you for putting this together, and it does make sense to me.
> Leaving the DPDK build out by 

Re: [ovs-dev] [PATCH v10 10/10] odp-execute: Add ISA implementation of set_masked IPv4 action

[Pai G, Sunil]

> -Original Message-
> From: Van Haaren, Harry 
> Sent: Wednesday, July 13, 2022 11:58 PM
> To: d...@openvswitch.org
> Cc: i.maxim...@ovn.org; echau...@redhat.com; Amber, Kumar
> ; Pai G, Sunil ; Finn, Emma
> ; Stokes, Ian 
> Subject: [PATCH v10 10/10] odp-execute: Add ISA implementation of
> set_masked IPv4 action
> 
> From: Emma Finn 
> 
> This commit adds support for the AVX512 implementation of the
> ipv4_set_addrs action as well as an AVX512 implementation of updating the
> checksums.
> 
> Signed-off-by: Emma Finn 
> ---
>  lib/odp-execute-avx512.c | 208 +++
>  1 file changed, 208 insertions(+)
> 

LGTM, 
Acked-by: Sunil Pai G 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v10 09/10] odp-execute: Add ISA implementation of set_masked ETH

[Pai G, Sunil]

> -Original Message-
> From: Van Haaren, Harry 
> Sent: Wednesday, July 13, 2022 11:58 PM
> To: d...@openvswitch.org
> Cc: i.maxim...@ovn.org; echau...@redhat.com; Amber, Kumar
> ; Pai G, Sunil ; Finn, Emma
> ; Stokes, Ian 
> Subject: [PATCH v10 09/10] odp-execute: Add ISA implementation of
> set_masked ETH
> 
> From: Emma Finn 
> 
> This commit includes infrastructure changes for enabling set_masked_X
> actions and also adds support for the AVX512 implementation of the
> eth_set_addrs action.
> 
> Signed-off-by: Emma Finn 
> ---
>  lib/odp-execute-avx512.c  | 90 +++
>  lib/odp-execute-private.c | 14 ++
>  lib/odp-execute-private.h |  3 ++
>  lib/odp-execute.c | 49 +++--
>  lib/odp-execute.h |  3 ++
>  5 files changed, 137 insertions(+), 22 deletions(-)
> 

LGTM, 
Acked-by: Sunil Pai G 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH ovn] tests: Fix flaky "interconnection - IGMP/MLD multicast" test.

[Dumitru Ceara]

Make sure the IGMP/MLD group is learned and processed before sending
traffic.  Otherwise the IP multicast packets get dropped.

Spotted in one of the ovsrobot runs:
https://github.com/ovsrobot/ovn/runs/7321368564?check_suite_focus=true

  ovn.at:24712: waiting until check_packets 'hv1/vif1-tx.pcap expected_az1' \
   'hv2/vif2-tx.pcap expected_az2'...
  ovn.at:24712: wait failed after 30 seconds
  --- exp   2022-07-13 13:55:21.909520463 +
  +++ rcv   2022-07-13 13:55:21.909520463 +
  @@ -3,6 +3,5 @@ --- hv1/vif1-tx.pcap
   
00010001010086dd600e113e00100042ff0adeadbeef000193407a69000e2b4e61736461640a

   --- hv2/vif2-tx.pcap
  
-01005e000144000202000800451e95f140001e117e6b2c2c2c02ef000144e518e518000aed35
   
00010002020086dd600e113e00100042ff0adeadbeef000193407a69000e2b4e61736461640a

  ../../../tests/ovs-macros.at:255: hard failure
  561. ovn.at:24712: 561. interconnection - IGMP/MLD multicast -- ovn-northd -- 
parallelization=no -- ovn_monitor_all=yes (ovn.at:24712): FAILED 
(ovs-macros.at:255)

Signed-off-by: Dumitru Ceara 
---
 tests/ovn.at | 12 
 1 file changed, 12 insertions(+)

diff --git a/tests/ovn.at b/tests/ovn.at
index c346975e6..c4c1c40e9 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -24885,6 +24885,18 @@ send_mld_v2_report hv2-vif2 hv2 \
 ff0adeadbeef0001 04 c0e4 \
 /dev/null
 
+# Check that the IGMP and MLD groups are learned on both AZs (on the LS
+# and TS).
+ovn_as az1
+wait_row_count IGMP_Group 2 address=239.0.1.68
+wait_row_count IGMP_Group 2 address='"ff0a:dead:beef::1"'
+check ovn-nbctl --wait=hv sync
+
+ovn_as az2
+wait_row_count IGMP_Group 2 address=239.0.1.68
+wait_row_count IGMP_Group 2 address='"ff0a:dead:beef::1"'
+check ovn-nbctl --wait=hv sync
+
 # Send an IP multicast packet from LSP2, it should be forwarded
 # to lsp1 and lsp3.
 > expected_az1
-- 
2.31.1

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

Re: [ovs-dev] [PATCH] netdev-linux: Fix leak of a tc police get/del reply.

[Ilya Maximets]

On 7/14/22 07:33, Simon Horman wrote:
> On Wed, Jul 13, 2022 at 04:30:41PM +0200, Ilya Maximets wrote:
>>  Direct leak of 64 byte(s) in 1 object(s) allocated from:
>>0 0x51b1d8 in malloc (vswitchd/ovs-vswitchd+0x51b1d8)
>>1 0xc81ded in xmalloc__ lib/util.c:137:15
>>2 0xc81ded in xmalloc lib/util.c:172:12
>>3 0xb32153 in ofpbuf_new lib/ofpbuf.c:168:24
>>4 0xd563e4 in nl_sock_transact lib/netlink-socket.c:1113:34
>>5 0xd56261 in nl_transact lib/netlink-socket.c:1812:13
>>6 0xd5e096 in tc_transact lib/tc.c:238:17
>>7 0xd01622 in tc_del_policer_action lib/netdev-linux.c:5807:13
>>8 0xd2e681 in meter_tc_del_policer lib/netdev-offload-tc.c:2827:15
>>9 0x94ec21 in meter_offload_del lib/netdev-offload.c:245:23
>>   10 0xcc86c4 in dpif_netlink_meter_del lib/dpif-netlink.c:4288:9
>>   11 0x86c595 in dpif_meter_del lib/dpif.c:2014:13
>>   12 0x663439 in free_meter_id ofproto/ofproto-dpif.c:6789:5
>>   13 0xb47518 in ovsrcu_call_postponed lib/ovs-rcu.c:346:13
>>   14 0xb48031 in ovsrcu_postpone_thread lib/ovs-rcu.c:362:14
>>   15 0xb5015a in ovsthread_wrapper lib/ovs-thread.c:422:12
>>   16 0x7f86af4081ce in start_thread (/lib64/libpthread.so.0+0x81ce)
>>
>> Fixes: 5c039ddc64ff ("netdev-linux: Add functions to manipulate tc police 
>> action")
>> Signed-off-by: Ilya Maximets 
> 
> Acked-by: Simon Horman 
> 
> I'd also be happy to apply this patch if that was your intention.

Feel free to apply these 3 fixes, if you have time.  Thanks!
The one about misaligned access in pedit action will also need
a backport to stable branches.

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

Re: [ovs-dev] [RFC ovn] controller: send GARPs for LSPs in vlan-backed network scenario

[shy liu]

> 2022年7月14日 下午4:32，Lorenzo Bianconi  写道：
> 
>>> 
>>> On 7/13/22 18:07, Lorenzo Bianconi wrote:
> On 6/17/22 00:31, Lorenzo Bianconi wrote:
>> When using VLAN backed networks and OVN routers leveraging the
>> 'ovn-chassis-mac-mappings' option, the eth.src field is replaced by the
>> chassis mac address in order to not expose the router mac address from
>> different nodes and confuse the TOR switch. However doing so the TOR
>> switch is not able to learn the port/mac bindings for routed E/W traffic
>> and it is force to always flood it. Fix this issue adding the capability
>> to send GARP traffic for logical switch ports if the corresponding 
>> logical
>> switch has the ovn-lsp-garp parameter set to true in the option column.
>> More into about the issue can be found here [0].
>> 
>> [0] 
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-September/050678.html
>>  
>> 
>> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2087779 
>> 
>> 
>> Signed-off-by: Lorenzo Bianconi > >
>> ---
> 
> Hi Lorenzo,
 
 Hi Dumitru,
 
 Thanks for reviewing it :)
 
> 
> I have a few concerns with this approach:
> 
> a. The CMS will have to set this option for all VMs on all logical
> switches which will enable periodic GARPs for all of them all the time.
> That seems like quite a lot of broadcast traffic in the fabric.
> 
> b. There's no guarantee that the GARPs are sent in time to prevent the
> FDB timeouts on the ToR switches.  At best we could make the interval
> configurable but I don't think this is way better either.
> 
> c. This is not really introduced by your patch but we will be causing
> this more often now.  With the topology:
> 
> (HV1) VM1 -- LS1 --- LR -- LS2 -- VM2 (HV2)
>   (VLAN-backed network)
> 
> HV1 configured with chassis mac mapping HV1-MAC
> HV2 configured with chassis mac mapping HV2-MAC
> 
> We're leaking MAC addresses from LS1's broadcast domain (VM1-MAC) and
> from LS2's broadcast domain (VM2-MAC) into the fabric.  I'm not sure
> that's OK.
> 
> I think a proper solution is to change how we run the logical pipelines
> in case of vlan-backed networks.  We currently have an assymetry:
> 
> For packets flowing from VM1 to VM2 we execute:
> - on HV1: LS1-ingress, LS1-egress, LR-ingress, LR-egress, LS2-ingress
> - on HV2: LS2-egress
> 
> For packets flowing from VM2 to VM1 we execute:
> - on HV2: LS2-ingress, LS2-egress, LR-ingress, LR-egress, LS1-ingress
> - on HV1: LS1-egress
> 
> What if we change this to:
> VM1 -> VM2:
> - on HV1: LS1-ingress, LS1-egress, LR-ingress
> - on HV2: LR-egress, LS2-ingress, LS2-egress
> 
> VM2 -> VM1:
> - on HV2: LS2-ingress, LS2-egress, LR-ingress
> - on HV2: LR-egress, LS1-ingress, LS1-egress
 
 I do not know why the current architecture is done this way (any 
 suggestions??).
 I guess the approach you suggested should work. Are we introducing any 
 backward
 compatibility issue?
>>> 
>>> We would probably create a compatibility issue. :)
>>> 
>>> I don't know if this approach would even work, I was just trying to
>>> imagine how traffic from within OVN should be seen on the fabric in this
>>> case.
>>> 
>>> Maybe we need to think some more about other options.
>>> 
>>> Regards,
>>> Dumitru
>> Hi Dumitru and Lorenzo, 
> 
> Hi Shy Liu,
> 
>> in my opinion, the flood issue maybe caused by the implemention that
>> logical_switch always be an arp-proxy for lsp which has known address, 
>> but this implemention is not applicable to vlan backed network. Right ?
>> 
>> I have an solution:
>> Maybe we can add a option named arp-proxy for logical_switch 
>> that always be false if network type is vlan, then disable the 
>> logical_switch response the arp for  the lsp which belongs to 
>> the vlan backed network.
>> 
>> So that this solution can let the destination MAC address
>> always learnt by TOR for vlan backed network.
> 
> For e/w routed traffic from pod A to pod B, pod A will send an arp request
> for the router ip address. Who is going to reply to this request in this way?
Hi Lorenzo, 
sorry that I had not describe it clearly.
We can disable arp response for the lsp which type is not router port nor 
localport.
So the logical_switch still responses the arp request for lrp.

> If ovn replies to the arp request from pod A but let the request go through
> the router pipeline I think even the other hypervisor will reply to the arp
> request (please remember the logical router is distributed in ovn) and so we
> will confuse the TOR switch since we will see the router mac address 

Re: [ovs-dev] [PATCH v10 08/10] odp-execute: Add ISA implementation of push_vlan action.

[Pai G, Sunil]

Hi Harry/Emma,

> -Original Message-
> From: Van Haaren, Harry 
> Sent: Wednesday, July 13, 2022 11:58 PM
> To: d...@openvswitch.org
> Cc: i.maxim...@ovn.org; echau...@redhat.com; Amber, Kumar
> ; Pai G, Sunil ; Finn, Emma
> ; Stokes, Ian 
> Subject: [PATCH v10 08/10] odp-execute: Add ISA implementation of
> push_vlan action.
> 
> From: Emma Finn 
> 
> This commit adds the AVX512 implementation of the push_vlan action.
> 
> Signed-off-by: Emma Finn 
> ---
>  lib/odp-execute-avx512.c | 55 
>  lib/odp-execute.c| 22 +---
>  2 files changed, 68 insertions(+), 9 deletions(-)
> 

Patch LGTM, 

Acked-by: Sunil Pai G 

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

Re: [ovs-dev] [PATCH ovn v3] pinctrl.c: Add delay after ARP packet

[Dumitru Ceara]

On 7/14/22 10:15, Ales Musil wrote:
> Hi,
> 

Hi Ales,

> thank you for the review, I have posted v4. See also my replies inline.
> 
> On Wed, Jul 13, 2022 at 10:02 PM Dumitru Ceara  wrote:
> 
>> On 7/13/22 14:36, Ales Musil wrote:
>>> The ovn-controller had a race condition over MAC
>>> binding table with other controllers. When multiple
>>> controllers received GARP from single source usually
>>> the one who was able to win the race put it into SB.
>>> The others got transaction error which triggered
>>> full recompute even if it's not needed.
>>>
>>> In order to reduce the chance of multiple controllers
>>> trying to insert same row at the same time add slight
>>> delay to the MAC binding processing. This delay
>>> is random interval between 1-50 in ms. This greatly
>>> reduces the chance that multiple controllers will try
>>> to add MAC binding at exactly the same time. This applies
>>> only to multicast ARP request which applies only to GARP
>>> that is sent to broadcast address.
>>>
>>> Local testing with this delay vs without show significantly
>>> reduced chance of hitting the transaction error.
>>>
>>> During the testing 10 GARPs was sent to two controllers
>>> at the same time. Without proposed fix at least one controller
>>> had multiple transaction errors present every test iteration.
>>>
>>> With the proposed fix the transaction error was reduced to a
>>> single one when it happened which was usually in less than
>>> 10% of the iterations.
>>>
>>> As was mentioned before the race condition can still happen,
>>> but the chance is greatly reduced.
>>>
>>> Suggested-by: Daniel Alvarez Sanchez 
>>> Signed-off-by: Ales Musil 
>>> ---
>>
>> Hi Ales,
>>
>> Thanks for this revision!  In general it makes sense but I have some
>> comments here and there.
>>
>>> v3: Rebase on top of current main.
>>> Change the delay to be per ARP request instead of
>>> single delay for everything. This allows the possibility
>>> to delay only multicast/broadcast AP as suggested by Han.
>>> ---
>>>  controller/mac-learn.c | 23 ++-
>>>  controller/mac-learn.h |  7 ++-
>>>  controller/pinctrl.c   | 33 -
>>>  tests/ovn.at   |  7 +++
>>>  4 files changed, 59 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/controller/mac-learn.c b/controller/mac-learn.c
>>> index 27634dca8..b7b392bb1 100644
>>> --- a/controller/mac-learn.c
>>> +++ b/controller/mac-learn.c
>>> @@ -20,12 +20,15 @@
>>>  /* OpenvSwitch lib includes. */
>>>  #include "openvswitch/vlog.h"
>>>  #include "lib/packets.h"
>>> +#include "lib/random.h"
>>>  #include "lib/smap.h"
>>> +#include "lib/timeval.h"
>>>
>>>  VLOG_DEFINE_THIS_MODULE(mac_learn);
>>>
>>>  #define MAX_MAC_BINDINGS 1000
>>>  #define MAX_FDB_ENTRIES  1000
>>> +#define MAX_MAC_BINDING_DELAY_MSEC 50
>>>
>>>  static size_t mac_binding_hash(uint32_t dp_key, uint32_t port_key,
>>> struct in6_addr *);
>>> @@ -64,7 +67,7 @@ ovn_mac_bindings_destroy(struct hmap *mac_bindings)
>>>  struct mac_binding *
>>>  ovn_mac_binding_add(struct hmap *mac_bindings, uint32_t dp_key,
>>>  uint32_t port_key, struct in6_addr *ip,
>>> -struct eth_addr mac)
>>> +struct eth_addr mac, bool is_delayed)
>>
>> What if we pass 'int max_delay_ms' instead of 'bool is_delayed'?
>>
> 
> This kinda breaks the encapsulation a bit. Why would the code outside
> need to know what is the max delay? I am still inclined to have it as a
> bool.
> 

It's arguable in my opinion.  The code outside (pinctrl) uses the delay
value already.  Anyhow, it's probably fine to leave it as is.

> 
>>
>>>  {
>>>  uint32_t hash = mac_binding_hash(dp_key, port_key, ip);
>>>
>>> @@ -79,6 +82,11 @@ ovn_mac_binding_add(struct hmap *mac_bindings,
>> uint32_t dp_key,
>>>  mb->dp_key = dp_key;
>>>  mb->port_key = port_key;
>>>  mb->ip = *ip;
>>> +mb->delay = 0;
>>> +mb->created = time_msec();
>>> +if (is_delayed) {
>>> +mb->delay = random_range(MAX_MAC_BINDING_DELAY_MSEC) + 1;
>>> +}
>>
>> This could become:
>>
>> mb->delay = max_delay_ms ? random_range(max_delay_ms) + 1 : 0;
>>
> 
> Done
> 
> 
>>
>>>  hmap_insert(mac_bindings, &mb->hmap_node, hash);
>>>  }
>>>  mb->mac = mac;
>>> @@ -86,6 +94,19 @@ ovn_mac_binding_add(struct hmap *mac_bindings,
>> uint32_t dp_key,
>>>  return mb;
>>>  }
>>>
>>> +long long
>>> +ovn_mac_binding_shortest_delay(struct hmap *mac_bindings)
>>> +{
>>> +long long min = LLONG_MAX;
>>> +
>>> +struct mac_binding *mb;
>>> +HMAP_FOR_EACH (mb, hmap_node, mac_bindings) {
>>> +min = MIN(mb->delay, min);
>>> +}
>>> +
>>> +return min;
>>> +}
>>
>> We don't really need to return the shortest delay.  We can rewrite this as:
>>
>> void
>> ovn_mac_binding_wait(struct hmap *mac_bindings)
>> {
>> struct mac_binding *mb;
>> HMAP_FOR_EACH (mb, hmap_node, mac_bin