[ovs-dev] [PATCH v1] Travis: Fix path search issue for AFXDP on arm CI

2020-07-23 Thread Lance Yang 
The current AFXDP job only supports x86 on Travis CI. The patch only
fixes some issues for arm CI. It did not add AFXDP as an additional job
for arm CI. The following issues are fixed:

1. The header file cdefs.h is under different path on arm, this patch adds
the path for searching headers in linux-build.sh.

2. GCC on arm does not search a library path, causing the bfp
library cannot be found during compilation. To fix this library link issue,
this patch adds the bfp library search path in CFLAGS.

The fix of above issues will help developers who want to manually run
AFXDP job on arm CI when they validate their patches.

Reviewed-by: Yanqin Wei 
Signed-off-by: Lance Yang 
---
 .travis/linux-build.sh | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
index 02615a8ec..ec92c92d0 100755
--- a/.travis/linux-build.sh
+++ b/.travis/linux-build.sh
@@ -71,8 +71,16 @@ function install_kernel()
 # The Linux kernel defines __always_inline in stddef.h (283d7573), and
 # sys/cdefs.h tries to re-define it.  Older libc-dev package in xenial
 # doesn't have a fix for this issue.  Applying it manually.
-sudo sed -i '/^# define __always_inline .*/i # undef __always_inline' \
-/usr/include/x86_64-linux-gnu/sys/cdefs.h || true
+if [ "$TRAVIS_ARCH" == "aarch64" ]; then
+sudo sed -i \
+ '/^# define __always_inline .*/i # undef __always_inline' \
+ /usr/include/aarch64-linux-gnu/sys/cdefs.h || true
+CFLAGS_FOR_OVS="$CFLAGS_FOR_OVS -L/usr/local/lib64"
+else
+sudo sed -i \
+'/^# define __always_inline .*/i # undef __always_inline' \
+ /usr/include/x86_64-linux-gnu/sys/cdefs.h || true
+fi
 EXTRA_OPTS="${EXTRA_OPTS} --enable-afxdp"
 else
 EXTRA_OPTS="${EXTRA_OPTS} --with-linux=$(pwd)"
-- 
2.27.0

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

Re: [ovs-dev] OVN: Two datapath-bindings are created for the same logical-switch

2020-07-23 Thread Tony Liu 
Hi Han,

Thanks for taking the time to look into this. This problem is not consistently 
reproduced.
Developers normally ignore it:) I think we collected enough context and we can 
let it go for now.
I will rebuild setup, tune that RAFT heartbeat timer and rerun the test. Will 
keep you posted.


Thanks again!

Tony


From: Han Zhou 
Sent: July 23, 2020 06:53 PM
To: Tony Liu ; Ben Pfaff 
Cc: Numan Siddique ; ovs-dev ; 
ovs-disc...@openvswitch.org 
Subject: Re: [ovs-dev] OVN: Two datapath-bindings are created for the same 
logical-switch


On Thu, Jul 23, 2020 at 10:33 AM Tony Liu 
mailto:tonyliu0...@hotmail.com>> wrote:
>
> Changed the title for this specific problem.
> I looked into logs and have more findings.
> The problem was happening when sb-db leader switched.

Hi Tony,

Thanks for this detailed information. Could you confirm which version of OVS is 
used (to understand OVSDB behavior).

>
> For ovsdb cluster, what may trigger the leader switch? Given the log,
> 2020-07-21T01:08:38.119Z|00074|raft|INFO|term 2: 1135 ms timeout expired, 
> starting election
> The election is asked by a follower node. Is that because the connection from 
> follower to leader timeout,
> then follower assumes the leader is dead and starts an election?

You are right, the RAFT heart beat would timeout when server is too busy and 
the election timer is too small (default 1s). For large scale test, please 
increase the election timer by:
ovn-appctl -t  cluster/change-election-timer OVN_Southbound 

I suggest to set  to be at least bigger than 1 or more in your case. 
(you need to increase the value gradually - 2000, 4000, 8000, 16000 - so it 
will take you 4 commands to reach this from the initial default value 1000, not 
very convenient, I know :)

 here is the path to the socket ctl file of ovn-sb, usually under 
/var/run/ovn.

>
> For ovn-northd (3 instances), they all connect to the sb-db leader, whoever 
> has the locker is the master.
> When sb-db leader switches, all ovn-northd instances look for the new leader. 
> In this case, there is no
> guarantee that the old ovn-northd master remains the role, other ovn-northd 
> instance may find the
> leader and acquire the lock first. So, the sb-db leader switch may also cause 
> ovn-northd master switch.
> Such switch may happen in the middle of ovn-northd transaction, in that case, 
> is there any guarantee to
> the transaction completeness? My guess is that, the older created a 
> datapath-binding for a logical-switch,
> switch happened when this transaction is not completed, then the new 
> master/leader created another
> data-path binding for the same logical-switch. Does it make any sense?

I agree with you it could be related to the failover and the lock behavior 
during the failover. It could be a lock problem causing 2 northds became active 
at the same time for a short moment. However, I still can't imagine how the 
duplicated entries are created with different tunnel keys. If both northd 
create the datapath binding for the same LS at the same time, they should 
allocate the same tunnel key, and then one of them should fail during the 
transaction commit because of index conflict in DB. But here they have 
different keys so both were inserted in DB.

(OVSDB transaction is atomic even during failover and no client should see 
partial data of a transaction.)

(cc Ben to comment more on the possibility of both clients acquiring the lock 
during failover)

>
> From the log, when sb-db switched, ovn-northd master connected to the new 
> leader and lost the master,
> but immediately, it acquired the lock and become master again. Not sure how 
> this happened.

>From the ovn-northd logs, the ovn-northd on .86 firstly connected to SB DB on 
>.85, which suggests that it regarded .85 as the leader (otherwise it would 
>disconnect and retry another server), and then immediately after connecting 
>.85 and acquiring the lock, it disconnected because it somehow noticed that 
>.85 is not the leader, and then retried and connected to .86 (the new leader) 
>and found out that the lock is already acquired by .85 northd, so it switched 
>to standby. The .85 northd luckly connected to .86 in the first try so it was 
>able to acquire the lock on the leader node first. Maybe the key thing is to 
>figure out why the .86 northd initially connected to .85 DB which is not the 
>leader and acquired lock.

Thanks,
Han

>
> Here are some loggings.
>  .84 sb-db leader =
> 2020-07-21T01:08:20.221Z|01408|raft|INFO|current entry eid 
> 639238ba-bc00-4efe-bb66-6ac766bb5f4b does not match prerequisite 
> 78e8e167-8b4c-4292-8e25-d9975631b010 in execute_command_request
>
> 2020-07-21T01:08:38.450Z|01409|timeval|WARN|Unreasonably long 1435ms poll 
> interval (1135ms user, 43ms system)
> 2020-07-21T01:08:38.451Z|01410|timeval|WARN|faults: 5942 minor, 0 major
> 2020-07-21T01:08:38.451Z|01411|timeval|WARN|disk: 0 reads, 50216 writes
>

Re: [ovs-dev] [PATCH net-next v2 1/2] net: openvswitch: add masks cache hit counter

2020-07-23 Thread Tonghao Zhang 
On Thu, Jul 23, 2020 at 8:58 PM Eelco Chaudron  wrote:
>
> Add a counter that counts the number of masks cache hits, and
> export it through the megaflow netlink statistics.
>
> Reviewed-by: Paolo Abeni 
> Signed-off-by: Eelco Chaudron 
LGTM
Reviewed-by: Tonghao Zhang 

> ---
>  include/uapi/linux/openvswitch.h |2 +-
>  net/openvswitch/datapath.c   |5 -
>  net/openvswitch/datapath.h   |3 +++
>  net/openvswitch/flow_table.c |   19 ++-
>  net/openvswitch/flow_table.h |3 ++-
>  5 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/include/uapi/linux/openvswitch.h 
> b/include/uapi/linux/openvswitch.h
> index 9b14519e74d9..7cb76e5ca7cf 100644
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -102,8 +102,8 @@ struct ovs_dp_megaflow_stats {
> __u64 n_mask_hit;/* Number of masks used for flow lookups. */
> __u32 n_masks;   /* Number of masks for the datapath. */
> __u32 pad0;  /* Pad for future expension. */
> +   __u64 n_cache_hit;   /* Number of cache matches for flow lookups. 
> */
> __u64 pad1;  /* Pad for future expension. */
> -   __u64 pad2;  /* Pad for future expension. */
>  };
>
>  struct ovs_vport_stats {
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 95805f0e27bd..a54df1fe3ec4 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -225,13 +225,14 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct 
> sw_flow_key *key)
> struct dp_stats_percpu *stats;
> u64 *stats_counter;
> u32 n_mask_hit;
> +   u32 n_cache_hit;
> int error;
>
> stats = this_cpu_ptr(dp->stats_percpu);
>
> /* Look up flow. */
> flow = ovs_flow_tbl_lookup_stats(>table, key, skb_get_hash(skb),
> -_mask_hit);
> +_mask_hit, _cache_hit);
> if (unlikely(!flow)) {
> struct dp_upcall_info upcall;
>
> @@ -262,6 +263,7 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct 
> sw_flow_key *key)
> u64_stats_update_begin(>syncp);
> (*stats_counter)++;
> stats->n_mask_hit += n_mask_hit;
> +   stats->n_cache_hit += n_cache_hit;
> u64_stats_update_end(>syncp);
>  }
>
> @@ -699,6 +701,7 @@ static void get_dp_stats(const struct datapath *dp, 
> struct ovs_dp_stats *stats,
> stats->n_missed += local_stats.n_missed;
> stats->n_lost += local_stats.n_lost;
> mega_stats->n_mask_hit += local_stats.n_mask_hit;
> +   mega_stats->n_cache_hit += local_stats.n_cache_hit;
> }
>  }
>
> diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
> index 697a2354194b..86d78613edb4 100644
> --- a/net/openvswitch/datapath.h
> +++ b/net/openvswitch/datapath.h
> @@ -38,12 +38,15 @@
>   * @n_mask_hit: Number of masks looked up for flow match.
>   *   @n_mask_hit / (@n_hit + @n_missed)  will be the average masks looked
>   *   up per packet.
> + * @n_cache_hit: The number of received packets that had their mask found 
> using
> + * the mask cache.
>   */
>  struct dp_stats_percpu {
> u64 n_hit;
> u64 n_missed;
> u64 n_lost;
> u64 n_mask_hit;
> +   u64 n_cache_hit;
> struct u64_stats_sync syncp;
>  };
>
> diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
> index af22c9ee28dd..a5912ea05352 100644
> --- a/net/openvswitch/flow_table.c
> +++ b/net/openvswitch/flow_table.c
> @@ -667,6 +667,7 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
>struct mask_array *ma,
>const struct sw_flow_key *key,
>u32 *n_mask_hit,
> +  u32 *n_cache_hit,
>u32 *index)
>  {
> u64 *usage_counters = this_cpu_ptr(ma->masks_usage_cntr);
> @@ -682,6 +683,7 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
> u64_stats_update_begin(>syncp);
> usage_counters[*index]++;
> u64_stats_update_end(>syncp);
> +   (*n_cache_hit)++;
> return flow;
> }
> }
> @@ -719,7 +721,8 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
>  struct sw_flow *ovs_flow_tbl_lookup_stats(struct flow_table *tbl,
>   const struct sw_flow_key *key,
>   u32 skb_hash,
> - u32 *n_mask_hit)
> + u32 *n_mask_hit,
> + u32 *n_cache_hit)
>  {
>

Re: [ovs-dev] OVN: Two datapath-bindings are created for the same logical-switch

2020-07-23 Thread Han Zhou 
On Thu, Jul 23, 2020 at 10:33 AM Tony Liu  wrote:
>
> Changed the title for this specific problem.
> I looked into logs and have more findings.
> The problem was happening when sb-db leader switched.

Hi Tony,

Thanks for this detailed information. Could you confirm which version of
OVS is used (to understand OVSDB behavior).

>
> For ovsdb cluster, what may trigger the leader switch? Given the log,
> 2020-07-21T01:08:38.119Z|00074|raft|INFO|term 2: 1135 ms timeout expired,
starting election
> The election is asked by a follower node. Is that because the connection
from follower to leader timeout,
> then follower assumes the leader is dead and starts an election?

You are right, the RAFT heart beat would timeout when server is too busy
and the election timer is too small (default 1s). For large scale test,
please increase the election timer by:
ovn-appctl -t  cluster/change-election-timer OVN_Southbound 

I suggest to set  to be at least bigger than 1 or more in your
case. (you need to increase the value gradually - 2000, 4000, 8000, 16000 -
so it will take you 4 commands to reach this from the initial default value
1000, not very convenient, I know :)

 here is the path to the socket ctl file of ovn-sb, usually under
/var/run/ovn.

>
> For ovn-northd (3 instances), they all connect to the sb-db leader,
whoever has the locker is the master.
> When sb-db leader switches, all ovn-northd instances look for the new
leader. In this case, there is no
> guarantee that the old ovn-northd master remains the role, other
ovn-northd instance may find the
> leader and acquire the lock first. So, the sb-db leader switch may also
cause ovn-northd master switch.
> Such switch may happen in the middle of ovn-northd transaction, in that
case, is there any guarantee to
> the transaction completeness? My guess is that, the older created a
datapath-binding for a logical-switch,
> switch happened when this transaction is not completed, then the new
master/leader created another
> data-path binding for the same logical-switch. Does it make any sense?

I agree with you it could be related to the failover and the lock behavior
during the failover. It could be a lock problem causing 2 northds became
active at the same time for a short moment. However, I still can't imagine
how the duplicated entries are created with different tunnel keys. If both
northd create the datapath binding for the same LS at the same time, they
should allocate the same tunnel key, and then one of them should fail
during the transaction commit because of index conflict in DB. But here
they have different keys so both were inserted in DB.

(OVSDB transaction is atomic even during failover and no client should see
partial data of a transaction.)

(cc Ben to comment more on the possibility of both clients acquiring the
lock during failover)

>
> From the log, when sb-db switched, ovn-northd master connected to the new
leader and lost the master,
> but immediately, it acquired the lock and become master again. Not sure
how this happened.

>From the ovn-northd logs, the ovn-northd on .86 firstly connected to SB DB
on .85, which suggests that it regarded .85 as the leader (otherwise it
would disconnect and retry another server), and then immediately after
connecting .85 and acquiring the lock, it disconnected because it somehow
noticed that .85 is not the leader, and then retried and connected to .86
(the new leader) and found out that the lock is already acquired by .85
northd, so it switched to standby. The .85 northd luckly connected to .86
in the first try so it was able to acquire the lock on the leader node
first. Maybe the key thing is to figure out why the .86 northd initially
connected to .85 DB which is not the leader and acquired lock.

Thanks,
Han

>
> Here are some loggings.
>  .84 sb-db leader =
> 2020-07-21T01:08:20.221Z|01408|raft|INFO|current entry eid
639238ba-bc00-4efe-bb66-6ac766bb5f4b does not match prerequisite
78e8e167-8b4c-4292-8e25-d9975631b010 in execute_command_request
>
> 2020-07-21T01:08:38.450Z|01409|timeval|WARN|Unreasonably long 1435ms poll
interval (1135ms user, 43ms system)
> 2020-07-21T01:08:38.451Z|01410|timeval|WARN|faults: 5942 minor, 0 major
> 2020-07-21T01:08:38.451Z|01411|timeval|WARN|disk: 0 reads, 50216 writes
> 2020-07-21T01:08:38.452Z|01412|timeval|WARN|context switches: 60
voluntary, 25 involuntary
> 2020-07-21T01:08:38.453Z|01413|coverage|INFO|Skipping details of
duplicate event coverage for hash=45329980
>
> 2020-07-21T01:08:38.455Z|01414|raft|WARN|ignoring vote request received
as leader
> 2020-07-21T01:08:38.456Z|01415|raft|INFO|server 1f9e is leader for term 2
> 2020-07-21T01:08:38.457Z|01416|raft|INFO|rejected append_reply (not
leader)
> 2020-07-21T01:08:38.471Z|01417|raft|INFO|rejected append_reply (not
leader)
>
> 2020-07-21T01:23:00.890Z|01418|timeval|WARN|Unreasonably long 1336ms poll
interval (1102ms user, 20ms system)
>
>  .85 sb-db ==
>

Re: [ovs-dev] OVN Controller Incremental Processing

2020-07-23 Thread Han Zhou 
On Thu, Jul 23, 2020 at 5:40 PM Tony Liu  wrote:
>
> Hi Han,
>
> Now, I have 4000 records in logical-switch table in nb-db, only 1567
records in datapath-binding
> table in sb-db. The translation was broken by a duplication (2 datapath
bindings point to the same
> logical-switch). Not sure how that happened. Anyways, I manually removed
this duplication.
> How can I trigger ovn-northd to finish the translation for all the rest
logical switches?
>
One thing you need to be aware of with many networks is that you probably
want to enable the option "ovn-monitor-all=true" on each HV node, to avoid
overloading the SB DB because of the big size of conditional monitoring
condition updates.

If you trigger any change to NB, ovn-northd will recompute everything. If
it doesn't complete the processing, there must be something wrong, and
there should be error logs.

>
> Thanks!
>
> Tony
>
> 
> From: Han Zhou 
> Sent: July 23, 2020 04:19 PM
> To: Tony Liu 
> Cc: Han Zhou ; ovs-dev ;
ovs-discuss 
> Subject: Re: [ovs-dev] OVN Controller Incremental Processing
>
>
>
> On Thu, Jul 23, 2020 at 4:12 PM  wrote:
> >
> > Thanks Han for the quick confirmation!
> > That says, when changes was made into nb-db, ovn-northd doesn't
recompile the whole db, instead, it only updates the increment into sb-db.
I am currently running some scaling test and seeing 100% CPU usage, hence
asking.
> >
> Oh, no. The talk was about "OVN-controller", which is the component
running on hypervisors, to translate SB data into OVS flows, and this has
been implemented (although not all scenarios are incrementally processed).
For ovn-northd, it runs on central node to convert data from NB to SB DB,
and it is not incremental yet with incremental processing, so it is
expected to see 100% CPU. There is currently a work ongoing for ovn-northd
incremental processing, with DDlog, by Ben and Leonid.
>
> > Tony
> >
> > On Jul 23, 2020 4:02 PM, Han Zhou  wrote:
> >
> >
> >
> > On Thu, Jul 23, 2020 at 11:17 AM Tony Liu 
wrote:
> > >
> > > Hi,
> > >
> > > Is this implemented and released?
> > >
https://www.slideshare.net/hanzhou1978/ovn-controller-incremental-processing
> > > Could anyone share an update on this?
> > >
> > >
> > > Thanks!
> > >
> > > Tony
> > >
> >
> > Yes, it was released initially in OVS/OVN 2.12 (if I remember
correctly), and there have been more improvements added gradually since
then.
> > (The "future" part which talks about DDlog is not implemented yet.)
> >
> > Thanks,
> > Han
> >
> >
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVN Controller Incremental Processing

2020-07-23 Thread Tony Liu 
Hi Han,

Now, I have 4000 records in logical-switch table in nb-db, only 1567 records in 
datapath-binding
table in sb-db. The translation was broken by a duplication (2 datapath 
bindings point to the same
logical-switch). Not sure how that happened. Anyways, I manually removed this 
duplication.
How can I trigger ovn-northd to finish the translation for all the rest logical 
switches?


Thanks!

Tony


From: Han Zhou 
Sent: July 23, 2020 04:19 PM
To: Tony Liu 
Cc: Han Zhou ; ovs-dev ; ovs-discuss 

Subject: Re: [ovs-dev] OVN Controller Incremental Processing



On Thu, Jul 23, 2020 at 4:12 PM 
mailto:tonyliu0...@hotmail.com>> wrote:
>
> Thanks Han for the quick confirmation!
> That says, when changes was made into nb-db, ovn-northd doesn't recompile the 
> whole db, instead, it only updates the increment into sb-db. I am currently 
> running some scaling test and seeing 100% CPU usage, hence asking.
>
Oh, no. The talk was about "OVN-controller", which is the component running on 
hypervisors, to translate SB data into OVS flows, and this has been implemented 
(although not all scenarios are incrementally processed). For ovn-northd, it 
runs on central node to convert data from NB to SB DB, and it is not 
incremental yet with incremental processing, so it is expected to see 100% CPU. 
There is currently a work ongoing for ovn-northd incremental processing, with 
DDlog, by Ben and Leonid.

> Tony
>
> On Jul 23, 2020 4:02 PM, Han Zhou mailto:hz...@ovn.org>> wrote:
>
>
>
> On Thu, Jul 23, 2020 at 11:17 AM Tony Liu 
> mailto:tonyliu0...@hotmail.com>> wrote:
> >
> > Hi,
> >
> > Is this implemented and released?
> > https://www.slideshare.net/hanzhou1978/ovn-controller-incremental-processing
> > Could anyone share an update on this?
> >
> >
> > Thanks!
> >
> > Tony
> >
>
> Yes, it was released initially in OVS/OVN 2.12 (if I remember correctly), and 
> there have been more improvements added gradually since then.
> (The "future" part which talks about DDlog is not implemented yet.)
>
> Thanks,
> Han
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] DONATION OFFER

2020-07-23 Thread Steve lenka 
Hello, Donation of 1,000,000.00 GBP given to you by Steve & Lenka Thomson, This 
is to help fight against Corona Virus and help the poor people off the streets. 
send email for more details: stevelenkathomso...@gmail.com
Steve & Lenka Thomson

-- 
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

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

[ovs-dev] Establecer una correcta política de precios

2020-07-23 Thread Cómo ganar en tiempos de crisis 
Buenos día 
Quise aprovechar la oportunidad de hacerte una invitación para tomar nuestro:
 
Nombre: Estrategias de precios para ganar en tiempos de crisis.
Fecha: 05 de Agosto
Horario: 10:00 am a 17:00 pm 
Formato: En línea con interacción en vivo.
Lugar: En Vivo desde su computadora
Instructor: Diana Lira cuenta con más de 10 años de experiencia en fijación de 
precios en diferentes empresas, áreas y mercados.

Fijar los precios adecuados cobra vital importancia sobre todo en épocas en que 
la economía obliga al consumidor a revisar más 
de una vez las opciones que el mercado le ofrece. Establecer una correcta 
política de precios puede tener una repercusión definitiva
en el éxito de la estrategia comercial de la empresa.

Objetivos Específicos:

- Conocerá la importancia de establecer un precio base fundamentado en el valor.
- Aprenderá a generar un árbol de precios basado en la realidad de la empresa y 
del mercado.
- Aprenderá las generalidades de establecer una cultura de pricing dentro de la 
compañía.

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

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

Para información inmediata llamar al:
(+52) 55 15 54 66 30 - (+52) 55 30 16 70 85

o puede enviarnos un Whatsapp. 

Qué tengas un gran día.
Saludos.

Innova Learn México - innovalearn. mx - Mérida, Yucatán, México


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

Re: [ovs-dev] OVN Controller Incremental Processing

2020-07-23 Thread Han Zhou 
On Thu, Jul 23, 2020 at 4:12 PM  wrote:
>
> Thanks Han for the quick confirmation!
> That says, when changes was made into nb-db, ovn-northd doesn't recompile
the whole db, instead, it only updates the increment into sb-db. I am
currently running some scaling test and seeing 100% CPU usage, hence asking.
>
Oh, no. The talk was about "OVN-controller", which is the component running
on hypervisors, to translate SB data into OVS flows, and this has been
implemented (although not all scenarios are incrementally processed). For
ovn-northd, it runs on central node to convert data from NB to SB DB, and
it is not incremental yet with incremental processing, so it is expected to
see 100% CPU. There is currently a work ongoing for ovn-northd incremental
processing, with DDlog, by Ben and Leonid.

> Tony
>
> On Jul 23, 2020 4:02 PM, Han Zhou  wrote:
>
>
>
> On Thu, Jul 23, 2020 at 11:17 AM Tony Liu  wrote:
> >
> > Hi,
> >
> > Is this implemented and released?
> >
https://www.slideshare.net/hanzhou1978/ovn-controller-incremental-processing
> > Could anyone share an update on this?
> >
> >
> > Thanks!
> >
> > Tony
> >
>
> Yes, it was released initially in OVS/OVN 2.12 (if I remember correctly),
and there have been more improvements added gradually since then.
> (The "future" part which talks about DDlog is not implemented yet.)
>
> Thanks,
> Han
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] OVN Controller Incremental Processing

2020-07-23 Thread Han Zhou 
On Thu, Jul 23, 2020 at 11:17 AM Tony Liu  wrote:
>
> Hi,
>
> Is this implemented and released?
>
https://www.slideshare.net/hanzhou1978/ovn-controller-incremental-processing
> Could anyone share an update on this?
>
>
> Thanks!
>
> Tony
>

Yes, it was released initially in OVS/OVN 2.12 (if I remember correctly),
and there have been more improvements added gradually since then.
(The "future" part which talks about DDlog is not implemented yet.)

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

Re: [ovs-dev] [ovs-discuss] OVN nb-db and sb-db out of sync

2020-07-23 Thread Tony Liu 
Hi Numan,

This is how sb-db is brought up.
```
/usr/share/ovn/scripts/ovn-ctl run_sb_ovsdb --db-sb-create-insecure-remote=yes 
--db-sb-addr=10.6.20.84 --db-sb-cluster-local-addr=10.6.20.84  
--db-sock=/run/ovn/ovnsb_db.sock --db-sb-pid=/run/ovn/ovnsb_db.pid 
--db-sb-file=/var/lib/openvswitch/ovn-sb/ovnsb.db 
--ovn-sb-logfile=/var/log/kolla/openvswitch/ovn-sb-db.log
```
The script you pointed to me starts both nb-db and sb-db without 
"run_sb_ovsdb". But I don't think
that really matters. In this case, I assume "ovnsb.db" will be initialized 
properly?

I checked code, that "stale data" is caused by some index mismatch. Any clues?


Thanks!

Tony


From: Numan Siddique 
Sent: July 23, 2020 11:54 AM
To: Tony Liu 
Cc: ovs-dev ; ovs-disc...@openvswitch.org 

Subject: Re: [ovs-discuss] OVN nb-db and sb-db out of sync



On Thu, Jul 23, 2020 at 11:35 PM Tony Liu 
mailto:tonyliu0...@hotmail.com>> wrote:
Hi Numan,

I did each of the followings on all 3 OVN DB nodes.
```
docker stop ovn_sb_db
mv /var/lib/docker/volumes/ovn_sb_db/_data/ovnsb.db 
/var/lib/docker/volumes/ovn_sb_db/_data/ovnsb.db.bak
docker start ovn_sb_db
docker restart ovn_northd
```

I see new DB file is created, but I got complaints from ovn-northd.
```
2020-07-22T23:37:27.274Z|80540|ovsdb_idl|WARN|tcp:10.6.20.84:6642:
 clustered database server has stale data; trying another server
```

Should I use ovsdb-tool to initialize the DB, instead of relying on ovn-sb-db, 
or something else I am missing?

I would suggest to use ovn-ctl for initializing/starting the cluster.

Please take a look at this as an example - 
https://github.com/ovn-org/ovn-fake-multinode/blob/master/ovn_cluster.sh#L337

Thanks
Numan


I also tried to use "ovn-sbctl destroy" to remove the record, but onv-sbctl is 
stuck there forever.


Thanks!

Tony


From: Numan Siddique mailto:num...@ovn.org>>
Sent: July 23, 2020 03:15 AM
To: Tony Liu mailto:tonyliu0...@hotmail.com>>
Cc: ovs-dev mailto:ovs-dev@openvswitch.org>>; 
ovs-disc...@openvswitch.org 
mailto:ovs-disc...@openvswitch.org>>
Subject: Re: [ovs-discuss] OVN nb-db and sb-db out of sync



On Thu, Jul 23, 2020 at 8:22 AM Tony Liu 
mailto:tonyliu0...@hotmail.com>> wrote:
Hi,

I see why sb-db broke at 1568th port-binding.
The 1568th datapath-binding in sb-db references the same

_uuid   : 108cf745-db82-43c0-a9d3-afe27a41e4aa
external_ids: {logical-switch="8a5d1d3c-e9fc-4cbe-a461-98ff838e6473", 
name=neutron-e907dc17-f1e8-4217-a37d-86e9a98c86c2, name2=net-97-192}
tunnel_key  : 1567

_uuid   : d934ed92-2f3c-4b31-8a76-2a5047a3bb46
external_ids: {logical-switch="8a5d1d3c-e9fc-4cbe-a461-98ff838e6473", 
name=neutron-e907dc17-f1e8-4217-a37d-86e9a98c86c2, name2=net-97-192}
tunnel_key  : 1568

I don't believe this is supposed to happen. Any idea how could it happen?
Then ovn-northd is stuck in trying to delete this duplication, and it ignores 
all the following updates.
That caused out-of-sync between nb-db and sb-db.
Any way I can fix it manually, like with ovn-sbctl to delete it?

If you delete the ovn sb db resources manually, ovn-northd should sync it up.

But I'm surprised why ovn-northd didn't sync earlier. There's something wrong 
related to raft going
on here. Not sure what.

Thanks
Numan




Thanks!

Tony


From: dev 
mailto:ovs-dev-boun...@openvswitch.org>> on 
behalf of Tony Liu mailto:tonyliu0...@hotmail.com>>
Sent: July 22, 2020 11:33 AM
To: ovs-dev mailto:ovs-dev@openvswitch.org>>
Subject: [ovs-dev] OVN nb-db and sb-db out of sync

Hi,

During a scaling test where 4000 networks are created from OpenStack, I see that
nb-db and sb-db are out of sync. All 4000 logical switches and 8000 LS ports
(GW port and service port of each network) are created in nb-db. In sb-db,
only 1567 port-bindings, 4000 is expected.

[root@ovn-db-2 ~]# ovn-nbctl list nb_global
_uuid   : b7b3aa05-f7ed-4dbc-979f-10445ac325b8
connections : []
external_ids: {"neutron:liveness_check_at"="2020-07-22 
04:03:17.726917+00:00"}
hv_cfg  : 312
ipsec   : false
name: ""
nb_cfg  : 2636
options : {mac_prefix="ca:e8:07", 
svc_monitor_mac="4e:d0:3a:80:d4:b7"}
sb_cfg  : 2005
ssl : []

[root@ovn-db-2 ~]# ovn-sbctl list sb_global
_uuid   : 3720bc1d-b0da-47ce-85ca-96fa8d398489
connections : []
external_ids: {}
ipsec   : false
nb_cfg  : 312
options : {mac_prefix="ca:e8:07", 
svc_monitor_mac="4e:d0:3a:80:d4:b7"}
ssl : []

Is there any way to force ovn-northd to rebuild sb-db to sync with nb-db,
like manipulating nb_cfg or anything else? Note, it's 3-node RAFT cluster for 
both
nb-db and sb-db.

Is that "incremental update" implemented in 20.03?
If not, in which release

[ovs-dev] NEWS

2020-07-23 Thread UNITED NATIONS DEPARTMENT 
FROM THE OFFICE OF THE UNITED NATIONS DEPARTMENT YOUR COMPENSATION FUND IS NOW 
READY TO BE REFUNDED TO YOU.
 
We bring to your notice that your Email address has been in our database of 
scammed victims for a long time, Due to complains by individuals and 
Governmental agencies, an emergency meeting was held at the United Nation 
building.
You were randomly selected to be compensated, that is why we are in contact 
with you so take your time to read this information carefully.
Series of meetings have been held over the past few months with the secretary 
General of the United Nations, which Ended 7days ago. It is obvious that you 
have not received your funds valued at $1.5 Million US dollars, due to past 
corrupt governmental officials who almost held the funds to them self for their 
selfish reasons.
The United Nations have successfully passed A mandate to boost the Exercise of 
clearing all foreign debts Owed to individuals and organizations, Who have not 
Receive their Funds yet to effect the release of your fund Valued at 
$1.5Million US Dollars, You are advised to contact funds Transfer agent Mr. 
Jude Bakers with The information below, E-MAIL: bakersju...@gmail.com
 
1. Full Name:
2. Contact Address:...
3. Phone:.
4. Date Of Birth:...
5. Marital Status:.
6. Country:...
7. Occupation:.
 
Regards
UNITED NATIONS DEPARTMENT
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v2 3/3] Add ECMP symmetric replies.

2020-07-23 Thread 0-day Robot 
Bleep bloop.  Greetings Mark Michelson, 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 80 characters long (recommended limit is 79)
#229 FILE: northd/ovn-northd.c:7783:
ds_put_format(_reply, "ct.rpl && ct_label.ecmp_reply_port == %" PRId64,

WARNING: Line lacks whitespace around operator
WARNING: Line lacks whitespace around operator
WARNING: Line lacks whitespace around operator
#726 FILE: utilities/ovn-nbctl.c:690:
  [--policy=POLICY] [--ecmp] [--ecmp-symmetric-reply] lr-route-add ROUTER \n\

Lines checked: 769, Warnings: 4, Errors: 0


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

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

[ovs-dev] [PATCH ovn v2 3/3] Add ECMP symmetric replies.

2020-07-23 Thread Mark Michelson 
When traffic arrives over an ECMP route, there is no guarantee that the
reply traffic will egress over the same route. Sometimes, the nature of
the traffic (or the intervening equipment) means that it is important
for reply traffic to go out the same route it came in.

This commit introduces optional ECMP symmetric reply behavior. If
configured, then traffic to or from the ECMP route will be sent to
conntrack. New incoming traffic over the route will have the source MAC
address and incoming port saved in the ct_label. Reply traffic then uses
this saved information to send the packet back out the same way it came
in.

To facilitate this, a new table was added to the ingress logical router
pipeline. The ECMP_STATEFUL table is responsible for committing to
conntrack and setting the ct_label when it detects new incoming traffic
from the route.

Signed-off-by: Mark Michelson 
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1849683
---
 lib/logical-fields.c  |   4 ++
 northd/ovn-northd.8.xml   |  49 ++---
 northd/ovn-northd.c   | 119 +++
 ovn-architecture.7.xml|   7 +-
 ovn-nb.ovsschema  |   5 +-
 ovn-nb.xml|  14 
 tests/ovn.at  |  28 
 tests/system-ovn.at   | 144 ++
 utilities/ovn-nbctl.8.xml |  31 ++--
 utilities/ovn-nbctl.c |  18 -
 10 files changed, 367 insertions(+), 52 deletions(-)

diff --git a/lib/logical-fields.c b/lib/logical-fields.c
index 8639523ea..4c129814d 100644
--- a/lib/logical-fields.c
+++ b/lib/logical-fields.c
@@ -127,6 +127,10 @@ ovn_init_symtab(struct shash *symtab)
 
 expr_symtab_add_field(symtab, "ct_label", MFF_CT_LABEL, NULL, false);
 expr_symtab_add_subfield(symtab, "ct_label.blocked", NULL, "ct_label[0]");
+expr_symtab_add_subfield(symtab, "ct_label.ecmp_reply_eth", NULL,
+ "ct_label[0..47]");
+expr_symtab_add_subfield(symtab, "ct_label.ecmp_reply_port", NULL,
+ "ct_label[48..63]");
 
 expr_symtab_add_field(symtab, "ct_state", MFF_CT_STATE, NULL, false);
 
diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index eb2514f15..cf251e02a 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -2120,15 +2120,31 @@ icmp6 {
 
   This is to send packets to connection tracker for tracking and
   defragmentation.  It contains a priority-0 flow that simply moves traffic
-  to the next table.  If load balancing rules with virtual IP addresses
-  (and ports) are configured in OVN_Northbound database for a
-  Gateway router, a priority-100 flow is added for each configured virtual
-  IP address VIP. For IPv4 VIPs the flow matches
-  ip  ip4.dst == VIP.  For IPv6
-  VIPs, the flow matches ip  ip6.dst ==
-  VIP.  The flow uses the action ct_next;
-  to send IP packets to the connection tracker for packet de-fragmentation
-  and tracking before sending it to the next table.
+  to the next table.
+
+
+
+  If load balancing rules with virtual IP addresses (and ports) are
+  configured in OVN_Northbound database for a Gateway router,
+  a priority-100 flow is added for each configured virtual IP address
+  VIP. For IPv4 VIPs the flow matches ip
+   ip4.dst == VIP.  For IPv6 VIPs,
+  the flow matches ip  ip6.dst == VIP.
+  The flow uses the action ct_next; to send IP packets to the
+  connection tracker for packet de-fragmentation and tracking before
+  sending it to the next table.
+
+
+
+  If ECMP routes with symmetric reply are configured in the
+  OVN_Northbound database for a gateway router, a priority-100
+  flow is added for each router port on which symmetric replies are
+  configured. The matching logic for these ports essentially reverses the
+  configured logic of the ECMP route. So for instance, a route with a
+  destination routing policy will instead match if the source IP address
+  matches the static route's prefix. The flow uses the action
+  ct_next to send IP packets to the connection tracker for
+  packet de-fragmentation and tracking before sending it to the next table.
 
 
 Ingress Table 5: UNSNAT
@@ -2489,7 +2505,15 @@ output;
   table.  This table, instead, is responsible for determine the ECMP
   group id and select a member id within the group based on 5-tuple
   hashing.  It stores group id in reg8[0..15] and member id in
-  reg8[16..31].
+  reg8[16..31]. This step is skipped if the traffic going
+  out the ECMP route is reply traffic, and the ECMP route was configured
+  to use symmetric replies. Instead, the stored ct_label value
+  is used to choose the destination. The least significant 48 bits of the
+  ct_label tell the destination MAC address to which the
+  packet should be sent. The next 16 bits tell the logical router port on
+

[ovs-dev] [PATCH ovn v2 2/3] Use nested actions in ct_commit.

2020-07-23 Thread Mark Michelson 
ct_commit allow for ct_label and ct_mark to be set within. However,
there are some restrictions with the current implementation:

* It is not possible to address the indiviual bits within the ct_mark or
  ct_label.
* It is not possible to set these to the value of a register. Only
  explicit integer setting can be used.

With this change, ct_commit now can have arbitrary nested actions
inside. This makes it similar to how the "exec" option works in OVS's
ct() action.

In this commit, the only noticeable effect is that it allows for
slightly more expressive setting of ct_label.blocked. A future commit
will take further advantage of this.

Signed-off-by: Mark Michelson 
---
 include/ovn/actions.h |   9 +---
 lib/actions.c | 109 +++---
 northd/ovn-northd.c   |   8 ++--
 tests/ovn.at  |  50 +--
 4 files changed, 47 insertions(+), 129 deletions(-)

diff --git a/include/ovn/actions.h b/include/ovn/actions.h
index 0f7f4cdb8..12b7ab0df 100644
--- a/include/ovn/actions.h
+++ b/include/ovn/actions.h
@@ -57,7 +57,7 @@ struct ovn_extend_table;
 OVNACT(EXCHANGE,  ovnact_move)\
 OVNACT(DEC_TTL,   ovnact_null)\
 OVNACT(CT_NEXT,   ovnact_ct_next) \
-OVNACT(CT_COMMIT, ovnact_ct_commit)   \
+OVNACT(CT_COMMIT, ovnact_nest)\
 OVNACT(CT_DNAT,   ovnact_ct_nat)  \
 OVNACT(CT_SNAT,   ovnact_ct_nat)  \
 OVNACT(CT_LB, ovnact_ct_lb)   \
@@ -220,13 +220,6 @@ struct ovnact_ct_next {
 uint8_t ltable;/* Logical table ID of next table. */
 };
 
-/* OVNACT_CT_COMMIT. */
-struct ovnact_ct_commit {
-struct ovnact ovnact;
-uint32_t ct_mark, ct_mark_mask;
-ovs_be128 ct_label, ct_label_mask;
-};
-
 /* OVNACT_CT_DNAT, OVNACT_CT_SNAT. */
 struct ovnact_ct_nat {
 struct ovnact ovnact;
diff --git a/lib/actions.c b/lib/actions.c
index e14907e3d..330fd616b 100644
--- a/lib/actions.c
+++ b/lib/actions.c
@@ -199,6 +199,14 @@ struct action_context {
 
 static void parse_actions(struct action_context *, enum lex_type sentinel);
 
+static void parse_nested_action(struct action_context *ctx,
+enum ovnact_type type,
+const char *prereq);
+
+static void format_nested_action(const struct ovnact_nest *on,
+ const char *name,
+ struct ds *s);
+
 static bool
 action_parse_field(struct action_context *ctx,
int n_bits, bool rw, struct expr_field *f)
@@ -617,125 +625,40 @@ ovnact_ct_next_free(struct ovnact_ct_next *a OVS_UNUSED)
 {
 }
 
-static void
-parse_ct_commit_arg(struct action_context *ctx,
-struct ovnact_ct_commit *cc)
-{
-if (lexer_match_id(ctx->lexer, "ct_mark")) {
-if (!lexer_force_match(ctx->lexer, LEX_T_EQUALS)) {
-return;
-}
-if (ctx->lexer->token.type == LEX_T_INTEGER) {
-cc->ct_mark = ntohll(ctx->lexer->token.value.integer);
-cc->ct_mark_mask = UINT32_MAX;
-} else if (ctx->lexer->token.type == LEX_T_MASKED_INTEGER) {
-cc->ct_mark = ntohll(ctx->lexer->token.value.integer);
-cc->ct_mark_mask = ntohll(ctx->lexer->token.mask.integer);
-} else {
-lexer_syntax_error(ctx->lexer, "expecting integer");
-return;
-}
-lexer_get(ctx->lexer);
-} else if (lexer_match_id(ctx->lexer, "ct_label")) {
-if (!lexer_force_match(ctx->lexer, LEX_T_EQUALS)) {
-return;
-}
-if (ctx->lexer->token.type == LEX_T_INTEGER) {
-cc->ct_label = ctx->lexer->token.value.be128_int;
-cc->ct_label_mask = OVS_BE128_MAX;
-} else if (ctx->lexer->token.type == LEX_T_MASKED_INTEGER) {
-cc->ct_label = ctx->lexer->token.value.be128_int;
-cc->ct_label_mask = ctx->lexer->token.mask.be128_int;
-} else {
-lexer_syntax_error(ctx->lexer, "expecting integer");
-return;
-}
-lexer_get(ctx->lexer);
-} else {
-lexer_syntax_error(ctx->lexer, NULL);
-}
-}
-
 static void
 parse_CT_COMMIT(struct action_context *ctx)
 {
-add_prerequisite(ctx, "ip");
-
-struct ovnact_ct_commit *ct_commit = ovnact_put_CT_COMMIT(ctx->ovnacts);
-if (lexer_match(ctx->lexer, LEX_T_LPAREN)) {
-while (!lexer_match(ctx->lexer, LEX_T_RPAREN)) {
-parse_ct_commit_arg(ctx, ct_commit);
-if (ctx->lexer->error) {
-return;
-}
-lexer_match(ctx->lexer, LEX_T_COMMA);
-}
-}
+parse_nested_action(ctx, OVNACT_CT_COMMIT, "ip");
 }
 
 static void
-format_CT_COMMIT(const struct ovnact_ct_commit *cc, struct ds *s)
+format_CT_COMMIT(const struct ovnact_nest *on, struct ds *s)
 {
-ds_put_cstr(s, "ct_commit(");
-if

[ovs-dev] [PATCH ovn v2 1/3] Add IP address normalization to ovn-utils.

2020-07-23 Thread Mark Michelson 
This moves a couple of existing IP address normalization routines from
ovn-nbctl.c to ovn-util.c. It also adds a new normalization function for
a v46_address. This new function is not used in this commit but will be
used in a future commit in this series.

Signed-off-by: Mark Michelson 
---
 lib/ovn-util.c| 39 +++
 lib/ovn-util.h|  4 
 utilities/ovn-nbctl.c | 29 -
 3 files changed, 43 insertions(+), 29 deletions(-)

diff --git a/lib/ovn-util.c b/lib/ovn-util.c
index f09fdaffe..cdb5e18fb 100644
--- a/lib/ovn-util.c
+++ b/lib/ovn-util.c
@@ -589,6 +589,45 @@ ip46_equals(const struct v46_ip *addr1, const struct 
v46_ip *addr2)
  IN6_ARE_ADDR_EQUAL(>ipv6, >ipv6)));
 }
 
+/* The caller must free the returned string. */
+char *
+normalize_ipv4_prefix(ovs_be32 ipv4, unsigned int plen)
+{
+ovs_be32 network = ipv4 & be32_prefix_mask(plen);
+if (plen == 32) {
+return xasprintf(IP_FMT, IP_ARGS(network));
+} else {
+return xasprintf(IP_FMT "/%d", IP_ARGS(network), plen);
+}
+}
+
+/* The caller must free the returned string. */
+char *
+normalize_ipv6_prefix(struct in6_addr ipv6, unsigned int plen)
+{
+char network_s[INET6_ADDRSTRLEN];
+
+struct in6_addr mask = ipv6_create_mask(plen);
+struct in6_addr network = ipv6_addr_bitand(, );
+
+inet_ntop(AF_INET6, , network_s, INET6_ADDRSTRLEN);
+if (plen == 128) {
+return xasprintf("%s", network_s);
+} else {
+return xasprintf("%s/%d", network_s, plen);
+}
+}
+
+char *
+normalize_v46_prefix(const struct v46_ip *prefix, unsigned int plen)
+{
+if (prefix->family == AF_INET) {
+return normalize_ipv4_prefix(prefix->ipv4, plen);
+} else {
+return normalize_ipv6_prefix(prefix->ipv6, plen);
+}
+}
+
 char *
 str_tolower(const char *orig)
 {
diff --git a/lib/ovn-util.h b/lib/ovn-util.h
index 4e08ee01e..0f7b501f1 100644
--- a/lib/ovn-util.h
+++ b/lib/ovn-util.h
@@ -144,6 +144,10 @@ bool ip46_parse_cidr(const char *str, struct v46_ip 
*prefix,
  unsigned int *plen);
 bool ip46_equals(const struct v46_ip *addr1, const struct v46_ip *addr2);
 
+char *normalize_ipv4_prefix(ovs_be32 ipv4, unsigned int plen);
+char *normalize_ipv6_prefix(struct in6_addr ipv6, unsigned int plen);
+char *normalize_v46_prefix(const struct v46_ip *prefix, unsigned int plen);
+
 /* Returns a lowercase copy of orig.
  * Caller must free the returned string.
  */
diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
index 7578b9928..0079ad5a6 100644
--- a/utilities/ovn-nbctl.c
+++ b/utilities/ovn-nbctl.c
@@ -3482,35 +3482,6 @@ nbctl_dhcp_options_list(struct ctl_context *ctx)
 free(nodes);
 }
 
-/* The caller must free the returned string. */
-static char *
-normalize_ipv4_prefix(ovs_be32 ipv4, unsigned int plen)
-{
-ovs_be32 network = ipv4 & be32_prefix_mask(plen);
-if (plen == 32) {
-return xasprintf(IP_FMT, IP_ARGS(network));
-} else {
-return xasprintf(IP_FMT"/%d", IP_ARGS(network), plen);
-}
-}
-
-/* The caller must free the returned string. */
-static char *
-normalize_ipv6_prefix(struct in6_addr ipv6, unsigned int plen)
-{
-char network_s[INET6_ADDRSTRLEN];
-
-struct in6_addr mask = ipv6_create_mask(plen);
-struct in6_addr network = ipv6_addr_bitand(, );
-
-inet_ntop(AF_INET6, , network_s, INET6_ADDRSTRLEN);
-if (plen == 128) {
-return xasprintf("%s", network_s);
-} else {
-return xasprintf("%s/%d", network_s, plen);
-}
-}
-
 static char *
 normalize_ipv4_prefix_str(const char *orig_prefix)
 {
-- 
2.25.4

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

Re: [ovs-dev] (no subject)

2020-07-23 Thread Steve & Lenka Thomson 
We are pleased to inform you that an amount of 1,,000.00 (GBP) has been 
donated and given to you and your family by  Steve & Lenka Thomson 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [ovs-discuss] OVN nb-db and sb-db out of sync

2020-07-23 Thread Numan Siddique 
On Thu, Jul 23, 2020 at 11:35 PM Tony Liu  wrote:

> Hi Numan,
>
> I did each of the followings on all 3 OVN DB nodes.
> ```
> docker stop ovn_sb_db
> mv /var/lib/docker/volumes/ovn_sb_db/_data/ovnsb.db
> /var/lib/docker/volumes/ovn_sb_db/_data/ovnsb.db.bak
> docker start ovn_sb_db
> docker restart ovn_northd
> ```
>
> I see new DB file is created, but I got complaints from ovn-northd.
> ```
> 2020-07-22T23:37:27.274Z|80540|ovsdb_idl|WARN|tcp:10.6.20.84:6642:
> clustered database server has stale data; trying another server
> ```
>
> Should I use ovsdb-tool to initialize the DB, instead of relying on
> ovn-sb-db, or something else I am missing?
>

I would suggest to use ovn-ctl for initializing/starting the cluster.

Please take a look at this as an example -
https://github.com/ovn-org/ovn-fake-multinode/blob/master/ovn_cluster.sh#L337

Thanks
Numan


>
> I also tried to use "ovn-sbctl destroy" to remove the record, but
> onv-sbctl is stuck there forever.
>
>
> Thanks!
>
> Tony
>
> --
> *From:* Numan Siddique 
> *Sent:* July 23, 2020 03:15 AM
> *To:* Tony Liu 
> *Cc:* ovs-dev ; ovs-disc...@openvswitch.org <
> ovs-disc...@openvswitch.org>
> *Subject:* Re: [ovs-discuss] OVN nb-db and sb-db out of sync
>
>
>
> On Thu, Jul 23, 2020 at 8:22 AM Tony Liu  wrote:
>
> Hi,
>
> I see why sb-db broke at 1568th port-binding.
> The 1568th datapath-binding in sb-db references the same
>
> _uuid   : 108cf745-db82-43c0-a9d3-afe27a41e4aa
> external_ids:
> {logical-switch="8a5d1d3c-e9fc-4cbe-a461-98ff838e6473",
> name=neutron-e907dc17-f1e8-4217-a37d-86e9a98c86c2, name2=net-97-192}
> tunnel_key  : 1567
>
> _uuid   : d934ed92-2f3c-4b31-8a76-2a5047a3bb46
> external_ids:
> {logical-switch="8a5d1d3c-e9fc-4cbe-a461-98ff838e6473",
> name=neutron-e907dc17-f1e8-4217-a37d-86e9a98c86c2, name2=net-97-192}
> tunnel_key  : 1568
>
> I don't believe this is supposed to happen. Any idea how could it happen?
> Then ovn-northd is stuck in trying to delete this duplication, and it
> ignores all the following updates.
> That caused out-of-sync between nb-db and sb-db.
> Any way I can fix it manually, like with ovn-sbctl to delete it?
>
>
> If you delete the ovn sb db resources manually, ovn-northd should sync it
> up.
>
> But I'm surprised why ovn-northd didn't sync earlier. There's something
> wrong related to raft going
> on here. Not sure what.
>
> Thanks
> Numan
>
>
>
>
> Thanks!
>
> Tony
>
> --
> *From:* dev  on behalf of Tony Liu <
> tonyliu0...@hotmail.com>
> *Sent:* July 22, 2020 11:33 AM
> *To:* ovs-dev 
> *Subject:* [ovs-dev] OVN nb-db and sb-db out of sync
>
> Hi,
>
> During a scaling test where 4000 networks are created from OpenStack, I
> see that
> nb-db and sb-db are out of sync. All 4000 logical switches and 8000 LS
> ports
> (GW port and service port of each network) are created in nb-db. In sb-db,
> only 1567 port-bindings, 4000 is expected.
>
> [root@ovn-db-2 ~]# ovn-nbctl list nb_global
> _uuid   : b7b3aa05-f7ed-4dbc-979f-10445ac325b8
> connections : []
> external_ids: {"neutron:liveness_check_at"="2020-07-22
> 04:03:17.726917+00:00"}
> hv_cfg  : 312
> ipsec   : false
> name: ""
> nb_cfg  : 2636
> options : {mac_prefix="ca:e8:07",
> svc_monitor_mac="4e:d0:3a:80:d4:b7"}
> sb_cfg  : 2005
> ssl : []
>
> [root@ovn-db-2 ~]# ovn-sbctl list sb_global
> _uuid   : 3720bc1d-b0da-47ce-85ca-96fa8d398489
> connections : []
> external_ids: {}
> ipsec   : false
> nb_cfg  : 312
> options : {mac_prefix="ca:e8:07",
> svc_monitor_mac="4e:d0:3a:80:d4:b7"}
> ssl : []
>
> Is there any way to force ovn-northd to rebuild sb-db to sync with nb-db,
> like manipulating nb_cfg or anything else? Note, it's 3-node RAFT cluster
> for both
> nb-db and sb-db.
>
> Is that "incremental update" implemented in 20.03?
> If not, in which release it's going to be available?
>
>
> Thanks!
>
> Tony
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCHv2] python: fixed package dependency

2020-07-23 Thread Ilya Maximets 
On 7/23/20 6:40 PM, Gregory Rose wrote:
> 
> 
> On 7/23/2020 7:36 AM, William Tu wrote:
>> On Wed, Jul 22, 2020 at 3:22 PM Gregory Rose  wrote:
>>>
>>>
>>> On 7/22/2020 2:25 PM, Toms Atteka wrote:
 Python3 does not have python3-twisted-web. Required codebase is inside
 python3-twisted.


Fixes: 1ca0323e7c29 ("Require Python 3 and remove support for Python 2.")

 Signed-off-by: Toms Atteka 
 ---
    debian/control | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/debian/control b/debian/control
 index 0646b22a1..6420b9d3e 100644
 --- a/debian/control
 +++ b/debian/control
 @@ -188,7 +188,7 @@ Description: Python bindings for Open vSwitch
    Package: openvswitch-test
>>
>> We have some offline discussions on this.
>> Do you want to remove the openvswitch-test package entirely since
>> probably no one is using it?
> 
> Sounds like a good idea to me.

While this might be a good idea to remove package entirely, I'm not
sure if we can do that for already released branches.  We likely
need this fix as is for branches 2.13 and 2.14.

What do you think?

> 
> - Greg
> 
>>
>> William
>>
    Architecture: all
    Depends: python3,
 - python3-twisted-web,
 + python3-twisted,
     ${misc:Depends},
     ${python3:Depends}
    Description: Open vSwitch test package

>>>
>>> LGTM
>>> Acked-by: Greg Rose 
>>> ___
>>> 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
> 

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

[ovs-dev] OVN Controller Incremental Processing

2020-07-23 Thread Tony Liu 
Hi,

Is this implemented and released?
https://www.slideshare.net/hanzhou1978/ovn-controller-incremental-processing
Could anyone share an update on this?


Thanks!

Tony

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

Re: [ovs-dev] [ovs-discuss] OVN nb-db and sb-db out of sync

2020-07-23 Thread Tony Liu 
Hi Numan,

I did each of the followings on all 3 OVN DB nodes.
```
docker stop ovn_sb_db
mv /var/lib/docker/volumes/ovn_sb_db/_data/ovnsb.db 
/var/lib/docker/volumes/ovn_sb_db/_data/ovnsb.db.bak
docker start ovn_sb_db
docker restart ovn_northd
```

I see new DB file is created, but I got complaints from ovn-northd.
```
2020-07-22T23:37:27.274Z|80540|ovsdb_idl|WARN|tcp:10.6.20.84:6642: clustered 
database server has stale data; trying another server
```

Should I use ovsdb-tool to initialize the DB, instead of relying on ovn-sb-db, 
or something else I am missing?

I also tried to use "ovn-sbctl destroy" to remove the record, but onv-sbctl is 
stuck there forever.


Thanks!

Tony


From: Numan Siddique 
Sent: July 23, 2020 03:15 AM
To: Tony Liu 
Cc: ovs-dev ; ovs-disc...@openvswitch.org 

Subject: Re: [ovs-discuss] OVN nb-db and sb-db out of sync



On Thu, Jul 23, 2020 at 8:22 AM Tony Liu 
mailto:tonyliu0...@hotmail.com>> wrote:
Hi,

I see why sb-db broke at 1568th port-binding.
The 1568th datapath-binding in sb-db references the same

_uuid   : 108cf745-db82-43c0-a9d3-afe27a41e4aa
external_ids: {logical-switch="8a5d1d3c-e9fc-4cbe-a461-98ff838e6473", 
name=neutron-e907dc17-f1e8-4217-a37d-86e9a98c86c2, name2=net-97-192}
tunnel_key  : 1567

_uuid   : d934ed92-2f3c-4b31-8a76-2a5047a3bb46
external_ids: {logical-switch="8a5d1d3c-e9fc-4cbe-a461-98ff838e6473", 
name=neutron-e907dc17-f1e8-4217-a37d-86e9a98c86c2, name2=net-97-192}
tunnel_key  : 1568

I don't believe this is supposed to happen. Any idea how could it happen?
Then ovn-northd is stuck in trying to delete this duplication, and it ignores 
all the following updates.
That caused out-of-sync between nb-db and sb-db.
Any way I can fix it manually, like with ovn-sbctl to delete it?

If you delete the ovn sb db resources manually, ovn-northd should sync it up.

But I'm surprised why ovn-northd didn't sync earlier. There's something wrong 
related to raft going
on here. Not sure what.

Thanks
Numan




Thanks!

Tony


From: dev 
mailto:ovs-dev-boun...@openvswitch.org>> on 
behalf of Tony Liu mailto:tonyliu0...@hotmail.com>>
Sent: July 22, 2020 11:33 AM
To: ovs-dev mailto:ovs-dev@openvswitch.org>>
Subject: [ovs-dev] OVN nb-db and sb-db out of sync

Hi,

During a scaling test where 4000 networks are created from OpenStack, I see that
nb-db and sb-db are out of sync. All 4000 logical switches and 8000 LS ports
(GW port and service port of each network) are created in nb-db. In sb-db,
only 1567 port-bindings, 4000 is expected.

[root@ovn-db-2 ~]# ovn-nbctl list nb_global
_uuid   : b7b3aa05-f7ed-4dbc-979f-10445ac325b8
connections : []
external_ids: {"neutron:liveness_check_at"="2020-07-22 
04:03:17.726917+00:00"}
hv_cfg  : 312
ipsec   : false
name: ""
nb_cfg  : 2636
options : {mac_prefix="ca:e8:07", 
svc_monitor_mac="4e:d0:3a:80:d4:b7"}
sb_cfg  : 2005
ssl : []

[root@ovn-db-2 ~]# ovn-sbctl list sb_global
_uuid   : 3720bc1d-b0da-47ce-85ca-96fa8d398489
connections : []
external_ids: {}
ipsec   : false
nb_cfg  : 312
options : {mac_prefix="ca:e8:07", 
svc_monitor_mac="4e:d0:3a:80:d4:b7"}
ssl : []

Is there any way to force ovn-northd to rebuild sb-db to sync with nb-db,
like manipulating nb_cfg or anything else? Note, it's 3-node RAFT cluster for 
both
nb-db and sb-db.

Is that "incremental update" implemented in 20.03?
If not, in which release it's going to be available?


Thanks!

Tony

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

[ovs-dev] OVN Meeting Logs 23 July, 2020

2020-07-23 Thread mmichels 
Here is the IRC log for the OVN meeting for 23 July, 2020

http://eavesdrop.openstack.org/meetings//ovn_community_development_discussion/2020/ovn_community_development_discussion.2020-07-23-17.22.log.html

If you are interested in attending this meeting, it happens every
Thursday in the #openvswitch channel on the Freenode IRC server. The
next one is at 13:15 EDT (18:15 BST, 10:15 PDT) on 30 July, 2020.

Mark Michelson

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

[ovs-dev] Oil Contract

2020-07-23 Thread info 
Saudi Aramco Crude Oil Company.
P.O. Box 5000. Dhahran 31311,
Dhahran-Saudi Arabia.

Hello,

I have a legit and genuine lucrative business deal to discuss with you.
Can i trust you to be a sincere partner to handle the business?
For more information reply back.

Regards,

Mrs.Reem Nasser,
Sales/Marketing Manager
Saudi Aramco Crude Oil Company
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] OVN: Two datapath-bindings are created for the same logical-switch

2020-07-23 Thread Tony Liu 
Changed the title for this specific problem.
I looked into logs and have more findings.
The problem was happening when sb-db leader switched.

For ovsdb cluster, what may trigger the leader switch? Given the log,
2020-07-21T01:08:38.119Z|00074|raft|INFO|term 2: 1135 ms timeout expired, 
starting election
The election is asked by a follower node. Is that because the connection from 
follower to leader timeout,
then follower assumes the leader is dead and starts an election?

For ovn-northd (3 instances), they all connect to the sb-db leader, whoever has 
the locker is the master.
When sb-db leader switches, all ovn-northd instances look for the new leader. 
In this case, there is no
guarantee that the old ovn-northd master remains the role, other ovn-northd 
instance may find the
leader and acquire the lock first. So, the sb-db leader switch may also cause 
ovn-northd master switch.
Such switch may happen in the middle of ovn-northd transaction, in that case, 
is there any guarantee to
the transaction completeness? My guess is that, the older created a 
datapath-binding for a logical-switch,
switch happened when this transaction is not completed, then the new 
master/leader created another
data-path binding for the same logical-switch. Does it make any sense?

>From the log, when sb-db switched, ovn-northd master connected to the new 
>leader and lost the master,
but immediately, it acquired the lock and become master again. Not sure how 
this happened.

Here are some loggings.
 .84 sb-db leader =
2020-07-21T01:08:20.221Z|01408|raft|INFO|current entry eid 
639238ba-bc00-4efe-bb66-6ac766bb5f4b does not match prerequisite 
78e8e167-8b4c-4292-8e25-d9975631b010 in execute_command_request

2020-07-21T01:08:38.450Z|01409|timeval|WARN|Unreasonably long 1435ms poll 
interval (1135ms user, 43ms system)
2020-07-21T01:08:38.451Z|01410|timeval|WARN|faults: 5942 minor, 0 major
2020-07-21T01:08:38.451Z|01411|timeval|WARN|disk: 0 reads, 50216 writes
2020-07-21T01:08:38.452Z|01412|timeval|WARN|context switches: 60 voluntary, 25 
involuntary
2020-07-21T01:08:38.453Z|01413|coverage|INFO|Skipping details of duplicate 
event coverage for hash=45329980

2020-07-21T01:08:38.455Z|01414|raft|WARN|ignoring vote request received as 
leader
2020-07-21T01:08:38.456Z|01415|raft|INFO|server 1f9e is leader for term 2
2020-07-21T01:08:38.457Z|01416|raft|INFO|rejected append_reply (not leader)
2020-07-21T01:08:38.471Z|01417|raft|INFO|rejected append_reply (not leader)

2020-07-21T01:23:00.890Z|01418|timeval|WARN|Unreasonably long 1336ms poll 
interval (1102ms user, 20ms system)

 .85 sb-db ==
2020-07-21T01:05:25.734Z|00061|coverage|INFO|Skipping details of duplicate 
event coverage for hash=a1e16f5b

2020-07-21T01:08:38.166Z|00062|raft|INFO|server 1f9e is leader for term 2
2020-07-21T01:08:38.455Z|00063|raft|INFO|rejecting term 1 < current term 2 
received in append_request message from server 39a9

2020-07-21T01:23:44.500Z|00064|timeval|WARN|Unreasonably long 1447ms poll 
interval (1118ms user, 33ms system)

 .86 sb-db =
2020-07-21T01:02:35.607Z|00073|coverage|INFO|70 events never hit

2020-07-21T01:08:38.119Z|00074|raft|INFO|term 2: 1135 ms timeout expired, 
starting election
2020-07-21T01:08:38.165Z|00075|raft|INFO|term 2: elected leader by 2+ of 3 
servers
2020-07-21T01:08:38.455Z|00076|raft|INFO|rejecting term 1 < current term 2 
received in append_request message from server 39a9
2020-07-21T01:08:38.456Z|00077|raft|INFO|rejecting term 1 < current term 2 
received in vote_reply message from server 39a9

2020-07-21T01:12:51.363Z|00078|timeval|WARN|Unreasonably long 1466ms poll 
interval (1186ms user, 27ms system)

 .85 ovn-northd master ==
2020-07-21T01:08:25.925Z|00479|poll_loop|INFO|wakeup due to [POLLIN] on fd 8 
(10.6.20.85:45478<->10.6.20.84:6641) at lib/stream-fd.c:157 (54% CPU usage)

2020-07-21T01:08:38.464Z|00480|ovsdb_idl|INFO|tcp:10.6.20.84:6642: clustered 
database server is not cluster leader; trying another server
2020-07-21T01:08:38.465Z|00481|reconnect|INFO|tcp:10.6.20.84:6642: connection 
attempt timed out
2020-07-21T01:08:38.465Z|00482|reconnect|INFO|tcp:10.6.20.86:6642: connecting...
2020-07-21T01:08:38.465Z|00483|reconnect|INFO|tcp:10.6.20.86:6642: connected
2020-07-21T01:08:38.465Z|00484|ovn_northd|INFO|ovn-northd lock lost. This 
ovn-northd instance is now on standby.
2020-07-21T01:08:38.465Z|00485|ovn_northd|INFO|ovn-northd lock acquired. This 
ovn-northd instance is now active.
2020-07-21T01:08:38.966Z|00486|ovn_northd|INFO|deleting Datapath_Binding 
108cf745-db82-43c0-a9d3-afe27a41e4aa with duplicate 
external-ids:logical-switch/router 8a5d1d3c-e9fc-4cbe-a461-98ff838e6473

2020-07-20T21:32:48.803Z|00019|reconnect|INFO|tcp:10.6.20.84:6641: connected

 .86 ovn-northd ==
2020-07-21T01:08:38.463Z|00020|ovsdb_idl|INFO|tcp:10.6.20.84:6642: clustered 
database server is not cluster leader; trying another server

Re: [ovs-dev] [PATCH] dpif-netdev.at: Wait for miss upcall log.

2020-07-23 Thread William Tu 
On Thu, Jul 23, 2020 at 8:17 AM Ilya Maximets  wrote:
>
> Some tests checks for 'miss upcall' log in a log file immediately
> after sending the packet, this causes test failures while running
> them under valgrind or on the overloaded system.
>
> Fix that by waiting for appearance of the actual string in the log
> file.  Some other tests uses 'sleep 1' to fix that, but it's better
> to wait for event than sleep for a specific amount of time.
>
> Signed-off-by: Ilya Maximets 
> ---

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

Re: [ovs-dev] [PATCH net-next v2 2/2] net: openvswitch: make masks cache size configurable

2020-07-23 Thread Jakub Kicinski 
On Thu, 23 Jul 2020 14:58:31 +0200 Eelco Chaudron wrote:
> + if ((size & (size - 1)) != 0 ||

is_power_of_2() ?

> + (size * sizeof(struct mask_cache_entry)) > PCPU_MIN_UNIT_SIZE)
> + return NULL;

> + new->cache_size = size;
> + if (new->cache_size > 0) {
> + cache = __alloc_percpu(sizeof(struct mask_cache_entry) *
> +new->cache_size,

array_size() ?

> +__alignof__(struct mask_cache_entry));
> +

No need for the new line here

> + if (!cache) {
> + kfree(new);
> + return NULL;
> + }
> + }

> + if (size == mc->cache_size || (size & (size - 1)) != 0)

why check "is power of 2" twice?

> @@ -454,7 +516,7 @@ void ovs_flow_tbl_destroy(struct flow_table *table)
>   struct table_instance *ti = rcu_dereference_raw(table->ti);
>   struct table_instance *ufid_ti = rcu_dereference_raw(table->ufid_ti);
>  
> - free_percpu(table->mask_cache);
> + call_rcu(>mask_cache->rcu, mask_cache_rcu_cb);
>   call_rcu(>mask_array->rcu, mask_array_rcu_cb);
>   table_instance_destroy(table, ti, ufid_ti, false);
>  }

This adds a new warning :(

net/openvswitch/flow_table.c:519:24: warning: incorrect type in argument 1 
(different address spaces)
net/openvswitch/flow_table.c:519:24:expected struct callback_head *head
net/openvswitch/flow_table.c:519:24:got struct callback_head [noderef] 
__rcu *
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCHv2] python: fixed package dependency

2020-07-23 Thread Gregory Rose 




On 7/23/2020 7:36 AM, William Tu wrote:

On Wed, Jul 22, 2020 at 3:22 PM Gregory Rose  wrote:



On 7/22/2020 2:25 PM, Toms Atteka wrote:

Python3 does not have python3-twisted-web. Required codebase is inside
python3-twisted.

Signed-off-by: Toms Atteka 
---
   debian/control | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 0646b22a1..6420b9d3e 100644
--- a/debian/control
+++ b/debian/control
@@ -188,7 +188,7 @@ Description: Python bindings for Open vSwitch
   Package: openvswitch-test


We have some offline discussions on this.
Do you want to remove the openvswitch-test package entirely since
probably no one is using it?


Sounds like a good idea to me.

- Greg



William


   Architecture: all
   Depends: python3,
- python3-twisted-web,
+ python3-twisted,
${misc:Depends},
${python3:Depends}
   Description: Open vSwitch test package



LGTM
Acked-by: Greg Rose 
___
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

[ovs-dev] [PATCH] tests: Refactor the iptables accept rule.

2020-07-23 Thread William Tu 
Certain Linux distributions, like CentOS, have default iptable
rules to reject input traffic from br-underlay.  Refactor by
creating a macro 'IPTABLES_ACCEPT([bridge])' for adding the
accept rule to the iptable input chain.

Signed-off-by: William Tu 
---
 tests/ovs-macros.at |  7 +++
 tests/system-traffic.at | 12 ++--
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
index fee50901543e..b1f666f4e83f 100644
--- a/tests/ovs-macros.at
+++ b/tests/ovs-macros.at
@@ -333,3 +333,10 @@ m4_ifndef([AT_FAIL_IF],
   [m4_define([AT_FAIL_IF],
 [AT_CHECK([($1) \
 && exit 99 || exit 0], [0], [ignore], [ignore])])])
+
+dnl Certain Linux distributions, like CentOS, have default iptable rules
+dnl to reject input traffic from bridges such as br-underlay.
+dnl Add a rule to always accept the traffic.
+m4_define([IPTABLES_ACCEPT],
+  [AT_CHECK([iptables -I INPUT 1 -i $1 -j ACCEPT])
+   on_exit 'iptables -D INPUT 1 -i $1'])
diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index 2a0fbadff4a1..02f0e2716320 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -688,11 +688,7 @@ AT_CHECK([ip link set dev br-underlay up])
 dnl Set up tunnel endpoints on OVS outside the namespace.
 ADD_OVS_TUNNEL([gre], [br0], [at_gre0], [172.31.1.1], [10.1.1.100/24])
 
-dnl Certain Linux distributions, like CentOS, have default iptable rules
-dnl to reject input traffic from br-underlay. Here we add a rule to walk
-dnl around it.
-iptables -I INPUT 1 -i br-underlay -j ACCEPT
-on_exit 'iptables -D INPUT 1'
+IPTABLES_ACCEPT([br-underlay])
 
 ip netns exec at_ns0 tcpdump -n -i p0 dst host 172.31.1.1 -l > p0.pcap &
 sleep 1
@@ -739,11 +735,7 @@ dnl Set up tunnel endpoints on OVS outside the namespace 
and emulate a native
 dnl linux device inside the namespace.
 ADD_OVS_TUNNEL([erspan], [br0], [at_erspan0], [172.31.1.1], [10.1.1.100/24], 
[options:key=1 options:erspan_ver=1 options:erspan_idx=7])
 
-dnl Certain Linux distributions, like CentOS, have default iptable rules
-dnl to reject input traffic from br-underlay. Here we add a rule to walk
-dnl around it.
-iptables -I INPUT 1 -i br-underlay -j ACCEPT
-on_exit 'iptables -D INPUT 1'
+IPTABLES_ACCEPT([br-underlay])
 
 ip netns exec at_ns0 tcpdump -n -x -i p0 dst host 172.31.1.1 -l > p0.pcap &
 sleep 1
-- 
2.7.4

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

Re: [ovs-dev] [PATCH v4] bfd: Support overlay BFD

2020-07-23 Thread Yifeng Sun 
Confirmed that the setup is quite unstable. Sometimes bfd flow shows up in
datapath-flows.txt but sometimes not.
Let me take a look.

Thanks,
Yifeng

On Thu, Jul 23, 2020 at 6:51 AM William Tu  wrote:

> On Wed, Jul 22, 2020 at 1:41 PM Yifeng Sun  wrote:
> >
> > Current OVS intercepts and processes all BFD packets, thus VM-2-VM
> > BFD packets get lost and the recipient VM never sees them.
> >
> > This patch fixes it by only intercepting and processing BFD packets
> > destined to a configured BFD instance, and other BFD packets are made
> > available to the OVS flow table for forwarding.
> >
> > This patch keeps BFD's backward compatibility.
> >
> > VMWare-BZ: 2579326
> s/VMWare/VMware
> s/2579326/#2579326/
>
> > Signed-off-by: Yifeng Sun 
> > ---
> > v1->v2: Add test by William's suggestion.
> > v2->v3: Fix BFD config, thanks William.
> > v3->v4: Test will fail at second run, fixed it.
> >
> >  lib/bfd.c   | 16 +---
> >  tests/system-traffic.at | 44
> 
> >  vswitchd/vswitch.xml|  7 +++
> >  3 files changed, 64 insertions(+), 3 deletions(-)
> >
> > diff --git a/lib/bfd.c b/lib/bfd.c
> > index cc8c6857afa4..3c965699ace3 100644
> > --- a/lib/bfd.c
> > +++ b/lib/bfd.c
> > @@ -149,6 +149,9 @@ BUILD_ASSERT_DECL(BFD_PACKET_LEN == sizeof(struct
> msg));
> >  #define FLAGS_MASK 0x3f
> >  #define DEFAULT_MULT 3
> >
> > +#define BFD_DEFAULT_SRC_IP 0xA9FE0101 /* 169.254.1.1 */
> > +#define BFD_DEFAULT_DST_IP 0xA9FE0100 /* 169.254.1.0 */
> > +
> >  struct bfd {
> >  struct hmap_node node;/* In 'all_bfds'. */
> >  uint32_t disc;/* bfd.LocalDiscr. Key in 'all_bfds'
> hmap. */
> > @@ -457,9 +460,9 @@ bfd_configure(struct bfd *bfd, const char *name,
> const struct smap *cfg,
> >   >rmt_eth_dst);
> >
> >  bfd_lookup_ip(smap_get_def(cfg, "bfd_src_ip", ""),
> > -  htonl(0xA9FE0101) /* 169.254.1.1 */, >ip_src);
> > +  htonl(BFD_DEFAULT_SRC_IP), >ip_src);
> >  bfd_lookup_ip(smap_get_def(cfg, "bfd_dst_ip", ""),
> > -  htonl(0xA9FE0100) /* 169.254.1.0 */, >ip_dst);
> > +  htonl(BFD_DEFAULT_DST_IP), >ip_dst);
> >
> >  forwarding_if_rx = smap_get_bool(cfg, "forwarding_if_rx", false);
> >  if (bfd->forwarding_if_rx != forwarding_if_rx) {
> > @@ -674,7 +677,14 @@ bfd_should_process_flow(const struct bfd *bfd_,
> const struct flow *flow,
> >  memset(>masks.nw_proto, 0xff, sizeof wc->masks.nw_proto);
> >  if (flow->nw_proto == IPPROTO_UDP
> >  && !(flow->nw_frag & FLOW_NW_FRAG_LATER)
> > -&& tp_dst_equals(flow, BFD_DEST_PORT, wc)) {
> > +&& tp_dst_equals(flow, BFD_DEST_PORT, wc)
> > +&& (bfd->ip_src == htonl(BFD_DEFAULT_SRC_IP)
> > +|| bfd->ip_src == flow->nw_dst)) {
> > +
> > +if (bfd->ip_src == flow->nw_dst) {
> > +memset(>masks.nw_dst, 0x, sizeof
> wc->masks.nw_dst);
> > +}
> > +
> >  bool check_tnl_key;
> >
> >  atomic_read_relaxed(>check_tnl_key, _tnl_key);
> > diff --git a/tests/system-traffic.at b/tests/system-traffic.at
> > index 2a0fbadff4a1..ea72f155782f 100644
> > --- a/tests/system-traffic.at
> > +++ b/tests/system-traffic.at
> > @@ -6289,3 +6289,47 @@ OVS_WAIT_UNTIL([cat p2.pcap | egrep "0x0050:
> * * *5002 *2000 *b85e *
> >
> >  OVS_TRAFFIC_VSWITCHD_STOP
> >  AT_CLEANUP
> > +
> > +AT_SETUP([bfd - BFD overlay])
> > +OVS_CHECK_GENEVE()
> > +
> > +OVS_TRAFFIC_VSWITCHD_START()
> > +
> > +AT_CHECK([ovs-vsctl -- set bridge br0
> other-config:hwaddr=\"f2:ff:00:00:00:01\"])
> > +ADD_BR([br-underlay], [set bridge br-underlay
> other-config:hwaddr=\"ee:09:e0:4d:bf:31\"])
> > +
> > +AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"])
> > +AT_CHECK([ovs-ofctl add-flow br-underlay "actions=normal"])
> > +
> > +ADD_NAMESPACES(at_ns0)
> > +
> > +dnl Set up underlay link from host into the namespace using veth pair.
> > +ADD_VETH(p0, at_ns0, br-underlay, "172.16.180.105/24",
> 4e:12:5d:6c:74:3d)
> > +AT_CHECK([ip addr add dev br-underlay "172.16.180.106/24"])
> > +AT_CHECK([ip link set dev br-underlay up])
> > +
> > +dnl Set up tunnel endpoints on OVS outside the namespace.
> > +ADD_OVS_TUNNEL([geneve], [br0], [at_gnv0], [172.16.180.105], [
> 192.168.10.100/24],
> > +[options:packet_type=ptap])
> > +AT_CHECK([ovs-vsctl -- set Interface at_gnv0 ofport_request=1])
> > +AT_CHECK([ovs-vsctl -- set Interface at_gnv0 bfd:enable=true
> bfd:bfd_src_ip="172.16.180.106"])
> > +
> > +dnl Certain Linux distributions, like CentOS, have default iptable rules
> > +dnl to reject input traffic from br-underlay. Here we add a rule to walk
> > +dnl around it.
> > +iptables -I INPUT 1 -i br-underlay -j ACCEPT
> > +on_exit 'iptables -D INPUT 1'
> > +
> > +dnl Firstly, test normal BFD packet.
> > +ovs-ofctl -O OpenFlow13 packet-out br-underlay "in_port=1
>

Re: [ovs-dev] [PATCH ovn 1/3] Add IP address normalization to ovn-utils.

2020-07-23 Thread Numan Siddique 
On Tue, Jul 21, 2020 at 2:28 AM Mark Michelson  wrote:

> This moves a couple of existing IP address normalization routines from
> ovn-nbctl.c to ovn-util.c. It also adds a new normalization function for
> a v46_address. This new function is not used in this commit but will be
> used in a future commit in this series.
>
> Signed-off-by: Mark Michelson 
>

Acked-by: Numan Siddique 

Thanks
Numan


> ---
>  lib/ovn-util.c| 39 +++
>  lib/ovn-util.h|  4 
>  utilities/ovn-nbctl.c | 29 -
>  3 files changed, 43 insertions(+), 29 deletions(-)
>
> diff --git a/lib/ovn-util.c b/lib/ovn-util.c
> index f09fdaffe..cdb5e18fb 100644
> --- a/lib/ovn-util.c
> +++ b/lib/ovn-util.c
> @@ -589,6 +589,45 @@ ip46_equals(const struct v46_ip *addr1, const struct
> v46_ip *addr2)
>   IN6_ARE_ADDR_EQUAL(>ipv6, >ipv6)));
>  }
>
> +/* The caller must free the returned string. */
> +char *
> +normalize_ipv4_prefix(ovs_be32 ipv4, unsigned int plen)
> +{
> +ovs_be32 network = ipv4 & be32_prefix_mask(plen);
> +if (plen == 32) {
> +return xasprintf(IP_FMT, IP_ARGS(network));
> +} else {
> +return xasprintf(IP_FMT "/%d", IP_ARGS(network), plen);
> +}
> +}
> +
> +/* The caller must free the returned string. */
> +char *
> +normalize_ipv6_prefix(struct in6_addr ipv6, unsigned int plen)
> +{
> +char network_s[INET6_ADDRSTRLEN];
> +
> +struct in6_addr mask = ipv6_create_mask(plen);
> +struct in6_addr network = ipv6_addr_bitand(, );
> +
> +inet_ntop(AF_INET6, , network_s, INET6_ADDRSTRLEN);
> +if (plen == 128) {
> +return xasprintf("%s", network_s);
> +} else {
> +return xasprintf("%s/%d", network_s, plen);
> +}
> +}
> +
> +char *
> +normalize_v46_prefix(const struct v46_ip *prefix, unsigned int plen)
> +{
> +if (prefix->family == AF_INET) {
> +return normalize_ipv4_prefix(prefix->ipv4, plen);
> +} else {
> +return normalize_ipv6_prefix(prefix->ipv6, plen);
> +}
> +}
> +
>  char *
>  str_tolower(const char *orig)
>  {
> diff --git a/lib/ovn-util.h b/lib/ovn-util.h
> index 4e08ee01e..0f7b501f1 100644
> --- a/lib/ovn-util.h
> +++ b/lib/ovn-util.h
> @@ -144,6 +144,10 @@ bool ip46_parse_cidr(const char *str, struct v46_ip
> *prefix,
>   unsigned int *plen);
>  bool ip46_equals(const struct v46_ip *addr1, const struct v46_ip *addr2);
>
> +char *normalize_ipv4_prefix(ovs_be32 ipv4, unsigned int plen);
> +char *normalize_ipv6_prefix(struct in6_addr ipv6, unsigned int plen);
> +char *normalize_v46_prefix(const struct v46_ip *prefix, unsigned int
> plen);
> +
>  /* Returns a lowercase copy of orig.
>   * Caller must free the returned string.
>   */
> diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
> index 7578b9928..0079ad5a6 100644
> --- a/utilities/ovn-nbctl.c
> +++ b/utilities/ovn-nbctl.c
> @@ -3482,35 +3482,6 @@ nbctl_dhcp_options_list(struct ctl_context *ctx)
>  free(nodes);
>  }
>
> -/* The caller must free the returned string. */
> -static char *
> -normalize_ipv4_prefix(ovs_be32 ipv4, unsigned int plen)
> -{
> -ovs_be32 network = ipv4 & be32_prefix_mask(plen);
> -if (plen == 32) {
> -return xasprintf(IP_FMT, IP_ARGS(network));
> -} else {
> -return xasprintf(IP_FMT"/%d", IP_ARGS(network), plen);
> -}
> -}
> -
> -/* The caller must free the returned string. */
> -static char *
> -normalize_ipv6_prefix(struct in6_addr ipv6, unsigned int plen)
> -{
> -char network_s[INET6_ADDRSTRLEN];
> -
> -struct in6_addr mask = ipv6_create_mask(plen);
> -struct in6_addr network = ipv6_addr_bitand(, );
> -
> -inet_ntop(AF_INET6, , network_s, INET6_ADDRSTRLEN);
> -if (plen == 128) {
> -return xasprintf("%s", network_s);
> -} else {
> -return xasprintf("%s/%d", network_s, plen);
> -}
> -}
> -
>  static char *
>  normalize_ipv4_prefix_str(const char *orig_prefix)
>  {
> --
> 2.25.4
>
> ___
> 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

[ovs-dev] [PATCH] dpif-netdev.at: Wait for miss upcall log.

2020-07-23 Thread Ilya Maximets 
Some tests checks for 'miss upcall' log in a log file immediately
after sending the packet, this causes test failures while running
them under valgrind or on the overloaded system.

Fix that by waiting for appearance of the actual string in the log
file.  Some other tests uses 'sleep 1' to fix that, but it's better
to wait for event than sleep for a specific amount of time.

Signed-off-by: Ilya Maximets 
---
 tests/dpif-netdev.at | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/tests/dpif-netdev.at b/tests/dpif-netdev.at
index ec5ffc290..2862a3c9b 100644
--- a/tests/dpif-netdev.at
+++ b/tests/dpif-netdev.at
@@ -70,11 +70,13 @@ AT_CHECK([ovs-ofctl add-flow br0 action=normal])
 ovs-appctl time/stop
 ovs-appctl time/warp 5000
 AT_CHECK([ovs-appctl netdev-dummy/receive p1 
'in_port(1),eth(src=50:54:00:00:00:01,dst=50:54:00:00:02:00),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10.0.0.2,proto=6,tos=0,ttl=64,frag=no),tcp(src=8,dst=9),tcp_flags(ack)'])
+   OVS_WAIT_UNTIL([grep "miss upcall" ovs-vswitchd.log])
AT_CHECK([grep -A 1 'miss upcall' ovs-vswitchd.log | tail -n 1], [0], [dnl
 
skb_priority(0),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),dp_hash(0),in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:01,dst=50:54:00:00:02:00),eth_type(0x0800),ipv4(src=10.0.0.1,dst=10.0.0.2,proto=6,tos=0,ttl=64,frag=no),tcp(src=8,dst=9),tcp_flags(ack)
 ])
 
 AT_CHECK([ovs-appctl netdev-dummy/receive p1 
'in_port(1),eth(src=50:54:00:00:00:05,dst=50:54:00:00:06:00),eth_type(0x0800),ipv4(src=10.0.0.5,dst=10.0.0.6,proto=6,tos=0,ttl=64,frag=no),tcp(src=8,dst=9),tcp_flags(ack)'
 --len 1024])
+   OVS_WAIT_UNTIL([test `grep -c "miss upcall" ovs-vswitchd.log` -ge 2])
AT_CHECK([grep -A 1 'miss upcall' ovs-vswitchd.log | tail -n 1], [0], [dnl
 
skb_priority(0),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),dp_hash(0),in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:05,dst=50:54:00:00:06:00),eth_type(0x0800),ipv4(src=10.0.0.5,dst=10.0.0.6,proto=6,tos=0,ttl=64,frag=no),tcp(src=8,dst=9),tcp_flags(ack)
 ])
@@ -134,8 +136,8 @@ m4_define([DPIF_NETDEV_MISS_FLOW_INSTALL],
AT_CHECK([ovs-ofctl add-flow br0 action=normal])
AT_CHECK([ovs-appctl netdev-dummy/receive p1 
'in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0)'])
ovs-appctl ofproto/trace 
'in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0)'
-   sleep 1
 
+   OVS_WAIT_UNTIL([grep "miss upcall" ovs-vswitchd.log])
AT_CHECK([grep -A 1 'miss upcall' ovs-vswitchd.log | tail -n 1], [0], [dnl
 
skb_priority(0),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),dp_hash(0),in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0)
 ])
@@ -147,8 +149,8 @@ 
recirc_id(0),in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:09,dst=50:
AT_CHECK([ovs-appctl upcall/disable-megaflows], [0], [megaflows disabled
 ])
AT_CHECK([ovs-appctl netdev-dummy/receive p1 
'in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0)'])
-   sleep 1
 
+   OVS_WAIT_UNTIL([test `grep -c "miss upcall" ovs-vswitchd.log` -ge 2])
AT_CHECK([grep -A 1 'miss upcall' ovs-vswitchd.log | tail -n 1], [0], [dnl
 
skb_priority(0),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),dp_hash(0),in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0)
 ])
@@ -231,11 +233,12 @@ m4_define([DPIF_NETDEV_MISS_FLOW_DUMP],
 
AT_CHECK([ovs-ofctl add-flow br0 action=normal])
AT_CHECK([ovs-appctl netdev-dummy/receive p1 
'in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0)'])
-   sleep 1
 
+   OVS_WAIT_UNTIL([grep "miss upcall" ovs-vswitchd.log])
AT_CHECK([grep -A 1 'miss upcall' ovs-vswitchd.log | tail -n 1], [0], [dnl
 
skb_priority(0),skb_mark(0),ct_state(0),ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),dp_hash(0),in_port(1),packet_type(ns=0,id=0),eth(src=50:54:00:00:00:09,dst=50:54:00:00:00:0a),eth_type(0x0800),ipv4(src=10.0.0.2,dst=10.0.0.1,proto=1,tos=0,ttl=64,frag=no),icmp(type=8,code=0)
 ])
+   ovs-appctl revalidator/wait
AT_CHECK([filter_flow_dump < ovs-vswitchd.log | strip_xout], [0], [dnl

Re: [ovs-dev] [PATCHv2] python: fixed package dependency

2020-07-23 Thread William Tu 
On Wed, Jul 22, 2020 at 3:22 PM Gregory Rose  wrote:
>
>
> On 7/22/2020 2:25 PM, Toms Atteka wrote:
> > Python3 does not have python3-twisted-web. Required codebase is inside
> > python3-twisted.
> >
> > Signed-off-by: Toms Atteka 
> > ---
> >   debian/control | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/debian/control b/debian/control
> > index 0646b22a1..6420b9d3e 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -188,7 +188,7 @@ Description: Python bindings for Open vSwitch
> >   Package: openvswitch-test

We have some offline discussions on this.
Do you want to remove the openvswitch-test package entirely since
probably no one is using it?

William

> >   Architecture: all
> >   Depends: python3,
> > - python3-twisted-web,
> > + python3-twisted,
> >${misc:Depends},
> >${python3:Depends}
> >   Description: Open vSwitch test package
> >
>
> LGTM
> Acked-by: Greg Rose 
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH ovn v3] ovn-northd: Fix logical flows to limit ARP/NS broadcast domain.

2020-07-23 Thread Numan Siddique 
On Fri, Jul 10, 2020 at 5:07 PM Numan Siddique  wrote:

>
>
> On Fri, Jul 10, 2020 at 1:27 AM Dumitru Ceara  wrote:
>
>> Logical flows that limit the ARP/NS broadcast domain on a logical switch
>> should only match on ARP requests/NS for IPs that can actually be
>> replied to on the connected router port (i.e., an IP on the same network
>> is configured on the router port).
>>
>> Reported-by: Girish Moodalbail 
>> Reported-at:
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-June/050287.html
>> Fixes: 32f5ebb06226 ("ovn-northd: Limit ARP/ND broadcast domain whenever
>> possible.")
>> Signed-off-by: Dumitru Ceara 
>>
>
> Acked-by: Numan Siddique 
>

I applied this patch to master.

Thanks
Numan


>
> Thanks
> Numan
>
>
>> ---
>> v3:
>> - The first patch of the series was already applied.
>> - Addressed Numan's comments:
>>   - use precomputed ipv4/ipv6_netaddr network field instead of
>> recomputing it.
>>   - reworded comments to make them more clear.
>> v2:
>> - Changed the fix into a series, such that the memory leak fix can be
>>   easily backported to stable branches.
>> - Fixed the "Fixes" tag.
>> ---
>>  northd/ovn-northd.c | 162
>> +++-
>>  tests/ovn.at|  74 
>>  2 files changed, 208 insertions(+), 28 deletions(-)
>>
>> diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
>> index 1921982..d64b467 100644
>> --- a/northd/ovn-northd.c
>> +++ b/northd/ovn-northd.c
>> @@ -6091,6 +6091,42 @@ build_lrouter_groups(struct hmap *ports, struct
>> ovs_list *lr_list)
>>  }
>>  }
>>
>> +/* Returns 'true' if the IPv4 'addr' is on the same subnet with one of
>> the
>> + * IPs configured on the router port.
>> + */
>> +static bool
>> +lrouter_port_ipv4_reachable(const struct ovn_port *op, ovs_be32 addr)
>> +{
>> +for (size_t i = 0; i < op->lrp_networks.n_ipv4_addrs; i++) {
>> +struct ipv4_netaddr *op_addr = >lrp_networks.ipv4_addrs[i];
>> +
>> +if ((addr & op_addr->mask) == op_addr->network) {
>> +return true;
>> +}
>> +}
>> +return false;
>> +}
>> +
>> +/* Returns 'true' if the IPv6 'addr' is on the same subnet with one of
>> the
>> + * IPs configured on the router port.
>> + */
>> +static bool
>> +lrouter_port_ipv6_reachable(const struct ovn_port *op,
>> +const struct in6_addr *addr)
>> +{
>> +for (size_t i = 0; i < op->lrp_networks.n_ipv6_addrs; i++) {
>> +struct ipv6_netaddr *op_addr = >lrp_networks.ipv6_addrs[i];
>> +
>> +struct in6_addr nat_addr6_masked =
>> +ipv6_addr_bitand(addr, _addr->mask);
>> +
>> +if (ipv6_addr_equals(_addr6_masked, _addr->network)) {
>> +return true;
>> +}
>> +}
>> +return false;
>> +}
>> +
>>  /*
>>   * Ingress table 19: Flows that flood self originated ARP/ND packets in
>> the
>>   * switching domain.
>> @@ -6101,8 +6137,47 @@ build_lswitch_rport_arp_req_self_orig_flow(struct
>> ovn_port *op,
>> struct ovn_datapath *od,
>> struct hmap *lflows)
>>  {
>> -struct ds match = DS_EMPTY_INITIALIZER;
>> +struct sset all_eth_addrs = SSET_INITIALIZER(_eth_addrs);
>>  struct ds eth_src = DS_EMPTY_INITIALIZER;
>> +struct ds match = DS_EMPTY_INITIALIZER;
>> +
>> +sset_add(_eth_addrs, op->lrp_networks.ea_s);
>> +
>> +for (size_t i = 0; i < op->od->nbr->n_nat; i++) {
>> +struct ovn_nat *nat_entry = >od->nat_entries[i];
>> +const struct nbrec_nat *nat = nat_entry->nb;
>> +
>> +if (!nat_entry_is_valid(nat_entry)) {
>> +continue;
>> +}
>> +
>> +if (!strcmp(nat->type, "snat")) {
>> +continue;
>> +}
>> +
>> +if (!nat->external_mac) {
>> +continue;
>> +}
>> +
>> +/* Check if the ovn port has a network configured on which we
>> could
>> + * expect ARP requests/NS for the DNAT external_ip.
>> + */
>> +if (nat_entry_is_v6(nat_entry)) {
>> +struct in6_addr *addr =
>> _entry->ext_addrs.ipv6_addrs[0].addr;
>> +
>> +if (!lrouter_port_ipv6_reachable(op, addr)) {
>> +continue;
>> +}
>> +} else {
>> +ovs_be32 addr = nat_entry->ext_addrs.ipv4_addrs[0].addr;
>> +
>> +if (!lrouter_port_ipv4_reachable(op, addr)) {
>> +continue;
>> +}
>> +}
>> +sset_add(_eth_addrs, nat->external_mac);
>> +}
>> +
>>
>>  /* Self originated (G)ARP requests/ND need to be flooded as usual.
>>   * Determine that packets are self originated by also matching on
>> @@ -6110,15 +6185,11 @@ build_lswitch_rport_arp_req_self_orig_flow(struct
>> ovn_port *op,
>>   * is a VLAN-backed network.
>>   * Priority: 80.
>>   */
>> -ds_put_format(_src, "{ %s, ", op->lrp_networks.ea_s);
>> -for (size_t i = 0; i <

Re: [ovs-dev] [PATCH ovn 0/2] Improve ovn-detrace usability with clustered DBs.

2020-07-23 Thread Numan Siddique 
On Tue, Jul 7, 2020 at 9:23 PM Dumitru Ceara  wrote:

> Patch 1 of the series adds support for multiple remotes when connecting
> to OVSDBs. This is useful when the NB/SB DBs are clustered.
>
> Patch 2 of the series adds support for connecting to DB remotes via SSL.
>
> Signed-off-by: Dumitru Ceara 
>

Thanks Dumitru.
I applied both the patches in this series to master.

Numan


>
> Dumitru Ceara (2):
>   ovn-detrace: Add support for multiple remotes.
>   ovn-detrace: Support SSL remotes.
>
>
>  utilities/ovn-detrace.1.in |   30 +++---
>  utilities/ovn-detrace.in   |   59
> +---
>  2 files changed, 76 insertions(+), 13 deletions(-)
>
>
> ___
> 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 v4] bfd: Support overlay BFD

2020-07-23 Thread William Tu 
On Wed, Jul 22, 2020 at 1:41 PM Yifeng Sun  wrote:
>
> Current OVS intercepts and processes all BFD packets, thus VM-2-VM
> BFD packets get lost and the recipient VM never sees them.
>
> This patch fixes it by only intercepting and processing BFD packets
> destined to a configured BFD instance, and other BFD packets are made
> available to the OVS flow table for forwarding.
>
> This patch keeps BFD's backward compatibility.
>
> VMWare-BZ: 2579326
s/VMWare/VMware
s/2579326/#2579326/

> Signed-off-by: Yifeng Sun 
> ---
> v1->v2: Add test by William's suggestion.
> v2->v3: Fix BFD config, thanks William.
> v3->v4: Test will fail at second run, fixed it.
>
>  lib/bfd.c   | 16 +---
>  tests/system-traffic.at | 44 
>  vswitchd/vswitch.xml|  7 +++
>  3 files changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/lib/bfd.c b/lib/bfd.c
> index cc8c6857afa4..3c965699ace3 100644
> --- a/lib/bfd.c
> +++ b/lib/bfd.c
> @@ -149,6 +149,9 @@ BUILD_ASSERT_DECL(BFD_PACKET_LEN == sizeof(struct msg));
>  #define FLAGS_MASK 0x3f
>  #define DEFAULT_MULT 3
>
> +#define BFD_DEFAULT_SRC_IP 0xA9FE0101 /* 169.254.1.1 */
> +#define BFD_DEFAULT_DST_IP 0xA9FE0100 /* 169.254.1.0 */
> +
>  struct bfd {
>  struct hmap_node node;/* In 'all_bfds'. */
>  uint32_t disc;/* bfd.LocalDiscr. Key in 'all_bfds' hmap. 
> */
> @@ -457,9 +460,9 @@ bfd_configure(struct bfd *bfd, const char *name, const 
> struct smap *cfg,
>   >rmt_eth_dst);
>
>  bfd_lookup_ip(smap_get_def(cfg, "bfd_src_ip", ""),
> -  htonl(0xA9FE0101) /* 169.254.1.1 */, >ip_src);
> +  htonl(BFD_DEFAULT_SRC_IP), >ip_src);
>  bfd_lookup_ip(smap_get_def(cfg, "bfd_dst_ip", ""),
> -  htonl(0xA9FE0100) /* 169.254.1.0 */, >ip_dst);
> +  htonl(BFD_DEFAULT_DST_IP), >ip_dst);
>
>  forwarding_if_rx = smap_get_bool(cfg, "forwarding_if_rx", false);
>  if (bfd->forwarding_if_rx != forwarding_if_rx) {
> @@ -674,7 +677,14 @@ bfd_should_process_flow(const struct bfd *bfd_, const 
> struct flow *flow,
>  memset(>masks.nw_proto, 0xff, sizeof wc->masks.nw_proto);
>  if (flow->nw_proto == IPPROTO_UDP
>  && !(flow->nw_frag & FLOW_NW_FRAG_LATER)
> -&& tp_dst_equals(flow, BFD_DEST_PORT, wc)) {
> +&& tp_dst_equals(flow, BFD_DEST_PORT, wc)
> +&& (bfd->ip_src == htonl(BFD_DEFAULT_SRC_IP)
> +|| bfd->ip_src == flow->nw_dst)) {
> +
> +if (bfd->ip_src == flow->nw_dst) {
> +memset(>masks.nw_dst, 0x, sizeof 
> wc->masks.nw_dst);
> +}
> +
>  bool check_tnl_key;
>
>  atomic_read_relaxed(>check_tnl_key, _tnl_key);
> diff --git a/tests/system-traffic.at b/tests/system-traffic.at
> index 2a0fbadff4a1..ea72f155782f 100644
> --- a/tests/system-traffic.at
> +++ b/tests/system-traffic.at
> @@ -6289,3 +6289,47 @@ OVS_WAIT_UNTIL([cat p2.pcap | egrep "0x0050: * 
> * *5002 *2000 *b85e *
>
>  OVS_TRAFFIC_VSWITCHD_STOP
>  AT_CLEANUP
> +
> +AT_SETUP([bfd - BFD overlay])
> +OVS_CHECK_GENEVE()
> +
> +OVS_TRAFFIC_VSWITCHD_START()
> +
> +AT_CHECK([ovs-vsctl -- set bridge br0 
> other-config:hwaddr=\"f2:ff:00:00:00:01\"])
> +ADD_BR([br-underlay], [set bridge br-underlay 
> other-config:hwaddr=\"ee:09:e0:4d:bf:31\"])
> +
> +AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"])
> +AT_CHECK([ovs-ofctl add-flow br-underlay "actions=normal"])
> +
> +ADD_NAMESPACES(at_ns0)
> +
> +dnl Set up underlay link from host into the namespace using veth pair.
> +ADD_VETH(p0, at_ns0, br-underlay, "172.16.180.105/24", 4e:12:5d:6c:74:3d)
> +AT_CHECK([ip addr add dev br-underlay "172.16.180.106/24"])
> +AT_CHECK([ip link set dev br-underlay up])
> +
> +dnl Set up tunnel endpoints on OVS outside the namespace.
> +ADD_OVS_TUNNEL([geneve], [br0], [at_gnv0], [172.16.180.105], 
> [192.168.10.100/24],
> +[options:packet_type=ptap])
> +AT_CHECK([ovs-vsctl -- set Interface at_gnv0 ofport_request=1])
> +AT_CHECK([ovs-vsctl -- set Interface at_gnv0 bfd:enable=true 
> bfd:bfd_src_ip="172.16.180.106"])
> +
> +dnl Certain Linux distributions, like CentOS, have default iptable rules
> +dnl to reject input traffic from br-underlay. Here we add a rule to walk
> +dnl around it.
> +iptables -I INPUT 1 -i br-underlay -j ACCEPT
> +on_exit 'iptables -D INPUT 1'
> +
> +dnl Firstly, test normal BFD packet.
> +ovs-ofctl -O OpenFlow13 packet-out br-underlay "in_port=1 
> packet=ee09e04dbf314e125d6c743d080045c00066ea4e400040118e83ac10b469ac10b46a356e17c10052cb5500806558002320018ad232b919c4080045c00034ff11fa03ac10b469ac10b46acec8002020800318035cd00e000f424f4240
>  actions=NORMAL"
> +dnl Next we test overlay BFD packet.
> +ovs-ofctl -O OpenFlow13 packet-out br-underlay "in_port=1 
>

[ovs-dev] [PATCH net-next v2 2/2] net: openvswitch: make masks cache size configurable

2020-07-23 Thread Eelco Chaudron 
This patch makes the masks cache size configurable, or with
a size of 0, disable it.

Reviewed-by: Paolo Abeni 
Signed-off-by: Eelco Chaudron 
---
 include/uapi/linux/openvswitch.h |1 
 net/openvswitch/datapath.c   |   14 ++
 net/openvswitch/flow_table.c |   90 ++
 net/openvswitch/flow_table.h |   10 
 4 files changed, 104 insertions(+), 11 deletions(-)

diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 7cb76e5ca7cf..8300cc29dec8 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -86,6 +86,7 @@ enum ovs_datapath_attr {
OVS_DP_ATTR_MEGAFLOW_STATS, /* struct ovs_dp_megaflow_stats */
OVS_DP_ATTR_USER_FEATURES,  /* OVS_DP_F_*  */
OVS_DP_ATTR_PAD,
+   OVS_DP_ATTR_MASKS_CACHE_SIZE,
__OVS_DP_ATTR_MAX
 };
 
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index a54df1fe3ec4..114b2ddb8037 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -1498,6 +1498,7 @@ static size_t ovs_dp_cmd_msg_size(void)
msgsize += nla_total_size_64bit(sizeof(struct ovs_dp_stats));
msgsize += nla_total_size_64bit(sizeof(struct ovs_dp_megaflow_stats));
msgsize += nla_total_size(sizeof(u32)); /* OVS_DP_ATTR_USER_FEATURES */
+   msgsize += nla_total_size(sizeof(u32)); /* OVS_DP_ATTR_MASKS_CACHE_SIZE 
*/
 
return msgsize;
 }
@@ -1535,6 +1536,10 @@ static int ovs_dp_cmd_fill_info(struct datapath *dp, 
struct sk_buff *skb,
if (nla_put_u32(skb, OVS_DP_ATTR_USER_FEATURES, dp->user_features))
goto nla_put_failure;
 
+   if (nla_put_u32(skb, OVS_DP_ATTR_MASKS_CACHE_SIZE,
+   ovs_flow_tbl_masks_cache_size(>table)))
+   goto nla_put_failure;
+
genlmsg_end(skb, ovs_header);
return 0;
 
@@ -1599,6 +1604,13 @@ static int ovs_dp_change(struct datapath *dp, struct 
nlattr *a[])
 #endif
}
 
+   if (a[OVS_DP_ATTR_MASKS_CACHE_SIZE]) {
+   u32 cache_size;
+
+   cache_size = nla_get_u32(a[OVS_DP_ATTR_MASKS_CACHE_SIZE]);
+   ovs_flow_tbl_masks_cache_resize(>table, cache_size);
+   }
+
dp->user_features = user_features;
 
if (dp->user_features & OVS_DP_F_TC_RECIRC_SHARING)
@@ -1894,6 +1906,8 @@ static const struct nla_policy 
datapath_policy[OVS_DP_ATTR_MAX + 1] = {
[OVS_DP_ATTR_NAME] = { .type = NLA_NUL_STRING, .len = IFNAMSIZ - 1 },
[OVS_DP_ATTR_UPCALL_PID] = { .type = NLA_U32 },
[OVS_DP_ATTR_USER_FEATURES] = { .type = NLA_U32 },
+   [OVS_DP_ATTR_MASKS_CACHE_SIZE] =  NLA_POLICY_RANGE(NLA_U32, 0,
+   PCPU_MIN_UNIT_SIZE / sizeof(struct mask_cache_entry)),
 };
 
 static const struct genl_ops dp_datapath_genl_ops[] = {
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index a5912ea05352..386b7e7a0454 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -38,8 +38,8 @@
 #define MASK_ARRAY_SIZE_MIN16
 #define REHASH_INTERVAL(10 * 60 * HZ)
 
+#define MC_DEFAULT_HASH_ENTRIES256
 #define MC_HASH_SHIFT  8
-#define MC_HASH_ENTRIES(1u << MC_HASH_SHIFT)
 #define MC_HASH_SEGS   ((sizeof(uint32_t) * 8) / MC_HASH_SHIFT)
 
 static struct kmem_cache *flow_cache;
@@ -341,15 +341,76 @@ static void flow_mask_remove(struct flow_table *tbl, 
struct sw_flow_mask *mask)
}
 }
 
+static void __mask_cache_destroy(struct mask_cache *mc)
+{
+   if (mc->mask_cache)
+   free_percpu(mc->mask_cache);
+   kfree(mc);
+}
+
+static void mask_cache_rcu_cb(struct rcu_head *rcu)
+{
+   struct mask_cache *mc = container_of(rcu, struct mask_cache, rcu);
+
+   __mask_cache_destroy(mc);
+}
+
+static struct mask_cache *tbl_mask_cache_alloc(u32 size)
+{
+   struct mask_cache_entry __percpu *cache = NULL;
+   struct mask_cache *new;
+
+   /* Only allow size to be 0, or a power of 2, and does not exceed
+* percpu allocation size.
+*/
+   if ((size & (size - 1)) != 0 ||
+   (size * sizeof(struct mask_cache_entry)) > PCPU_MIN_UNIT_SIZE)
+   return NULL;
+
+   new = kzalloc(sizeof(*new), GFP_KERNEL);
+   if (!new)
+   return NULL;
+
+   new->cache_size = size;
+   if (new->cache_size > 0) {
+   cache = __alloc_percpu(sizeof(struct mask_cache_entry) *
+  new->cache_size,
+  __alignof__(struct mask_cache_entry));
+
+   if (!cache) {
+   kfree(new);
+   return NULL;
+   }
+   }
+
+   new->mask_cache = cache;
+   return new;
+}
+
+void ovs_flow_tbl_masks_cache_resize(struct flow_table *table, u32 size)
+{
+   struct mask_cache *mc = rcu_dereference(table->mask_cache);
+   struct mask_cache *new;

[ovs-dev] [PATCH net-next v2 1/2] net: openvswitch: add masks cache hit counter

2020-07-23 Thread Eelco Chaudron 
Add a counter that counts the number of masks cache hits, and
export it through the megaflow netlink statistics.

Reviewed-by: Paolo Abeni 
Signed-off-by: Eelco Chaudron 
---
 include/uapi/linux/openvswitch.h |2 +-
 net/openvswitch/datapath.c   |5 -
 net/openvswitch/datapath.h   |3 +++
 net/openvswitch/flow_table.c |   19 ++-
 net/openvswitch/flow_table.h |3 ++-
 5 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index 9b14519e74d9..7cb76e5ca7cf 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -102,8 +102,8 @@ struct ovs_dp_megaflow_stats {
__u64 n_mask_hit;/* Number of masks used for flow lookups. */
__u32 n_masks;   /* Number of masks for the datapath. */
__u32 pad0;  /* Pad for future expension. */
+   __u64 n_cache_hit;   /* Number of cache matches for flow lookups. */
__u64 pad1;  /* Pad for future expension. */
-   __u64 pad2;  /* Pad for future expension. */
 };
 
 struct ovs_vport_stats {
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 95805f0e27bd..a54df1fe3ec4 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -225,13 +225,14 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct 
sw_flow_key *key)
struct dp_stats_percpu *stats;
u64 *stats_counter;
u32 n_mask_hit;
+   u32 n_cache_hit;
int error;
 
stats = this_cpu_ptr(dp->stats_percpu);
 
/* Look up flow. */
flow = ovs_flow_tbl_lookup_stats(>table, key, skb_get_hash(skb),
-_mask_hit);
+_mask_hit, _cache_hit);
if (unlikely(!flow)) {
struct dp_upcall_info upcall;
 
@@ -262,6 +263,7 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct 
sw_flow_key *key)
u64_stats_update_begin(>syncp);
(*stats_counter)++;
stats->n_mask_hit += n_mask_hit;
+   stats->n_cache_hit += n_cache_hit;
u64_stats_update_end(>syncp);
 }
 
@@ -699,6 +701,7 @@ static void get_dp_stats(const struct datapath *dp, struct 
ovs_dp_stats *stats,
stats->n_missed += local_stats.n_missed;
stats->n_lost += local_stats.n_lost;
mega_stats->n_mask_hit += local_stats.n_mask_hit;
+   mega_stats->n_cache_hit += local_stats.n_cache_hit;
}
 }
 
diff --git a/net/openvswitch/datapath.h b/net/openvswitch/datapath.h
index 697a2354194b..86d78613edb4 100644
--- a/net/openvswitch/datapath.h
+++ b/net/openvswitch/datapath.h
@@ -38,12 +38,15 @@
  * @n_mask_hit: Number of masks looked up for flow match.
  *   @n_mask_hit / (@n_hit + @n_missed)  will be the average masks looked
  *   up per packet.
+ * @n_cache_hit: The number of received packets that had their mask found using
+ * the mask cache.
  */
 struct dp_stats_percpu {
u64 n_hit;
u64 n_missed;
u64 n_lost;
u64 n_mask_hit;
+   u64 n_cache_hit;
struct u64_stats_sync syncp;
 };
 
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index af22c9ee28dd..a5912ea05352 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -667,6 +667,7 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
   struct mask_array *ma,
   const struct sw_flow_key *key,
   u32 *n_mask_hit,
+  u32 *n_cache_hit,
   u32 *index)
 {
u64 *usage_counters = this_cpu_ptr(ma->masks_usage_cntr);
@@ -682,6 +683,7 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
u64_stats_update_begin(>syncp);
usage_counters[*index]++;
u64_stats_update_end(>syncp);
+   (*n_cache_hit)++;
return flow;
}
}
@@ -719,7 +721,8 @@ static struct sw_flow *flow_lookup(struct flow_table *tbl,
 struct sw_flow *ovs_flow_tbl_lookup_stats(struct flow_table *tbl,
  const struct sw_flow_key *key,
  u32 skb_hash,
- u32 *n_mask_hit)
+ u32 *n_mask_hit,
+ u32 *n_cache_hit)
 {
struct mask_array *ma = rcu_dereference(tbl->mask_array);
struct table_instance *ti = rcu_dereference(tbl->ti);
@@ -729,10 +732,13 @@ struct sw_flow *ovs_flow_tbl_lookup_stats(struct 
flow_table *tbl,
int seg;
 
*n_mask_hit = 0;
+   *n_cache_hit = 0;
if

[ovs-dev] [PATCH net-next v2 0/2] net: openvswitch: masks cache enhancements

2020-07-23 Thread Eelco Chaudron 
This patchset adds two enhancements to the Open vSwitch masks cache.

Signed-off-by: Eelco Chaudron 

Changes in v2:
 - Fix sparse warnings
 - Fix netlink policy items reported by Florian Westphal

Eelco Chaudron (2):
  net: openvswitch: add masks cache hit counter
  net: openvswitch: make masks cache size configurable


 include/uapi/linux/openvswitch.h |3 +
 net/openvswitch/datapath.c   |   19 ++-
 net/openvswitch/datapath.h   |3 +
 net/openvswitch/flow_table.c |  109 +-
 net/openvswitch/flow_table.h |   13 -
 5 files changed, 128 insertions(+), 19 deletions(-)

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

Re: [ovs-dev] INFO: task hung in ovs_exit_net

2020-07-23 Thread Hillf Danton 

On Thu, 23 Jul 2020 13:48:59 +0200 Eelco Chaudron wrote:
> On 23 Jul 2020, at 13:06, Hillf Danton wrote:
> 
> > Wed, 22 Jul 2020 23:27:19 -0700
> >> syzbot found the following issue on:
>   
> >
> > Fixes: eac87c413bf9 ("net: openvswitch: reorder masks array based on usage")
> > by moving cancel_delayed_work_sync() in to the rcu cb, therefore out of ovs
> > lock. To facilitate that, add a flag in datapath to inform the kworker that
> > there is no more work needed.
> 
> I was thinking of re-working the patch and move the handling to the 
> “struct ovs_net” instead of the datapath. This way the rebalance 
> worker can rebalance all datapaths in the netns. Than I can move 
> cancel_delayed_work_sync() from __dp_destroy()
> to ovs_exit_net(), i.e. outside the ovs lock scope.

I have no prefer over either way.

> However, your fix would be way less intrusive. Are you planning on 
> sending it as a patch?

This is the candy to get syzbot out of depression and frustration and
work again tomorrow.

> If so, maybe add a comment around the called_rcu 
> variable to be more clear where it’s used for, or maybe rename it to 
> something like called_destory_rcu?

I try much to avoid over-comment, see below, given the absence of
something like is_rcu_called(rcu);
 
> If you think my approach would be better let me know, and I work on a 
> patch.

Feel free to do what you like. 

> > +   dp->called_rcu = true;
> > /* RCU destroy the flow table */
> > call_rcu(>rcu, destroy_dp_rcu);

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

Re: [ovs-dev] INFO: task hung in ovs_exit_net

2020-07-23 Thread Eelco Chaudron 



On 23 Jul 2020, at 13:06, Hillf Danton wrote:


Wed, 22 Jul 2020 23:27:19 -0700

syzbot found the following issue on:

 


Fixes: eac87c413bf9 ("net: openvswitch: reorder masks array based on 
usage")
by moving cancel_delayed_work_sync() in to the rcu cb, therefore out 
of ovs
lock. To facilitate that, add a flag in datapath to inform the kworker 
that

there is no more work needed.


I was thinking of re-working the patch and move the handling to the 
“struct ovs_net” instead of the datapath. This way the rebalance 
worker can rebalance all datapaths in the netns. Than I can move 
cancel_delayed_work_sync() from __dp_destroy()

to ovs_exit_net(), i.e. outside the ovs lock scope.

However, your fix would be way less intrusive. Are you planning on 
sending it as a patch? If so, maybe add a comment around the called_rcu 
variable to be more clear where it’s used for, or maybe rename it to 
something like called_destory_rcu?


If you think my approach would be better let me know, and I work on a 
patch.


Feedback anyone?


--- a/net/openvswitch/datapath.h
+++ b/net/openvswitch/datapath.h
@@ -82,6 +82,7 @@ struct datapath {

u32 max_headroom;

+   int called_rcu;
/* Switch meters. */
struct dp_meter_table meter_tbl;

--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -161,6 +161,7 @@ static void destroy_dp_rcu(struct rcu_he
 {
struct datapath *dp = container_of(rcu, struct datapath, rcu);

+   cancel_delayed_work_sync(>masks_rebalance);
ovs_flow_tbl_destroy(>table);
free_percpu(dp->stats_percpu);
kfree(dp->ports);
@@ -1760,11 +1761,9 @@ static void __dp_destroy(struct datapath
 */
ovs_dp_detach_port(ovs_vport_ovsl(dp, OVSP_LOCAL));

+   dp->called_rcu = true;
/* RCU destroy the flow table */
call_rcu(>rcu, destroy_dp_rcu);
-
-   /* Cancel remaining work. */
-   cancel_delayed_work_sync(>masks_rebalance);
 }

 static int ovs_dp_cmd_del(struct sk_buff *skb, struct genl_info 
*info)

@@ -2356,6 +2355,8 @@ static void ovs_dp_masks_rebalance(struc
ovs_flow_masks_rebalance(>table);
ovs_unlock();

+   if (dp->called_rcu)
+   return;
schedule_delayed_work(>masks_rebalance,
  msecs_to_jiffies(DP_MASKS_REBALANCE_INTERVAL));
 }


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

Re: [ovs-dev] INFO: task hung in ovs_exit_net

2020-07-23 Thread Hillf Danton 


Wed, 22 Jul 2020 23:27:19 -0700
> syzbot found the following issue on:
> 
> HEAD commit:a6c0d093 net: explicitly include  in net/c..
> git tree:   net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=179ee64090
> kernel config:  https://syzkaller.appspot.com/x/.config?x=2b7b67c0c1819c87
> dashboard link: https://syzkaller.appspot.com/bug?extid=2c4ff3614695f75ce26c
> compiler:   gcc (GCC) 10.1.0-syz 20200507
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+2c4ff3614695f75ce...@syzkaller.appspotmail.com
> 
> INFO: task kworker/u4:3:235 blocked for more than 143 seconds.
>   Not tainted 5.8.0-rc4-syzkaller #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kworker/u4:3D24856   235  2 0x4000
> Workqueue: netns cleanup_net
> Call Trace:
>  context_switch kernel/sched/core.c:3453 [inline]
>  __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
>  schedule+0xd0/0x2a0 kernel/sched/core.c:4253
>  schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4312
>  __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
>  __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
>  ovs_lock net/openvswitch/datapath.c:105 [inline]
>  ovs_exit_net+0x1de/0xba0 net/openvswitch/datapath.c:2491
>  ops_exit_list+0xb0/0x160 net/core/net_namespace.c:186
>  cleanup_net+0x4ea/0xa00 net/core/net_namespace.c:603
>  process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
>  worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
>  kthread+0x3b5/0x4a0 kernel/kthread.c:291
>  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
> INFO: task kworker/0:5:9052 blocked for more than 143 seconds.
>   Not tainted 5.8.0-rc4-syzkaller #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> kworker/0:5 D27408  9052  2 0x4000
> Workqueue: events ovs_dp_masks_rebalance
> Call Trace:
>  context_switch kernel/sched/core.c:3453 [inline]
>  __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
>  schedule+0xd0/0x2a0 kernel/sched/core.c:4253
>  schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4312
>  __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
>  __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
>  ovs_lock net/openvswitch/datapath.c:105 [inline]
>  ovs_dp_masks_rebalance+0x18/0x80 net/openvswitch/datapath.c:2355
>  process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
>  worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
>  kthread+0x3b5/0x4a0 kernel/kthread.c:291
>  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
> INFO: task syz-executor.3:21286 blocked for more than 143 seconds.
>   Not tainted 5.8.0-rc4-syzkaller #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> syz-executor.3  D26160 21286   7072 0x4004
> Call Trace:
>  context_switch kernel/sched/core.c:3453 [inline]
>  __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
>  schedule+0xd0/0x2a0 kernel/sched/core.c:4253
>  schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1873
>  do_wait_for_common kernel/sched/completion.c:85 [inline]
>  __wait_for_common kernel/sched/completion.c:106 [inline]
>  wait_for_common kernel/sched/completion.c:117 [inline]
>  wait_for_completion+0x163/0x260 kernel/sched/completion.c:138
>  __flush_work+0x51f/0xab0 kernel/workqueue.c:3046
>  __cancel_work_timer+0x5de/0x700 kernel/workqueue.c:3133
>  ovs_dp_cmd_del+0x18c/0x270 net/openvswitch/datapath.c:1790
>  genl_family_rcv_msg_doit net/netlink/genetlink.c:669 [inline]
>  genl_family_rcv_msg net/netlink/genetlink.c:714 [inline]
>  genl_rcv_msg+0x61d/0x980 net/netlink/genetlink.c:731
>  netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2470
>  genl_rcv+0x24/0x40 net/netlink/genetlink.c:742
>  netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
>  netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
>  netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919
>  sock_sendmsg_nosec net/socket.c:651 [inline]
>  sock_sendmsg+0xcf/0x120 net/socket.c:671
>  sys_sendmsg+0x6e8/0x810 net/socket.c:2363
>  ___sys_sendmsg+0xf3/0x170 net/socket.c:2417
>  __sys_sendmsg+0xe5/0x1b0 net/socket.c:2450
>  do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x45c1f9
> Code: Bad RIP value.
> RSP: 002b:7f75a409cc78 EFLAGS: 0246 ORIG_RAX: 002e
> RAX: ffda RBX: 0002b3c0 RCX: 0045c1f9
> RDX:  RSI: 20c0 RDI: 0004
> RBP: 0078bf40 R08:  R09: 
> R10:  R11: 0246 R12: 0078bf0c
> R13: 7ffed0e2724f R14: 7f75a409d9c0 R15: 0078bf0c
> INFO: task syz-executor.3:21355 blocked for more than 144 seconds.
>   Not tainted 5.8.0-rc4-syzkaller #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this

Re: [ovs-dev] [PATCH net-next 2/2] net: openvswitch: make masks cache size configurable

2020-07-23 Thread Florian Westphal 
Eelco Chaudron  wrote:
> On 22 Jul 2020, at 21:22, Florian Westphal wrote:
> > I see a 0 cache size is legal (turns it off) and that the allocation
> > path has a few sanity checks as well.
> > 
> > Would it make sense to add min/max policy to datapath_policy[] for this
> > as well?
> 
> Yes I could add the following:
> 
> @@ -1906,7 +1906,8 @@ static const struct nla_policy
> datapath_policy[OVS_DP_ATTR_MAX + 1] = {
> [OVS_DP_ATTR_NAME] = { .type = NLA_NUL_STRING, .len = IFNAMSIZ - 1
> },
> [OVS_DP_ATTR_UPCALL_PID] = { .type = NLA_U32 },
> [OVS_DP_ATTR_USER_FEATURES] = { .type = NLA_U32 },
> +   [OVS_DP_ATTR_MASKS_CACHE_SIZE] =  NLA_POLICY_RANGE(NLA_U32, 0,
> +   PCPU_MIN_UNIT_SIZE / sizeof(struct mask_cache_entry)),
>  };
> Let me know your thoughts

I think its a good idea.  When 'max' becomes too restricted one could
rework internal kernel logic to support larger size and userspace
can detect it by probing with a larger size first.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [ovs-discuss] OVN nb-db and sb-db out of sync

2020-07-23 Thread Numan Siddique 
On Thu, Jul 23, 2020 at 8:22 AM Tony Liu  wrote:

> Hi,
>
> I see why sb-db broke at 1568th port-binding.
> The 1568th datapath-binding in sb-db references the same
>
> _uuid   : 108cf745-db82-43c0-a9d3-afe27a41e4aa
> external_ids:
> {logical-switch="8a5d1d3c-e9fc-4cbe-a461-98ff838e6473",
> name=neutron-e907dc17-f1e8-4217-a37d-86e9a98c86c2, name2=net-97-192}
> tunnel_key  : 1567
>
> _uuid   : d934ed92-2f3c-4b31-8a76-2a5047a3bb46
> external_ids:
> {logical-switch="8a5d1d3c-e9fc-4cbe-a461-98ff838e6473",
> name=neutron-e907dc17-f1e8-4217-a37d-86e9a98c86c2, name2=net-97-192}
> tunnel_key  : 1568
>
> I don't believe this is supposed to happen. Any idea how could it happen?
> Then ovn-northd is stuck in trying to delete this duplication, and it
> ignores all the following updates.
> That caused out-of-sync between nb-db and sb-db.
> Any way I can fix it manually, like with ovn-sbctl to delete it?
>

If you delete the ovn sb db resources manually, ovn-northd should sync it
up.

But I'm surprised why ovn-northd didn't sync earlier. There's something
wrong related to raft going
on here. Not sure what.

Thanks
Numan



>
> Thanks!
>
> Tony
>
> --
> *From:* dev  on behalf of Tony Liu <
> tonyliu0...@hotmail.com>
> *Sent:* July 22, 2020 11:33 AM
> *To:* ovs-dev 
> *Subject:* [ovs-dev] OVN nb-db and sb-db out of sync
>
> Hi,
>
> During a scaling test where 4000 networks are created from OpenStack, I
> see that
> nb-db and sb-db are out of sync. All 4000 logical switches and 8000 LS
> ports
> (GW port and service port of each network) are created in nb-db. In sb-db,
> only 1567 port-bindings, 4000 is expected.
>
> [root@ovn-db-2 ~]# ovn-nbctl list nb_global
> _uuid   : b7b3aa05-f7ed-4dbc-979f-10445ac325b8
> connections : []
> external_ids: {"neutron:liveness_check_at"="2020-07-22
> 04:03:17.726917+00:00"}
> hv_cfg  : 312
> ipsec   : false
> name: ""
> nb_cfg  : 2636
> options : {mac_prefix="ca:e8:07",
> svc_monitor_mac="4e:d0:3a:80:d4:b7"}
> sb_cfg  : 2005
> ssl : []
>
> [root@ovn-db-2 ~]# ovn-sbctl list sb_global
> _uuid   : 3720bc1d-b0da-47ce-85ca-96fa8d398489
> connections : []
> external_ids: {}
> ipsec   : false
> nb_cfg  : 312
> options : {mac_prefix="ca:e8:07",
> svc_monitor_mac="4e:d0:3a:80:d4:b7"}
> ssl : []
>
> Is there any way to force ovn-northd to rebuild sb-db to sync with nb-db,
> like manipulating nb_cfg or anything else? Note, it's 3-node RAFT cluster
> for both
> nb-db and sb-db.
>
> Is that "incremental update" implemented in 20.03?
> If not, in which release it's going to be available?
>
>
> Thanks!
>
> Tony
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH net-next 2/2] net: openvswitch: make masks cache size configurable

2020-07-23 Thread Eelco Chaudron 




On 22 Jul 2020, at 21:22, Florian Westphal wrote:


Eelco Chaudron  wrote:

This patch makes the masks cache size configurable, or with
a size of 0, disable it.

Reviewed-by: Paolo Abeni 
Signed-off-by: Eelco Chaudron 
---
 include/uapi/linux/openvswitch.h |1
 net/openvswitch/datapath.c   |   11 +
 net/openvswitch/flow_table.c |   86 
++

 net/openvswitch/flow_table.h |   10 
 4 files changed, 98 insertions(+), 10 deletions(-)

diff --git a/include/uapi/linux/openvswitch.h 
b/include/uapi/linux/openvswitch.h

index 7cb76e5ca7cf..8300cc29dec8 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -86,6 +86,7 @@ enum ovs_datapath_attr {
OVS_DP_ATTR_MEGAFLOW_STATS, /* struct ovs_dp_megaflow_stats */
OVS_DP_ATTR_USER_FEATURES,  /* OVS_DP_F_*  */
OVS_DP_ATTR_PAD,
+   OVS_DP_ATTR_MASKS_CACHE_SIZE,


This new attr should probably get an entry in
datapath.c datapath_policy[].


Yes, I should have, will fix in v2.


--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -1535,6 +1535,10 @@ static int ovs_dp_cmd_fill_info(struct 
datapath *dp, struct sk_buff *skb,

if (nla_put_u32(skb, OVS_DP_ATTR_USER_FEATURES, dp->user_features))
goto nla_put_failure;

+   if (nla_put_u32(skb, OVS_DP_ATTR_MASKS_CACHE_SIZE,
+   ovs_flow_tbl_masks_cache_size(>table)))
+   goto nla_put_failure;
+
genlmsg_end(skb, ovs_header);
return 0;



ovs_dp_cmd_msg_size() should add another nla_total_size(sizeof(u32))
to make sure there is enough space.


Same as above


+   if (a[OVS_DP_ATTR_MASKS_CACHE_SIZE]) {
+   u32 cache_size;
+
+   cache_size = nla_get_u32(a[OVS_DP_ATTR_MASKS_CACHE_SIZE]);
+   ovs_flow_tbl_masks_cache_resize(>table, cache_size);
+   }


I see a 0 cache size is legal (turns it off) and that the allocation
path has a few sanity checks as well.

Would it make sense to add min/max policy to datapath_policy[] for 
this

as well?


Yes I could add the following:

@@ -1906,7 +1906,8 @@ static const struct nla_policy 
datapath_policy[OVS_DP_ATTR_MAX + 1] = {
[OVS_DP_ATTR_NAME] = { .type = NLA_NUL_STRING, .len = IFNAMSIZ 
- 1 },

[OVS_DP_ATTR_UPCALL_PID] = { .type = NLA_U32 },
[OVS_DP_ATTR_USER_FEATURES] = { .type = NLA_U32 },
+   [OVS_DP_ATTR_MASKS_CACHE_SIZE] =  NLA_POLICY_RANGE(NLA_U32, 0,
+   PCPU_MIN_UNIT_SIZE / sizeof(struct mask_cache_entry)),
 };

Let me know your thoughts

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

[ovs-dev] [PATCH] ofproto/trace: Support for DP-HASH recirculation

2020-07-23 Thread Surya Rudra via dev 
Issue:
Current OVS implementation, recirculation information
is not displayed in ofproto trace command if it happens
for dp-hash calculation.

Fix:
Updated ofproto/trace implementation to support dp-hash
recirculation.

Test:
Added unit testcase to test the changes.

Signed-off-by: Surya Rudra 
---
 ofproto/ofproto-dpif-trace.c | 19 ++-
 ofproto/ofproto-dpif-trace.h |  5 -
 ofproto/ofproto-dpif-xlate.c | 16 +++-
 tests/ofproto-dpif.at| 21 +
 4 files changed, 58 insertions(+), 3 deletions(-)

diff --git a/ofproto/ofproto-dpif-trace.c b/ofproto/ofproto-dpif-trace.c
index 78a54c7..d558c4b 100644
--- a/ofproto/ofproto-dpif-trace.c
+++ b/ofproto/ofproto-dpif-trace.c
@@ -88,7 +88,7 @@ oftrace_add_recirc_node(struct ovs_list *recirc_queue,
 enum oftrace_recirc_type type, const struct flow *flow,
 const struct ofpact_nat *ofn,
 const struct dp_packet *packet, uint32_t recirc_id,
-const uint16_t zone)
+const uint16_t zone, struct ovs_action_hash *hash_act)
 {
 if (!recirc_id_node_find_and_ref(recirc_id)) {
 return false;
@@ -99,6 +99,7 @@ oftrace_add_recirc_node(struct ovs_list *recirc_queue,
 
 node->type = type;
 node->recirc_id = recirc_id;
+node->act_hash = hash_act;
 node->flow = *flow;
 node->flow.recirc_id = recirc_id;
 node->flow.ct_zone = zone;
@@ -682,6 +683,22 @@ ofproto_trace_recirc_node(struct oftrace_recirc_node *node,
 ds_destroy();
 }
 node->flow.ct_state = ct_state;
+} else if (node->type == OFT_RECIRC_DP_HASH) {
+ const struct ovs_action_hash *hash_act = node->act_hash;
+ uint32_t hash = 0;
+ switch (hash_act->hash_alg) {
+ case OVS_HASH_ALG_SYM_L4:
+ hash = flow_hash_symmetric_l3l4(>flow,
+ hash_act->hash_basis,
+ false);
+ break;
+ case OVS_HASH_ALG_L4:
+ default:
+ hash = flow_hash_5tuple(>flow,
+ hash_act->hash_basis);
+ break;
+ }
+ node->flow.dp_hash = hash;
 }
 ds_put_char(output, '\n');
 
diff --git a/ofproto/ofproto-dpif-trace.h b/ofproto/ofproto-dpif-trace.h
index 4b04f17..e50c415 100644
--- a/ofproto/ofproto-dpif-trace.h
+++ b/ofproto/ofproto-dpif-trace.h
@@ -54,6 +54,7 @@ enum oftrace_recirc_type {
 OFT_RECIRC_CONNTRACK,
 OFT_RECIRC_MPLS,
 OFT_RECIRC_BOND,
+OFT_RECIRC_DP_HASH,
 };
 
 /* A node within a trace. */
@@ -74,6 +75,7 @@ struct oftrace_recirc_node {
 struct flow flow;
 struct dp_packet *packet;
 const struct ofpact_nat *nat_act;
+struct ovs_action_hash *act_hash;
 };
 
 /* A node within a next_ct_states list. */
@@ -94,6 +96,7 @@ bool oftrace_add_recirc_node(struct ovs_list *recirc_queue,
  enum oftrace_recirc_type, const struct flow *,
  const struct ofpact_nat *,
  const struct dp_packet *, uint32_t recirc_id,
- const uint16_t zone);
+ const uint16_t zone,
+ struct ovs_action_hash *hash_act);
 
 #endif /* ofproto-dpif-trace.h */
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index e0ede2c..08caacb 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -4977,6 +4977,20 @@ finish_freezing__(struct xlate_ctx *ctx, uint8_t table)
 sizeof *act_hash);
 act_hash->hash_alg = ctx->dp_hash_alg;
 act_hash->hash_basis = ctx->dp_hash_basis;
+
+if (OVS_UNLIKELY(ctx->xin->trace) && recirc_id) {
+if (oftrace_add_recirc_node(ctx->xin->recirc_queue,
+  OFT_RECIRC_DP_HASH, >xin->flow, NULL,
+  ctx->xin->packet, recirc_id, 0, act_hash)) {
+xlate_report(ctx, OFT_DETAIL, "A clone of the packet is "
+"forked to recirculate. The forked pipeline will "
+"be resumed at table %u.", table);
+} else {
+xlate_report(ctx, OFT_DETAIL, "Failed to trace the "
+"DP hash forked pipeline with recirc_id = %d.",
+recirc_id);
+}
+}
 }
 nl_msg_put_u32(ctx->odp_actions, OVS_ACTION_ATTR_RECIRC, recirc_id);
 }
@@ -5010,7 +5024,7 @@ compose_recirculate_and_fork(struct xlate_ctx *ctx, 
uint8_t table,
 if (oftrace_add_recirc_node(ctx->xin->recirc_queue,
 OFT_RECIRC_CONNTRACK, >xin->flow,
 ctx->ct_nat_action, ctx->xin->packet,
-

Re: [ovs-dev] INFO: task hung in ovs_exit_net

2020-07-23 Thread Eelco Chaudron 
Looks like the same problem as “[ovs-dev] INFO: task hung in 
ovs_dp_masks_rebalance”.


//Eelco


On 23 Jul 2020, at 8:27, syzbot wrote:


Hello,

syzbot found the following issue on:

HEAD commit:a6c0d093 net: explicitly include  in 
net/c..

git tree:   net-next
console output: 
https://syzkaller.appspot.com/x/log.txt?x=179ee64090
kernel config:  
https://syzkaller.appspot.com/x/.config?x=2b7b67c0c1819c87
dashboard link: 
https://syzkaller.appspot.com/bug?extid=2c4ff3614695f75ce26c

compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the 
commit:

Reported-by: syzbot+2c4ff3614695f75ce...@syzkaller.appspotmail.com

INFO: task kworker/u4:3:235 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.

kworker/u4:3D24856   235  2 0x4000
Workqueue: netns cleanup_net
Call Trace:
 context_switch kernel/sched/core.c:3453 [inline]
 __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
 schedule+0xd0/0x2a0 kernel/sched/core.c:4253
 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4312
 __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
 __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
 ovs_lock net/openvswitch/datapath.c:105 [inline]
 ovs_exit_net+0x1de/0xba0 net/openvswitch/datapath.c:2491
 ops_exit_list+0xb0/0x160 net/core/net_namespace.c:186
 cleanup_net+0x4ea/0xa00 net/core/net_namespace.c:603
 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
INFO: task kworker/0:5:9052 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.

kworker/0:5 D27408  9052  2 0x4000
Workqueue: events ovs_dp_masks_rebalance
Call Trace:
 context_switch kernel/sched/core.c:3453 [inline]
 __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
 schedule+0xd0/0x2a0 kernel/sched/core.c:4253
 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4312
 __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
 __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
 ovs_lock net/openvswitch/datapath.c:105 [inline]
 ovs_dp_masks_rebalance+0x18/0x80 net/openvswitch/datapath.c:2355
 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
INFO: task syz-executor.3:21286 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.

syz-executor.3  D26160 21286   7072 0x4004
Call Trace:
 context_switch kernel/sched/core.c:3453 [inline]
 __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
 schedule+0xd0/0x2a0 kernel/sched/core.c:4253
 schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1873
 do_wait_for_common kernel/sched/completion.c:85 [inline]
 __wait_for_common kernel/sched/completion.c:106 [inline]
 wait_for_common kernel/sched/completion.c:117 [inline]
 wait_for_completion+0x163/0x260 kernel/sched/completion.c:138
 __flush_work+0x51f/0xab0 kernel/workqueue.c:3046
 __cancel_work_timer+0x5de/0x700 kernel/workqueue.c:3133
 ovs_dp_cmd_del+0x18c/0x270 net/openvswitch/datapath.c:1790
 genl_family_rcv_msg_doit net/netlink/genetlink.c:669 [inline]
 genl_family_rcv_msg net/netlink/genetlink.c:714 [inline]
 genl_rcv_msg+0x61d/0x980 net/netlink/genetlink.c:731
 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2470
 genl_rcv+0x24/0x40 net/netlink/genetlink.c:742
 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919
 sock_sendmsg_nosec net/socket.c:651 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:671
 sys_sendmsg+0x6e8/0x810 net/socket.c:2363
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2417
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2450
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45c1f9
Code: Bad RIP value.
RSP: 002b:7f75a409cc78 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 0002b3c0 RCX: 0045c1f9
RDX:  RSI: 20c0 RDI: 0004
RBP: 0078bf40 R08:  R09: 
R10:  R11: 0246 R12: 0078bf0c
R13: 7ffed0e2724f R14: 7f75a409d9c0 R15: 0078bf0c
INFO: task syz-executor.3:21355 blocked for more than 144 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.

syz-executor.3  D27400 21355   7072 0x4004
Call

Re: [ovs-dev] INFO: task hung in ovs_dp_masks_rebalance

2020-07-23 Thread Eelco Chaudron 

FYI, I’m looking into this…

//Eelco


On 22 Jul 2020, at 22:52, syzbot wrote:


Hello,

syzbot found the following issue on:

HEAD commit:fa56a987 Merge branch 'ionic-updates'
git tree:   net-next
console output: 
https://syzkaller.appspot.com/x/log.txt?x=1105f05310
kernel config:  
https://syzkaller.appspot.com/x/.config?x=2b7b67c0c1819c87
dashboard link: 
https://syzkaller.appspot.com/bug?extid=bad6507e5db05017b008

compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the 
commit:

Reported-by: syzbot+bad6507e5db05017b...@syzkaller.appspotmail.com

INFO: task kworker/1:8:10136 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.

kworker/1:8 D27336 10136  2 0x4000
Workqueue: events ovs_dp_masks_rebalance
Call Trace:
 context_switch kernel/sched/core.c:3453 [inline]
 __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
 schedule+0xd0/0x2a0 kernel/sched/core.c:4253
 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4312
 __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
 __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
 ovs_lock net/openvswitch/datapath.c:105 [inline]
 ovs_dp_masks_rebalance+0x18/0x80 net/openvswitch/datapath.c:2355
 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
INFO: task kworker/0:9:8606 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.

kworker/0:9 D27792  8606  2 0x4000
Workqueue: events ovs_dp_masks_rebalance
Call Trace:
 context_switch kernel/sched/core.c:3453 [inline]
 __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
 schedule+0xd0/0x2a0 kernel/sched/core.c:4253
 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4312
 __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
 __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
 ovs_lock net/openvswitch/datapath.c:105 [inline]
 ovs_dp_masks_rebalance+0x18/0x80 net/openvswitch/datapath.c:2355
 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
INFO: task syz-executor.2:9414 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.

syz-executor.2  D27832  9414   7005 0x4004
Call Trace:
 context_switch kernel/sched/core.c:3453 [inline]
 __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
 schedule+0xd0/0x2a0 kernel/sched/core.c:4253
 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4312
 __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
 __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
 ovs_lock net/openvswitch/datapath.c:105 [inline]
 ovs_dp_cmd_new+0x69d/0x1160 net/openvswitch/datapath.c:1690
 genl_family_rcv_msg_doit net/netlink/genetlink.c:669 [inline]
 genl_family_rcv_msg net/netlink/genetlink.c:714 [inline]
 genl_rcv_msg+0x61d/0x980 net/netlink/genetlink.c:731
 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2469
 genl_rcv+0x24/0x40 net/netlink/genetlink.c:742
 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1329
 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1918
 sock_sendmsg_nosec net/socket.c:651 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:671
 sys_sendmsg+0x6e8/0x810 net/socket.c:2363
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2417
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2450
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45c1f9
Code: Bad RIP value.
RSP: 002b:7f864e02dc78 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 0002b400 RCX: 0045c1f9
RDX:  RSI: 20c0 RDI: 0003
RBP: 0078bf40 R08:  R09: 
R10:  R11: 0246 R12: 0078bf0c
R13: 7ffc8c137ccf R14: 7f864e02e9c0 R15: 0078bf0c
INFO: task syz-executor.2:9422 blocked for more than 144 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.

syz-executor.2  D27040  9422   7005 0x4004
Call Trace:
 context_switch kernel/sched/core.c:3453 [inline]
 __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
 schedule+0xd0/0x2a0 kernel/sched/core.c:4253
 schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1873
 do_wait_for_common kernel/sched/completion.c:85 [inline]
 __wait_for_common kernel/sched/completion.c:106 [inline]

[ovs-dev] INFO: task hung in ovs_exit_net

2020-07-23 Thread syzbot 
Hello,

syzbot found the following issue on:

HEAD commit:a6c0d093 net: explicitly include  in net/c..
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=179ee64090
kernel config:  https://syzkaller.appspot.com/x/.config?x=2b7b67c0c1819c87
dashboard link: https://syzkaller.appspot.com/bug?extid=2c4ff3614695f75ce26c
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2c4ff3614695f75ce...@syzkaller.appspotmail.com

INFO: task kworker/u4:3:235 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/u4:3D24856   235  2 0x4000
Workqueue: netns cleanup_net
Call Trace:
 context_switch kernel/sched/core.c:3453 [inline]
 __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
 schedule+0xd0/0x2a0 kernel/sched/core.c:4253
 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4312
 __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
 __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
 ovs_lock net/openvswitch/datapath.c:105 [inline]
 ovs_exit_net+0x1de/0xba0 net/openvswitch/datapath.c:2491
 ops_exit_list+0xb0/0x160 net/core/net_namespace.c:186
 cleanup_net+0x4ea/0xa00 net/core/net_namespace.c:603
 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
INFO: task kworker/0:5:9052 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:5 D27408  9052  2 0x4000
Workqueue: events ovs_dp_masks_rebalance
Call Trace:
 context_switch kernel/sched/core.c:3453 [inline]
 __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
 schedule+0xd0/0x2a0 kernel/sched/core.c:4253
 schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:4312
 __mutex_lock_common kernel/locking/mutex.c:1033 [inline]
 __mutex_lock+0x3e2/0x10d0 kernel/locking/mutex.c:1103
 ovs_lock net/openvswitch/datapath.c:105 [inline]
 ovs_dp_masks_rebalance+0x18/0x80 net/openvswitch/datapath.c:2355
 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
INFO: task syz-executor.3:21286 blocked for more than 143 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.3  D26160 21286   7072 0x4004
Call Trace:
 context_switch kernel/sched/core.c:3453 [inline]
 __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
 schedule+0xd0/0x2a0 kernel/sched/core.c:4253
 schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1873
 do_wait_for_common kernel/sched/completion.c:85 [inline]
 __wait_for_common kernel/sched/completion.c:106 [inline]
 wait_for_common kernel/sched/completion.c:117 [inline]
 wait_for_completion+0x163/0x260 kernel/sched/completion.c:138
 __flush_work+0x51f/0xab0 kernel/workqueue.c:3046
 __cancel_work_timer+0x5de/0x700 kernel/workqueue.c:3133
 ovs_dp_cmd_del+0x18c/0x270 net/openvswitch/datapath.c:1790
 genl_family_rcv_msg_doit net/netlink/genetlink.c:669 [inline]
 genl_family_rcv_msg net/netlink/genetlink.c:714 [inline]
 genl_rcv_msg+0x61d/0x980 net/netlink/genetlink.c:731
 netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2470
 genl_rcv+0x24/0x40 net/netlink/genetlink.c:742
 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919
 sock_sendmsg_nosec net/socket.c:651 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:671
 sys_sendmsg+0x6e8/0x810 net/socket.c:2363
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2417
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2450
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45c1f9
Code: Bad RIP value.
RSP: 002b:7f75a409cc78 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 0002b3c0 RCX: 0045c1f9
RDX:  RSI: 20c0 RDI: 0004
RBP: 0078bf40 R08:  R09: 
R10:  R11: 0246 R12: 0078bf0c
R13: 7ffed0e2724f R14: 7f75a409d9c0 R15: 0078bf0c
INFO: task syz-executor.3:21355 blocked for more than 144 seconds.
  Not tainted 5.8.0-rc4-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.3  D27400 21355   7072 0x4004
Call Trace:
 context_switch kernel/sched/core.c:3453 [inline]
 __schedule+0x8e1/0x1eb0 kernel/sched/core.c:4178
 schedule+0xd0/0x2a0 kernel/sched/core.c:4253

Re: [ovs-dev] [PATCH ovn 7/7] ovn-northd.c: Support optionally disabling neighbor learning from ARP request/NS.

2020-07-23 Thread 0-day Robot 
Bleep bloop.  Greetings Han Zhou, 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 92 characters long (recommended limit is 79)
#370 FILE: ovn-nb.xml:1862:
  

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


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

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

Re: [ovs-dev] [PATCH ovn 4/7] actions: Implement new actions lookup_arp_ip and lookup_nd_ip.

2020-07-23 Thread 0-day Robot 
Bleep bloop.  Greetings Han Zhou, 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 80 characters long (recommended limit is 79)
#211 FILE: ovn-sb.xml:1449:
  R = lookup_arp_ip(P, A);

WARNING: Line is 81 characters long (recommended limit is 79)
#245 FILE: ovn-sb.xml:1660:
R = lookup_nd_ip(P, 
A);

Lines checked: 436, Warnings: 2, Errors: 0


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

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

Re: [ovs-dev] [PATCH ovn 1/7] ovn-northd: Support optionally avoid static neighbor flows in routers.

2020-07-23 Thread 0-day Robot 
Bleep bloop.  Greetings Han Zhou, 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 84 characters long (recommended limit is 79)
#61 FILE: ovn-nb.xml:1849:
  

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


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

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