Hello,
I would like you whether OVN is currently supporting multus CNI plugin and
can be used as additional plugin ?
Also , if you can help me with a reference example
Thanks a lot
Best Regards
___
dev mailing list
d...@openvswitch.org
https://mail.ope
Dear Friend,
How are you and your entire family? I hope you and your entire family are doing
everything possible to stay safe and protected from the coronavirus pandemic. I
am your friend Mr. Ismael from the Arab Republic of Syrian. I am eagerly
looking for an investment opportunity in your coun
Hi, I rebase the patch on the latest master branch.
From 07f10707699a39e3a6de68012dd6c0453120c543 Mon Sep 17 00:00:00 2001
From: hepeng
Date: Wed, 4 Dec 2019 17:38:22 +0800
Subject: [PATCH] ofproto-dpif-xlate: do not unwildcard source address if not
needed
if the tunnel is specified as "remote
When processing update2 messages, if the IDL detects that previous
updates were missed, clear db->last_id and trigger a reconnect such that
the IDL refreshes its complete view of the database.
Such scenarios can happen for example when bugs in
ovsdb-server/ovsdb-idl are encountered. One such situa
Tun_metadata can be referened by flow and frozen_state at the same
time. When ovs-vswitchd handles TLV table mod message, the involved
tun_metadata gets freed. The call trace to free tun_metadata is
shown as below:
ofproto_run
- handle_openflow
- handle_single_part_openflow
- handle_tlv_tabl
This patch enhances a system traffic test to prevent regression on
the tunnel metadata table (tun_table) handling with frozen state.
Without a proper fix this test can crash ovs-vswitchd due to a
use-after-free bug on tun_table.
These are the timed sequence of how this bug is triggered:
- Adds an
Martes 28 de Abril | Horario de 10:00 a 14:00 hrs. | (hora del centro de
México)
- Guía paso a paso: Trámites de capacitación ante la S.T.P.S. -
Al inscribirte en cualquiera de nuestros cursos obtén tres accesos o conexiones
al precio de uno para un mismo un curso.
En este webinar te presen
On 3/25/20 9:15 PM, Dumitru Ceara wrote:
> This reverts commit 5351980b047f4dd40be7a59a1e4b910df21eca0a.
>
> If the ovsdb-server reply to "monitor_cond_since" requests has
> "found" == false then ovsdb_idl_db_parse_monitor_reply() calls
> ovsdb_idl_db_clear() which iterates through all tables and
On Sun, Mar 22, 2020 at 10:42:16AM +0800, 贺鹏 wrote:
> if the tunnel is specified as "remote_ip=flow", we can try to generate
> a megaflow
> which ignores all source address, such as source mac, source IP address
> in the outter header of the packet. This can reduce the number of
> megaflows and avo
Acked-by: Mark Michelson
On 3/26/20 10:49 AM, num...@ovn.org wrote:
From: Numan Siddique
Suppose there is below NAT entry with external_ip = 172.168.0.100
nat
external ip: "172.168.0.100"
logical ip: "10.0.0.0/24"
type: "snat"
And a load balancer with the VIP - 172.168.0.100
I think you may have accidentally re-sent v1 patches with v2's commit
message. The LB protocol is still not in the new flow's match, and the
`ovn-sbctl dump-flows` command is still in the test.
On 3/26/20 10:35 AM, num...@ovn.org wrote:
From: Numan Siddique
Suppose there is below NAT entry w
On 3/26/20 10:17 AM, Numan Siddique wrote:
On Thu, Mar 26, 2020 at 6:06 PM Mark Michelson wrote:
The gist of this change is that the configured SNAT external address and
the load balancer VIP are the same. This means that we end up with both
SNAT and DNAT occurring for the same external addres
From: Numan Siddique
Suppose there is below NAT entry with external_ip = 172.168.0.100
nat
external ip: "172.168.0.100"
logical ip: "10.0.0.0/24"
type: "snat"
And a load balancer with the VIP - 172.168.0.100
_uuid :
external_ids: {}
name: lb1
From: Numan Siddique
Suppose there is below NAT entry with external_ip = 172.168.0.100
nat
external ip: "172.168.0.100"
logical ip: "10.0.0.0/24"
type: "snat"
And a load balancer with the VIP - 172.168.0.100
_uuid :
external_ids: {}
name: lb1
On Thu, Mar 26, 2020 at 6:06 PM Mark Michelson wrote:
>
> The gist of this change is that the configured SNAT external address and
> the load balancer VIP are the same. This means that we end up with both
> SNAT and DNAT occurring for the same external address. Would we see a
> similar problem if
The gist of this change is that the configured SNAT external address and
the load balancer VIP are the same. This means that we end up with both
SNAT and DNAT occurring for the same external address. Would we see a
similar problem if there were no load balancer, but we had configured
the nat ty
In order to use dequeue-zero-copy in DPDK Vhost library, application
has to disable linear buffer option. Hence dequeue-zero-copy is not
supported for vhost application thats requries linear buffers.
This patch is a workaround to support dq-zero-copy in OVS by overcoming
the current limitation in
From: Numan Siddique
Suppose there is below NAT entry with external_ip = 172.168.0.100
nat
external ip: "172.168.0.100"
logical ip: "10.0.0.0/24"
type: "snat"
And a load balancer with the VIP - 172.168.0.100
_uuid :
external_ids: {}
name: lb1
Fixes: Remove duplicate code.
Signed-off-by: wllabs
---
lib/netdev-dpdk.c | 1 -
1 file changed, 0 insertion(+), 1 deletion(-)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 6187129..2f388ae 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -1832,7 +1832,6 @@ netdev_dpdk_pro
sorry, No problem. I'm wrong.
At 2020-03-26 15:28:47, "wllabs" wrote:
Fixes: Remove duplicate code.
Signed-off-by: wllabs
---
lib/netdev-dpdk.c | 1 -
1 file changed, 0 insertion(+), 1 deletion(-)
diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index 6187129..2f388ae 100644
--- a
The SKB_SGO_CB_OFFSET should be SKB_GSO_CB_OFFSET which means the
offset of the GSO in skb cb. This patch fixes the typo.
Fixes: 9207f9d45b0a ("net: preserve IP control block during GSO segmentation")
Signed-off-by: Cambda Zhu
---
include/linux/skbuff.h | 4 ++--
net/core/dev.c |
21 matches
Mail list logo
