Re: [ovs-dev] [PATCHv11] netdev-afxdp: add new netdev type for AF_XDP.

[Eelco Chaudron]

On 8 Jun 2019, at 6:48, William Tu wrote:


+  ethtool -L enp2s0 combined 1
+  ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x10
+  ovs-vsctl add-port br0 enp2s0 -- set interface enp2s0 
type="afxdp"

\
+options:n_rxq=1 options:xdpmode=drv \
+other_config:pmd-rxq-affinity="0:4"


another feature I'm thinking about to add is a new options
for loading custom XDP program

For example:
ovs-vsctl add-port br0 enp2s0 -- set interface enp2s0 type="afxdp"
options:n_rxq=1 options:xdpmode=drv
options:xdp_prog=/path/to/xdp.o

If users do not specify the path, then it is using the libbpf's 
default program

(which forwards all packets to userspace)

If users want to use their own xdp object, then this option can load 
the

xdp object file from the path.


This might be useful, specially if you would like to do some 
experiments.

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

Re: [ovs-dev] [patch v2] conntrack: Add option to disable TCP sequence checking.

[王志克]

Hi,



I would like to describe our scenario to use 'no-tcp-seq-chk'.



We JDCloud design conntrack hardware offloading as below:

1. SW maintains the conntrack state and timer. So packets that would impact 
conntrack state/timer should be sent to CPU, like TCP FIN/RST. In this way, we 
can clean up the connection ASAP.

2. HW has no idea about the conntrack, and just forwards the packet according 
to HW rule.

3. SW only inserts HW rule when the conntrack state is EST.

4. SW polls the HW periodically to know whether the HW rule is hit or not. If 
HW rule is idle for certain time, it will be deleted by SW.



In this design, most TCP data packet will go through the HW, so conntrack in SW 
will not update the seq. Finally the TCP FIN/RST are sent to CPU, so these 
should NOT be checked for seq.



Best regards,



Zhike Wang



Date: Mon, 10 Jun 2019 09:51:25 -0700

From: Ben Pfaff mailto:b...@ovn.org>>

To: Darrell Ball mailto:dlu...@gmail.com>>

Cc: d...@openvswitch.org

Subject: Re: [ovs-dev] [patch v2] conntrack: Add option to disable TCP

 sequence checking.

Message-ID: 
<20190610165125.gg28...@ovn.org>

Content-Type: text/plain; charset=us-ascii



On Sun, Jun 09, 2019 at 07:35:09AM -0700, Darrell Ball wrote:

> This may be needed in some special cases, such as to support some

> hardware offload implementations.

>

> Reported-at: 
> https://mail.openvswitch.org/pipermail/ovs-dev/2019-May/359188.html

> Signed-off-by: Darrell Ball mailto:dlu...@gmail.com>>

> ---

>

> v2: Per particular requirement, support  'no-tcp-seq-chk' rather than

> 'liberal' mode.

>

> Add some debug counters.



I'm not sure whether an ovs-appctl command is the best way for users to

enable and disable this.  It means that it is difficult for an OpenFlow

controller to do it, since those commands aren't exposed via OpenFlow or

OVSDB.



The documentation says that sequence checking should only be disabled if

absolutely necessary.  If you have an example of such a case, it would

be helpful to add it to the documentation.


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

Re: [ovs-dev] [PATCH 4/5] net: core: dev: Add extack argument to dev_change_flags()

[0-day Robot]

Bleep bloop.  Greetings Yifeng Sun, 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 Petr Machata  needs to sign off.
WARNING: Unexpected sign-offs from developers who are not authors or co-authors 
or committers: Yifeng Sun 
Lines checked: 192, Warnings: 1, Errors: 1


Please check this out.  If you feel there has been an error, please email 
acon...@bytheb.org

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

Re: [ovs-dev] [PATCH 2/5] OVS: remove use of VLAN_TAG_PRESENT

[0-day Robot]

Bleep bloop.  Greetings Yifeng Sun, 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 Michał Mirosław  needs to sign off.
WARNING: Unexpected sign-offs from developers who are not authors or co-authors 
or committers: Yifeng Sun 
Lines checked: 254, Warnings: 1, Errors: 1


Please check this out.  If you feel there has been an error, please email 
acon...@bytheb.org

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

[ovs-dev] [PATCH 5/5] datapath: Support kernel version 5.0.x

[Yifeng Sun]

This patch updated acinclude.m4 so that OVS can be compiled on
5.0.x kernels.
This patch also updated travis files so that 5.0.x kernel versions
are used during travis test builds.
Besides, NEWS and releases.rst are also updated to reflect this
new support.

Signed-off-by: Yifeng Sun 
---
 .travis.yml|  1 +
 .travis/linux-build.sh |  4 +++-
 Documentation/faq/releases.rst |  2 +-
 NEWS   |  1 +
 acinclude.m4   | 10 ++
 5 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 6621fb53575f..cb96d13cf537 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -35,6 +35,7 @@ env:
   - KERNEL=3.16 TESTSUITE=1 DPDK=1
   - KERNEL=3.16 DPDK_SHARED=1
   - KERNEL=3.16 DPDK_SHARED=1 OPTS="--enable-shared"
+  - KERNEL=5.0
   - KERNEL=4.20
   - KERNEL=4.19
   - KERNEL=4.18
diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index 123cde575667..bb97600c9789 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -11,7 +11,9 @@ TARGET="x86_64-native-linuxapp-gcc"
 
 function install_kernel()
 {
-if [[ "$1" =~ ^4.* ]]; then
+if [[ "$1" =~ ^5.* ]]; then
+PREFIX="v5.x"
+elif [[ "$1" =~ ^4.* ]]; then
 PREFIX="v4.x"
 elif [[ "$1" =~ ^3.* ]]; then
 PREFIX="v3.x"
diff --git a/Documentation/faq/releases.rst b/Documentation/faq/releases.rst
index 6c5949b33d63..d9504d682c60 100644
--- a/Documentation/faq/releases.rst
+++ b/Documentation/faq/releases.rst
@@ -68,7 +68,7 @@ Q: What Linux kernel versions does each Open vSwitch release 
work with?
 2.8.x3.10 to 4.12
 2.9.x3.10 to 4.13
 2.10.x   3.10 to 4.17
-2.11.x   3.10 to 4.18
+2.11.x   3.10 to 5.0
  ==
 
 Open vSwitch userspace should also work with the Linux kernel module built
diff --git a/NEWS b/NEWS
index 19cebf89a785..a38ab258fc6c 100644
--- a/NEWS
+++ b/NEWS
@@ -46,6 +46,7 @@ Post-v2.11.0
- Added support for TLS Server Name Indication (SNI).
- Linux datapath:
  * Support for the kernel versions 4.19.x and 4.20.x.
+ * Support for the kernel version 5.0.x.
 
 
 v2.11.0 - 19 Feb 2019
diff --git a/acinclude.m4 b/acinclude.m4
index 93fbf0ebb84c..321a741985db 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -150,12 +150,14 @@ AC_DEFUN([OVS_CHECK_LINUX], [
 fi
 AC_MSG_RESULT([$kversion])
 
-if test "$version" -ge 4; then
-   if test "$version" = 4 && test "$patchlevel" -le 20; then
-  : # Linux 4.x
+if test "$version" -ge 5; then
+   if test "$version" = 5 && test "$patchlevel" -le 0; then
+  : # Linux 5.x
else
-  AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version 
newer than 4.20.x is not supported (please refer to the FAQ for advice)])
+  AC_ERROR([Linux kernel in $KBUILD is version $kversion, but version 
newer than 5.0.x is not supported (please refer to the FAQ for advice)])
fi
+elif test "$version" = 4; then
+   : # Linux 4.x
 elif test "$version" = 3 && test "$patchlevel" -ge 10; then
: # Linux 3.x
 else
-- 
2.7.4

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

[ovs-dev] [PATCH 4/5] net: core: dev: Add extack argument to dev_change_flags()

[Yifeng Sun]

From: Petr Machata 

Upstream commit:
commit 567c5e13be5cc74d24f5eb54cf353c2e2277189b
Author: Petr Machata 
Date:   Thu Dec 6 17:05:42 2018 +

net: core: dev: Add extack argument to dev_change_flags()

In order to pass extack together with NETDEV_PRE_UP notifications, it's
necessary to route the extack to __dev_open() from diverse (possibly
indirect) callers. One prominent API through which the notification is
invoked is dev_change_flags().

Therefore extend dev_change_flags() with and extra extack argument and
update all users. Most of the calls end up just encoding NULL, but
several sites (VLAN, ipvlan, VRF, rtnetlink) do have extack available.

Since the function declaration line is changed anyway, name the other
function arguments to placate checkpatch.

Signed-off-by: Petr Machata 
Acked-by: Jiri Pirko 
Reviewed-by: Ido Schimmel 
Reviewed-by: David Ahern 
Signed-off-by: David S. Miller 

This patch backports the above upstream patch and also adds fixes
in compat code.

Cc: Petr Machata 
Signed-off-by: Yifeng Sun 
---
 acinclude.m4|  3 +++
 datapath/linux/compat/include/linux/netdevice.h | 10 ++
 datapath/linux/compat/ip6_gre.c |  4 ++--
 datapath/linux/compat/ip_gre.c  |  4 ++--
 datapath/vport-geneve.c |  2 +-
 datapath/vport-gre.c|  2 +-
 datapath/vport-lisp.c   |  2 +-
 datapath/vport-stt.c|  2 +-
 datapath/vport-vxlan.c  |  2 +-
 9 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/acinclude.m4 b/acinclude.m4
index eb978e0fae6c..93fbf0ebb84c 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -617,6 +617,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
 [max_mtu])
   OVS_FIND_FIELD_IFELSE([$KSRC/include/linux/netdevice.h], 
[net_device_ops_extended],
 [ndo_change_mtu], [OVS_DEFINE([HAVE_RHEL7_MAX_MTU])])
+  OVS_FIND_PARAM_IFELSE([$KSRC/include/linux/netdevice.h],
+[dev_change_flags], [extack],
+[OVS_DEFINE([HAVE_DEV_CHANGE_FLAGS_TAKES_EXTACK])])
 
   OVS_GREP_IFELSE([$KSRC/include/linux/netfilter.h], [nf_hook_state])
   OVS_FIND_FIELD_IFELSE([$KSRC/include/linux/netfilter.h], [nf_hook_state],
diff --git a/datapath/linux/compat/include/linux/netdevice.h 
b/datapath/linux/compat/include/linux/netdevice.h
index cf68ed5238d4..126ff23cfa27 100644
--- a/datapath/linux/compat/include/linux/netdevice.h
+++ b/datapath/linux/compat/include/linux/netdevice.h
@@ -323,4 +323,14 @@ static inline void netif_keep_dst(struct net_device *dev)
 }
 #endif
 
+#ifndef HAVE_DEV_CHANGE_FLAGS_TAKES_EXTACK
+static inline int rpl_dev_change_flags(struct net_device *dev,
+  unsigned int flags,
+  struct netlink_ext_ack *extack)
+{
+   return dev_change_flags(dev, flags);
+}
+#define dev_change_flags rpl_dev_change_flags
+#endif
+
 #endif /* __LINUX_NETDEVICE_WRAPPER_H */
diff --git a/datapath/linux/compat/ip6_gre.c b/datapath/linux/compat/ip6_gre.c
index 2ffdda5e1dc3..ca4e66133570 100644
--- a/datapath/linux/compat/ip6_gre.c
+++ b/datapath/linux/compat/ip6_gre.c
@@ -2647,7 +2647,7 @@ static struct vport *erspan6_tnl_create(const struct 
vport_parms *parms)
return ERR_CAST(dev);
}
 
-   err = dev_change_flags(dev, dev->flags | IFF_UP);
+   err = dev_change_flags(dev, dev->flags | IFF_UP, NULL);
if (err < 0) {
rtnl_delete_link(dev);
rtnl_unlock();
@@ -2748,7 +2748,7 @@ static struct vport *ip6gre_tnl_create(const struct 
vport_parms *parms)
return ERR_CAST(dev);
}
 
-   err = dev_change_flags(dev, dev->flags | IFF_UP);
+   err = dev_change_flags(dev, dev->flags | IFF_UP, NULL);
if (err < 0) {
rtnl_delete_link(dev);
rtnl_unlock();
diff --git a/datapath/linux/compat/ip_gre.c b/datapath/linux/compat/ip_gre.c
index 89ef45556dce..cf8803b53075 100644
--- a/datapath/linux/compat/ip_gre.c
+++ b/datapath/linux/compat/ip_gre.c
@@ -1500,7 +1500,7 @@ static struct vport *erspan_tnl_create(const struct 
vport_parms *parms)
return ERR_CAST(dev);
}
 
-   err = dev_change_flags(dev, dev->flags | IFF_UP);
+   err = dev_change_flags(dev, dev->flags | IFF_UP, NULL);
if (err < 0) {
rtnl_delete_link(dev);
rtnl_unlock();
@@ -1554,7 +1554,7 @@ static struct vport *ipgre_tnl_create(const struct 
vport_parms *parms)
return ERR_CAST(dev);
}
 
-   err = dev_change_flags(dev, dev->flags | IFF_UP);
+   err = dev_change_flags(dev, dev->flags | IFF_UP, NULL);
if (err < 0) {
rtnl_delete_link(dev);
rtnl_unlock();
diff --git a/datapat

[ovs-dev] [PATCH 3/5] datapath: Backport the removal of __tcp_checksum_complete()

[Yifeng Sun]

Upstream commit 6ab6dfa6bb500f5cbb9b7a0f23a1613417ca2d12 ("net: get
rid of __tcp_checksum_complete())" deleted __tcp_checksum_complete()
and caused compilation failure for OVS on newer kernels.

This patch fixes it by using __skb_checksum_complete(), which is
100% the same with __tcp_checksum_complete().

Signed-off-by: Yifeng Sun 
---
 datapath/linux/compat/stt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/datapath/linux/compat/stt.c b/datapath/linux/compat/stt.c
index 5f045120ed20..21fef09f4329 100644
--- a/datapath/linux/compat/stt.c
+++ b/datapath/linux/compat/stt.c
@@ -1299,7 +1299,7 @@ static bool validate_checksum(struct sk_buff *skb)
skb->csum = csum_tcpudp_nofold(iph->saddr, iph->daddr, skb->len,
   IPPROTO_TCP, 0);
 
-   return __tcp_checksum_complete(skb) == 0;
+   return __skb_checksum_complete(skb) == 0;
 }
 
 static bool set_offloads(struct sk_buff *skb)
-- 
2.7.4

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

[ovs-dev] [PATCH 2/5] OVS: remove use of VLAN_TAG_PRESENT

[Yifeng Sun]

From: Michał Mirosław 

Upstream commit:
commit 9df46aefafa6dee81a27c2a9d8ba360abd8c5fe3
Author: Michał Mirosław 
Date:   Thu Nov 8 18:44:50 2018 +0100

OVS: remove use of VLAN_TAG_PRESENT

This is a minimal change to allow removing of VLAN_TAG_PRESENT.
It leaves OVS unable to use CFI bit, as fixing this would need
a deeper surgery involving userspace interface.

Signed-off-by: Michał Mirosław 
Signed-off-by: David S. Miller 

This patch backports the above upstream patch to OVS and adds
extra checking in kernel module's compat code.

Cc: Michał Mirosław 
Signed-off-by: Yifeng Sun 
---
 acinclude.m4  |  4 
 datapath/actions.c| 13 +
 datapath/flow.c   |  6 +++---
 datapath/flow.h   |  2 +-
 datapath/flow_netlink.c   | 22 +++---
 datapath/linux/compat/include/linux/if_vlan.h | 19 +++
 6 files changed, 47 insertions(+), 19 deletions(-)

diff --git a/acinclude.m4 b/acinclude.m4
index 6783512a68f3..eb978e0fae6c 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -511,6 +511,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
   OVS_GREP_IFELSE([$KSRC/include/linux/if_link.h], [rtnl_link_stats64])
   OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [vlan_set_encap_proto])
   OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [vlan_hwaccel_push_inside])
+  OVS_GREP_IFELSE([$KSRC/include/linux/if_vlan.h], [__vlan_hwaccel_clear_tag])
 
   OVS_GREP_IFELSE([$KSRC/include/linux/in.h], [ipv4_is_multicast])
   OVS_GREP_IFELSE([$KSRC/include/linux/in.h], [proto_ports_offset])
@@ -925,6 +926,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
   OVS_FIND_FIELD_IFELSE([$KSRC/include/linux/skbuff.h], [sk_buff],
 [csum_valid],
 [OVS_DEFINE([HAVE_SKBUFF_CSUM_VALID])])
+  OVS_FIND_FIELD_IFELSE([$KSRC/include/linux/skbuff.h], [sk_buff],
+[vlan_present],
+[OVS_DEFINE([HAVE_SKBUFF_VLAN_PRESENT])])
   OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h],
   [skb_checksum_simple_validate])
   OVS_GREP_IFELSE([$KSRC/include/linux/netdevice.h],
diff --git a/datapath/actions.c b/datapath/actions.c
index f5db12389889..5a1d3206a101 100644
--- a/datapath/actions.c
+++ b/datapath/actions.c
@@ -306,7 +306,7 @@ static int push_vlan(struct sk_buff *skb, struct 
sw_flow_key *key,
key->eth.vlan.tpid = vlan->vlan_tpid;
}
return skb_vlan_push(skb, vlan->vlan_tpid,
-ntohs(vlan->vlan_tci) & ~VLAN_TAG_PRESENT);
+ntohs(vlan->vlan_tci) & ~VLAN_CFI_MASK);
 }
 
 /* 'src' is already properly masked. */
@@ -828,8 +828,10 @@ static int ovs_vport_output(OVS_VPORT_OUTPUT_PARAMS)
__skb_dst_copy(skb, data->dst);
*OVS_GSO_CB(skb) = data->cb;
ovs_skb_set_inner_protocol(skb, data->inner_protocol);
-   skb->vlan_tci = data->vlan_tci;
-   skb->vlan_proto = data->vlan_proto;
+   if (data->vlan_tci & VLAN_CFI_MASK)
+   __vlan_hwaccel_put_tag(skb, data->vlan_proto, data->vlan_tci & 
~VLAN_CFI_MASK);
+   else
+   __vlan_hwaccel_clear_tag(skb);
 
/* Reconstruct the MAC header.  */
skb_push(skb, data->l2_len);
@@ -873,7 +875,10 @@ static void prepare_frag(struct vport *vport, struct 
sk_buff *skb,
data->cb = *OVS_GSO_CB(skb);
data->inner_protocol = ovs_skb_get_inner_protocol(skb);
data->network_offset = orig_network_offset;
-   data->vlan_tci = skb->vlan_tci;
+   if (skb_vlan_tag_present(skb))
+   data->vlan_tci = skb_vlan_tag_get(skb) | VLAN_CFI_MASK;
+   else
+   data->vlan_tci = 0;
data->vlan_proto = skb->vlan_proto;
data->mac_proto = mac_proto;
data->l2_len = hlen;
diff --git a/datapath/flow.c b/datapath/flow.c
index f6a95f9fd86c..618c25e0c3ad 100644
--- a/datapath/flow.c
+++ b/datapath/flow.c
@@ -327,7 +327,7 @@ static int parse_vlan_tag(struct sk_buff *skb, struct 
vlan_head *key_vh,
return -ENOMEM;
 
vh = (struct vlan_head *)skb->data;
-   key_vh->tci = vh->tci | htons(VLAN_TAG_PRESENT);
+   key_vh->tci = vh->tci | htons(VLAN_CFI_MASK);
key_vh->tpid = vh->tpid;
 
if (unlikely(untag_vlan)) {
@@ -365,7 +365,7 @@ static int parse_vlan(struct sk_buff *skb, struct 
sw_flow_key *key)
key->eth.cvlan.tpid = 0;
 
if (skb_vlan_tag_present(skb)) {
-   key->eth.vlan.tci = htons(skb->vlan_tci);
+   key->eth.vlan.tci = htons(skb->vlan_tci) | htons(VLAN_CFI_MASK);
key->eth.vlan.tpid = skb->vlan_proto;
} else {
/* Parse outer vlan tag in the non-accelerated case. */
@@ -604,7 +604,7 @@ static int key_extract(struct sk_buff *skb, struct 
sw_flow_key *key)
 * skb_vlan_pop(), which will later shift 

[ovs-dev] [PATCH 1/5] datapath: Check extack argument of rtnl_create_link()

[Yifeng Sun]

Upstream commit d0522f1cd25edb796548f91e04766fa3cbc3b6df ("net:
Add extack argument to rtnl_create_link") added new argument
to rtnl_create_link(). This introduced compiling errors in
the code of kernel datapath.

This patch fixes this issue.

Signed-off-by: Yifeng Sun 
---
 acinclude.m4  | 3 +++
 datapath/linux/compat/include/net/rtnetlink.h | 4 
 2 files changed, 7 insertions(+)

diff --git a/acinclude.m4 b/acinclude.m4
index 08686044f635..6783512a68f3 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -681,6 +681,9 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
[rcu_read_lock_held])])
   OVS_GREP_IFELSE([$KSRC/include/linux/rtnetlink.h], [lockdep_rtnl_is_held])
   OVS_GREP_IFELSE([$KSRC/include/linux/rtnetlink.h], [net_rwsem])
+  OVS_FIND_PARAM_IFELSE([$KSRC/include/net/rtnetlink.h],
+[rtnl_create_link], [extack],
+[OVS_DEFINE([HAVE_RTNL_CREATE_LINK_TAKES_EXTACK])])
 
   # Check for the proto_data_valid member in struct sk_buff.  The [^@]
   # is necessary because some versions of this header remove the
diff --git a/datapath/linux/compat/include/net/rtnetlink.h 
b/datapath/linux/compat/include/net/rtnetlink.h
index 74d6a27b799f..e026cab9530d 100644
--- a/datapath/linux/compat/include/net/rtnetlink.h
+++ b/datapath/linux/compat/include/net/rtnetlink.h
@@ -32,7 +32,11 @@ static inline struct net_device *rpl_rtnl_create_link(struct 
net *net, const cha
 const struct rtnl_link_ops *ops,
 struct nlattr *tb[])
 {
+#ifdef HAVE_RTNL_CREATE_LINK_TAKES_EXTACK
+   return rtnl_create_link(net, (char *) ifname, name_assign_type, ops, 
tb, NULL);
+#else
return rtnl_create_link(net, (char *) ifname, name_assign_type, ops, 
tb);
+#endif
 }
 #endif
 
-- 
2.7.4

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

[ovs-dev] [PATCH 0/5] datapath: Support 5.0.x kernel version

[Yifeng Sun]

This series of patches enabled OVS to run on kernel 5.0.x.

Tests shows that this series of patches passed check-kmod tests or
didn't introduce new failed check-kmod tests for the following
kernel versions:
3.10.0-957.12.1.el7.x86_64 (rhel)
4.4.0-31-generic (ubuntu 14.04)
4.4.0-146-generic (ubuntu 16.04)
4.4.179
4.9.171
4.14.111
4.15.0-48-generic (ubuntu 18.04)
4.17.19
4.18.0-18-generic (ubuntu 18.10)
4.19.37
4.20.17
5.0.0-16-generic (ubuntu 19.04)

Several fragmentation-related tests failed on 5.0.x kernels. Another
pull request was created to fix this issue:
https://github.com/openvswitch/ovs/pull/278

Travis passed at:
https://travis-ci.org/yifsun/ovs-travis/builds/543907186

In addition, builds succeeded and 'make check-kmod' passed on:
CentOS73, Fedora, RHEL74, RHEL75, RHEL76 and Ubuntu (bionic, trusty,
xenial, Disco Dingo).

Yifeng Sun (5):
  datapath: Check extack argument of rtnl_create_link()
  OVS: remove use of VLAN_TAG_PRESENT
  datapath: Backport the removal of __tcp_checksum_complete()
  net: core: dev: Add extack argument to dev_change_flags()
  datapath: Support kernel version 5.0.x

 .travis.yml |  1 +
 .travis/linux-build.sh  |  4 +++-
 Documentation/faq/releases.rst  |  2 +-
 NEWS|  1 +
 acinclude.m4| 20 
 datapath/actions.c  | 13 +
 datapath/flow.c |  6 +++---
 datapath/flow.h |  2 +-
 datapath/flow_netlink.c | 22 +++---
 datapath/linux/compat/include/linux/if_vlan.h   | 19 +++
 datapath/linux/compat/include/linux/netdevice.h | 10 ++
 datapath/linux/compat/include/net/rtnetlink.h   |  4 
 datapath/linux/compat/ip6_gre.c |  4 ++--
 datapath/linux/compat/ip_gre.c  |  4 ++--
 datapath/linux/compat/stt.c |  2 +-
 datapath/vport-geneve.c |  2 +-
 datapath/vport-gre.c|  2 +-
 datapath/vport-lisp.c   |  2 +-
 datapath/vport-stt.c|  2 +-
 datapath/vport-vxlan.c  |  2 +-
 20 files changed, 89 insertions(+), 35 deletions(-)

-- 
2.7.4

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

Re: [ovs-dev] [PATCH] ovn: Send GARP for the router ports connected to localnet switches

[Ankur Sharma]

Hi Numan,

Sure, we can wait for your “garp_addresses”  based changes to do both “gw ports 
and  “resident-on-redirect-chassis”.
I can provide periodic advertisement related changes after that.

Regards,
Ankur

From: Numan Siddique 
Sent: Monday, June 10, 2019 10:27 AM
To: Han Zhou 
Cc: ovs dev ; Ankur Sharma 
Subject: Re: [ovs-dev] [PATCH] ovn: Send GARP for the router ports connected to 
localnet switches



On Fri, Jun 7, 2019 at 5:18 AM Han Zhou 
mailto:zhou...@gmail.com>> wrote:


On Wed, May 1, 2019 at 9:04 AM 
mailto:nusid...@redhat.com>> wrote:
>
> From: Numan Siddique mailto:nusid...@redhat.com>>
>
> With the commit [1], the routing for the provider logical switches
> connected to a router is centralized on the master gateway chassis
> (if the option - reside-on-redirect-chassis) is set. When the
> failover happens and a standby gateway chassis becomes master,
> it should send GARPs for the router port macs. Without this, the
> physical switch doesn't learn the new location of the router port macs
> immediately and this could result in traffic disruption.
>
> This patch addresses this issue so that the ovn-controller which claims the
> distributed gatweway router port sends out the GARPs.
>
> [1] - 85706c34d53d ("ovn: Avoid tunneling for VLAN packets redirected to a 
> gateway chassis")
>
> Signed-off-by: Numan Siddique 
> mailto:nusid...@redhat.com>>
> ---
>  ovn/northd/ovn-northd.c | 21 +++
>  tests/ovn.at 
> [ovn.at]
> | 58 +++--
>  2 files changed, 77 insertions(+), 2 deletions(-)
>
Hi Numan,

Thanks for the fix. I have 2 comments:
1. The title is general which seems to address the problem for all "router 
ports connected to localnet switches". However, the commit message body and the 
code seems only handling the "reside-on-redirect-chassis" scenario, without 
taking care of the more common scenario - the gateway port GARP.

Agree. I think Ankur (CC'ed) is planning to handle this scenario - i.e sending 
the GAR for the gateway ports.



2. The fix seems all related to "nat_addresses" handling, but this problem is 
not directly related to "NAT". After reading more context of the code, I 
realized that it is the right place to fix, but it is really not 
straightforward to understand. Of course this is not a problem introduced by 
current patch. It would be better if we had named the option "garp_addresses" 
instead of "nat_addresses", but I think it may be hard to rename at this stage 
because it will introduce compatibility problem. So probably we can add some 
more comments just to make the context more clear for readers.

How about adding a new column "garp_addresses" ? This column can be used both 
for the gw port GARP and for the "reside-on-redirect-chassis" ?

If this makes sense, I will work on it.
@Ankur - I will submit a patch with a new column (which will send GARPs for 
both the gw router ports and other router ports with the option - 
reside-on-redirect-chassis ) and and then you can enhance it to send the GARPs 
in periodic interval instead of initial bursts  (which the present code does 
for NAT addresses ) ? Does this sound good ?


Thanks
Numan



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

[ovs-dev] Historia y Cultura de México

[Para ejecutivos extranjeros]

¡Hola!

Me da mucho gusto saludarte.

Es para mi un placer poder invitarte a nuestro webinar "Historia y cultura de 
México para ejecutivos extranjeros" que se estará
llevando a cabo el día Viernes 05 de Julio con un horario de 10:00 a 14:00 hrs. 
(hora de la ciudad de México)


Con este curso en línea lograremos:

Las raíces culturales indígenas aportadas por el México prehispánico. 
La influencia española y la formación de una cultura criolla y mestiza 
mexicana. 
La génesis y desarrollo del México actual, en el inicio de vida independiente.
El experto que nos acompañará Alejandro Ibarra tiene una formación dual idónea 
para el curso: posee una trayectoria de más de 30 años como alto
ejecutivo de la función de compras en empresas nacionales, globales, públicas y 
privadas, y se desempeñaactualmente como consultor y capacitador. 
Tiene asimismo estudios de maestría en historia de México (candidato al grado), 
especializado en historia política del siglo XIX. Para el expositor el
conocimiento histórico es esencial para comprender la cultura de un país, y ha 
podido constatar las limitaciones que la falta de este conocimiento provoca 
a los ejecutivos extranjeros y sus familias en su integración profesional y 
social.

Te invito a que participes con nosotros y conozcas los beneficios de la 
capacitación en línea.

Tel: (045) 55 15 54 66 30 

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

Nombre:
Correo electrónico:
Número telefónico:

¡Qué tengas un excelente día!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next] net: openvswitch: remove unnecessary ASSERT_OVSL in ovs_vport_del()

[Gregory Rose]

On 6/9/2019 10:19 AM, Taehee Yoo wrote:

ASSERT_OVSL() in ovs_vport_del() is unnecessary because
ovs_vport_del() is only called by ovs_dp_detach_port() and
ovs_dp_detach_port() calls ASSERT_OVSL() too.

Signed-off-by: Taehee Yoo 
---
  net/openvswitch/vport.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/net/openvswitch/vport.c b/net/openvswitch/vport.c
index 258ce3b7b452..9e71f1a601a9 100644
--- a/net/openvswitch/vport.c
+++ b/net/openvswitch/vport.c
@@ -261,8 +261,6 @@ int ovs_vport_set_options(struct vport *vport, struct 
nlattr *options)
   */
  void ovs_vport_del(struct vport *vport)
  {
-   ASSERT_OVSL();
-
hlist_del_rcu(&vport->hash_node);
module_put(vport->ops->owner);
vport->ops->destroy(vport);


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

[ovs-dev] FRAU MUELLER MÉLANIE

[bouboule bella via dev]

Meineaufrichtigen Grüße

Ichentschuldige mich aufrichtig für die Störung Ihres Seelenfriedens, indem 
ichIhnen diese Nachricht sende.

Ich bin Witwe Mélanie Müller, 63 Jahre alt, deutscherHerkunft.

Ich schreibe Ihnen wegen meines Gesundheitszustands,der sich von Tag zu Tag 
verschlechtert.

Ich bin einer von denen, mit denen die Natur großzügigwar. Gott hat mich in 
seiner unendlichen Güte während meiner kleinen Existenzbelohnt.

Sicher habe ich weder Familie noch Kinder. aber ichhatte ein relativ 
glückliches Leben.

Bisher; Ich habe diese Leere in meinem Lebenwettgemacht, indem ich mein Bestes 
gegeben habe, um den Armen zu helfen, indemich ihnen nur einen Moment des 
Glücks bringe.

Leider leide ich an einer sehr ernsten Krankheit ohneHoffnung auf Heilung. 
Daher kann ich meine guten Werke nicht fortsetzen.Deshalb wende ich mich mit 
dieser E-Mail an Sie, um mir zu helfen, meinenletzten Wunsch in dieser Welt zu 
erfüllen.

Ich weiß nicht, in welchem Tätigkeitsbereich Sie sichbefinden, geschweige denn 
Ihre persönliche Situation, aber mit IhrerZustimmung, wenn Sie mir natürlich 
erlauben, würde ich gerne die Summe vonachtundneunzigtausend vermachen Euro 
(98.000 €), die ich in einer Bank eineswestafrikanischen Landes in (Benin) 
hinterlassen habe.

Ein Teil dieses Geldes muss für dieWohltätigkeitsarbeit in einigen Kirchen um 
Sie herum und für die Armen um Sieherum verwendet werden, und der zweite Teil 
kann für Ihre persönlichenBedürfnisse verwendet werden.

Seien Sie nicht überrascht, wenn ich Sie wähle. Ich habenur Gott gebeten, mich 
zu jemandem zu führen, der es wert wäre, diesegroßzügige Spende zu erhalten, um 
meine letzten Entscheidungen zu treffen.

Ich gebe zu, dass meine Herangehensweise ungewöhnlichist, aber ich bitte Sie, 
an meinen guten Willen zu glauben.

Ich denke aus ganzem Herzen, dass ich Sie nichtauserwählt habe, aber ich traue 
mich, Gott zu vertrauen.

Wisse, dass ich eine aufrichtige, ehrliche, einfacheund direkte Person 
gegenüber allen Menschen bin. Ich habe es immer gewohnt,meine Ideen, Neid, 
Schmerz und mein Glück mitzuteilen.

Wenn Sie sich für meinen Vorschlag interessieren,können Sie sich an meinen 
Pastor, meinen großen Freund und Vertrauten inWestafrika, dem ich diese große 
Verantwortung anvertraut habe, wenden, indemSie ihm unten die Informationen für 
den gesamten Prozess der Einziehung vonGeldern geben Legalität.

Pastor Petersen ist auch deutscher Nationalität, erlebt seit fast 6 Jahren 
aufgrund seiner pastoralen Pflichten in Afrika.

Sie können ihm dann vollkommen vertrauen, er ist einMann Gottes und sehr 
freundlich.

Sie werden alle Beweise und Details zu meiner Spendebei sich haben, also keine 
Sorgen.

Name ...

Vorname: ..

Land ..

Stadt ..

Telefon ...

Alter ...

VollständigeAdresse ...

 

PastorsE-Mail: pastor.peterse...@gmail.com

Meinepersönliche E-Mail-Adresse:mullermelanie1...@gmail.com

Trotzdemdanke ich Ihnen, dass Sie sich die Mühe gemacht haben, meine E-Mail zu 
lesen.

Ich bitte Gott, den Ewigen in all seiner Pracht undseiner Güte, Ihnen Freude 
und Glück in Ihrem Leben zu bringen.

Nochmals vielen Dank und Ihnen im Frieden des Herrn

MelanieMüller

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

Re: [ovs-dev] [PATCH] rhel: let *-ctl handle runtime directory

[Ben Pfaff]

On Mon, Jun 10, 2019 at 03:55:31PM +0200, Jaime Caamaño Ruiz wrote:
> Recent versions of systemd restores RuntimeDirectory ownership to the
> unit's User in between execution of *Exec directives (see [1]). Using
> ExecStartPre to reset RuntimeDirectory ownership to OVS_USER no longer
> works as expected.
> 
> The ctl scripts already handle creation of the runtime directory with
> correct ownership and permissions so we can basically remove
> RuntimeDirectory from systemd unit file. There is still need to handle
> ownsership to cover some upgrade scenarios, but success of that will be
> optional as the directory itself wont exist at first time run.
> 
> [1] https://github.com/systemd/systemd/issues/12713
> 
> Signed-off-by: Jaime Caamaño Ruiz 

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

Re: [ovs-dev] [PATCH net] net: openvswitch: do not free vport if register_netdevice() is failed.

[Gregory Rose]

On 6/9/2019 7:26 AM, Taehee Yoo wrote:

In order to create an internal vport, internal_dev_create() is used and
that calls register_netdevice() internally.
If register_netdevice() fails, it calls dev->priv_destructor() to free
private data of netdev. actually, a private data of this is a vport.

Hence internal_dev_create() should not free and use a vport after failure
of register_netdevice().

Test command
 ovs-dpctl add-dp bonding_masters

Splat looks like:
[ 1035.667767] kasan: GPF could be caused by NULL-ptr deref or user memory 
access
[ 1035.675958] general protection fault:  [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 1035.676916] CPU: 1 PID: 1028 Comm: ovs-vswitchd Tainted: GB 
5.2.0-rc3+ #240
[ 1035.676916] RIP: 0010:internal_dev_create+0x2e5/0x4e0 [openvswitch]
[ 1035.676916] Code: 48 c1 ea 03 80 3c 02 00 0f 85 9f 01 00 00 4c 8b 23 48 b8 00 00 
00 00 00 fc ff df 49 8d bc 24 60 05 00 00 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 
85 86 01 00 00 49 8b bc 24 60 05 00 00 e8 e4 68 f4
[ 1035.713720] RSP: 0018:88810dcb7578 EFLAGS: 00010206
[ 1035.713720] RAX: dc00 RBX: 88810d13fe08 RCX: 84297704
[ 1035.713720] RDX: 00ac RSI:  RDI: 0560
[ 1035.713720] RBP: ffef R08: fbfff0d3b881 R09: fbfff0d3b881
[ 1035.713720] R10: 0001 R11: fbfff0d3b880 R12: 
[ 1035.768776] R13: 607ee460b900 R14: 88810dcb7690 R15: 88810dcb7698
[ 1035.09] FS:  7f02095fc980() GS:88811b40() 
knlGS:
[ 1035.09] CS:  0010 DS:  ES:  CR0: 80050033
[ 1035.09] CR2: 7ffdf01d2f28 CR3: 000108258000 CR4: 001006e0
[ 1035.09] Call Trace:
[ 1035.09]  ovs_vport_add+0x267/0x4f0 [openvswitch]
[ 1035.09]  new_vport+0x15/0x1e0 [openvswitch]
[ 1035.09]  ovs_vport_cmd_new+0x567/0xd10 [openvswitch]
[ 1035.09]  ? ovs_dp_cmd_dump+0x490/0x490 [openvswitch]
[ 1035.09]  ? __kmalloc+0x131/0x2e0
[ 1035.09]  ? genl_family_rcv_msg+0xa54/0x1030
[ 1035.09]  genl_family_rcv_msg+0x63a/0x1030
[ 1035.09]  ? genl_unregister_family+0x630/0x630
[ 1035.841681]  ? debug_show_all_locks+0x2d0/0x2d0
[ ... ]

Fixes: cf124db566e6 ("net: Fix inconsistent teardown and release of private netdev 
state.")
Signed-off-by: Taehee Yoo 
---
  net/openvswitch/vport-internal_dev.c | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/net/openvswitch/vport-internal_dev.c 
b/net/openvswitch/vport-internal_dev.c
index 26f71cbf7527..5993405c25c1 100644
--- a/net/openvswitch/vport-internal_dev.c
+++ b/net/openvswitch/vport-internal_dev.c
@@ -170,7 +170,9 @@ static struct vport *internal_dev_create(const struct 
vport_parms *parms)
  {
struct vport *vport;
struct internal_dev *internal_dev;
+   struct net_device *dev;
int err;
+   bool free_vport = true;
  
  	vport = ovs_vport_alloc(0, &ovs_internal_vport_ops, parms);

if (IS_ERR(vport)) {
@@ -178,8 +180,9 @@ static struct vport *internal_dev_create(const struct 
vport_parms *parms)
goto error;
}
  
-	vport->dev = alloc_netdev(sizeof(struct internal_dev),

- parms->name, NET_NAME_USER, do_setup);
+   dev = alloc_netdev(sizeof(struct internal_dev),
+  parms->name, NET_NAME_USER, do_setup);
+   vport->dev = dev;
if (!vport->dev) {
err = -ENOMEM;
goto error_free_vport;
@@ -200,8 +203,10 @@ static struct vport *internal_dev_create(const struct 
vport_parms *parms)
  
  	rtnl_lock();

err = register_netdevice(vport->dev);
-   if (err)
+   if (err) {
+   free_vport = false;
goto error_unlock;
+   }
  
  	dev_set_promiscuity(vport->dev, 1);

rtnl_unlock();
@@ -211,11 +216,12 @@ static struct vport *internal_dev_create(const struct 
vport_parms *parms)
  
  error_unlock:

rtnl_unlock();
-   free_percpu(vport->dev->tstats);
+   free_percpu(dev->tstats);
  error_free_netdev:
-   free_netdev(vport->dev);
+   free_netdev(dev);
  error_free_vport:
-   ovs_vport_free(vport);
+   if (free_vport)
+   ovs_vport_free(vport);
  error:
return ERR_PTR(err);
  }


Reviewed-by: Greg Rose 

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

Re: [ovs-dev] [PATCH 2/2] rhel: Fix ovn database dir optional on first run

[Ben Pfaff]

On Mon, Jun 10, 2019 at 06:58:12PM +0200, Jaime Caamaño Ruiz wrote:
> OVN database directory is createid on first run so make ownership
> handling optional.
> 
> Fixes: 94e1e8be3187 ("rhel: run ovn with the same user as ovs")
> Signed-off-by: Jaime Caamaño Ruiz 

Thanks, I applied these to master.  If they should be backported, let me
know.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] AF_XDP with QoS support question

[William Tu]

Hi Jakub,

Thanks for your feedback.


On Sat, Jun 8, 2019 at 2:19 PM Jakub Kicinski
 wrote:
>
> On Fri, 7 Jun 2019 19:55:34 -0700, William Tu wrote:
> > Hi,
> >
> > When using AF_XDP, the TC qdisc layer is by-passed and packets go to
> > userspace directly. One problem is that there is no QoS support when
> > using AF_XDP.
> >
> > For egress shaping, I'm thinking about using tc-mqprio, which has
> > hardware offload support. And for OVS, we can add tc-mqprio support.
>
> What is your end game?  Once upon the time Simon was explaining the QoS

I thought I could do s.t like
1) combined to 1 queue only using ethtool
2) using AF_XDP in OVS to send packets to queue0,
3) program the mqprio to do some ratelimit, and set prio by SO_PRIORITY

ex: use queue 0-1, 2-3,  and 4
tc qdisc add dev eth3 root mqprio num_tc 3 map 0 0 0 0 1 1 1 2 queues
2@0 2@2 1@4

> stuff in OvS to me, but IIRC it used CBQ and/or HTB.  The XDP TX queues
> are not exposed to the stack, so we can't set per-queue QoS, setting a
> root Qdisc (like mqprio) and expecting the XDP queues to have the same
> settings would be very limiting (then again even with mqprio IDK how
> you'd select the prio? by using the TX queue ID? hm..).
>
I see.
So the hw queues used by AF_XDP is the same queues used by QoS?
Then I guess the above command won't work.

> > For ingress policing, I don't know how to do it. Is there an hardware
> > offload ingress policing support?
>
> There is support for act_police in a couple drivers.  Although using it
> per queue could be a challenge...  (At least we do have a real queue ID
> on the RX, hopefully the mlx5 fake queues never get merged.)

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

Re: [ovs-dev] [PATCH] ovn: Send GARP for the router ports connected to localnet switches

[Numan Siddique]

On Fri, Jun 7, 2019 at 5:18 AM Han Zhou  wrote:

>
>
> On Wed, May 1, 2019 at 9:04 AM  wrote:
> >
> > From: Numan Siddique 
> >
> > With the commit [1], the routing for the provider logical switches
> > connected to a router is centralized on the master gateway chassis
> > (if the option - reside-on-redirect-chassis) is set. When the
> > failover happens and a standby gateway chassis becomes master,
> > it should send GARPs for the router port macs. Without this, the
> > physical switch doesn't learn the new location of the router port macs
> > immediately and this could result in traffic disruption.
> >
> > This patch addresses this issue so that the ovn-controller which claims
> the
> > distributed gatweway router port sends out the GARPs.
> >
> > [1] - 85706c34d53d ("ovn: Avoid tunneling for VLAN packets redirected to
> a gateway chassis")
> >
> > Signed-off-by: Numan Siddique 
> > ---
> >  ovn/northd/ovn-northd.c | 21 +++
> >  tests/ovn.at| 58 +++--
> >  2 files changed, 77 insertions(+), 2 deletions(-)
> >
> Hi Numan,
>
> Thanks for the fix. I have 2 comments:
>
> 1. The title is general which seems to address the problem for all "router
> ports connected to localnet switches". However, the commit message body and
> the code seems only handling the "reside-on-redirect-chassis" scenario,
> without taking care of the more common scenario - the gateway port GARP.
>

Agree. I think Ankur (CC'ed) is planning to handle this scenario - i.e
sending the GAR for the gateway ports.



>
> 2. The fix seems all related to "nat_addresses" handling, but this problem
> is not directly related to "NAT". After reading more context of the code, I
> realized that it is the right place to fix, but it is really not
> straightforward to understand. Of course this is not a problem introduced
> by current patch. It would be better if we had named the option
> "garp_addresses" instead of "nat_addresses", but I think it may be hard to
> rename at this stage because it will introduce compatibility problem. So
> probably we can add some more comments just to make the context more clear
> for readers.
>

How about adding a new column "garp_addresses" ? This column can be used
both for the gw port GARP and for the "reside-on-redirect-chassis" ?

If this makes sense, I will work on it.
@Ankur - I will submit a patch with a new column (which will send GARPs for
both the gw router ports and other router ports with the option -
reside-on-redirect-chassis ) and and then you can enhance it to send the
GARPs in periodic interval instead of initial bursts  (which the present
code does for NAT addresses ) ? Does this sound good ?

Thanks
Numan



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

Re: [ovs-dev] [PATCH v9 2/2] OVN: Enable N-S Traffic, Vlan backed DVR

[Numan Siddique]

On Fri, Jun 7, 2019 at 5:15 AM Ankur Sharma 
wrote:

> Hi Numan,
>
> Thanks for trying out the patch and providing feedback.
> I am planning to change this series to reflect only the E-W and would send
> out separate patches for N-S improvements.
>
> Following is the reasoning:
>
> ==
> a. I agree that the network_type construct is adding to the confusion and
> may be we should rely on optional/external-id based key-value config.
> b. N-S patch has 3- changes (on a high level) which are distinct from each
> other, having them in a single patch is causing the confusion and is
> holding rest of the reviewed changes.
> c. Last but not the least, there were some gaps in the patch as well.
>
> Here is what I am planning to do:
>
> ==
> a. Keep this series for E-W only and remove all the network_type related
> changes from here (including showing type as bridged/vlan).
>


Hi Ankur.

I agree with the approach you are planning to take.



>
> b. For N-S Changes, this series has following changes. I will send them
> out in separate patches, especially the ones which are more of a bug fix.
> i. Do not allow ARP resolution from physical network unless gateway
> chassis is configured è More of a bug fix, will be sent as a separate
> standalone patch.
>
>ii. GARP advertisement during failover  in the absence of NAT
> configuration è More of a bug fix, will be sent as a separate standalone
> patch.
>
>   iii. Periodic GARP advertisement with/without NAT configuration è New
> feature, will be added along with SNAT changes.
>

This periodic GARP adv will be required irrespective of network_type of the
logical switches connected to a router. So I would request you to handle
this as well
when you submit the patch.


>   iv. Avoid redirection è New feature, will come as a separate patchset,
> we will make it as optional feature, i.e by default even non NATed traffic
> will go via gateway chassis, but config knob can override it.
>

Agree. This makes sense and easier.


>v. No chassis mac replace on gateway chassis è More of a addendum to
> E-W, I am thinking about clubbing it some of N-S changes as this is where
> it will be relevant.
>
>
>
> c. Will send out separate patch for showing network type as overlay or
> bridged (based on localnet port’s presence), I believe it is good to have
> 😊.
> i.e we will not have any new column in logical switch table, but the
> output of relevant ovn-nbctl show command will show type as “overlay” or
> “bridged”.
>
>
> Above will allow us to make progress on the changes we are in agreement
> on, while having thorough discussion on the remaining.
>
> Let me know, if you are fine with the plan, I should be able to send E-W
> only changes in a couple of days and should be able to individual bug fixes
> soon after as well.
>
>
> For rest of the comments, please find my replies inline.
>
> Appreciate your feedback.
>
> Regards,
> Ankur
>
>
>
>
> *From:* Numan Siddique 
> *Sent:* Monday, June 3, 2019 3:06 AM
> *To:* Ankur Sharma 
> *Cc:* ovs-dev@openvswitch.org
> *Subject:* Re: [ovs-dev] [PATCH v9 2/2] OVN: Enable N-S Traffic, Vlan
> backed DVR
>
>
>
>
>
> Hi Ankur,
>
>
>
> Please see some comments inline. Please note that I haven't got the chance
> to look into the code
>
> in detail. I am first trying to test out the patches. (I am in PTO. Expect
> some delay in my replies).
>
>
>
>
>
>
>
> On Thu, May 30, 2019 at 5:58 AM Ankur Sharma 
> wrote:
>
> Background:
> [1] https://mail.openvswitch.org/pipermail/ovs-dev/2018-October/353066.html
> [mail.openvswitch.org]
> 
> [2] 
> https://docs.google.com/document/d/1uoQH478wM1OZ16HrxzbOUvk5LvFnfNEWbkPT6Zmm9OU/edit?usp=sharing
> [docs.google.com]
> 
>
> This Series:
> Layer 2, Layer 3 E-W and Layer 3 N-S (NO NAT) changes for vlan
> backed distributed logical router.
>
> This patch:
> For North-South traffic, we need a chassis which will respond to
> ARP requests for router port coming from outside. For this purpose,
> we will reply upon gateway-chassis construct in OVN, on a logical
> router port, we will associate one or more chassis as gateway chassis.
>
> One of these chassis would be active at a point and will become
> entry point to traffic, bound for end points behind logical router
> coming from outside network (North to South).
>
> This patch make some enhancements to gateway ch

Re: [ovs-dev] [PATCH v3] ovn: Add a new logical switch port type - 'virtual'

[Numan Siddique]

On Sat, Jun 8, 2019 at 2:09 AM Ben Pfaff  wrote:

> On Mon, May 27, 2019 at 12:52:24PM +0530, nusid...@redhat.com wrote:
> > If suppose the virtual_ip is configured to 10.0.0.10 on a virtual
> logical port 'sw0-vip'
> > and the virtual_parents are set to - [sw0-p1, sw0-p2] then below logical
> flows are added in the
> > lsp_in_arp_rsp logical switch pipeline
> >
> >  - table=11(ls_in_arp_rsp), priority=100,
> >match=(inport == "sw0-p1" && ((arp.op == 1 && arp.spa == 10.0.0.10 &&
> arp.tpa == 10.0.0.10) ||
> >  (arp.op == 2 && arp.spa == 10.0.0.10))),
> >action=(bind_vport("sw0-vip", inport); next;)
> > - table=11(ls_in_arp_rsp), priority=100,
> >match=(inport == "sw0-p2" && ((arp.op == 1 && arp.spa == 10.0.0.10 &&
> arp.tpa == 10.0.0.10) ||
> >  (arp.op == 2 && arp.spa == 10.0.0.10))),
> >action=(bind_vport("sw0-vip", inport); next;)
> >
> > The action bind_vport will claim the logical port - sw0-vip on the
> chassis where this action
> > is executed. Since the port - sw0-vip is claimed by a chassis, the
> dnat_and_snat rule for
> > the VIP will be handled by the compute node.
>
> The behavior here is a little bit different from what I ordinarily
> expect in OVN.  Usually, the flow table that ovn-northd outputs depends
> only on the logical network topology and configuration.  With this
> change, the flow table also depends on state, and ovn-northd needs to
> update it if that state changes.
>
> A design that I would perceive as more in the spirit of the current
> design would be one that always puts bind_vport on all of the chassis.
> That would require some work in ovn-controller so that it doesn't
> process a continuous stream of packets in the common case, but it would
> fit the current design better.
>
> Let me know if I misunderstand.
>
>
You are right. I thought it would be fine since we are doing something
similar when adding
ARP responder flows - we only add if the logical port is up. But this patch
goes a bit further
and looks into the Port_Binding's chassis row.

I think it's possible to handle the same in ovn-controller. I will work on
it and post v4.

Thanks for the review.

Numan

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

[ovs-dev] [PATCH 2/2] rhel: Fix ovn database dir optional on first run

[Jaime Caamaño Ruiz]

OVN database directory is createid on first run so make ownership
handling optional.

Fixes: 94e1e8be3187 ("rhel: run ovn with the same user as ovs")
Signed-off-by: Jaime Caamaño Ruiz 
---
 rhel/usr_lib_systemd_system_ovn-northd.service | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rhel/usr_lib_systemd_system_ovn-northd.service 
b/rhel/usr_lib_systemd_system_ovn-northd.service
index ff510fbde..ea8c191e3 100644
--- a/rhel/usr_lib_systemd_system_ovn-northd.service
+++ b/rhel/usr_lib_systemd_system_ovn-northd.service
@@ -25,7 +25,7 @@ RemainAfterExit=yes
 Environment=OVS_RUNDIR=%t/openvswitch OVS_DBDIR=/var/lib/openvswitch
 EnvironmentFile=-/etc/sysconfig/ovn-northd
 EnvironmentFile=/run/openvswitch.useropts
-ExecStartPre=/usr/bin/chown -R ${OVS_USER_ID} ${OVS_DBDIR}
+ExecStartPre=-/usr/bin/chown -R ${OVS_USER_ID} ${OVS_DBDIR}
 ExecStart=/usr/share/openvswitch/scripts/ovn-ctl \
   --ovs-user=${OVS_USER_ID} --ovn-user=${OVS_USER_ID} \
   start_northd $OVN_NORTHD_OPTS
-- 
2.16.4

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

[ovs-dev] [PATCH 1/2] rhel: set useropts optional for ovsdb-server

[Jaime Caamaño Ruiz]

systemd assesses the presssence of all EnvironmentFile before execution
of Exec* directives, thus useropts needs to be optional even though it
will always be created at ExecStartPre.

Fixes: 94e1e8be3187 ("rhel: run ovn with the same user as ovs")
Signed-off-by: Jaime Caamaño Ruiz 
---
 rhel/usr_lib_systemd_system_ovsdb-server.service | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rhel/usr_lib_systemd_system_ovsdb-server.service 
b/rhel/usr_lib_systemd_system_ovsdb-server.service
index a6de4d3c1..4c170c09b 100644
--- a/rhel/usr_lib_systemd_system_ovsdb-server.service
+++ b/rhel/usr_lib_systemd_system_ovsdb-server.service
@@ -14,7 +14,7 @@ EnvironmentFile=-/etc/sysconfig/openvswitch
 ExecStartPre=-/usr/bin/chown ${OVS_USER_ID} /var/run/openvswitch 
/var/log/openvswitch
 ExecStartPre=/bin/sh -c 'rm -f /run/openvswitch.useropts; /usr/bin/echo 
"OVS_USER_ID=${OVS_USER_ID}" > /run/openvswitch.useropts'
 ExecStartPre=/bin/sh -c 'if [ "$${OVS_USER_ID/:*/}" != "root" ]; then 
/usr/bin/echo "OVS_USER_OPT=--ovs-user=${OVS_USER_ID}" >> 
/run/openvswitch.useropts; fi'
-EnvironmentFile=/run/openvswitch.useropts
+EnvironmentFile=-/run/openvswitch.useropts
 ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
   --no-ovs-vswitchd --no-monitor --system-id=random \
   ${OVS_USER_OPT} \
-- 
2.16.4

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

Re: [ovs-dev] [patch v2] conntrack: Add option to disable TCP sequence checking.

[Ben Pfaff]

On Sun, Jun 09, 2019 at 07:35:09AM -0700, Darrell Ball wrote:
> This may be needed in some special cases, such as to support some
> hardware offload implementations.
> 
> Reported-at: 
> https://mail.openvswitch.org/pipermail/ovs-dev/2019-May/359188.html
> Signed-off-by: Darrell Ball 
> ---
> 
> v2: Per particular requirement, support  'no-tcp-seq-chk' rather than
> 'liberal' mode.
> 
> Add some debug counters.

I'm not sure whether an ovs-appctl command is the best way for users to
enable and disable this.  It means that it is difficult for an OpenFlow
controller to do it, since those commands aren't exposed via OpenFlow or
OVSDB.

The documentation says that sequence checking should only be disabled if
absolutely necessary.  If you have an example of such a case, it would
be helpful to add it to the documentation.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] rhel: set useropts optional for ovsdb-server

[Ben Pfaff]

On Mon, Jun 10, 2019 at 06:27:04PM +0200, Jaime Caamaño Ruiz wrote:
> systemd assesses the presssence of all EnvironmentFile before execution
> of Exec* directives, thus useropts needs to be optional even though it
> will always be created at ExecStartPre.
> 
> Problem introduced with commit 94e1e8be3.
> 
> Signed-off-by: Jaime Caamaño Ruiz 

Would you mind reposting after converting the "Problem introduced with
commit 94e1e8be3." line into a Fixes tag for these patches, e.g.:

Fixes: 94e1e8be3187 ("rhel: run ovn with the same user as ovs")

I have a git-fixes script I use to generate these tags, which is just
this one-liner:

git --no-pager log -1 --pretty=format:"CC: %an <%ae>%nFixes: %h (\"%s\")%n" 
--abbrev=12 "$@"
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/4] ovn-controller-vtep: Fix wrong value for ovnsb-db argument

[Ben Pfaff]

This process is fine as is.

On Mon, Jun 10, 2019 at 06:26:33PM +0200, Jaime Caamaño Ruiz wrote:
> Hello Ben
> 
> I have a couple of follow up fixes for this series. Sorry for the
> inconvinience. Let me know if you wish to handle this differently (i.e.
> revert and comprehensive new patches).
> 
> BR
> Jaime.
> 
> -Original Message-
> From: Ben Pfaff 
> To: jcaam...@suse.de
> Cc: d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH 1/4] ovn-controller-vtep: Fix wrong value
> for ovnsb-db argument
> Date: Sun, 9 Jun 2019 17:27:06 -0700
> 
> On Wed, May 08, 2019 at 01:53:45PM +0200, Jaime Caamaño Ruiz wrote:
> > Fix help output of ovn-controller-vtep that was suggesting the
> > openvswitch database instead of the ovn southbound database for the
> > ovnsb-db argument.
> > 
> > Also fix the corresponding systemd unit that was passing the
> > openvswitch
> > database instead of the ovn southbound database for the ovnsb-db
> > argument.
> > 
> > Signed-off-by: Jaime Caamaño Ruiz 
> 
> Thank you for the bug fixes.  I applied this series to master.  If you
> think that it should be backported to earlier release versions, please
> let me know.
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH 2/2] rhel: Fix ovn database dir optional on first run

[Jaime Caamaño Ruiz]

OVN database directory is createid on first run so make ownership
handling optional.

Problem introduced with commit 94e1e8be3.

Signed-off-by: Jaime Caamaño Ruiz 
---
 rhel/usr_lib_systemd_system_ovn-northd.service | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rhel/usr_lib_systemd_system_ovn-northd.service 
b/rhel/usr_lib_systemd_system_ovn-northd.service
index ff510fbde..ea8c191e3 100644
--- a/rhel/usr_lib_systemd_system_ovn-northd.service
+++ b/rhel/usr_lib_systemd_system_ovn-northd.service
@@ -25,7 +25,7 @@ RemainAfterExit=yes
 Environment=OVS_RUNDIR=%t/openvswitch OVS_DBDIR=/var/lib/openvswitch
 EnvironmentFile=-/etc/sysconfig/ovn-northd
 EnvironmentFile=/run/openvswitch.useropts
-ExecStartPre=/usr/bin/chown -R ${OVS_USER_ID} ${OVS_DBDIR}
+ExecStartPre=-/usr/bin/chown -R ${OVS_USER_ID} ${OVS_DBDIR}
 ExecStart=/usr/share/openvswitch/scripts/ovn-ctl \
   --ovs-user=${OVS_USER_ID} --ovn-user=${OVS_USER_ID} \
   start_northd $OVN_NORTHD_OPTS
-- 
2.16.4

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

[ovs-dev] [PATCH 1/2] rhel: set useropts optional for ovsdb-server

[Jaime Caamaño Ruiz]

systemd assesses the presssence of all EnvironmentFile before execution
of Exec* directives, thus useropts needs to be optional even though it
will always be created at ExecStartPre.

Problem introduced with commit 94e1e8be3.

Signed-off-by: Jaime Caamaño Ruiz 
---
 rhel/usr_lib_systemd_system_ovsdb-server.service | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rhel/usr_lib_systemd_system_ovsdb-server.service 
b/rhel/usr_lib_systemd_system_ovsdb-server.service
index a6de4d3c1..4c170c09b 100644
--- a/rhel/usr_lib_systemd_system_ovsdb-server.service
+++ b/rhel/usr_lib_systemd_system_ovsdb-server.service
@@ -14,7 +14,7 @@ EnvironmentFile=-/etc/sysconfig/openvswitch
 ExecStartPre=-/usr/bin/chown ${OVS_USER_ID} /var/run/openvswitch 
/var/log/openvswitch
 ExecStartPre=/bin/sh -c 'rm -f /run/openvswitch.useropts; /usr/bin/echo 
"OVS_USER_ID=${OVS_USER_ID}" > /run/openvswitch.useropts'
 ExecStartPre=/bin/sh -c 'if [ "$${OVS_USER_ID/:*/}" != "root" ]; then 
/usr/bin/echo "OVS_USER_OPT=--ovs-user=${OVS_USER_ID}" >> 
/run/openvswitch.useropts; fi'
-EnvironmentFile=/run/openvswitch.useropts
+EnvironmentFile=-/run/openvswitch.useropts
 ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \
   --no-ovs-vswitchd --no-monitor --system-id=random \
   ${OVS_USER_OPT} \
-- 
2.16.4

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

Re: [ovs-dev] [PATCH 1/4] ovn-controller-vtep: Fix wrong value for ovnsb-db argument

[Jaime Caamaño Ruiz]

Hello Ben

I have a couple of follow up fixes for this series. Sorry for the
inconvinience. Let me know if you wish to handle this differently (i.e.
revert and comprehensive new patches).

BR
Jaime.

-Original Message-
From: Ben Pfaff 
To: jcaam...@suse.de
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH 1/4] ovn-controller-vtep: Fix wrong value
for ovnsb-db argument
Date: Sun, 9 Jun 2019 17:27:06 -0700

On Wed, May 08, 2019 at 01:53:45PM +0200, Jaime Caamaño Ruiz wrote:
> Fix help output of ovn-controller-vtep that was suggesting the
> openvswitch database instead of the ovn southbound database for the
> ovnsb-db argument.
> 
> Also fix the corresponding systemd unit that was passing the
> openvswitch
> database instead of the ovn southbound database for the ovnsb-db
> argument.
> 
> Signed-off-by: Jaime Caamaño Ruiz 

Thank you for the bug fixes.  I applied this series to master.  If you
think that it should be backported to earlier release versions, please
let me know.

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

Re: [ovs-dev] [PATCH] rhel: useropts should be owned by package

[Ben Pfaff]

On Mon, Jun 10, 2019 at 03:55:45PM +0200, Jaime Caamaño Ruiz wrote:
> So that is properly cleaned up after package is uninstalled.
> 
> Signed-off-by: Jaime Caamaño Ruiz 

Hard to argue with that.  I pushed this to master.  Please let me know
if you want it backported.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] 回复: 回复: 回复: one issue in vxlan functionality of the kernel-datapath type of ovs

[Ben Pfaff]

On Mon, Jun 10, 2019 at 01:19:33AM +, pei Jikui wrote:
> 1) Based on my understanding, there are two kinds of cases to age out the 
> datapath flow.
> a) Timer.
> b) revalidate. The flow will be deleted if there are some invalidated 
> conditions such as there is no output interface for this flow.
> 
> Even if the revalidate does not work, the timer mechanism will eventually 
> delete the flows.

The timer mechanism is only used if a flow becomes idle, which can take
an indefinite time.

> 2) Would you please help to elaborate what the impaction of this change 
> imposes to the case where the actions are changed from "drop" to anything 
> else?  I couldn't understand this well.

If the controller changes the OpenFlow flow table, then revalidation
might change datapath flow actions arbitrarily.  Some of those changes
can be from "drop" to something else.

> Thanks for working on the problem.
> 
> I agree that this will solve this particular problem.  At the same time,
> it will break OVS in every situation where a flow's actions need to
> change from "drop" to anything else.  We can't accept that regression,
> which would be a correctness issue, not just a performance issue.
> 
> On Sun, Jun 02, 2019 at 01:52:56AM +, pei Jikui wrote:
> > Attach the diff which I have verified locally.
> > Thanks.
> >
> > [root@localhost ovs]# git diff
> > diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
> > index dc30824..c5a7de6 100644
> > --- a/ofproto/ofproto-dpif-upcall.c
> > +++ b/ofproto/ofproto-dpif-upcall.c
> > @@ -2678,9 +2678,12 @@ revalidate(struct revalidator *revalidator)
> >  }
> >  if (kill_them_all || (used && used < now - max_idle)) {
> >  result = UKEY_DELETE;
> > -} else {
> > +/*Only validate the ukey if the flow's action is not 
> > drop.Since for the drop flows, there might be not validated.*/
> > +} else if (f->actions_len > 0) {
> >  result = revalidate_ukey(udpif, ukey, &f->stats, 
> > &odp_actions,
> >   reval_seq, &recircs);
> > +} else {
> > +result = UKEY_KEEP;
> >  }
> >  ukey->dump_seq = dump_seq;
> >
> >
> >
> > 
> > 发件人: ovs-dev-boun...@openvswitch.org  代表 
> > pei Jikui 
> > 发送时间: 2019年6月2日 9:42
> > 收件人: Ben Pfaff
> > 抄送: ovs-dev@openvswitch.org; ovs-disc...@openvswitch.org
> > 主题: [ovs-dev] 回复: one issue in vxlan functionality of the kernel-datapath 
> > type of ovs
> >
> > hi,
> >
> > I looked into this further and found the root cause.
> >
> > 1) for the unwanted packets(no vxlan tunnel configured for this case), the 
> > receiver will install the drop-action flow to the datapath.
> > 2) when the revalidator thread is trying to age-out/clean-up the flows 
> > installed in step 1), they are considered as invalidated by revalidator 
> > thread since the revalidator thread could not find the xport for them. 
> > Hence the revalidator thread delete the them very soon.
> > 3) that is causing all the upcoming packets are sending to userspace again. 
> >   And repeat the steps that  a) send to userspace, b) install drop-action 
> > flow table c) the revalidator thread delete them.
> > 4) A proposed fix is if the flow's action is drop, we only bank on the time 
> > age-out mechanism to clean them up and don't enforce the revalidate_ukey 
> > action for them.
> >
> > Thanks.
> >
> > Jikui
> >
> > 
> > 发件人: pei Jikui 
> > 发送时间: 2019年5月25日 7:31
> > 收件人: Ben Pfaff
> > 抄送: ovs-dev@openvswitch.org; ovs-disc...@openvswitch.org
> > 主题: Re: [ovs-dev] one issue in vxlan functionality of the kernel-datapath 
> > type of ovs
> >
> > In my test bed there is no any dropping flow entry generated in the 
> > datapath, which causes all the unwanted vxlan packets will go to the slow 
> > path.  That’s a little time-consuming for this case.
> >
> >
> >
> > 发送自 Outlook
> >
> > 
> > 发件人: Ben Pfaff 
> > 发送时间: 2019年5月25日 2:36
> > 收件人: pei Jikui
> > 抄送: ovs-dev@openvswitch.org; ovs-disc...@openvswitch.org
> > 主题: Re: [ovs-dev] one issue in vxlan functionality of the kernel-datapath 
> > type of ovs
> >
> > On Sat, May 18, 2019 at 10:23:50AM +, pei Jikui wrote:
> > > I found one issue in the vxlan functionality in kernel-datapath type of 
> > > ovs which could be potentially optimize?
> > >
> > >
> > > For example, there is a machine (A) running ovs with one configured one 
> > > vxlan interface with tunnel value 123,  then all the vxlan traffics 
> > > destinate to this machine(A) will be dealt with the ovs.
> > >
> > >
> > > Although the ovs in machine A only configured with one vxlan tunnel 
> > > (123), all the vxlan traffics regardless the tunnel value is 123 or not, 
> > > will be delivered to the vswitchd to do the slow path if there is no flow 
> > > tables found in t

Re: [ovs-dev] [PATCH v3 2/2] Don't send or receive LACP PDUs when carrier state of slave is down

[Ben Pfaff]

On Sun, Jun 09, 2019 at 02:18:10PM +, Nitin Katiyar wrote:
> Fortville NICs (or their drivers) can get into an inconsistent state,
> in which the NIC can actually transmit and receive packets even
> though they report "PHY down". In such a state, OVS can exchange and
> process LACP messages and enable a LACP slave. However, further packet
> exchange over the slave fails because OVS sees that the PHY is down.
> 
> This commit fixes the problem by making OVS ignore received LACP PDUs
> and suppress transmitting LACP PDUs when carrier is down. In addition,
> when a LACP PDU is received with carrier down, this commit triggers
> rechecking the carrier status (by incrementing the connectivity sequence
> number) to ensure that it is updated as quickly as possible.

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

Re: [ovs-dev] [PATCH v7 1/2] Avoid packet drop on LACP bond after link up

[Ben Pfaff]

On Sun, Jun 09, 2019 at 02:17:45PM +, Nitin Katiyar wrote:
> Problem:
> 
> The OVS state machine that enables and disables bond slaves runs in 
> the OVS main thread. The OVS code that processes received LACP packets
> runs in a different thread. Until now, when the latter processes a LACP
> PDU that should enable a slave, the slave was only enabled when the
> main thread was able to run the state machine. In some cases this led
> to delays of up to 350ms when the main thread was busy or not scheduled,
> which led to corresponding delays in which packets were dropped due to
> the bond-admissibility check.

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

Re: [ovs-dev] [dpdk-latest PATCH] netdev-dpdk: Prefix network structures with rte_.

[David Marchand]

On Mon, Jun 10, 2019 at 4:58 PM Ian Stokes  wrote:

> On 6/6/2019 12:36 PM, David Marchand wrote:
> >
> >
> > On Thu, Jun 6, 2019 at 1:25 PM Ian Stokes  > > wrote:
> > I'll be applying this to dpdk-latest and dpdk-hwol branches but not
> ovs
> > master (master is still using DPDK 18.11.1 currently so no need for
> > these changes until it moves to 19.11).
> >
> >
> >
> > Yes, makes sense.
> > Thanks Ian.
>
> Thanks David, validated and pushed to dpdk-latest and dpdk-wol.
>

Thanks Ian.
I noticed that the travis stuff is pointing at 18.11.1.
Is this intended or do we want to point at the master branch?


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

Re: [ovs-dev] [PATCH v2] travis: Test with latest stable kernel releases.

[Ilya Maximets]

On 24.05.2019 19:57, Ben Pfaff wrote:
> On Tue, May 21, 2019 at 03:46:22PM +0300, Ilya Maximets wrote:
>> Instead of managing kernel minor versions manually we could always test
>> with the most recent stable release of the desired branch.
>>
>> With this patch applied Travis will always check with the most recent
>> kernels, so we'll be notified about changes in upstream kernels that
>> breaks the build of our kernel module. However, this will also break
>> Travis checks on patches that doesn't touch the kernel parts until
>> we fix the module.
>>
>> Signed-off-by: Ilya Maximets 
>> Tested-by: Yifeng Sun 
>> Reviewed-by: Yifeng Sun 
>> ---
>>
>> Right now we have a broken build with recent longterm 4.9.177.
>> So, this patch, should not be applied before the build with
>> 4.9.177 fixed: https://patchwork.ozlabs.org/patch/1102480/
>>
>> Version 2:
>>   * Rebased on current master.
>>   * No functional changes so I kept tags from v1.
> 
> Acked-by: Ben Pfaff 
> 
> but I guess you should wait for the broken build to be fixed before
> applying it.


Thanks, Yifeng and Ben!
Since the build with recent 4.9 is fixed, I applied this patch to master.

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

Re: [ovs-dev] [PATCH] rhel: let *-ctl handle runtime directory

[0-day Robot]

Bleep bloop.  Greetings Jaime Caamaño Ruiz, I am a robot and I have tried out 
your patch.
Thanks for your contribution.

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


checkpatch:
WARNING: Line is 85 characters long (recommended limit is 79)
#33 FILE: rhel/usr_lib_systemd_system_ovsdb-server.service:14:
ExecStartPre=-/usr/bin/chown ${OVS_USER_ID} /var/run/openvswitch 
/var/log/openvswitch

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


Please check this out.  If you feel there has been an error, please email 
acon...@bytheb.org

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

Re: [ovs-dev] [PATCH] netdev-tc-offloads: Use correct hook qdisc at init tc flow

[John Hurley]

On Mon, Jun 10, 2019 at 12:58 PM Roi Dayan  wrote:
>
> From: Raed Salem 
>
> A preliminary netdev qdisc cleanup is done during init tc flow.
> The cited commit allows for creating of egress hook qdiscs on internal
> ports. This breaks the netdev qdisc cleanup as currently only ingress
> hook qdiscs type is deleted. As a consequence the check for tc ingress
> shared block support fails when the check is done on internal port.
>
> Issue can be reproduced by the following steps:
> - start openvswitch service
> - create ovs bridge
> - restart openvswitch service
>
> Fix by using the correct hook qdisc type at netdev hook qdisc cleanup.
>

Nice catch here. Thanks.

Acked-by: John Hurley 


> Fixes 608ff46aaf0d ("ovs-tc: offload datapath rules matching on internal 
> ports")
> Signed-off-by: Raed Salem 
> Reviewed-by: Roi Dayan 
> ---
>  lib/netdev-tc-offloads.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/netdev-tc-offloads.c b/lib/netdev-tc-offloads.c
> index ef9ee0786215..97fbe03ed11d 100644
> --- a/lib/netdev-tc-offloads.c
> +++ b/lib/netdev-tc-offloads.c
> @@ -1571,8 +1571,8 @@ netdev_tc_init_flow_api(struct netdev *netdev)
>  return -ifindex;
>  }
>
> -/* make sure there is no ingress qdisc */
> -tc_add_del_qdisc(ifindex, false, 0, TC_INGRESS);
> +/* make sure there is no ingress/egress qdisc */
> +tc_add_del_qdisc(ifindex, false, 0, hook);
>
>  if (ovsthread_once_start(&block_once)) {
>  probe_tc_block_support(ifindex);
> --
> 2.7.5
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Comprensión de las necesidades del cliente

[Atención al cliente de alta calidad]

¡Hola!

Me da mucho gusto saludarte.

Es para mi un placer poder invitarte a nuestro webinar "Atención al cliente de 
alta calidad" que se estará llevando a cabo 
el día jueves 20 de junio con un horario de 10:00 a 17:00 hrs. (hora de la 
ciudad de México)


Con este curso en línea lograremos:

Mejorar la predisposición hacia la calidad en la atención al cliente. 
Fortalecer la comprensión de las necesidades del cliente. 
Mejorar la transmisión de información a los clientes. 
Proporcionar herramientas para la resolución de quejas y conflictos.
El experto que nos acompañará será Josué Lozano, mentor especializado en 
asesorar a directivos de empresas con necesidades 
de implementar estrategias de desarrollo humano - organizacional y comercial. 
El enfoque de sus intervenciones están basadas
en los principios de la empresa altamente productiva y plenamente humana, 
fomentando la implementación de procesos orientados
a la satisfacción del cliente interno y externo.

Te invito a que participes con nosotros y conozcas los beneficios de la 
capacitación en línea.

Tel: (045) 55 15 54 66 30 

Solicita información respondiendo a este correo con la palabra Cliente, junto 
con:

Nombre:
Correo electrónico:
Número telefónico:

¡Qué tengas un excelente día!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [dpdk-latest PATCH] netdev-dpdk: Prefix network structures with rte_.

[Ian Stokes]

On 6/6/2019 12:36 PM, David Marchand wrote:



On Thu, Jun 6, 2019 at 1:25 PM Ian Stokes > wrote:


On 6/4/2019 12:14 PM, David Marchand wrote:
 > On Tue, Jun 4, 2019 at 11:29 AM David Marchand
 > mailto:david.march...@redhat.com>
>> wrote:
 >
 >     Following a rework of dpdk network structures names [1],
update the
 >     concerned parts.
 >
 >     Ran Olivier script:
 >     sh prefix-net-rte.sh $(find -name "*dpdk*.c")
 >     sh prefix-net-rte.sh $(find -name "*dpdk*.h")
 >     sh prefix-net-rte.sh $(find -name "*rte*.c")
 >     sh prefix-net-rte.sh $(find -name "*rte*.h")
 >
 >     Plus an extra pass following further changes [2]:
 >     old=RTE_IPv4
 >     new=RTE_IPV4
 >     git grep -lw $old | xargs sed -i -e "s/\<$old\>/$new/g"
 >
 >     old=RTE_ETHER_TYPE_IPv4
 >     new=RTE_ETHER_TYPE_IPV4
 >     git grep -lw $old | xargs sed -i -e "s/\<$old\>/$new/g"
 >
 >     old=RTE_ETHER_TYPE_IPv6
 >     new=RTE_ETHER_TYPE_IPV6
 >     git grep -lw $old | xargs sed -i -e "s/\<$old\>/$new/g"
 >
 >     1: http://mails.dpdk.org/archives/dev/2019-May/132612.html
 >     2: https://git.dpdk.org/dpdk/commit/?id=0c9da7555da8
 >
 >
 > Olivier noticed that I had used an early version of his patch.
 > The published one handles the update on RTE_IPv4.
 > I tried the last version which gives the same result anyway.
 > So the extra pass is unnecessary.
 >
 > I can send a v2 to update the commitlog accordingly.
 >

Hi David,

thanks for this, upon inspection the patch looks fine and I can confirm
that dpdk-latest is now building with Master of DPDK again.

I'm just in the process of running a few smoke tests to make sure
there's no issues functionally (I don't expect to see any as the
changes
seem straight forward).

WRT the v2, what exactly do you want to change in the commit? If it's
trivial I can amend it before committing.



I just stripped the useless part in the commitlog and put a link to 
Olivier mail which contained his script.

You can see the commitlog here:
https://github.com/david-marchand/ovs/commit/9d367de7d323c28f7c89d590ff60373c47ffa073



I'll be applying this to dpdk-latest and dpdk-hwol branches but not ovs
master (master is still using DPDK 18.11.1 currently so no need for
these changes until it moves to 19.11).



Yes, makes sense.
Thanks Ian.


Thanks David, validated and pushed to dpdk-latest and dpdk-wol.

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

Re: [ovs-dev] [PATCH 1/3] sat-math: Add functions for saturating arithmetic on "long long int".

[Ilya Maximets]

On 02.03.2019 2:54, Ben Pfaff wrote:
> The first users will be added in an upcoming commit.
> 
> Signed-off-by: Ben Pfaff 
> ---
>  lib/automake.mk |  3 ++-
>  lib/sat-math.c  | 31 +++
>  lib/sat-math.h  | 25 ++---
>  3 files changed, 55 insertions(+), 4 deletions(-)
>  create mode 100644 lib/sat-math.c
> 
> diff --git a/lib/automake.mk b/lib/automake.mk
> index bae032bd835e..6df8037a3fd8 100644
> --- a/lib/automake.mk
> +++ b/lib/automake.mk
> @@ -1,4 +1,4 @@
> -# Copyright (C) 2009-2018 Nicira, Inc.
> +# Copyright (C) 2009-2019 Nicira, Inc.
>  #
>  # Copying and distribution of this file, with or without modification,
>  # are permitted in any medium without royalty provided the copyright
> @@ -248,6 +248,7 @@ lib_libopenvswitch_la_SOURCES = \
>   lib/rstp-common.h \
>   lib/rstp-state-machines.c \
>   lib/rstp-state-machines.h \
> + lib/sat-math.c \
>   lib/sat-math.h \
>   lib/seq.c \
>   lib/seq.h \
> diff --git a/lib/sat-math.c b/lib/sat-math.c
> new file mode 100644
> index ..24b73af12eb4
> --- /dev/null
> +++ b/lib/sat-math.c
> @@ -0,0 +1,31 @@
> +/*
> + * Copyright (c) 2019 Nicira, 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.
> + */
> +#include 
> +#include "sat-math.h"
> +
> +/* Returns x * y, clamping out-of-range results into the range of the return
> + * type. */
> +long long int
> +llsat_mul(long long int x, long long int y)
> +{
> +return (  x > 0 && y > 0 && x >  LLONG_MAX / y ? LLONG_MAX
> +: x < 0 && y > 0 && x <= LLONG_MIN / y ? LLONG_MIN
> +: x > 0 && y < 0 && y <= LLONG_MIN / x ? LLONG_MIN
> +/* Special case because -LLONG_MIN / -1 overflows: */
> +: x == LLONG_MIN && y == -1 ? LLONG_MAX
> +: x < 0 && y < 0 && x < LLONG_MIN / y ? LLONG_MAX

Shouldn't there be x < LLONG_MAX / y ?

if (y < 0) --> (LLONG_MIN / y) > 0
--> x always less than (LLONG_MIN / y), because x < 0.


Code become complicated here. Maybe it's time to write some unit tests for
this library?

Have you considered using compiler builtins like __builtin_mul_overflow()
for these functions? Modern clang and gcc supports them.

Best regards, Ilya Maximets.

> +: x * y);
> +}
> diff --git a/lib/sat-math.h b/lib/sat-math.h
> index beeff8b2b429..79757726ead5 100644
> --- a/lib/sat-math.h
> +++ b/lib/sat-math.h
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2008, 2012 Nicira, Inc.
> + * Copyright (c) 2008, 2012, 2019 Nicira, Inc.
>   *
>   * Licensed under the Apache License, Version 2.0 (the "License");
>   * you may not use this file except in compliance with the License.
> @@ -20,24 +20,43 @@
>  #include 
>  #include "openvswitch/util.h"
>  
> -/* Saturating addition: overflow yields UINT_MAX. */
> +/* Returns x + y, clamping out-of-range results into the range of the return
> + * type. */
>  static inline unsigned int
>  sat_add(unsigned int x, unsigned int y)
>  {
>  return x + y >= x ? x + y : UINT_MAX;
>  }
> +static inline long long int
> +llsat_add(long long int x, long long int y)
> +{
> +return (x >= 0 && y >= 0 && x > LLONG_MAX - y ? LLONG_MAX
> +: x < 0 && y < 0 && x < LLONG_MIN - y ? LLONG_MIN
> +: x + y);
> +}
>  
> -/* Saturating subtraction: underflow yields 0. */
> +/* Returns x - y, clamping out-of-range results into the range of the return
> + * type. */
>  static inline unsigned int
>  sat_sub(unsigned int x, unsigned int y)
>  {
>  return x >= y ? x - y : 0;
>  }
> +static inline long long int
> +llsat_sub(long long int x, long long int y)
> +{
> +return (x >= 0 && y < 0 && x > LLONG_MAX + y ? LLONG_MAX
> +: x < 0 && y >= 0 && x < LLONG_MIN + y ? LLONG_MIN
> +: x - y);
> +}
>  
> +/* Returns x * y, clamping out-of-range results into the range of the return
> + * type. */
>  static inline unsigned int
>  sat_mul(unsigned int x, unsigned int y)
>  {
>  return OVS_SAT_MUL(x, y);
>  }
> +long long int llsat_mul(long long int x, long long int y);
>  
>  #endif /* sat-math.h */
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] rhel: useropts should be owned by package

[Jaime Caamaño Ruiz]

So that is properly cleaned up after package is uninstalled.

Signed-off-by: Jaime Caamaño Ruiz 
---
 rhel/openvswitch-fedora.spec.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in
index d41d11cc4..9c752ff4e 100644
--- a/rhel/openvswitch-fedora.spec.in
+++ b/rhel/openvswitch-fedora.spec.in
@@ -553,6 +553,7 @@ fi
 /var/lib/openvswitch
 %attr(750,root,root) /var/log/openvswitch
 %ghost %attr(755,root,root) %{_rundir}/openvswitch
+%ghost %attr(644,root,root) %{_rundir}/openvswitch.useropts
 
 %files ipsec
 %{_datadir}/openvswitch/scripts/ovs-monitor-ipsec
-- 
2.16.4

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

[ovs-dev] [PATCH] rhel: let *-ctl handle runtime directory

[Jaime Caamaño Ruiz]

Recent versions of systemd restores RuntimeDirectory ownership to the
unit's User in between execution of *Exec directives (see [1]). Using
ExecStartPre to reset RuntimeDirectory ownership to OVS_USER no longer
works as expected.

The ctl scripts already handle creation of the runtime directory with
correct ownership and permissions so we can basically remove
RuntimeDirectory from systemd unit file. There is still need to handle
ownsership to cover some upgrade scenarios, but success of that will be
optional as the directory itself wont exist at first time run.

[1] https://github.com/systemd/systemd/issues/12713

Signed-off-by: Jaime Caamaño Ruiz 
---
 rhel/usr_lib_systemd_system_ovsdb-server.service | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/rhel/usr_lib_systemd_system_ovsdb-server.service 
b/rhel/usr_lib_systemd_system_ovsdb-server.service
index 9bb37fd06..a6de4d3c1 100644
--- a/rhel/usr_lib_systemd_system_ovsdb-server.service
+++ b/rhel/usr_lib_systemd_system_ovsdb-server.service
@@ -11,7 +11,7 @@ PIDFile=/var/run/openvswitch/ovsdb-server.pid
 Restart=on-failure
 EnvironmentFile=/etc/openvswitch/default.conf
 EnvironmentFile=-/etc/sysconfig/openvswitch
-ExecStartPre=/usr/bin/chown ${OVS_USER_ID} /var/run/openvswitch 
/var/log/openvswitch
+ExecStartPre=-/usr/bin/chown ${OVS_USER_ID} /var/run/openvswitch 
/var/log/openvswitch
 ExecStartPre=/bin/sh -c 'rm -f /run/openvswitch.useropts; /usr/bin/echo 
"OVS_USER_ID=${OVS_USER_ID}" > /run/openvswitch.useropts'
 ExecStartPre=/bin/sh -c 'if [ "$${OVS_USER_ID/:*/}" != "root" ]; then 
/usr/bin/echo "OVS_USER_OPT=--ovs-user=${OVS_USER_ID}" >> 
/run/openvswitch.useropts; fi'
 EnvironmentFile=/run/openvswitch.useropts
@@ -23,5 +23,3 @@ ExecStop=/usr/share/openvswitch/scripts/ovs-ctl 
--no-ovs-vswitchd stop
 ExecReload=/usr/share/openvswitch/scripts/ovs-ctl --no-ovs-vswitchd \
${OVS_USER_OPT} \
--no-monitor restart $OPTIONS
-RuntimeDirectory=openvswitch
-RuntimeDirectoryMode=0755
-- 
2.16.4

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

[ovs-dev] [PATCH] netdev-tc-offloads: Use correct hook qdisc at init tc flow

[Roi Dayan]

From: Raed Salem 

A preliminary netdev qdisc cleanup is done during init tc flow.
The cited commit allows for creating of egress hook qdiscs on internal
ports. This breaks the netdev qdisc cleanup as currently only ingress
hook qdiscs type is deleted. As a consequence the check for tc ingress
shared block support fails when the check is done on internal port.

Issue can be reproduced by the following steps:
- start openvswitch service
- create ovs bridge
- restart openvswitch service

Fix by using the correct hook qdisc type at netdev hook qdisc cleanup.

Fixes 608ff46aaf0d ("ovs-tc: offload datapath rules matching on internal ports")
Signed-off-by: Raed Salem 
Reviewed-by: Roi Dayan 
---
 lib/netdev-tc-offloads.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/netdev-tc-offloads.c b/lib/netdev-tc-offloads.c
index ef9ee0786215..97fbe03ed11d 100644
--- a/lib/netdev-tc-offloads.c
+++ b/lib/netdev-tc-offloads.c
@@ -1571,8 +1571,8 @@ netdev_tc_init_flow_api(struct netdev *netdev)
 return -ifindex;
 }
 
-/* make sure there is no ingress qdisc */
-tc_add_del_qdisc(ifindex, false, 0, TC_INGRESS);
+/* make sure there is no ingress/egress qdisc */
+tc_add_del_qdisc(ifindex, false, 0, hook);
 
 if (ovsthread_once_start(&block_once)) {
 probe_tc_block_support(ifindex);
-- 
2.7.5

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

Re: [ovs-dev] [PATCH v4 1/4] netdev: Dynamic per-port Flow API.

[Ilya Maximets]

On 10.06.2019 10:02, Roni Bar Yanai wrote:
> Hi Ilya,
> 
> See inline
> 
>> -Original Message-
>> From: Ilya Maximets 
>> Sent: Thursday, June 6, 2019 2:19 PM
>> To: Roni Bar Yanai ; Ophir Munk
>> ; Roi Dayan ; ovs-
>> d...@openvswitch.org
>> Cc: Ian Stokes ; Flavio Leitner ; 
>> Kevin
>> Traynor ; Finn Christensen ; Ben
>> Pfaff ; Simon Horman ; Olga
>> Shern ; Asaf Penso ; Majd Dibbiny
>> ; Oz Shlomo 
>> Subject: Re: [PATCH v4 1/4] netdev: Dynamic per-port Flow API.
>>
>> On 06.06.2019 13:38, Roni Bar Yanai wrote:
>>> Hi Ilya,
>>> was curious myself. Mark & RSS is working  (didn't test with representors 
>>> yet).
>>
>> Hi. Thanks for testing!
>>
>>> I've tested offload is supported on vport using !has_system_port, do you 
>>> think
>> failing in this test is enough to say that this is netdev bridge port?
>>
>> I think it's OK for now. '!has_system_port' allows to say that it's not a
>> system vport and, since 'dummy' flow API doesn't support vports offloading,
>> we could be sure that only dpdk flow API could be used (if allowed).
>>
>>> When I returned supported, "dpdk_put" was called as expected (after removing
>> the disallow).
>>>
>>> One thing I've encounters is while addin a tap to the dpdk bridge. I got 
>>> this:
>>>
>>> 2019-06-06T10:18:21.865Z|00055|netdev_offload_tc|INFO|probe tc: block
>> offload is supported.
>>> 2019-06-06T10:18:21.866Z|00056|netdev_offload_tc|INFO|added ingress qdisc
>> to veth0
>>> 2019-06-06T10:18:21.866Z|00057|netdev_offload|INFO|veth0: Assigned flow
>> API 'linux_tc'.
>>> 2019-06-06T10:18:21.866Z|00058|bridge|INFO|bridge br-int: added interface
>> veth0 on port 1
>>> 2019-06-06T10:18:21.867Z|00059|bridge|INFO|bridge br-phy: added interface
>> br-phy on port 65534
>>>
>>> Seems that we should block this as well.
>>
>> I don't think that we should block this, because we should allow
>> 'linux_tc' offloading for linux interfaces. For example, someone
>> could open two linux ports from the userspace datapath and expect
>> that flows could be offloaded to HW/tc layer. I agree that it will
>> not fully work in case of mixing port types within a single OVS
>> bridge, however this should be a valid case. Packets from linux to
>> DPDK ports and backwards will go through OVS, because such flows
>> could not be offloaded.
>>
>> Curious fact is that working this way (opening physical ports via
>> netdev-linux) could be even faster than using DPDK ports in some
>> cases, because 'linux_tc' supports full HW offloading unlike DPDK.
> 
> Can you explain what exactly are the use cases?
> DPDK supports full offload when using port representors, it is just a matter 
> of integrating it into OVS.

Yeah. I know. I just meant that netdev-rte-offload doesn't support full
offload yet, while linux_tc supports it already. The use-case is the same:
running userspace datapath with port representors, but opening them via
netdev-linux (i.e. usual linux port representors). This should be possible
to do that. Right now there could be no much profit from this setup, but,
after netdev-afxdp integration, it should be possible to use xdp for port
representors. This should give full HW offloading (via linux_tc)  + good
performance for unmatched traffic (via AF_XDP) for OVS. This might be
interesting out-of-the-box solution for users who don't want to use DPDK
for some reasons.

Another use-case for linux_tc offload from the userspace datapath is the
optimization of packet flows between linux interfaces. Some setups like
OpenStack installations has various linux interfaces (tap, veth, eth) for
the management purposes. They handle dhcp, some kind of routing, monitoring
and administration. Using linux_tc offloading we could keep most of this
traffic inside the kernel without need to handle it by the OVS main thread
in userspace.

> 
>>
>> We'll also have AF_XDP support some time soon which will give even
>> more benefits to linux interfaces (XDP bypasses tc layer, however
>> it might be possible to install flows to HW and handle unmatched
>> packets in userspace).
>>
>> Best regards, Ilya Maximets.
>>
>>>
>>> BR,
>>> Roni
>>>
 -Original Message-
 From: Ilya Maximets 
 Sent: Monday, June 3, 2019 6:30 PM
 To: Ophir Munk ; Roi Dayan ;
 ovs-dev@openvswitch.org
 Cc: Ian Stokes ; Flavio Leitner ;
>> Kevin
 Traynor ; Roni Bar Yanai ;
>> Finn
 Christensen ; Ben Pfaff ; Simon Horman
 ; Olga Shern ; Asaf
 Penso ; Majd Dibbiny ; Oz
>> Shlomo
 
 Subject: Re: [PATCH v4 1/4] netdev: Dynamic per-port Flow API.

 Hi Ophir.
 I'm curious, what is the current status of your testing?

 I'd like to apply this series to not block further development.

 Best regards, Ilya Maximets.

 On 23.05.2019 16:54, Ilya Maximets wrote:
> On 23.05.2019 16:53, Ilya Maximets wrote:
>> On 23.05.2019 16:18, Ophir Munk wrote:
>>>
>>>
 -Original Message-
 From: Ilya Maximets 
 Sent: Wednesday, May 22, 

Re: [ovs-dev] [PATCH v4 1/4] netdev: Dynamic per-port Flow API.

[Roni Bar Yanai]

Hi Ilya,

See inline

>-Original Message-
>From: Ilya Maximets 
>Sent: Thursday, June 6, 2019 2:19 PM
>To: Roni Bar Yanai ; Ophir Munk
>; Roi Dayan ; ovs-
>d...@openvswitch.org
>Cc: Ian Stokes ; Flavio Leitner ; 
>Kevin
>Traynor ; Finn Christensen ; Ben
>Pfaff ; Simon Horman ; Olga
>Shern ; Asaf Penso ; Majd Dibbiny
>; Oz Shlomo 
>Subject: Re: [PATCH v4 1/4] netdev: Dynamic per-port Flow API.
>
>On 06.06.2019 13:38, Roni Bar Yanai wrote:
>> Hi Ilya,
>> was curious myself. Mark & RSS is working  (didn't test with representors 
>> yet).
>
>Hi. Thanks for testing!
>
>> I've tested offload is supported on vport using !has_system_port, do you 
>> think
>failing in this test is enough to say that this is netdev bridge port?
>
>I think it's OK for now. '!has_system_port' allows to say that it's not a
>system vport and, since 'dummy' flow API doesn't support vports offloading,
>we could be sure that only dpdk flow API could be used (if allowed).
>
>> When I returned supported, "dpdk_put" was called as expected (after removing
>the disallow).
>>
>> One thing I've encounters is while addin a tap to the dpdk bridge. I got 
>> this:
>>
>> 2019-06-06T10:18:21.865Z|00055|netdev_offload_tc|INFO|probe tc: block
>offload is supported.
>> 2019-06-06T10:18:21.866Z|00056|netdev_offload_tc|INFO|added ingress qdisc
>to veth0
>> 2019-06-06T10:18:21.866Z|00057|netdev_offload|INFO|veth0: Assigned flow
>API 'linux_tc'.
>> 2019-06-06T10:18:21.866Z|00058|bridge|INFO|bridge br-int: added interface
>veth0 on port 1
>> 2019-06-06T10:18:21.867Z|00059|bridge|INFO|bridge br-phy: added interface
>br-phy on port 65534
>>
>> Seems that we should block this as well.
>
>I don't think that we should block this, because we should allow
>'linux_tc' offloading for linux interfaces. For example, someone
>could open two linux ports from the userspace datapath and expect
>that flows could be offloaded to HW/tc layer. I agree that it will
>not fully work in case of mixing port types within a single OVS
>bridge, however this should be a valid case. Packets from linux to
>DPDK ports and backwards will go through OVS, because such flows
>could not be offloaded.
>
>Curious fact is that working this way (opening physical ports via
>netdev-linux) could be even faster than using DPDK ports in some
>cases, because 'linux_tc' supports full HW offloading unlike DPDK.

Can you explain what exactly are the use cases?
DPDK supports full offload when using port representors, it is just a matter of 
integrating it into OVS.

>
>We'll also have AF_XDP support some time soon which will give even
>more benefits to linux interfaces (XDP bypasses tc layer, however
>it might be possible to install flows to HW and handle unmatched
>packets in userspace).
>
>Best regards, Ilya Maximets.
>
>>
>> BR,
>> Roni
>>
>>> -Original Message-
>>> From: Ilya Maximets 
>>> Sent: Monday, June 3, 2019 6:30 PM
>>> To: Ophir Munk ; Roi Dayan ;
>>> ovs-dev@openvswitch.org
>>> Cc: Ian Stokes ; Flavio Leitner ;
>Kevin
>>> Traynor ; Roni Bar Yanai ;
>Finn
>>> Christensen ; Ben Pfaff ; Simon Horman
>>> ; Olga Shern ; Asaf
>>> Penso ; Majd Dibbiny ; Oz
>Shlomo
>>> 
>>> Subject: Re: [PATCH v4 1/4] netdev: Dynamic per-port Flow API.
>>>
>>> Hi Ophir.
>>> I'm curious, what is the current status of your testing?
>>>
>>> I'd like to apply this series to not block further development.
>>>
>>> Best regards, Ilya Maximets.
>>>
>>> On 23.05.2019 16:54, Ilya Maximets wrote:
 On 23.05.2019 16:53, Ilya Maximets wrote:
> On 23.05.2019 16:18, Ophir Munk wrote:
>>
>>
>>> -Original Message-
>>> From: Ilya Maximets 
>>> Sent: Wednesday, May 22, 2019 2:50 PM
>>> To: Ophir Munk ; Roi Dayan
>>> ; ovs-dev@openvswitch.org
>>> Cc: Ian Stokes ; Flavio Leitner 
>>> ;
>>> Kevin Traynor ; Roni Bar Yanai
>>> ; Finn Christensen ; Ben
>Pfaff
>>> ; Simon Horman ; Olga
>>> Shern ; Asaf Penso ; Majd
>>> Dibbiny 
>>> Subject: Re: [PATCH v4 1/4] netdev: Dynamic per-port Flow API.
>>>
>>>
>>>
>>> On 22.05.2019 13:15, Ilya Maximets wrote:
 On 22.05.2019 1:12, Ophir Munk wrote:
>
>> -Original Message-
>> From: Roi Dayan
>> Sent: Tuesday, May 21, 2019 7:48 PM
>> To: Ilya Maximets ; ovs-
>>> d...@openvswitch.org
>> Cc: Ian Stokes ; Flavio Leitner
>> ; Ophir Munk ; Kevin
>>> Traynor
>> ; Roni Bar Yanai ;
>Finn
>> Christensen ; Ben Pfaff ; Simon
>>> Horman
>> 
>> Subject: Re: [PATCH v4 1/4] netdev: Dynamic per-port Flow API.
>>
>>
>> Acked-by: Roi Dayan 
>
> Hi Ilya,
> Can you please send a patch for the detection of netdev vport on top
>of
>>> this series (as you have already started suggesting in ML discussions)?
> I will then test it and will make sure it's applicable with this 
> series. I
>think it
>>> is better to do that before series accept