Re: [ovs-dev] [PATCH] vxlan: Fix for the packet loop issue in vxlan
Hi Pravin,
I have seen the below crash.
[] show_stack+0x6c/0xf8
[] do_raw_spin_lock+0x168/0x170
[] dev_queue_xmit+0x43c/0x470
[] ip_finish_output+0x250/0x490
[] rpl_iptunnel_xmit+0x134/0x218 [openvswitch]
[] rpl_vxlan_xmit+0x430/0x538 [openvswitch]
[] do_execute_actions+0x18f8/0x19e8 [openvswitch]
[] ovs_execute_actions+0x90/0x208 [openvswitch]
[] ovs_dp_process_packet+0xb0/0x1a8 [openvswitch]
[] ovs_vport_receive+0x78/0x130 [openvswitch]
[] internal_dev_xmit+0x34/0x98 [openvswitch]
[] dev_hard_start_xmit+0x2e8/0x4f8
[] sch_direct_xmit+0xf0/0x238
[] dev_queue_xmit+0x1d8/0x470
[] arp_process+0x614/0x628
[] __netif_receive_skb_core+0x2e8/0x5d8
[] process_backlog+0xc0/0x1b0
[] net_rx_action+0x154/0x240
[] __do_softirq+0x1d0/0x218
[] do_softirq+0x68/0x70
[] local_bh_enable+0xa8/0xb0
[] netif_rx_ni+0x20/0x30
I have spent some time in investigation and found that crash is because of
spinlock recursion in dev_queue_xmit function.
The packet path traced is : netif_rx->arp->dev_queue_xmit(internal
port)->vxlan_xmit->dev_queue_xmit(internal port).
The macro (XMIT_RECURSION_LIMIT) is defined as 10. This limit wont prevent
the crash since the recursion is 2 only for my configuration.
On Wed, Jun 13, 2018 at 4:11 AM, Pravin Shelar wrote:
> On Tue, Jun 12, 2018 at 10:11 AM, Neelakantam Gaddam
> wrote:
> >
> > Hi Pravin,
> >
> > The below configuration is causing the spinlock recursion issue.
> >
> > I am able to see the issue with below configuration.
> >
> >
> >
> > ovs-vsctl add-br br0
> >
> > ovs-vsctl add-bond br0 bond0 p1p1 p1p2
> >
> > ovs-vsctl set port bond0 lacp=active bond_mode=balance-tcp
> >
> > ifconfig br0 100.0.0.1 up
> >
> > ovs-vsctl add-port br0 veth0
> >
> > ovs-vsctl add-port br0 vx0 -- set interface vx0 type=vxlan
> options:local_ip=100.0.0.1 options:remote_ip=100.0.0.2 option:key=flow
> >
> >
> >
> > ovs-ofctl add-flow br0 "table=0, priority=1, cookie=100, tun_id=100,
> in_port=4, action=output:3"
> >
> > ovs-ofctl add-flow br0 "table=0, priority=1, cookie=100, in_port=3,
> actions=set_field:100->tun_id output:4"
> >
> >
> >
> > The same bridge br0 is being used as the local interface for vxlan
> tunnel. Even though this configuration is invalid, we should not see the
> kernel crash.
> >
>
> I agree this should not cause crash.
> Can you post the crash or investigate why it is crashing I think such
> configuration would hit the networking stack recursion limit
> (XMIT_RECURSION_LIMIT) and then the packet would be dropped. I am not
> sure which spinlock recursion issue you are referring to.
>
>
> >
> >
> >
> >
> > On Tue, Jun 12, 2018 at 11:55 AM, Pravin Shelar wrote:
> >>
> >>
> >>
> >> On Tue, May 22, 2018 at 10:16 PM, Neelakantam Gaddam <
> neelugad...@gmail.com> wrote:
> >>>
> >>> This patch fixes the kernel soft lockup issue with vxlan configuration
> >>> where the tunneled packet is sent on the same bridge where vxlan port
> is
> >>> attched to. It detects the loop in vxlan xmit functionb and drops if
> loop is
> >>> detected.
> >>>
> >>> Signed-off-by: Neelakantam Gaddam
> >>> ---
> >>> datapath/linux/compat/vxlan.c | 6 --
> >>> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/datapath/linux/compat/vxlan.c
> b/datapath/linux/compat/vxlan.c
> >>> index 287dad2..00562fa 100644
> >>> --- a/datapath/linux/compat/vxlan.c
> >>> +++ b/datapath/linux/compat/vxlan.c
> >>> @@ -1115,7 +1115,8 @@ static void vxlan_xmit_one(struct sk_buff *skb,
> struct net_device *dev,
> >>> goto tx_error;
> >>> }
> >>>
> >>> - if (rt->dst.dev == dev) {
> >>> + if ((rt->dst.dev == dev) ||
> >>> + (OVS_CB(skb)->input_vport->dev ==
> rt->dst.dev)) {
> >>
> >>
> >> I am not sure which case the OVS_CB(skb)->input_vport->dev is not same
> as the dev when there is recursion. Can you explain how to reproduce it?
> >>
> >
> >
> >
> > --
> > Thanks & Regards
> > Neelakantam Gaddam
>
--
Thanks & Regards
Neelakantam Gaddam
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Implicaciones fiscales, laborales y de seguridad social
Webinar Interactivo 26 de Junio "Normas del sat para el outsourcing" ¿Qué veré en este webinar? Nos ofrece la oportunidad de optimizar recursos y utilizar sólo lo necesario cuando enfrentamos una situación específica; sin embargo al momento de llevar a cabo nuestras obligaciones fiscales estas pueden resultar un poco confusas. ¿Cuáles son los temas que voy a ver en este webinar? Se verán temas introductorios como: “Un Contexto sobre la figura del “Outsourcing” y su problemática fiscal”. Y otros que nos ayudan a definir y comprender las situaciones que involucran esta figura en la empresa: “Definiendo los aspectos y especificaciones de la Subcontratación de personal” o “Outsourcing, Intermediación laboral ¿Dónde termina uno y comienza el otro?”. Temario e Inscripciones: Respondiendo por este medio con la frase: "Outsourcing"+ Nombre + Teléfono + Empresa o marcando al: 045 + 5515546630 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] vxlan: Fix for the packet loop issue in vxlan
On Tue, Jun 12, 2018 at 10:11 AM, Neelakantam Gaddam
wrote:
>
> Hi Pravin,
>
> The below configuration is causing the spinlock recursion issue.
>
> I am able to see the issue with below configuration.
>
>
>
> ovs-vsctl add-br br0
>
> ovs-vsctl add-bond br0 bond0 p1p1 p1p2
>
> ovs-vsctl set port bond0 lacp=active bond_mode=balance-tcp
>
> ifconfig br0 100.0.0.1 up
>
> ovs-vsctl add-port br0 veth0
>
> ovs-vsctl add-port br0 vx0 -- set interface vx0 type=vxlan
> options:local_ip=100.0.0.1 options:remote_ip=100.0.0.2 option:key=flow
>
>
>
> ovs-ofctl add-flow br0 "table=0, priority=1, cookie=100, tun_id=100,
> in_port=4, action=output:3"
>
> ovs-ofctl add-flow br0 "table=0, priority=1, cookie=100, in_port=3,
> actions=set_field:100->tun_id output:4"
>
>
>
> The same bridge br0 is being used as the local interface for vxlan tunnel.
> Even though this configuration is invalid, we should not see the kernel crash.
>
I agree this should not cause crash.
Can you post the crash or investigate why it is crashing I think such
configuration would hit the networking stack recursion limit
(XMIT_RECURSION_LIMIT) and then the packet would be dropped. I am not
sure which spinlock recursion issue you are referring to.
>
>
>
>
> On Tue, Jun 12, 2018 at 11:55 AM, Pravin Shelar wrote:
>>
>>
>>
>> On Tue, May 22, 2018 at 10:16 PM, Neelakantam Gaddam
>> wrote:
>>>
>>> This patch fixes the kernel soft lockup issue with vxlan configuration
>>> where the tunneled packet is sent on the same bridge where vxlan port is
>>> attched to. It detects the loop in vxlan xmit functionb and drops if loop is
>>> detected.
>>>
>>> Signed-off-by: Neelakantam Gaddam
>>> ---
>>> datapath/linux/compat/vxlan.c | 6 --
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/datapath/linux/compat/vxlan.c b/datapath/linux/compat/vxlan.c
>>> index 287dad2..00562fa 100644
>>> --- a/datapath/linux/compat/vxlan.c
>>> +++ b/datapath/linux/compat/vxlan.c
>>> @@ -1115,7 +1115,8 @@ static void vxlan_xmit_one(struct sk_buff *skb,
>>> struct net_device *dev,
>>> goto tx_error;
>>> }
>>>
>>> - if (rt->dst.dev == dev) {
>>> + if ((rt->dst.dev == dev) ||
>>> + (OVS_CB(skb)->input_vport->dev == rt->dst.dev)) {
>>
>>
>> I am not sure which case the OVS_CB(skb)->input_vport->dev is not same as
>> the dev when there is recursion. Can you explain how to reproduce it?
>>
>
>
>
> --
> Thanks & Regards
> Neelakantam Gaddam
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 3/3] datapath: compat: Fix RHEL 7.5 build warning from ip_tunnel_get_stats64()
On 6/11/2018 5:50 PM, Yi-Hung Wei wrote:
This patch fixes warning as the following in RHEL 7.5 kernel.
CC [M] /root/git/ovs/datapath/linux/geneve.o
/root/git/ovs/datapath/linux/geneve.c:1273:2: warning: initialization
from incompatible pointer type [enabled by default]
.ndo_get_stats64 = ip_tunnel_get_stats64,
^
/root/git/ovs/datapath/linux/geneve.c:1273:2: warning: (near
initialization for ‘geneve_netdev_ops..ndo_get_stats64’)
[enabled by default]
/root/git/ovs/datapath/linux/ip_gre.c:1162:2: warning: initialization
from incompatible pointer type [enabled by default]
.ndo_get_stats64 = ip_tunnel_get_stats64,
^
/root/git/ovs/datapath/linux/ip_gre.c:1162:2: warning: (near
initialization for ‘ipgre_netdev_ops..ndo_get_stats64’)
[enabled by default]
/root/git/ovs/datapath/linux/ip_gre.c:1180:2: warning: initialization
from incompatible pointer type [enabled by default]
.ndo_get_stats64 = ip_tunnel_get_stats64,
^
Fixes: 436d36db ("compat: Fixups for newer kernels")
Signed-off-by: Yi-Hung Wei
---
datapath/linux/compat/include/net/ip_tunnels.h | 2 +-
datapath/linux/compat/ip_tunnels_core.c| 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/datapath/linux/compat/include/net/ip_tunnels.h
b/datapath/linux/compat/include/net/ip_tunnels.h
index b1c383dc8036..d187a12d29ae 100644
--- a/datapath/linux/compat/include/net/ip_tunnels.h
+++ b/datapath/linux/compat/include/net/ip_tunnels.h
@@ -364,7 +364,7 @@ static inline int ovs_ip_tunnel_encap(struct sk_buff *skb,
struct ip_tunnel *t,
}
#define ip_tunnel_get_stats64 rpl_ip_tunnel_get_stats64
-#if LINUX_VERSION_CODE < KERNEL_VERSION(4,11,0)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,11,0) && !defined(HAVE_RHEL7_MAX_MTU)
struct rtnl_link_stats64 *rpl_ip_tunnel_get_stats64(struct net_device *dev,
struct rtnl_link_stats64
*tot);
#else
diff --git a/datapath/linux/compat/ip_tunnels_core.c
b/datapath/linux/compat/ip_tunnels_core.c
index fcb08905ef2f..38fb801e9411 100644
--- a/datapath/linux/compat/ip_tunnels_core.c
+++ b/datapath/linux/compat/ip_tunnels_core.c
@@ -274,7 +274,7 @@ static void netdev_stats_to_stats64(struct
rtnl_link_stats64 *stats64,
}
#endif
-#if LINUX_VERSION_CODE < KERNEL_VERSION(4,11,0)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,11,0) && !defined(HAVE_RHEL7_MAX_MTU)
struct rtnl_link_stats64 *rpl_ip_tunnel_get_stats64(struct net_device *dev,
struct rtnl_link_stats64 *tot)
#else
@@ -306,7 +306,7 @@ void rpl_ip_tunnel_get_stats64(struct net_device *dev,
tot->tx_bytes += tx_bytes;
}
-#if LINUX_VERSION_CODE < KERNEL_VERSION(4,11,0)
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,11,0) && !defined(HAVE_RHEL7_MAX_MTU)
return tot;
#endif
}
Also looks good.
Reviewed-by: Greg Rose
Tested-by: Greg Rose
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 2/3] datapath: Fix ip6_gre, ip6_tunnel, and ip_gre backport
On 6/11/2018 5:50 PM, Yi-Hung Wei wrote:
Recently added ERSAPN feature introduced changes in ip6_gre, ip6_tunnel,
and ip_gre which will break build on RHEL 7.5 kernel because of
ndo_change_mtu(). This patch fixes the issue in RHEL 7.5 kernel.
Fixes: 8e53509c ("gre: introduce native tunnel support for ERSPAN")
Fixes: c387d817 ("compat: Add ipv6 GRE and IPV6 Tunneling")
Signed-off-by: Yi-Hung Wei
---
datapath/linux/compat/ip6_gre.c| 15 +++
datapath/linux/compat/ip6_tunnel.c | 5 +
datapath/linux/compat/ip_gre.c | 10 ++
3 files changed, 30 insertions(+)
diff --git a/datapath/linux/compat/ip6_gre.c b/datapath/linux/compat/ip6_gre.c
index dd22240fc962..0c885472df5b 100644
--- a/datapath/linux/compat/ip6_gre.c
+++ b/datapath/linux/compat/ip6_gre.c
@@ -1525,7 +1525,12 @@ static const struct net_device_ops ip6gre_netdev_ops = {
.ndo_uninit = ip6gre_tunnel_uninit,
.ndo_start_xmit = ip6gre_tunnel_xmit,
.ndo_do_ioctl = ip6gre_tunnel_ioctl,
+#ifdef HAVE_RHEL7_MAX_MTU
+ .ndo_size = sizeof(struct net_device_ops),
+ .extended.ndo_change_mtu = ip6_tnl_change_mtu,
+#else
.ndo_change_mtu = ip6_tnl_change_mtu,
+#endif
.ndo_get_stats64= ip_tunnel_get_stats64,
#ifdef HAVE_NDO_GET_IFLINK
.ndo_get_iflink = ip6_tnl_get_iflink,
@@ -2010,7 +2015,12 @@ static const struct net_device_ops ip6gre_tap_netdev_ops
= {
.ndo_start_xmit = ip6gre_tunnel_xmit,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
+#ifdef HAVE_RHEL7_MAX_MTU
+ .ndo_size = sizeof(struct net_device_ops),
+ .extended.ndo_change_mtu = ip6_tnl_change_mtu,
+#else
.ndo_change_mtu = ip6_tnl_change_mtu,
+#endif
.ndo_get_stats64 = ip_tunnel_get_stats64,
#ifdef HAVE_NDO_GET_IFLINK
.ndo_get_iflink = ip6_tnl_get_iflink,
@@ -2073,7 +2083,12 @@ static const struct net_device_ops ip6erspan_netdev_ops
= {
.ndo_start_xmit = ip6erspan_tunnel_xmit,
.ndo_set_mac_address = eth_mac_addr,
.ndo_validate_addr =eth_validate_addr,
+#ifdef HAVE_RHEL7_MAX_MTU
+ .ndo_size = sizeof(struct net_device_ops),
+ .extended.ndo_change_mtu = ip6_tnl_change_mtu,
+#else
.ndo_change_mtu = ip6_tnl_change_mtu,
+#endif
.ndo_get_stats64 = ip_tunnel_get_stats64,
#ifdef HAVE_NDO_GET_IFLINK
.ndo_get_iflink = ip6_tnl_get_iflink,
diff --git a/datapath/linux/compat/ip6_tunnel.c
b/datapath/linux/compat/ip6_tunnel.c
index f6ac069b5281..7c66787967f6 100644
--- a/datapath/linux/compat/ip6_tunnel.c
+++ b/datapath/linux/compat/ip6_tunnel.c
@@ -1612,7 +1612,12 @@ static const struct net_device_ops ip6_tnl_netdev_ops = {
.ndo_uninit = ip6_tnl_dev_uninit,
.ndo_start_xmit = ip6_tnl_start_xmit,
.ndo_do_ioctl = ip6_tnl_ioctl,
+#ifdef HAVE_RHEL7_MAX_MTU
+ .ndo_size = sizeof(struct net_device_ops),
+ .extended.ndo_change_mtu = ip6_tnl_change_mtu,
+#else
.ndo_change_mtu = ip6_tnl_change_mtu,
+#endif
.ndo_get_stats = ip6_get_stats,
#ifdef HAVE_NDO_GET_IFLINK
.ndo_get_iflink = ip6_tnl_get_iflink,
diff --git a/datapath/linux/compat/ip_gre.c b/datapath/linux/compat/ip_gre.c
index d35614ee9a73..ac9fb8bfcc88 100644
--- a/datapath/linux/compat/ip_gre.c
+++ b/datapath/linux/compat/ip_gre.c
@@ -1153,7 +1153,12 @@ static const struct net_device_ops ipgre_netdev_ops = {
.ndo_init = ipgre_tunnel_init,
.ndo_uninit = rpl_ip_tunnel_uninit,
.ndo_start_xmit = ipgre_xmit,
+#ifdef HAVE_RHEL7_MAX_MTU
+ .ndo_size = sizeof(struct net_device_ops),
+ .extended.ndo_change_mtu = ip_tunnel_change_mtu,
+#else
.ndo_change_mtu = ip_tunnel_change_mtu,
+#endif
.ndo_get_stats64= ip_tunnel_get_stats64,
#ifdef HAVE_GET_LINK_NET
.ndo_get_iflink = ip_tunnel_get_iflink,
@@ -1187,7 +1192,12 @@ static const struct net_device_ops erspan_netdev_ops = {
.ndo_start_xmit = erspan_xmit,
.ndo_set_mac_address= eth_mac_addr,
.ndo_validate_addr = eth_validate_addr,
+#ifdef HAVE_RHEL7_MAX_MTU
+ .ndo_size = sizeof(struct net_device_ops),
+ .extended.ndo_change_mtu = ip_tunnel_change_mtu,
+#else
.ndo_change_mtu = ip_tunnel_change_mtu,
+#endif
.ndo_get_stats64= ip_tunnel_get_stats64,
#ifdef HAVE_NDO_GET_IFLINK
.ndo_get_iflink = rpl_ip_tunnel_get_iflink,
LGTM
Reviewed-by: Greg Rose
Tested-by: Greg Rose
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/3] datapath: Fix max MTU size on RHEL 7.5 kernel
On 6/11/2018 5:50 PM, Yi-Hung Wei wrote:
Without the patch, in RHEL 7.5, the maximum configurable MTU of vport
internal device is 1500, which shall be 65535. This patch fixes this
issue.
Fixes: 39ca338374ab ("datapath: compat: Fix build on RHEL 7.5")
Reported-by: Lucas Alvares Gomes
Signed-off-by: Yi-Hung Wei
---
datapath/vport-internal_dev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/datapath/vport-internal_dev.c b/datapath/vport-internal_dev.c
index 3cb8d06b2475..3fa86815c7fa 100644
--- a/datapath/vport-internal_dev.c
+++ b/datapath/vport-internal_dev.c
@@ -169,6 +169,8 @@ static void do_setup(struct net_device *netdev)
#ifdef HAVE_NET_DEVICE_WITH_MAX_MTU
netdev->max_mtu = ETH_MAX_MTU;
+#elif HAVE_RHEL7_MAX_MTU
+ netdev->extended->max_mtu = ETH_MAX_MTU;
#endif
netdev->netdev_ops = _dev_netdev_ops;
Works as advertised.
Reviewed-by: Greg Rose
Tested-by: Greg Rose
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Cómo medir el desempeño corporativo
Aplicación e Implementación BALANCED SCORECARD Fecha: 21/Junio/2018 Horario: 10:00 a 13:00 y 15:00 a 18:00 horas "El BSC es un poderoso instrumento para medir el desempeño corporativo y se ha demostrado que es la herramienta más efectiva para enlazar la visión, misión y la estrategia a cinco medidas de desempeño. " Los participantes conocerán las claves del éxito de las organizaciones japonesas: Objetivos empresariales y planeación estratégica. Medidores de desempeño para cada objetivo. Sistema gráfico de información gerencial. Además permite ofrecer una visión completa de la organización, siendo el elemento esencial del sistema de información que sirve de apoyo al sistema de control de gestión en su misión de mejorar su nivel de competitividad en el largo plazo. Responda este correo con el asunto Balanced, con los siguientes datos: Nombre: Correo: Teléfono: Si lo que usted desea dejar de recibir este tipo de mensajes responder este correo con el asunto BAJA ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Issue with OVS 2.9.0, DPDK 18.02 and vhost-user
On Tue, Jun 12, 2018 at 3:31 AM, Stokes, Ian wrote: > > Hi, > > > > I have used first link to install, compile and run OVS 2.9.0 and DPDK > > 18.02, second link to configure vhost-client ports. However, facing > > several issues when configured as per the documentation. Inputs > > appreciated. > > > > http://docs.openvswitch.org/en/latest/intro/install/dpdk/ > > > > http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/ > > > > Is there a specific reason you require DPDK 18.02? > > DPDK 17.11 is the latest officially support DPDK for OVS, I'd recommend > testing with this as I'm not sure how well validated DPDK 18.02 is. > > In testing I also found that OVS will fail to compile with 18.02 due to > 'rte_eth_find_next_owned_by' not being part of the stable ABI. > > The list of supported DPDK to OVS mappings can be found in the release doc > below. > > http://docs.openvswitch.org/en/latest/faq/releases/ Thanks Ian. I am currently using OVS 2.9 and DPDK 18.02 seperately for different things, hence thought of trying with that first. I was able to compile and run as shown in the logs. Issue was I didn't specify 'datapath_type=netdev' when adding the bridge. Deleting and adding the bridge with 'datapath_type', I was able to add dpdkvhostclient ports on the bridge. Having said that, I decided to try 'ovs-master' + dpdk-17.11 as mentioned in the link and was able to run everything with Tx/Rx packets. Some clarifications I need. My testbed has physical host + containers. (1) tried with dpdkvhostuser (server port on OVS on host) and virtio-user-client (testpmd/dpdk on containers). Was able to configure and run traffic. I do see following messages in log file 2018-06-12T15:51:39.152Z|00080|netdev_dpdk|WARN|dpdkvhostuser ports are considered deprecated; please migrate to dpdkvhostuserclient ports. Any reason why dpdkvhostuser is not recommended or being deprecated? (2) tried with dpdkvhostuserclient (client port OVS on host) and virtio-user-server (testpmd/dpdk on containers). Was unable to configure. Any examples available for this? Thanks. > > > Following logs from /usr/local/var/log/openvswitch/ovs-vswitchd.log > shows > > OVS/DPDK initialized correctly. > > > > 2018-06-11T21:15:06.028Z|1|vlog|INFO|opened log file > > /usr/local/var/log/openvswitch/ovs-vswitchd.log > > 2018-06-11T21:15:06.032Z|2|ovs_numa|INFO|Discovered 4 CPU cores on > > NUMA node 0 2018-06-11T21:15:06.032Z|3|ovs_numa|INFO|Discovered 1 > NUMA > > nodes and 4 CPU cores > > 2018-06- > > 11T21:15:06.032Z|4|reconnect|INFO|unix:/usr/ > local/var/run/openvswitch/ > > db.sock: > > connecting... > > 2018-06- > > 11T21:15:06.032Z|5|reconnect|INFO|unix:/usr/ > local/var/run/openvswitch/ > > db.sock: > > connected > > 2018-06-11T21:15:06.033Z|6|dpdk|INFO|Using DPDK 18.02.0 2018-06- > > 11T21:15:06.033Z|7|dpdk|INFO|DPDK Enabled - initializing... > > 2018-06-11T21:15:06.033Z|8|dpdk|INFO|No vhost-sock-dir provided - > > defaulting to /usr/local/var/run/openvswitch 2018-06- > > 11T21:15:06.033Z|9|dpdk|INFO|IOMMU support for vhost-user-client > > disabled. > > 2018-06-11T21:15:06.033Z|00010|dpdk|INFO|EAL ARGS: ovs-vswitchd > --huge-dir > > /dev/hugepages_1G --socket-mem 2,0 --no-pci --file-prefix=host -c > > 0x0001 > > 2018-06-11T21:15:06.034Z|00011|dpdk|INFO|EAL: Detected 4 lcore(s) > > 2018-06-11T21:15:06.034Z|00012|dpdk|INFO|EAL: 2048 hugepages of size > > 2097152 reserved, but no mounted hugetlbfs found for that size > > 2018-06-11T21:15:06.035Z|00013|dpdk|INFO|EAL: Multi-process socket > > /var/run/.host_unix > > 2018-06-11T21:15:06.036Z|00014|dpdk|INFO|EAL: Probing VFIO support... > > 2018-06-11T21:15:06.036Z|00015|dpdk|INFO|EAL: VFIO support initialized > > 2018-06-11T21:15:06.902Z|00016|dpdk|WARN|EAL: WARNING: cpu flags > > constant_tsc=yes nonstop_tsc=no -> using unreliable clock cycles ! > > 2018-06-11T21:15:06.906Z|00017|dpdk|INFO|DPDK Enabled - initialized > 2018- > > 06-11T21:15:06.906Z|00018|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.9.0 > > > > root# ovs-vswitchd --version > > ovs-vswitchd (Open vSwitch) 2.9.0 > > DPDK 18.02.0 > > > > root# ovs-vsctl get Open_vSwitch . dpdk_version > > ovs-vsctl: Open_vSwitch does not contain a column whose name matches > > "dpdk_version" > > root# ovs-vsctl get Open_vSwitch . dpdk_initialized > > ovs-vsctl: Open_vSwitch does not contain a column whose name matches > > "dpdk_initialized" > > The functionality above is only available on OVS master, it will be part > of OVS 2.10 but is not part of OVS 2.9. > > > > > Creating dpdkvhostclient port spits out following error message > > > > ovs-vsctl add-port br0 dpdkvhostclient0 -- set Interface dpdkvhostclient0 > > type=dpdkvhostuserclient options:vhost-server-path=/tmp/dpdkvhostclient0 > > The command above looks ok. > > > ovs-vsctl: Error detected while setting up 'dpdkvhostclient0': could not > > add network device dpdkvhostclient0 to ofproto (Invalid argument). See > > ovs-vswitchd log for details. > >
Re: [ovs-dev] OVS DPDK: dpdk_merge pull request for master
Thanks for the pull requests. I merged all of these (master, 2.9, and 2.8). ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] rhel: Add python-netifaces as a dependency for openvswitch-test
Timothy Redaelli writes:
> Currently python-netifaces is needed for ovs-tcpdump that is installed
> by openvswitch-test package.
>
> This commit adds {python,python2}-netifaces as a dependency for the
> openvswitch-test package.
>
> Signed-off-by: Timothy Redaelli
> ---
Acked-by: Aaron Conole
This should remove a step from the installation procedure. Thanks,
Timothy!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4] Upcall/Slowpath rate-limiter for OVS
Jan Scheurich writes: >> Have you considered making this token bucket per-port instead of >> per-pmd? As I read it, a greedy port can exhaust all the tokens from a >> particular PMD, possibly leading to an unfair performance for that PMD >> thread. Am I just being overly paranoid? >> [manu] Yes, this is possible. But it can happen for both fast and >> slowpath today, as PMDs sequentially iterate through ports. In order >> to keep it simple, its done per-PMD. It can be extended to per-port if >> needed. > > The purpose of the upcall rate limiter for the netdev datapath is to > protect a PMD from becoming clogged down by having to process an > excessive number of upcalls. It is not to police the number of upcalls > per port to some rate, especially not across multiple PMDs (in the > case of RSS). Okay. I guess you would first create this to police the global upcall pool, and then if you need a future policing per-port, you would add that (something like you indicate at the end of this mail)? > I think what you are after, Aaron, is some kind of fairness scheme > that provides each rx queue with a minimum rate of upcalls even if the > global PMD rate limit is reached? I don't believe simply partitioning > the global PMD rate limit into a number of smaller rx queue buckets > would be a good solution. But I don't have a better alternative > either. Yes, that's what I'm thinking about. I'm concerned about the scalability from the kernel side for the number of upcall fds required for the kernel case. I guess that if I'm going to try and propose a solution, I would want it to match with any existing userspace datapath solution (at least, semantically) if it could. > I agree with Manu that it should not stop us implementing the > PMD-level protection. We can add a fairness scheme later, if needed. Okay - I'm interested in that fairness for other reasons. Maybe I'll cook up the patches and see what comes from it. > BR, Jan ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4] Upcall/Slowpath rate-limiter for OVS
Manohar Krishnappa Chidambaraswamy writes: > How are you stress testing this? Is there some framework you're using? > [manu] Since the number/rate of new flows coming in depends on the > deployment (expected traffic pattern), upcall ratelimit parameters > need to be tuned for a given deployment. We have only done functional > tests on this for now. Let me know when you figure out what framework / setup you're planning on using to stress this. > I'm interested in possibly implementing a similar rate-limiter from the > kernel side (for parity), but want to see if it's really a problem > with the netlink datapath first. > > [manu] In kernel path, slow-path and fast-path are executed in > different contexts, with slow-path executing in dedicated userspace > threads and fast-path in kernel. An upcall is posted from the kernel > module over netlink sockets (a.k.a queues) to upcall threads in > userspace. Hence the number of upcalls can be controlled by > controlling the depth of this queue. So token-bucket would be > unnecessary IMO. Sure, but you end up with similar starvation issues (well... in practice you end up out of file descriptors because of the number of upcall sockets opened - maybe you see why I'm interested in per-port rate limiting :) ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] vxlan: Fix for the packet loop issue in vxlan
Hi Pravin,
The below configuration is causing the spinlock recursion issue.
I am able to see the issue with below configuration.
ovs-vsctl add-br br0
ovs-vsctl add-bond br0 bond0 p1p1 p1p2
ovs-vsctl set port bond0 lacp=active bond_mode=balance-tcp
ifconfig br0 100.0.0.1 up
ovs-vsctl add-port br0 veth0
ovs-vsctl add-port br0 vx0 -- set interface vx0 type=vxlan
options:local_ip=100.0.0.1 options:remote_ip=100.0.0.2 option:key=flow
ovs-ofctl add-flow br0 "table=0, priority=1, cookie=100, tun_id=100,
in_port=4, action=output:3"
ovs-ofctl add-flow br0 "table=0, priority=1, cookie=100, in_port=3,
actions=set_field:100->tun_id output:4"
The same bridge br0 is being used as the local interface for vxlan tunnel.
Even though this configuration is invalid, we should not see the kernel
crash.
On Tue, Jun 12, 2018 at 11:55 AM, Pravin Shelar wrote:
>
>
> On Tue, May 22, 2018 at 10:16 PM, Neelakantam Gaddam <
> neelugad...@gmail.com> wrote:
>
>> This patch fixes the kernel soft lockup issue with vxlan configuration
>> where the tunneled packet is sent on the same bridge where vxlan port is
>> attched to. It detects the loop in vxlan xmit functionb and drops if loop
>> is
>> detected.
>>
>> Signed-off-by: Neelakantam Gaddam
>> ---
>> datapath/linux/compat/vxlan.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/datapath/linux/compat/vxlan.c b/datapath/linux/compat/vxlan.
>> c
>> index 287dad2..00562fa 100644
>> --- a/datapath/linux/compat/vxlan.c
>> +++ b/datapath/linux/compat/vxlan.c
>> @@ -1115,7 +1115,8 @@ static void vxlan_xmit_one(struct sk_buff *skb,
>> struct net_device *dev,
>> goto tx_error;
>> }
>>
>> - if (rt->dst.dev == dev) {
>> + if ((rt->dst.dev == dev) ||
>> + (OVS_CB(skb)->input_vport->dev == rt->dst.dev)) {
>>
>
> I am not sure which case the OVS_CB(skb)->input_vport->dev is not same as
> the dev when there is recursion. Can you explain how to reproduce it?
>
>
--
Thanks & Regards
Neelakantam Gaddam
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] gateway logic question (was: Re: [PATCH v2 1/5] ovsdb-idl: Redesign use of indexes.)
There are 2 types of gateways in OVN - a "gateway router" and a
"distributed gateway router port". The latter is where BFD is used and has
been mostly been maintained by the OpenStack folks. I am adding the
original authors for comment. I am not very familiar with the latter
implementation.
On 12 June 2018 at 08:23, Ben Pfaff wrote:
> Hi Guru, Han raised the following question while reading a patch of
> mine. Will you give your opinion?
>
> On Mon, Jun 11, 2018 at 07:17:13PM -0700, Han Zhou wrote:
> > > +static struct ovs_list *
> > > +bfd_find_ha_gateway_chassis(
> > > +struct ovsdb_idl_index *sbrec_port_binding_by_datapath,
> > > +const struct chassis_index *chassis_index,
> > > +const struct sbrec_datapath_binding *datapath)
> > > +{
> > > +struct sbrec_port_binding *target =
> > sbrec_port_binding_index_init_row(
> > > +sbrec_port_binding_by_datapath);
> > > +sbrec_port_binding_index_set_datapath(target, datapath);
> > > +
> > > +struct ovs_list *ha_gateway_chassis = NULL;
> > > +const struct sbrec_port_binding *pb;
> > > +SBREC_PORT_BINDING_FOR_EACH_EQUAL (pb, target,
> > > + sbrec_port_binding_by_datapath)
> {
> > > +if (strcmp(pb->type, "chassisredirect")) {
> > > +continue;
> > > +}
> > > +
> > > +struct ovs_list *gateway_chassis =
> gateway_chassis_get_ordered(
> > > +pb, chassis_index);
> > > +if (!gateway_chassis || ovs_list_is_short(gateway_chassis)) {
> > > +/* We don't need BFD for non-HA chassisredirect. */
> > > +gateway_chassis_destroy(gateway_chassis);
> > > +continue;
> > > +}
> > > +
> > > +ha_gateway_chassis = gateway_chassis;
> > > +break;
> > > +}
> > > +sbrec_port_binding_index_destroy_row(target);
> > > +return ha_gateway_chassis;
> > > +}
> >
> > This is a good refactoring and it is functionally equal to the original
> > one, but I wonder if there is a problem even with the original logic. It
> > breaks out whenever the first logical router port is found with multiple
> > gateways chassises, but what if there are still some other logical router
> > ports on the same logical router are gateway ports and on different
> > gateways, would those gateways be missed in the bfd sessions? (Of course,
> > it shouldn't belong to this patch even if it is a real problem.)
>
> Thanks,
>
> Ben.
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 5/5] ovn-controller: Drop controller_ctx structure entirely.
On Mon, Jun 11, 2018 at 07:52:41PM -0700, Han Zhou wrote: > Acked-by: Han Zhou Thanks for the reviews. I applied this series to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] gateway logic question (was: Re: [PATCH v2 1/5] ovsdb-idl: Redesign use of indexes.)
Hi Guru, Han raised the following question while reading a patch of
mine. Will you give your opinion?
On Mon, Jun 11, 2018 at 07:17:13PM -0700, Han Zhou wrote:
> > +static struct ovs_list *
> > +bfd_find_ha_gateway_chassis(
> > +struct ovsdb_idl_index *sbrec_port_binding_by_datapath,
> > +const struct chassis_index *chassis_index,
> > +const struct sbrec_datapath_binding *datapath)
> > +{
> > +struct sbrec_port_binding *target =
> sbrec_port_binding_index_init_row(
> > +sbrec_port_binding_by_datapath);
> > +sbrec_port_binding_index_set_datapath(target, datapath);
> > +
> > +struct ovs_list *ha_gateway_chassis = NULL;
> > +const struct sbrec_port_binding *pb;
> > +SBREC_PORT_BINDING_FOR_EACH_EQUAL (pb, target,
> > + sbrec_port_binding_by_datapath) {
> > +if (strcmp(pb->type, "chassisredirect")) {
> > +continue;
> > +}
> > +
> > +struct ovs_list *gateway_chassis = gateway_chassis_get_ordered(
> > +pb, chassis_index);
> > +if (!gateway_chassis || ovs_list_is_short(gateway_chassis)) {
> > +/* We don't need BFD for non-HA chassisredirect. */
> > +gateway_chassis_destroy(gateway_chassis);
> > +continue;
> > +}
> > +
> > +ha_gateway_chassis = gateway_chassis;
> > +break;
> > +}
> > +sbrec_port_binding_index_destroy_row(target);
> > +return ha_gateway_chassis;
> > +}
>
> This is a good refactoring and it is functionally equal to the original
> one, but I wonder if there is a problem even with the original logic. It
> breaks out whenever the first logical router port is found with multiple
> gateways chassises, but what if there are still some other logical router
> ports on the same logical router are gateway ports and on different
> gateways, would those gateways be missed in the bfd sessions? (Of course,
> it shouldn't belong to this patch even if it is a real problem.)
Thanks,
Ben.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 1/5] ovsdb-idl: Redesign use of indexes.
On Mon, Jun 11, 2018 at 07:17:13PM -0700, Han Zhou wrote:
> On Mon, Jun 11, 2018 at 3:14 PM, Ben Pfaff wrote:
> > +2. Pass the index, an iteration variable, and the key values to the
> iterator.
>
> s/key values/index row objects
Thanks, fixed.
> > +void
> > +ovsdb_idl_cursor_next_eq(struct ovsdb_idl_cursor *cursor,
> > + struct ovsdb_idl_index *index)
>
> A minor comment: the signature of this function looked confusing because of
> the "index" parameter. Does it make sense to store the "index" pointer to
> struct ovsdb_idl_cursor, so that when traversing with cursor we only need
> the cursor parameter.
I was undecided about this. I don't think it's actually that confusing
because the only users are encapsulated within macros. But I made the
change and I don't think it's a big deal either way.
> > +static struct ovs_list *
> > +bfd_find_ha_gateway_chassis(
> > +struct ovsdb_idl_index *sbrec_port_binding_by_datapath,
> > +const struct chassis_index *chassis_index,
> > +const struct sbrec_datapath_binding *datapath)
> > +{
> > +struct sbrec_port_binding *target =
> sbrec_port_binding_index_init_row(
> > +sbrec_port_binding_by_datapath);
> > +sbrec_port_binding_index_set_datapath(target, datapath);
> > +
> > +struct ovs_list *ha_gateway_chassis = NULL;
> > +const struct sbrec_port_binding *pb;
> > +SBREC_PORT_BINDING_FOR_EACH_EQUAL (pb, target,
> > + sbrec_port_binding_by_datapath) {
> > +if (strcmp(pb->type, "chassisredirect")) {
> > +continue;
> > +}
> > +
> > +struct ovs_list *gateway_chassis = gateway_chassis_get_ordered(
> > +pb, chassis_index);
> > +if (!gateway_chassis || ovs_list_is_short(gateway_chassis)) {
> > +/* We don't need BFD for non-HA chassisredirect. */
> > +gateway_chassis_destroy(gateway_chassis);
> > +continue;
> > +}
> > +
> > +ha_gateway_chassis = gateway_chassis;
> > +break;
> > +}
> > +sbrec_port_binding_index_destroy_row(target);
> > +return ha_gateway_chassis;
> > +}
>
> This is a good refactoring and it is functionally equal to the original
> one, but I wonder if there is a problem even with the original logic. It
> breaks out whenever the first logical router port is found with multiple
> gateways chassises, but what if there are still some other logical router
> ports on the same logical router are gateway ports and on different
> gateways, would those gateways be missed in the bfd sessions? (Of course,
> it shouldn't belong to this patch even if it is a real problem.)
I'll ask Guru.
> All the comments are minor, so:
>
> Acked-by: Han Zhou
Thanks!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Can you handle this?
Mr. Sayid Hussein Al-Kayali Port of Tartus Street - Syria Please this is very important and urgent. I am Mr. Sayid Hussein Al-Kayali, I was a senior personal assistant to President Bashar al-Assad of Syria, I made away with $65 million USD from the proceed of my family's allocation of hydrocarbon exploration in Syria, because of the war situation in my country. I have been granted asylum in another country now, but I am contacting you to assist receive the fund for business investment in your country, because I can not go back to Syria now for the safety of my life. I lodged the fund under a special arrangement with a security vault in Vienna, Austria for safe-keeping until I find a competent and serious person to receive it for investment. If you are ready to receive and manage this fund, then get back to me with your full name and telephone number for more detailed information to proceed further. Best regards, Mr. Sayid Hussein Al-Kayali Add Home: Port - Street Tartous Syria ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Issue with OVS 2.9.0, DPDK 18.02 and vhost-user
> Hi, > > I have used first link to install, compile and run OVS 2.9.0 and DPDK > 18.02, second link to configure vhost-client ports. However, facing > several issues when configured as per the documentation. Inputs > appreciated. > > http://docs.openvswitch.org/en/latest/intro/install/dpdk/ > > http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/ > Is there a specific reason you require DPDK 18.02? DPDK 17.11 is the latest officially support DPDK for OVS, I'd recommend testing with this as I'm not sure how well validated DPDK 18.02 is. In testing I also found that OVS will fail to compile with 18.02 due to 'rte_eth_find_next_owned_by' not being part of the stable ABI. The list of supported DPDK to OVS mappings can be found in the release doc below. http://docs.openvswitch.org/en/latest/faq/releases/ > Following logs from /usr/local/var/log/openvswitch/ovs-vswitchd.log shows > OVS/DPDK initialized correctly. > > 2018-06-11T21:15:06.028Z|1|vlog|INFO|opened log file > /usr/local/var/log/openvswitch/ovs-vswitchd.log > 2018-06-11T21:15:06.032Z|2|ovs_numa|INFO|Discovered 4 CPU cores on > NUMA node 0 2018-06-11T21:15:06.032Z|3|ovs_numa|INFO|Discovered 1 NUMA > nodes and 4 CPU cores > 2018-06- > 11T21:15:06.032Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitch/ > db.sock: > connecting... > 2018-06- > 11T21:15:06.032Z|5|reconnect|INFO|unix:/usr/local/var/run/openvswitch/ > db.sock: > connected > 2018-06-11T21:15:06.033Z|6|dpdk|INFO|Using DPDK 18.02.0 2018-06- > 11T21:15:06.033Z|7|dpdk|INFO|DPDK Enabled - initializing... > 2018-06-11T21:15:06.033Z|8|dpdk|INFO|No vhost-sock-dir provided - > defaulting to /usr/local/var/run/openvswitch 2018-06- > 11T21:15:06.033Z|9|dpdk|INFO|IOMMU support for vhost-user-client > disabled. > 2018-06-11T21:15:06.033Z|00010|dpdk|INFO|EAL ARGS: ovs-vswitchd --huge-dir > /dev/hugepages_1G --socket-mem 2,0 --no-pci --file-prefix=host -c > 0x0001 > 2018-06-11T21:15:06.034Z|00011|dpdk|INFO|EAL: Detected 4 lcore(s) > 2018-06-11T21:15:06.034Z|00012|dpdk|INFO|EAL: 2048 hugepages of size > 2097152 reserved, but no mounted hugetlbfs found for that size > 2018-06-11T21:15:06.035Z|00013|dpdk|INFO|EAL: Multi-process socket > /var/run/.host_unix > 2018-06-11T21:15:06.036Z|00014|dpdk|INFO|EAL: Probing VFIO support... > 2018-06-11T21:15:06.036Z|00015|dpdk|INFO|EAL: VFIO support initialized > 2018-06-11T21:15:06.902Z|00016|dpdk|WARN|EAL: WARNING: cpu flags > constant_tsc=yes nonstop_tsc=no -> using unreliable clock cycles ! > 2018-06-11T21:15:06.906Z|00017|dpdk|INFO|DPDK Enabled - initialized 2018- > 06-11T21:15:06.906Z|00018|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.9.0 > > root# ovs-vswitchd --version > ovs-vswitchd (Open vSwitch) 2.9.0 > DPDK 18.02.0 > > root# ovs-vsctl get Open_vSwitch . dpdk_version > ovs-vsctl: Open_vSwitch does not contain a column whose name matches > "dpdk_version" > root# ovs-vsctl get Open_vSwitch . dpdk_initialized > ovs-vsctl: Open_vSwitch does not contain a column whose name matches > "dpdk_initialized" The functionality above is only available on OVS master, it will be part of OVS 2.10 but is not part of OVS 2.9. > > Creating dpdkvhostclient port spits out following error message > > ovs-vsctl add-port br0 dpdkvhostclient0 -- set Interface dpdkvhostclient0 > type=dpdkvhostuserclient options:vhost-server-path=/tmp/dpdkvhostclient0 The command above looks ok. > ovs-vsctl: Error detected while setting up 'dpdkvhostclient0': could not > add network device dpdkvhostclient0 to ofproto (Invalid argument). See > ovs-vswitchd log for details. > ovs-vsctl: The default log directory is "/usr/local/var/log/openvswitch". > How are you adding the bridge? Can you confirm that it is set to datapath type netdev as below ovs-vsctl add-br br0 -- set Bridge br0 datapath_type=netdev Ian > From the logs > > 2018-06-12T01:25:34.290Z|00071|dpif_netlink|WARN|system@ovs-system: cannot > create port `vhost-user-1' because it has unsupported type > `dpdkvhostuserclient' > 2018-06-12T01:25:34.290Z|00072|dpif|WARN|system@ovs-system: failed to add > vhost-user-1 as port: Invalid argument > 2018-06-12T01:25:34.290Z|00073|bridge|WARN|could not add network device > vhost-user-1 to ofproto (Invalid argument) > 2018-06-12T01:25:37.214Z|00074|dpif|WARN|system@ovs-system: failed to > query port dpdkvhostclient0: Invalid argument > 2018-06-12T01:25:37.214Z|00075|dpif_netlink|WARN|system@ovs-system: cannot > create port `dpdkvhostclient0' because it has unsupported type > `dpdkvhostuserclient' > 2018-06-12T01:25:37.214Z|00076|dpif|WARN|system@ovs-system: failed to add > dpdkvhostclient0 as port: Invalid argument 2018-06- > 12T01:25:37.214Z|00077|bridge|WARN|could not add network device > dpdkvhostclient0 to ofproto (Invalid argument) > 2018-06-12T01:25:37.214Z|00078|netdev_dpdk|ERR|dpdkvhostclient0: Unable to > unregister vhost driver for socket '/tmp/dpdkvhostclient0'. >
[ovs-dev] [PATCH] rhel: Add python-netifaces as a dependency for openvswitch-test
Currently python-netifaces is needed for ovs-tcpdump that is installed
by openvswitch-test package.
This commit adds {python,python2}-netifaces as a dependency for the
openvswitch-test package.
Signed-off-by: Timothy Redaelli
---
rhel/openvswitch-fedora.spec.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in
index 9be16ffe7..d88ed8ec4 100644
--- a/rhel/openvswitch-fedora.spec.in
+++ b/rhel/openvswitch-fedora.spec.in
@@ -145,7 +145,7 @@ Summary: Open vSwitch testing utilities
License: ASL 2.0
BuildArch: noarch
Requires: %{_py2}-openvswitch = %{version}-%{release}
-Requires: %{_py2} %{_py2}-twisted
+Requires: %{_py2} %{_py2}-netifaces %{_py2}-twisted
%description test
Utilities that are useful to diagnose performance and connectivity
--
2.17.0
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Reply Me Now It's Very Urgent
Reply Me Now It's Very Urgent Hello My Good Friend,I am a banker in Bank Atlantic Ivory Coast . I want to transfer an abandoned sum of 7.2millions USD to your account. 50% will be for you. No risk involved. Contact me immediately for more details becuase this is a deal at stake. Mrs Celina Joseph. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v8 01/13] netdev-dpdk: fix mbuf sizing
Hi,
On Monday 11 June 2018 09:51 PM, Tiago Lam wrote:
> From: Mark Kavanagh
>
> There are numerous factors that must be considered when calculating
> the size of an mbuf:
> - the data portion of the mbuf must be sized in accordance With Rx
> buffer alignment (typically 1024B). So, for example, in order to
> successfully receive and capture a 1500B packet, mbufs with a
> data portion of size 2048B must be used.
> - in OvS, the elements that comprise an mbuf are:
> * the dp packet, which includes a struct rte mbuf (704B)
> * RTE_PKTMBUF_HEADROOM (128B)
> * packet data (aligned to 1k, as previously described)
> * RTE_PKTMBUF_TAILROOM (typically 0)
>
> Some PMDs require that the total mbuf size (i.e. the total sum of all
> of the above-listed components' lengths) is cache-aligned. To satisfy
> this requirement, it may be necessary to round up the total mbuf size
> with respect to cacheline size. In doing so, it's possible that the
> dp_packet's data portion is inadvertently increased in size, such that
> it no longer adheres to Rx buffer alignment. Consequently, the
> following property of the mbuf no longer holds true:
>
> mbuf.data_len == mbuf.buf_len - mbuf.data_off
>
> This creates a problem in the case of multi-segment mbufs, where that
> assumption is assumed to be true for all but the final segment in an
> mbuf chain. Resolve this issue by adjusting the size of the mbuf's
> private data portion, as opposed to the packet data portion when
> aligning mbuf size to cachelines.
>
> Fixes: 4be4d22 ("netdev-dpdk: clean up mbuf initialization")
> Fixes: 31b88c9 ("netdev-dpdk: round up mbuf_size to cache_line_size")
> CC: Santosh Shukla
> Signed-off-by: Mark Kavanagh
> ---
Change looks good to me.
Even for default 2k buffer: This patch saves one cacheline_sz(128B) area for
arm64
platform.
Acked-by: Santosh Shukla
Thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] vxlan: Fix for the packet loop issue in vxlan
On Tue, May 22, 2018 at 10:16 PM, Neelakantam Gaddam
wrote:
> This patch fixes the kernel soft lockup issue with vxlan configuration
> where the tunneled packet is sent on the same bridge where vxlan port is
> attched to. It detects the loop in vxlan xmit functionb and drops if loop
> is
> detected.
>
> Signed-off-by: Neelakantam Gaddam
> ---
> datapath/linux/compat/vxlan.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/datapath/linux/compat/vxlan.c b/datapath/linux/compat/vxlan.c
> index 287dad2..00562fa 100644
> --- a/datapath/linux/compat/vxlan.c
> +++ b/datapath/linux/compat/vxlan.c
> @@ -1115,7 +1115,8 @@ static void vxlan_xmit_one(struct sk_buff *skb,
> struct net_device *dev,
> goto tx_error;
> }
>
> - if (rt->dst.dev == dev) {
> + if ((rt->dst.dev == dev) ||
> + (OVS_CB(skb)->input_vport->dev == rt->dst.dev)) {
>
I am not sure which case the OVS_CB(skb)->input_vport->dev is not same as
the dev when there is recursion. Can you explain how to reproduce it?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
