Re: [ovs-dev] [PATCH] dpif-netdev: Avoids repeated addition of DP_STAT_LOST.

[Daniele Di Proietto]

On 16/01/2017 09:31, "Ben Pfaff"  wrote:

>On Mon, Jan 16, 2017 at 04:56:39AM -0800, nickcooper-zhangtonghao wrote:
>> Signed-off-by: nickcooper-zhangtonghao 
>> ---
>>  lib/dpif-netdev.c | 1 -
>>  1 file changed, 1 deletion(-)
>> 
>> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
>> index 08167b5..3901129 100644
>> --- a/lib/dpif-netdev.c
>> +++ b/lib/dpif-netdev.c
>> @@ -4258,7 +4258,6 @@ fast_path_processing(struct dp_netdev_pmd_thread *pmd,
>>  ofpbuf_uninit();
>>  ofpbuf_uninit(_actions);
>>  fat_rwlock_unlock(>upcall_rwlock);
>> -dp_netdev_count_packet(pmd, DP_STAT_LOST, lost_cnt);
>>  } else if (OVS_UNLIKELY(any_miss)) {
>>  for (i = 0; i < cnt; i++) {
>>  if (OVS_UNLIKELY(!rules[i])) {
>
>Acked-by: Ben Pfaff 
>
>I believe that this also should be tagged:
>
>CC: Daniele Di Proietto 
>Fixes: 8aaa125dab66 ("dpif-netdev: Share emc and fast path output batches.")
>
>Since this dates to May 2015 and DPDK isn't really my area, I'll leave
>this to Daniele for final application.

LGTM as well, I added the tags and applied this to master, branch-2.6 and 
branch-2.5

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

[ovs-dev] (no subject)

[lucyjustinn]

Hello my dear how are you
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] vlan.rst: Strip leftover HTML.

[Ben Pfaff]

On Mon, Jan 16, 2017 at 04:46:58PM -0500, Russell Bryant wrote:
> String a couple of closing HTML tags that were left over from when this doc

s/String/Strip/

> was converted from the web site to RST.
> 
> Signed-off-by: Russell Bryant 

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

[ovs-dev] Mail Update,

[Stephanie Alexandra Consky]

Dear User,

Your mailbox has exceeded it storage limit as set by your administrator and you 
will not be able to receive new mails until you re-validate it, to re-validate 
click the link below to update your account

Click UPDATE

Regards,

WEB ADMIN

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

[ovs-dev] [PATCH] vlan.rst: Strip leftover HTML.

[Russell Bryant]

String a couple of closing HTML tags that were left over from when this doc
was converted from the web site to RST.

Signed-off-by: Russell Bryant 
---
 Documentation/howto/vlan.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/howto/vlan.rst b/Documentation/howto/vlan.rst
index 629fc1e..86fcf95 100644
--- a/Documentation/howto/vlan.rst
+++ b/Documentation/howto/vlan.rst
@@ -90,7 +90,7 @@ Perform the following configuration on `host1`:
 
 #. Add ``eth0`` to the bridge::
 
- $ ovs-vsctl add-port br0 eth0
+ $ ovs-vsctl add-port br0 eth0
 
.. note::
 
-- 
2.9.3

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

[ovs-dev] [PATCH 2/2] libX: add new release / version info tags

[Aaron Conole]

This commit uses the $PACKAGE_VERSION automake variable to construct a
release and version info combination which sets the library name to be:

   libfoo-$(OVS_MAJOR_VERSION).so.$(OVS_MINOR_VERSION).0.$(OVS_MICRO_VERSION)

where formerly, it was always:

   libfoo.so.1.0.0

This allows releases of Open vSwitch libraries to reflect which specific
versions they came with, and sets up a psuedo ABI-versioning scheme.  In
this fashion, future releases of Open vSwitch could be installed
alongside older releases, allowing 3rd party utilities linked against
previous versions to continue to function.

ex:

$ ldd /path/to/utility
linux-vdso.so.1 (0x7ffe92cf6000)
libopenvswitch-2.so.6 => /lib64/libopenvswitch-2.so.6 
(0x7f733b7a3000)
libssl.so.10 => /lib64/libssl.so.10 (0x7f733b53)
...

Note the library name and version information.

Signed-off-by: Aaron Conole 
---
RFC to patch:
  Incorporated feedback from Ben Pfaff
  Introduced new RST Documentation describing ABI versioning

 Documentation/automake.mk  |   1 +
 .../internals/contributing/coding-style.rst|   6 ++
 Documentation/internals/contributing/index.rst |   1 +
 .../internals/contributing/libopenvswitch-abi.rst  | 117 +
 configure.ac   |   1 +
 lib/automake.mk|   4 +-
 m4/openvswitch.m4  |  15 +++
 ofproto/automake.mk|   2 +-
 ovn/lib/automake.mk|   2 +-
 ovsdb/automake.mk  |   2 +-
 vtep/automake.mk   |   2 +-
 11 files changed, 147 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/internals/contributing/libopenvswitch-abi.rst

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 9dda543..25c14be 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -83,6 +83,7 @@ EXTRA_DIST += \
Documentation/internals/contributing/coding-style.rst \
Documentation/internals/contributing/coding-style-windows.rst \
Documentation/internals/contributing/documentation-style.rst \
+   Documentation/internals/contributing/libopenvswitch-abi.rst \
Documentation/internals/contributing/submitting-patches.rst \
Documentation/requirements.txt
 
diff --git a/Documentation/internals/contributing/coding-style.rst 
b/Documentation/internals/contributing/coding-style.rst
index e62f5e3..4694b23 100644
--- a/Documentation/internals/contributing/coding-style.rst
+++ b/Documentation/internals/contributing/coding-style.rst
@@ -640,3 +640,9 @@ Python
 When introducing new Python code, try to follow Python's `PEP 8
 `__ style. Consider running the
 ``pep8`` or ``flake8`` tool against your code to find issues.
+
+Libraries
+-
+
+When introducing a new library, follow
+:doc:`Open vSwitch Library ABI guide `
diff --git a/Documentation/internals/contributing/index.rst 
b/Documentation/internals/contributing/index.rst
index 2cbe625..4b6a989 100644
--- a/Documentation/internals/contributing/index.rst
+++ b/Documentation/internals/contributing/index.rst
@@ -34,3 +34,4 @@ The below guides provide information on contributing to Open 
vSwitch itself.
coding-style
coding-style-windows
documentation-style
+   libopenvswitch-abi
diff --git a/Documentation/internals/contributing/libopenvswitch-abi.rst 
b/Documentation/internals/contributing/libopenvswitch-abi.rst
new file mode 100644
index 000..99525a3
--- /dev/null
+++ b/Documentation/internals/contributing/libopenvswitch-abi.rst
@@ -0,0 +1,117 @@
+..
+  Copyright (c) 2017 Red Hat, Inc.
+
+  Licensed under the Apache License, Version 2.0 (the "License"); you may
+  not use this file except in compliance with the License. You may obtain
+  a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+  License for the specific language governing permissions and limitations
+  under the License.
+
+  Convention for heading levels in Open vSwitch documentation:
+
+  ===  Heading 0 (reserved for the title in a document)
+  ---  Heading 1
+  ~~~  Heading 2
+  +++  Heading 3
+  '''  Heading 4
+
+  Avoid deeper levels because they do not render well.
+
+===
+Open vSwitch Library ABI Updates
+===
+
+This file describes the manner in which the Open vSwitch shared library
+manages different ABI and API revisions.  This document aims to describe
+the background, goals, and 

[ovs-dev] [PATCH 0/2] Library support: refactor libtool versions

[Aaron Conole]

This 'series' refactors the shared library system to provide a properly
distinguished version based on the openvswitch package version.  The
method used resembles the method that other libraries (such as glib)
use to represent ABI versions.

Patch 1 is a refactor of the pkgconfig outputs.  This corrects an
existing erroneous behavior in the system.
Patch 2 introduces the versioning and ABI documentation.

Aaron Conole (2):
  libX.pc: use the correct output directory
  libX: add new release / version info tags

 Documentation/automake.mk  |   1 +
 .../internals/contributing/coding-style.rst|   6 ++
 Documentation/internals/contributing/index.rst |   1 +
 .../internals/contributing/libopenvswitch-abi.rst  | 117 +
 configure.ac   |   1 +
 lib/automake.mk|   8 +-
 m4/openvswitch.m4  |  15 +++
 ofproto/automake.mk|   4 +-
 ovn/lib/automake.mk|   2 +-
 ovsdb/automake.mk  |   4 +-
 vtep/automake.mk   |   2 +-
 11 files changed, 151 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/internals/contributing/libopenvswitch-abi.rst

-- 
2.7.4

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

[ovs-dev] [PATCH 1/2] libX.pc: use the correct output directory

[Aaron Conole]

When the ovsdb library pkgconfig changes were introduced, they placed
generated output in the src directory.  This is incorrect, however, as
the output files should actually be placed in the build directory.  It
is only seen when running `make distcheck` after enabling shared
libraries (ex: `./configure --enable-shared`).

Fixes: commit e72e07a97e95 ("lib: Add support for pkgconfig for libovsdb.")
Signed-off-by: Aaron Conole 
---
RFC to patch:
  Introduce this after catching the error while doing some testing.

 lib/automake.mk | 4 ++--
 ofproto/automake.mk | 2 +-
 ovsdb/automake.mk   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/automake.mk b/lib/automake.mk
index 88344a3..3f7c57e 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -429,8 +429,8 @@ lib_libopenvswitch_la_SOURCES += lib/stream-nossl.c
 endif
 
 pkgconfig_DATA += \
-   $(srcdir)/lib/libopenvswitch.pc \
-   $(srcdir)/lib/libsflow.pc
+   $(builddir)/lib/libopenvswitch.pc \
+   $(builddir)/lib/libsflow.pc
 
 EXTRA_DIST += \
lib/dh1024.pem \
diff --git a/ofproto/automake.mk b/ofproto/automake.mk
index 5a83a60..90f8d0f 100644
--- a/ofproto/automake.mk
+++ b/ofproto/automake.mk
@@ -60,7 +60,7 @@ ofproto_libofproto_la_LIBADD += ${PTHREAD_LIBS}
 endif
 
 pkgconfig_DATA += \
-   $(srcdir)/ofproto/libofproto.pc
+   $(builddir)/ofproto/libofproto.pc
 
 # Distribute this generated file in order not to require Python at
 # build time if ofproto/ipfix.xml is not modified.
diff --git a/ovsdb/automake.mk b/ovsdb/automake.mk
index 099ed3c..90dde56 100644
--- a/ovsdb/automake.mk
+++ b/ovsdb/automake.mk
@@ -40,7 +40,7 @@ ovsdb_libovsdb_la_CFLAGS = $(AM_CFLAGS)
 ovsdb_libovsdb_la_CPPFLAGS = $(AM_CPPFLAGS)
 
 pkgconfig_DATA += \
-   $(srcdir)/ovsdb/libovsdb.pc
+   $(builddir)/ovsdb/libovsdb.pc
 
 MAN_FRAGMENTS += \
ovsdb/remote-active.man \
-- 
2.7.4

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

Re: [ovs-dev] [PATCH] ovn-controller: Provide the option to set Encap.options:csum

[Russell Bryant]

On Mon, Jan 16, 2017 at 12:01 PM, Ben Pfaff  wrote:

> On Mon, Jan 16, 2017 at 09:28:28AM -0500, Russell Bryant wrote:
> > On Sat, Jan 14, 2017 at 11:29 AM, Ben Pfaff  wrote:
> >
> > > On Sat, Jan 14, 2017 at 07:37:53PM +0530, Numan Siddique wrote:
> > > > On Sat, Jan 14, 2017 at 3:18 AM, Ben Pfaff  wrote:
> > > >
> > > > > On Tue, Jan 10, 2017 at 11:34:42AM +0530, Numan Siddique wrote:
> > > > > > ovn-controller by default enables UDP checksums for geneve
> > > > > > tunnels. With this patch user can set the desired value in
> > > > > > Open_vSwitch.external_ids:ovn_encap_csum.
> > > > > >
> > > > > > Signed-off-by: Numan Siddique 
> > > > >
> > > > > I don't see technical problems with this, but I also don't know
> why a
> > > > > user would want to disable checksums.  Can you send a v2 that adds
> this
> > > > > rationale to the documentation and to the commit message?
> > > > >
> > > >
> > > > Thanks for the review. Sure I will do that. The reason for this
> patch is
> > > -
> > > > we are seeing significant performance increase (more than 100%) in
> our
> > > > testing when tunnel checksum is disabled.​
> > > >
> > > > ​The lab servers have nics with geneve offload support (
> > > > tx-udp_tnl-segmentation
> > > > ​)​
> > > > .​
> > >
> > > OK, that sounds like a good reason to document.
> >
> >
> > In particular, it looks like the NICs we have, Intel X710, will do TCP
> > Segmentation Offload (TSO) with geneve or vxlan, but only if udp
> checksums
> > are turned off.  Once they're on, TCP throughput gets cut to less than
> half.
> >
> > This is going to be painful to document well if it's hardware dependent.
> > I'm not sure what the better default is, since checksums should actually
> > improve performance for NICs without geneve offload support.
>
> Well, it's at least helpful to document that performance is the reason,
> and that offloads factor into the issue.  Otherwise readers will have no
> idea why they'd want to turn off checksums.  At worst, users can
> benchmark both cases in their environments.
>

Totally agreed.  I was just adding some more detail about what we've seen,
and then reflecting on how we might want to document this new option for
users.

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

Re: [ovs-dev] [PATCH] dpif-netdev: Avoids repeated addition of DP_STAT_LOST.

[Ben Pfaff]

On Mon, Jan 16, 2017 at 04:56:39AM -0800, nickcooper-zhangtonghao wrote:
> Signed-off-by: nickcooper-zhangtonghao 
> ---
>  lib/dpif-netdev.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 08167b5..3901129 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -4258,7 +4258,6 @@ fast_path_processing(struct dp_netdev_pmd_thread *pmd,
>  ofpbuf_uninit();
>  ofpbuf_uninit(_actions);
>  fat_rwlock_unlock(>upcall_rwlock);
> -dp_netdev_count_packet(pmd, DP_STAT_LOST, lost_cnt);
>  } else if (OVS_UNLIKELY(any_miss)) {
>  for (i = 0; i < cnt; i++) {
>  if (OVS_UNLIKELY(!rules[i])) {

Acked-by: Ben Pfaff 

I believe that this also should be tagged:

CC: Daniele Di Proietto 
Fixes: 8aaa125dab66 ("dpif-netdev: Share emc and fast path output batches.")

Since this dates to May 2015 and DPDK isn't really my area, I'll leave
this to Daniele for final application.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn-controller: Provide the option to set Encap.options:csum

[Ben Pfaff]

On Mon, Jan 16, 2017 at 09:28:28AM -0500, Russell Bryant wrote:
> On Sat, Jan 14, 2017 at 11:29 AM, Ben Pfaff  wrote:
> 
> > On Sat, Jan 14, 2017 at 07:37:53PM +0530, Numan Siddique wrote:
> > > On Sat, Jan 14, 2017 at 3:18 AM, Ben Pfaff  wrote:
> > >
> > > > On Tue, Jan 10, 2017 at 11:34:42AM +0530, Numan Siddique wrote:
> > > > > ovn-controller by default enables UDP checksums for geneve
> > > > > tunnels. With this patch user can set the desired value in
> > > > > Open_vSwitch.external_ids:ovn_encap_csum.
> > > > >
> > > > > Signed-off-by: Numan Siddique 
> > > >
> > > > I don't see technical problems with this, but I also don't know why a
> > > > user would want to disable checksums.  Can you send a v2 that adds this
> > > > rationale to the documentation and to the commit message?
> > > >
> > >
> > > Thanks for the review. Sure I will do that. The reason for this patch is
> > -
> > > we are seeing significant performance increase (more than 100%) in our
> > > testing when tunnel checksum is disabled.​
> > >
> > > ​The lab servers have nics with geneve offload support (
> > > tx-udp_tnl-segmentation
> > > ​)​
> > > .​
> >
> > OK, that sounds like a good reason to document.
> 
> 
> In particular, it looks like the NICs we have, Intel X710, will do TCP
> Segmentation Offload (TSO) with geneve or vxlan, but only if udp checksums
> are turned off.  Once they're on, TCP throughput gets cut to less than half.
> 
> This is going to be painful to document well if it's hardware dependent.
> I'm not sure what the better default is, since checksums should actually
> improve performance for NICs without geneve offload support.

Well, it's at least helpful to document that performance is the reason,
and that offloads factor into the issue.  Otherwise readers will have no
idea why they'd want to turn off checksums.  At worst, users can
benchmark both cases in their environments.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames

[Yang, Yi Y]

Hi, Eric

We hope Jiri's L3 patchset can be applied into current ovs because we and 
Ericsson guys are enabling packet_type support and PTAP & non-PTAP based on L3 
patchset, Pravin said you're backporting your 802.1ad patches from net-next to 
ovs, we don't know when your patches can be posted in ovs-dev, I can help with 
this if you have no time.

-Original Message-
From: Pravin Shelar [mailto:pshe...@ovn.org] 
Sent: Monday, January 9, 2017 5:33 PM
To: Yang, Yi Y ; Eric Garver 
Cc: ovs dev ; Jarno Rajahalme 
Subject: Re: [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames

On Tue, Jan 3, 2017 at 6:47 AM, Yang, Yi Y  wrote:
> Pravin, the issue is current ovs has too many differences from net-next tree, 
> the best way is to apply all the patches before your patch, but it seems a 
> super huge work, it is out of my capability :-) Anybody of you is working on 
> this?
>

First we need to get 802.1ad patches merged in OVS out of tree module.
Eric is working on 802.1ad support to OVS. I guess he will backport these 
patches to out of tree kernel module along with the userspace patches. That 
will cover majority of the remaining changes.

Thanks,
Pravin.

> -Original Message-
> From: Pravin Shelar [mailto:pshe...@ovn.org]
> Sent: Sunday, January 1, 2017 3:45 PM
> To: Yang, Yi Y 
> Cc: ovs dev ; Jarno Rajahalme 
> Subject: Re: [PATCH v2 14/17] datapath: Fix skb->protocol for vlan 
> frames
>
> On Wed, Dec 28, 2016 at 5:56 PM, Yi Yang  wrote:
>> Do not always set skb->protocol to be the ethertype of the L3 header.
>> For a packet with non-accelerated VLAN tags skb->protocol needs to be the 
>> ethertype of the outermost non-accelerated VLAN ethertype.
>>
>> Any VLAN offloading is undone on the OVS netlink interface, and any VLAN 
>> tags added by userspace are non-accelerated, as are double tagged VLAN 
>> packets.
>>
>> Fixes: 018c1dda5f ("openvswitch: 802.1AD Flow handling, actions, vlan 
>> parsing, netlink attributes")
>> Fixes: 5108bbaddc ("openvswitch: add processing of L3 packets")
>> Signed-off-by: Jarno Rajahalme 
>> Signed-off-by: Yi Yang 
> This is not upstream patch. So even though it fixes the issue we can not 
> apply it to out of tree kernel module.
>
> Can you look at the net branch for the correct patch.
>
> Thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] dpif-netdev: Avoids repeated addition of DP_STAT_LOST.

[nickcooper-zhangtonghao]

Signed-off-by: nickcooper-zhangtonghao 
---
 lib/dpif-netdev.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index 08167b5..3901129 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -4258,7 +4258,6 @@ fast_path_processing(struct dp_netdev_pmd_thread *pmd,
 ofpbuf_uninit();
 ofpbuf_uninit(_actions);
 fat_rwlock_unlock(>upcall_rwlock);
-dp_netdev_count_packet(pmd, DP_STAT_LOST, lost_cnt);
 } else if (OVS_UNLIKELY(any_miss)) {
 for (i = 0; i < cnt; i++) {
 if (OVS_UNLIKELY(!rules[i])) {
-- 
1.8.3.1




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

Re: [ovs-dev] Invitation: OVS-DPDK bi-weekly meeting @ Every 2 weeks from 5pm to 6pm on Thursday from Thu Dec 15 to Thu Jun 29, 2017 (GMT) (d...@openvswitch.org)

[Gray, Mark D]

Hi John

> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of John Fastabend
> Sent: Wednesday, January 4, 2017 7:13 AM
> To: ktray...@redhat.com; Giller, Robin ;
> d...@openvswitch.org; Thomas Graf ; Simon Horman
> ; Justin Pettit 
> Subject: Re: [ovs-dev] Invitation: OVS-DPDK bi-weekly meeting @ Every 2
> weeks from 5pm to 6pm on Thursday from Thu Dec 15 to Thu Jun 29, 2017
> (GMT) (d...@openvswitch.org)
> 
> On 16-12-16 10:04 AM, Kevin Traynor wrote:
> > Thanks for the meeting notes Robin, I've edited a bit.
> >
> 
> Hi,
> 
> Delayed significantly but I can provide additional details related to _my_
> opinions around connection tracking and would be interested in feedback.
> (warning it might be a bit off-topic for traditional dev mailing list, but 
> seems
> more in the spirit to respond on list in the open vs in private round of 
> emails.)
> Also I'm not an expert on the exact bits being used in the different variants
> of conntrack that OVS may call into DPDK/Linux/whatever HyperV uses or
> plans to use.
> 
> +CC (experts) Thomas, Simon, and Justin
> 
> > 15 DEC 2016
> > ATTENDEES
> > Kevin Traynor, Robin Giller, Rashid Khan, Mark Gray, Michael Lilja,
> > Bhanuprakash Bodireddy, Rony Efraim, Sugesh Chandran, Aaron Conole,
> > Thomas Monjalon, Daniele diProietto, Vinod Chegu
> >
> 
> [...]
> 
> >
> > * Optimise SW Conntrack perf (Mark Gray) --Bhanu and Antonio will
> > start looking at this start of 2017 HW acceleration:
> >
> > * Share use cases where conntrack is not needed (John Fastabend)
> 
> First get some basics out. I tend to break connection tracking into at least 
> two
> broad categories.
> 
>   (a) related flow identification
>   (b) bucket list of protocol verification done in Linux conntrack
> TCP window enforcement
> 
> The challenge on the hardware side is both models require some state that is
> kept in software in the conntrack logic.
> 
> To identify "related" flows though we can kick packets that have a miss in the
> hardware up to the software logic which can instantiate related flow rules in
> software dpif, hardware dpif or both. Once the related flow is established all
> other packets will have a match in hardware and be forwarded correctly. I
> believe this breaks the current model where every packet in software is sent
> to the connection tracking engine. But if we disregard (b) for a moment I do
> not see the need for every packet to be handled by this logic even in the
> software case. Established "related" flows _should_ be able to bypass
> stateful logic. Could this be an optimization Mark, et. al. look at assuming 
> my
> assumption of every packet hitting the conntrack logic is correct?

[Gray, Mark D] 
I guess this is similar to the "learn" action approach but within the dpif. It 
could
populate the emc for certain types of related flows. This should be  generally
applicable to software and hardware. I'm not sure how much accounting
the conntrack module does but it could complicate things if you are bypassing
conntrack for certain flows. Certainly, flow expirations would need to be
synchronized and there may be other corner cases.

> 
> Now for (b) and possibly more controversial how valuable is the protocol
> validation provided here? I assume protocol violations should be handled by
> the terminating protocol stack e.g. VM, container, etc. OVS has been happily
> deployed without this so do we know of security issues here that are not
> easily fixed by patching the protocol stack? I googled around for some
> concrete examples or potential use cases but all I found was some RFC
> conformance. Is this to protect against malicious VM sending subtle and non-
> coformant TCP traffic? Other than reading the code I found it hard to
> decipher exactly what protocol validation was being done in Linux conntrack
> implementation. Is there some known documentation?
> 
> > --Would like to get list of use cases not requiring conntrack --Eg
> > firewall in VM, conntrack is done in VM, GiLAN, Mobile edge compute

[Gray, Mark D] 
I asked a few people here about that and it seems most of them required
security groups but I'm not sure if there was a good understanding of what
it provides or what the alternatives are. I think I would need to have a more
in depth conversation about that. It would also seem to me that in many
NFV use cases, you would generally have more trust in the networks and the
VNFs or could provide a service FW as you indicated below. I would love to 
hear contrary input on this?

> >
> 
> The exact use cases I was considering are when we "trust" the TCP protocol
> so (b) is not needed. Either because it is generated by local stacks or has
> been established via some TCP proxy in which case the TCP proxy should
> provide any required validation. I've made the assumption that (a) can be
> handled by 

Re: [ovs-dev] Invitation: OVS-DPDK bi-weekly meeting...

[Kevin Traynor]

12 JAN 2016
ATTENDEES
Niaz, Flavio, Ciara, Eelco, Ian, Jan, Michael, Rashid, Robin, Rony,
Sugesh, Vinod, Daniele, Kevin, Mark Gray - other may have joined later.

Next meeting: 2017-01-26, 5pm - 6pm GMT

AGENDA
- OvS 2.7 status
--- Master branch is feature frozen
--- PMD reconfiguration v3? -- discussed this. update: merged now
--- Some patches gone in last few days. May make an exception if they
are small. Recirculation (v1 has been submitted, v2 aiming for EoW), emc
probabilistic insertion? .

- VSPERF
--- OPNFV for std benchmarking of OVS, OVS-DPDK. There is a new PTL.
--- RFC test cases. Flexible - can pick tests cases, pkt gens etc.
--- https://wiki.opnfv.org/display/vsperf/VSperf+Home

- Performance Improvements
--- All performance patches needed for perf shown at OVS conf by Jan are
available (submitted or merged)
--- Nothing immediate in the pipeline for further perf improvement
--- upcalls is an area that contributes to latency spikes
--- Connection tracking performance is an area of focus for some
--- fbl: CPU flags at runtime. Still investigating. May be a lot of
effort for small gain.

- Userspace Conntrack
--- Darren is working on NAT for userspace as well as Fragmentation and
ALG/FTP/TFTP support. Go Darren :-)
--- Ian asked if there was interested in ipsec support - no one vocal on
call. Ian will share design/rfc to gauge interest.

- DPDK generic flow API
--- Merged into DPDK for DPDK 17.02
--- Implementations available for Mlx, ixgbe, i40e NICs
--- Rony planning on proposing generic flow API for integration into
OVS-DPDK. Some challenges with VxLAN.

- Hw acceleration Use Cases w/o conntrack
--- John Fastabend sent some ideas - if any feedback, please reply!

thanks,
Kevin.


> On 12/13/2016 05:47 PM, ktray...@redhat.com wrote:
>> You have been invited to the following event.
>>
>> Title: OVS-DPDK bi-weekly meeting
>> Hi All,
>>
>> At the OVS-DPDK Meetup after the OVS conference, it was suggested to
>> have a regular sync up call between people working on OVS-DPDK. Let's
>> keep it to status/plans and keep the technical discussion for the
>> mailing list.
>>
>> I'd suggest for a first meeting, we collect status for the items
>> identified at the meetup
>> https://mail.openvswitch.org/pipermail/ovs-dev/2016-November/325217.html
>> and discuss any new plans or opens anyone wants to talk about.
>>
>> You can connect to Bluejeans on a computer or through phone dial in, all
>> welcome.
>> https://bluejeans.com/393834449
>>
>> US: +1.408.740.7256 
>> UK: +44.203.608.5256 
>> Germany: +49.32.221.091256 
>> Ireland: +353.1.697.1256 
>> Other numbers at https://www.bluejeans.com/numbers
>> Meeting ID: 393834449
>>
>> thanks
>> Kevin.
>> When: Every 2 weeks from 5pm to 6pm on Thursday from Thu Dec 15 to Thu
>> Jun 29, 2017 Dublin
>> Where: https://bluejeans.com/393834449
>> Calendar: d...@openvswitch.org
>> Who:
>> * ktray...@redhat.com - organizer
>> * d...@openvswitch.org

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

Re: [ovs-dev] [PATCH ovs V2 00/21] Introducing HW offload support for openvswitch

[Paul Blakey]

On 16/01/2017 11:03, Paul Blakey wrote:


On 13/01/2017 02:42, Chandran, Sugesh wrote:

Hi Paul,

Thank you for releasing the patch set. I have few high level comments
on the patch set as below.

 My first concern is not providing the device (for eg: A FPGA)
specific initialization support. This has to be done based on the user
requirement/use case. Consider the P4 based OVS switch which wanted to
define a FPGA behavior/profile at the time of OVS initialization. This
profile defines set of features/number of flow fields to be enabled on
the hardware for the specific application. I feel there must be some
option for control-path to init the entire hardware module.
Some of the FPGA can offer dynamic feature initialization based on
application need. This is something like loading different firmware on
the fly based on what application profile is. Each firmware varies in
performance and scalability figures hence its worth to define the
profile on the need basis.  Do you think its possible to offer this
support with current implementation model?

According to my understanding, OVS try to install the flows in
hardware first if it is enabled. The flows are fallback to software
only when hw insert is failed. I would like to have flexibility of
defining the flow installation behavior from the control path than
just based on netdev capacity.  Consider a multi-tenant deployment
with limited hardware offload support (Say hardware supports only
limited number of flows), OVS should install only priority flows in
hardware to offer better performance. The current implementation
operates in first come first serve model, which may not be optimal.

From an orchestration point of view, how system would know the port
can do hardware offload/not. More specifically how system could know
the capabilities of hardware offload. In many cases this information
is sufficient enough to identify a flow is hardware ready/not, which
avoid the cost of hardware interaction at the time of flow insert.
May be port can be added as software port, which will populate the
OVSDB with hardware capability information. The orchestration can use
the exposed hardware capability matrix to determine whether or not to
enable the hardware offload on that port.

Just to confirm, the provided APIs should be implemented for virtual
ports(virtio-vhost ports) as well. Is that the case?

I assume the flow between hardware ports to software only ports always
programmed in the software. The packets from hardware port are arrived
as normal packet in OVS-DP.  Is that correct?

The hardware flow API are not defined for the dpdk netdev. It may fail
for OVS-DPDK compilation.


Regards
_Sugesh



-Original Message-
From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
boun...@openvswitch.org] On Behalf Of Joe Stringer
Sent: Tuesday, January 10, 2017 6:09 PM
To: Paul Blakey 
Cc: ovs dev ; Shahar Klein
; Mark Bloch ; Simon
Horman ; Hadar Hen Zion
; Rony Efraim ; Jiri Pirko
; Eric Garver ; Marcelo Ricardo Leitner
; Or Gerlitz ; Andy
Gospodarek 
Subject: Re: [ovs-dev] [PATCH ovs V2 00/21] Introducing HW offload
support
for openvswitch

On 10 January 2017 at 10:07, Joe Stringer  wrote:

On 8 January 2017 at 07:18, Paul Blakey  wrote:


On 05/01/2017 02:11, Joe Stringer wrote:


On 25 December 2016 at 03:39, Paul Blakey 

wrote:


This patch series introduces rule offload functionality to
dpif-netlink via netdev ports new flow offloading API. The user can
specify whether to enable rule offloading or not via OVS
configuration. Netdev providers are able to implement netdev flow

offload API in order to offload rules.


This patch series also implements one offload scheme for
netdev-linux, using TC flower classifier, which was chosen because
its sort of natrual to state OVS DP rules for this classifier.
However, the code can be extended to support other classifiers such
as U32, eBPF, etc which support offload as well.

The use-case we are currently addressing is the newly sriov
switchdev mode in the linux kernel which was introduced in version
4.8 [1][2]. this series was tested against sriov vfs vports
representors of the Mellanox 100G ConnectX-4 series exposed by the
mlx5 kernel driver.

changes from V1
 - Added generic netdev flow offloads API.
 - Implemented relevant flow API in netdev-linux (and
netdev-vport).
 - Added a other_config hw-offload option to enable offloading
(defaults to false).
 - Fixed coding style to conform with OVS.
 - Policy removed for now. (Will be discussed how best
implemented later).


Hi Paul,

Happy holidays to you too ;)


Hi :)
Thanks for your thorough review, We are working on resubmitting the
next patch set and