Re: [ovs-dev] [ovs-discuss] OVN scale

[Tony Liu]

Hi,

Continue this thread with some updates.

I finally got 4096 networks and 256 router created, 16 networks connecting
to each router. All routers are set as external gateway.

On underlay, those 256 gateway addresses on the provider network are
reachable. Ping is steady.

I launched 10 VMs on one compute node. One of them failed because network
allocation failed. Didn't look into it.

When ping from underlay to VM, it's bumpy. There is 1s or 2s delay about
every 10 pings.

Can't launch any more VMs. It always fails.

One of the Neutron node is very busy. From the logging on INFO level,
it just keeps connecting to OVN.

The active ovn-northd is busy, but all ovn-nb-db and ovn-sb-db are not.

On compute node, ovn-controller is very busy. It keeps saying
"commit failed".

2020-08-05T02:44:23.927Z|04125|reconnect|INFO|tcp:10.6.20.84:6642: connected
2020-08-05T02:44:23.936Z|04126|main|INFO|OVNSB commit failed, force recompute 
next time.
2020-08-05T02:44:23.938Z|04127|ovsdb_idl|INFO|tcp:10.6.20.84:6642: clustered 
database server is disconnected from cluster; trying another server
2020-08-05T02:44:23.939Z|04128|reconnect|INFO|tcp:10.6.20.84:6642: connection 
attempt timed out
2020-08-05T02:44:23.939Z|04129|reconnect|INFO|tcp:10.6.20.84:6642: waiting 2 
seconds before reconnect


The connection to local OVSDB keeps being dropped, because no probe
response. The probe interval is set to 30s already.

2020-08-05T02:47:15.437Z|04351|poll_loop|INFO|wakeup due to [POLLIN] on fd 20 
(10.6.20.22:42362<->10.6.20.86:6642) at lib/stream-fd.c:157 (100% CPU usage)
2020-08-05T02:47:15.438Z|04352|reconnect|WARN|tcp:127.0.0.1:6640: connection 
dropped (Broken pipe)
2020-08-05T02:47:15.438Z|04353|rconn|INFO|unix:/var/run/openvswitch/br-int.mgmt:
 connecting...
2020-08-05T02:47:15.449Z|04354|rconn|INFO|unix:/var/run/openvswitch/br-int.mgmt:
 connected


Also error about localnet port.

2020-08-05T02:47:15.403Z|04345|patch|ERR|bridge not found for localnet port 
'provnet-006baf64-409d-434d-b95b-017a77969b55' with network name 'physnet1'


First of all, this kind of scale should work fine, right?

Any advices how to look into it?


Thanks!

Tony

> -Original Message-
> From: dev  On Behalf Of Tony Liu
> Sent: Monday, July 27, 2020 10:16 AM
> To: Han Zhou 
> Cc: ovs-dev@openvswitch.org; ovs-disc...@openvswitch.org
> Subject: Re: [ovs-dev] [ovs-discuss] OVN scale
> 
> Hi Han,
> 
> Just some updates here.
> 
> I tried with 4K networks on single router. Configuration was done
> without any issues. I checked both nb-db and sb-db, they all look good.
> It's just that router configuration is huge (in Neutron DB, nb-db and
> flow table in sb-db), because it contains all 4K ports. Also, the
> pipeline of router datapath in sb-db is quite big.
> 
> I see ovn-northd master and sb-db leader are busy, taking 90+% CPU.
> There are only 3 compute nodes and 2 gateway nodes. Does that monitor
> setting "ovn-monitor-all" matters in such case? Any idea what they are
> busy with, without any configuration updates from OpenStack? The nb-db
> is not busy though.
> 
> Probably because nb-db is busy, ovn-controller can't connect to it
> consistently. It keeps being disconnected and reconnecting. Restarting
> ovn-controller seems help. I am able to launch a few VMs on different
> networks and they are connected via the router.
> 
> Now, I have problem on external access. The router is set as gateway to
> a provider/underlay network on an interface on the gateway node. The
> router is allocated an underlay address from that provider network. My
> understanding is that, the br-ex on gateway node holding the active
> router will broadcast ARP to announce that router underlay address in
> case of failover. Also, it will respond ARP request for that router
> underlay address. But when I run tcpdump on that underlay interface on
> gateway node, I see ARP request coming in, but no ARP response going out.
> I checked the flow table in sb-db, it seems ok. I also checked flow on
> br-ex by "ovs-ofctl dump-flows br-ex", I don't see anything about ARP
> there.
> How should I look into it?
> 
> Again, the case is to support 4K networks with external access (security
> group is disabled), 4K routers (one for each network), 50 routers (one
> for 80 networks), 1 router (for all 4K networks)...
> All networks are isolated by ACL on the logical router. Which option
> should work better?
> Any comment is appreciated.
> 
> 
> Thanks!
> 
> Tony
> 
> 
> 
> From: discuss  on behalf of Tony
> Liu 
> Sent: July 21, 2020 09:09 PM
> To: Daniel Alvarez 
> Cc: ovs-disc...@openvswitch.org 
> Subject: Re: [ovs-discuss] OVN scale
> 
> [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 

Re: [ovs-dev] WARNING: suspicious RCU usage in ovs_flow_tbl_masks_cache_size

[syzbot]

syzbot has bisected this issue to:

commit 9bf24f594c6acf676fb8c229f152c21bfb915ddb
Author: Eelco Chaudron 
Date:   Fri Jul 31 12:21:34 2020 +

net: openvswitch: make masks cache size configurable

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=110e06dc90
start commit:   2f631133 net: Pass NULL to skb_network_protocol() when we ..
git tree:   net-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=130e06dc90
console output: https://syzkaller.appspot.com/x/log.txt?x=150e06dc90
kernel config:  https://syzkaller.appspot.com/x/.config?x=91a13b78c7dc258d
dashboard link: https://syzkaller.appspot.com/bug?extid=f612c02823acb02ff9bc
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=10e8430a90
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=123549fc90

Reported-by: syzbot+f612c02823acb02ff...@syzkaller.appspotmail.com
Fixes: 9bf24f594c6a ("net: openvswitch: make masks cache size configurable")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [ovs-discuss] [OVN] no response to inactivity probe

[Tony Liu]

In that case, I can use set-connection to set one row.


Thanks!

Tony

> -Original Message-
> From: Han Zhou 
> Sent: Tuesday, August 4, 2020 4:44 PM
> To: Tony Liu 
> Cc: Numan Siddique ; Han Zhou ; ovs-
> discuss ; ovs-dev 
> Subject: Re: [ovs-discuss] [OVN] no response to inactivity probe
> 
> 
> 
> On Tue, Aug 4, 2020 at 2:50 PM Tony Liu   > wrote:
> 
> 
>   Hi,
> 
>   Since I have 3 OVN DB nodes, should I add 3 rows in connection
> table
>   for the inactivity_probe? Or put 3 addresses into one row?
> 
>   "set-connection" set one row only, and there is no "add-connection".
>   How should I add 3 rows into the table connection?
> 
> 
> 
> 
> You only need to set one row. Try this command:
> 
> ovn-nbctl -- --id=@conn_uuid create Connection
> target="ptcp\:6641\:0.0.0.0" inactivity_probe=0 -- set NB_Global .
> connections=@conn_uuid
> 
> 
> 
>   Thanks!
> 
>   Tony
> 
>   > -Original Message-
>   > From: Numan Siddique mailto:num...@ovn.org> >
>   > Sent: Tuesday, August 4, 2020 12:36 AM
>   > To: Tony Liu   >
>   > Cc: ovs-discuss mailto:ovs-
> disc...@openvswitch.org> >; ovs-dev> d...@openvswitch.org  >
>   > Subject: Re: [ovs-discuss] [OVN] no response to inactivity probe
>   >
>   >
>   >
>   > On Tue, Aug 4, 2020 at 9:12 AM Tony Liu  
>   >   > > wrote:
>   >
>   >
>   >   In my deployment, on each Neutron server, there are 13
> Neutron
>   > server processes.
>   >   I see 12 of them (monitor, maintenance, RPC, API) connect
> to both
>   > ovn-nb-db
>   >   and ovn-sb-db. With 3 Neutron server nodes, that's 36 OVSDB
> clients.
>   >   Is so many clients OK?
>   >
>   >   Any suggestions how to figure out which side doesn't
> respond the
>   > probe,
>   >   if it's bi-directional? I don't see any activities from
> logging,
>   > other than
>   >   connect/drop and reconnect...
>   >
>   >   BTW, please let me know if this is not the right place to
> discuss
>   > Neutron OVN
>   >   ML2 driver.
>   >
>   >
>   >   Thanks!
>   >
>   >   Tony
>   >
>   >   > -Original Message-
>   >   > From: dev mailto:ovs-
> dev-boun...@openvswitch.org>  
>   > boun...@openvswitch.org  > > On
> Behalf Of Tony Liu
>   >   > Sent: Monday, August 3, 2020 7:45 PM
>   >   > To: ovs-discuss mailto:ovs-
> disc...@openvswitch.org>  
>   > disc...@openvswitch.org  > >;
> ovs-dev>   > d...@openvswitch.org 
>  > >
>   >   > Subject: [ovs-dev] [OVN] no response to inactivity probe
>   >   >
>   >   > Hi,
>   >   >
>   >   > Neutron OVN ML2 driver was disconnected by ovn-nb-db.
> There are
>   > many
>   >   > error messages from ovn-nb-db leader.
>   >   > 
>   >   > 2020-08-
> 04T02:31:39.751Z|03138|reconnect|ERR|tcp:10.6.20.81:58620
> 
>   >  : no
>   >   > response to inactivity probe after 5 seconds,
> disconnecting
>   >   > 2020-08-
> 04T02:31:42.484Z|03139|reconnect|ERR|tcp:10.6.20.81:58300
> 
>   >  : no
>   >   > response to inactivity probe after 5 seconds,
> disconnecting
>   >   > 2020-08-
> 04T02:31:49.858Z|03140|reconnect|ERR|tcp:10.6.20.81:59582
> 
>   >  : no
>   >   > response to inactivity probe after 5 seconds,
> disconnecting
>   >   > 2020-08-
> 04T02:31:53.057Z|03141|reconnect|ERR|tcp:10.6.20.83:42626
> 
>   >  : no
>   >   > response to inactivity probe after 5 seconds,
> disconnecting
>   >   > 2020-08-
> 04T02:31:53.058Z|03142|reconnect|ERR|tcp:10.6.20.82:45412
> 
>   >  : no
>   >   > response to inactivity probe after 5 seconds,
> disconnecting
>   >   > 2020-08-
> 04T02:31:54.067Z|03143|reconnect|ERR|tcp:10.6.20.81:59416
> 
>   >  : no
>   >   > response to inactivity probe after 5 seconds,
> disconnecting
>   >   > 2020-08-
> 04T02:31:54.809Z|03144|reconnect|ERR|tcp:10.6.20.81:60004
> 
>   >  : no
>   >   > response to inactivity probe after 5 seconds,
> 

Re: [ovs-dev] [ovs-discuss] [OVN] no response to inactivity probe

[Han Zhou]

On Tue, Aug 4, 2020 at 2:50 PM Tony Liu  wrote:

> Hi,
>
> Since I have 3 OVN DB nodes, should I add 3 rows in connection table
> for the inactivity_probe? Or put 3 addresses into one row?
>
> "set-connection" set one row only, and there is no "add-connection".
> How should I add 3 rows into the table connection?
>
>
You only need to set one row. Try this command:

ovn-nbctl -- --id=@conn_uuid create Connection target="ptcp\:6641\:0.0.0.0"
inactivity_probe=0 -- set NB_Global . connections=@conn_uuid


> Thanks!
>
> Tony
>
> > -Original Message-
> > From: Numan Siddique 
> > Sent: Tuesday, August 4, 2020 12:36 AM
> > To: Tony Liu 
> > Cc: ovs-discuss ; ovs-dev  > d...@openvswitch.org>
> > Subject: Re: [ovs-discuss] [OVN] no response to inactivity probe
> >
> >
> >
> > On Tue, Aug 4, 2020 at 9:12 AM Tony Liu  >  > wrote:
> >
> >
> >   In my deployment, on each Neutron server, there are 13 Neutron
> > server processes.
> >   I see 12 of them (monitor, maintenance, RPC, API) connect to both
> > ovn-nb-db
> >   and ovn-sb-db. With 3 Neutron server nodes, that's 36 OVSDB
> clients.
> >   Is so many clients OK?
> >
> >   Any suggestions how to figure out which side doesn't respond the
> > probe,
> >   if it's bi-directional? I don't see any activities from logging,
> > other than
> >   connect/drop and reconnect...
> >
> >   BTW, please let me know if this is not the right place to discuss
> > Neutron OVN
> >   ML2 driver.
> >
> >
> >   Thanks!
> >
> >   Tony
> >
> >   > -Original Message-
> >   > From: dev mailto:ovs-dev-
> > boun...@openvswitch.org> > On Behalf Of Tony Liu
> >   > Sent: Monday, August 3, 2020 7:45 PM
> >   > To: ovs-discuss mailto:ovs-
> > disc...@openvswitch.org> >; ovs-dev  >   > d...@openvswitch.org  >
> >   > Subject: [ovs-dev] [OVN] no response to inactivity probe
> >   >
> >   > Hi,
> >   >
> >   > Neutron OVN ML2 driver was disconnected by ovn-nb-db. There are
> > many
> >   > error messages from ovn-nb-db leader.
> >   > 
> >   > 2020-08-04T02:31:39.751Z|03138|reconnect|ERR|tcp:
> 10.6.20.81:58620
> >  : no
> >   > response to inactivity probe after 5 seconds, disconnecting
> >   > 2020-08-04T02:31:42.484Z|03139|reconnect|ERR|tcp:
> 10.6.20.81:58300
> >  : no
> >   > response to inactivity probe after 5 seconds, disconnecting
> >   > 2020-08-04T02:31:49.858Z|03140|reconnect|ERR|tcp:
> 10.6.20.81:59582
> >  : no
> >   > response to inactivity probe after 5 seconds, disconnecting
> >   > 2020-08-04T02:31:53.057Z|03141|reconnect|ERR|tcp:
> 10.6.20.83:42626
> >  : no
> >   > response to inactivity probe after 5 seconds, disconnecting
> >   > 2020-08-04T02:31:53.058Z|03142|reconnect|ERR|tcp:
> 10.6.20.82:45412
> >  : no
> >   > response to inactivity probe after 5 seconds, disconnecting
> >   > 2020-08-04T02:31:54.067Z|03143|reconnect|ERR|tcp:
> 10.6.20.81:59416
> >  : no
> >   > response to inactivity probe after 5 seconds, disconnecting
> >   > 2020-08-04T02:31:54.809Z|03144|reconnect|ERR|tcp:
> 10.6.20.81:60004
> >  : no
> >   > response to inactivity probe after 5 seconds, disconnecting
> > 
> >   >
> >   > Could anyone share a bit details how this inactivity probe works?
> >
> >
> >
> > The inactivity probe is sent by both the server and clients
> > independently.
> > Meaning ovsdb-server will send an inactivity probe every 'x' configured
> > seconds to all its connected clients and if it doesn't get a reply from
> > the client within some time, it disconnects the connection.
> >
> > The inactivity probe from the server side can be configured. Run "ovn-
> > nbctl list connection"
> > and you will see inactivity_probe column. You can set this column to
> > desired value like - ovn-nbctl set connection . inactivity_probe=3
> > (for 30 seconds)
> >
> > The same thing for SB ovsdb-server.
> >
> > Similarly each client (ovn-northd, ovn-controller, neutron server) sends
> > inactivity probe every 'y' seconds and if the client doesn't get any
> > reply from ovsdb-server it will disconnect the connection and reconnect
> > again.
> >
> > For ovn-northd you can configured this as - ovn-nbctl set NB_Global .
> > options:northd_probe_interval=3
> >
> > For ovn-controllers - ovs-vsctl set open . external_ids:ovn-remote-
> > probe-interval=3
> >
> > There is also a probe interval for openflow connection from ovn-
> > controller to ovs-vswitchd which you can configure as ovs-vsctl set
> > open . external_ids:ovn-openflow-probe-interval=30 (this is in seconds)
> >
> >
> > Regarding the neutron server I think it is set to 60 seconds. Please see
> > this -
> > 

Re: [ovs-dev] [ovs-discuss] [OVN] ovn-northd takes much CPU when no configuration update

[Tony Liu]

Hi Han,

Sounds good. I am looking forward to incremental-processing,
and will go from there.

BTW, it would be great if you could let me know how to set probe
interval for 3-node cluster, here or in another thread.


Thanks!

Tony

> -Original Message-
> From: Han Zhou 
> Sent: Tuesday, August 4, 2020 4:02 PM
> To: Tony Liu 
> Cc: Han Zhou ; Numan Siddique ; Ben Pfaff
> ; Leonid Ryzhyk ; ovs-dev  d...@openvswitch.org>; ovs-discuss 
> Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when no
> configuration update
> 
> Hi Tony,
> 
> I am glad it is more clear now. For your concern regarding taking too
> much time for one round of computing, it is valid, but I guess it is not
> directly related to the IDLE probe any more, right?
> The OVSDB IDL in fact already does some of the work of caping and
> buffering like what you proposed. The IDL will read a limited number of
> messages to get processed in each round (and the remaining messages are
> buffered in the stream). However, sometimes a single notification
> message can contain a huge amount of data. It is hard to split the data
> from one single notification, because the data are internally dependent
> on each other.
> 
> Without incremental-processing, the size of the data change doesn't
> matter much because all data is recomputed anyway. I'd suggest to see
> what's the outcome of incremental-processing, and see if any further
> improvement is still needed for handling big transactions.
> 
> In my opinion, the special cases of a big data change triggered by
> scenarios such as data restore can be handled by operational approaches
> instead of implementation. For example, you could adjust the probe
> interval before doing data restore, and change it back afterwards. But
> of course, if there are good ways to implement we should definitely
> consider.
> 
> 
> Thanks,
> Han
> 
> 
> On Tue, Aug 4, 2020 at 2:00 PM Tony Liu   > wrote:
> 
> 
>   Hi Han,
> 
>   Thanks for clarifications! It's crystal clear.
> 
>   My concern, in general, is blocking. For onv-northd, or OVSDB
> client,
>   (I assume all OVSDB clients are using the same library for
> connection,
>   proble, etc.?) when handing current event, it won't be interrupted
> to
>   handle any incoming event, right? How long does it take to handle a
>   computing event for big chunk of data? How much data can be
> buffered
>   to be computed? Is there estimated maximum time for handle so much
> data?
> 
>   In case it takes more than 5s to process an event, then the peer
> will
>   drop the connection because of probe timeout.
> 
>   With incremental-process, if I restore DB, then that still could be
> a
>   huge incremental, unless the incremental size is controlled. That's
>   probably why you recommend to restore to existing cluster, to avoid
>   huge incremental from restoring to a fresh cluster. Am I right?
> 
>   What I used to do is to chop big data into pieces and to be handled
> by
>   multiple event loops. That way, other events will have a chance to
> get
>   processed. So big chunk of data won't cause blocking.
> 
>   Enlarge probe interval will sort of resolve the issue, but it will
> lose
>   the point of probing. Just like that election timer, enlarge the
> timer
>   avoids often failover, but it also increases the failover time when
> real
>   problem happens. And yes, I agree that it's on control plane and
> doesn't
>   break data plane, but just like in networking world, routing
> convergence
>   is very important.
> 
>   I am thinking, in your incremental-processing, if the time for each
> event
>   loop can be capped or controlled, that would be very helpful. The
> side
>   effect of that option is memory consumption. You will need to
> buffer more
>   data. But today, it's lots easier to increase memory to boost
> performance.
> 
> 
>   Thanks!
> 
>   Tony
> 
>   > -Original Message-
>   > From: Han Zhou mailto:hz...@ovn.org> >
>   > Sent: Tuesday, August 4, 2020 12:34 PM
>   > To: Tony Liu   >
>   > Cc: Han Zhou mailto:hz...@ovn.org> >; Numan
> Siddique mailto:num...@ovn.org> >; Ben Pfaff
>   > mailto:b...@ovn.org> >; Leonid Ryzhyk
> mailto:lryz...@vmware.com> >; ovs-dev> d...@openvswitch.org  >; ovs-discuss
> mailto:ovs-disc...@openvswitch.org> >
>   > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when
> no
>   > configuration update
>   >
>   >
>   >
>   > On Tue, Aug 4, 2020 at 11:40 AM Tony Liu  
>   >   > > wrote:
>   >
>   >
>   >   Inline...
>   >
>   >   Thanks!
>   >
>   >   Tony
>   >   > -Original Message-
>   >  

Re: [ovs-dev] [ovs-discuss] [OVN] ovn-northd takes much CPU when no configuration update

[Han Zhou]

Hi Tony,

I am glad it is more clear now. For your concern regarding taking too much
time for one round of computing, it is valid, but I guess it is not
directly related to the IDLE probe any more, right?
The OVSDB IDL in fact already does some of the work of caping and buffering
like what you proposed. The IDL will read a limited number of messages to
get processed in each round (and the remaining messages are buffered in the
stream). However, sometimes a single notification message can contain a
huge amount of data. It is hard to split the data from one single
notification, because the data are internally dependent on each other.
Without incremental-processing, the size of the data change doesn't matter
much because all data is recomputed anyway. I'd suggest to see what's the
outcome of incremental-processing, and see if any further improvement is
still needed for handling big transactions.
In my opinion, the special cases of a big data change triggered by
scenarios such as data restore can be handled by operational approaches
instead of implementation. For example, you could adjust the probe interval
before doing data restore, and change it back afterwards. But of course, if
there are good ways to implement we should definitely consider.

Thanks,
Han

On Tue, Aug 4, 2020 at 2:00 PM Tony Liu  wrote:

> Hi Han,
>
> Thanks for clarifications! It's crystal clear.
>
> My concern, in general, is blocking. For onv-northd, or OVSDB client,
> (I assume all OVSDB clients are using the same library for connection,
> proble, etc.?) when handing current event, it won't be interrupted to
> handle any incoming event, right? How long does it take to handle a
> computing event for big chunk of data? How much data can be buffered
> to be computed? Is there estimated maximum time for handle so much data?
>
> In case it takes more than 5s to process an event, then the peer will
> drop the connection because of probe timeout.
>
> With incremental-process, if I restore DB, then that still could be a
> huge incremental, unless the incremental size is controlled. That's
> probably why you recommend to restore to existing cluster, to avoid
> huge incremental from restoring to a fresh cluster. Am I right?
>
> What I used to do is to chop big data into pieces and to be handled by
> multiple event loops. That way, other events will have a chance to get
> processed. So big chunk of data won't cause blocking.
>
> Enlarge probe interval will sort of resolve the issue, but it will lose
> the point of probing. Just like that election timer, enlarge the timer
> avoids often failover, but it also increases the failover time when real
> problem happens. And yes, I agree that it's on control plane and doesn't
> break data plane, but just like in networking world, routing convergence
> is very important.
>
> I am thinking, in your incremental-processing, if the time for each event
> loop can be capped or controlled, that would be very helpful. The side
> effect of that option is memory consumption. You will need to buffer more
> data. But today, it's lots easier to increase memory to boost performance.
>
>
> Thanks!
>
> Tony
>
> > -Original Message-
> > From: Han Zhou 
> > Sent: Tuesday, August 4, 2020 12:34 PM
> > To: Tony Liu 
> > Cc: Han Zhou ; Numan Siddique ; Ben Pfaff
> > ; Leonid Ryzhyk ; ovs-dev  > d...@openvswitch.org>; ovs-discuss 
> > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when no
> > configuration update
> >
> >
> >
> > On Tue, Aug 4, 2020 at 11:40 AM Tony Liu  >  > wrote:
> >
> >
> >   Inline...
> >
> >   Thanks!
> >
> >   Tony
> >   > -Original Message-
> >   > From: Han Zhou mailto:hz...@ovn.org> >
> >   > Sent: Tuesday, August 4, 2020 11:01 AM
> >   > To: Numan Siddique mailto:num...@ovn.org> >;
> Ben
> > Pfaff mailto:b...@ovn.org> >; Leonid
> >   > Ryzhyk mailto:lryz...@vmware.com> >
> >   > Cc: Tony Liu  >  >; Han Zhou  >  >; ovs-
> >   > dev mailto:ovs-dev@openvswitch.org> >;
> > ovs-discuss mailto:ovs-
> > disc...@openvswitch.org> >
> >   > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when
> > no
> >   > configuration update
> >   >
> >   >
> >   >
> >   > On Tue, Aug 4, 2020 at 12:38 AM Numan Siddique  > 
> >   >  > > wrote:
> >   >
> >   >
> >   >
> >   >
> >   >   On Tue, Aug 4, 2020 at 9:02 AM Tony Liu
> > mailto:tonyliu0...@hotmail.com>
> >   >  >  > > wrote:
> >   >
> >   >
> >   >   The probe awakes recomputing?
> >   >   There is probe every 5 seconds. Without any
> > connection
> >   > up/down or failover,
> >   >   ovn-northd will recompute everything every 5
> > seconds, no
> >   > 

Re: [ovs-dev] [ovs-discuss] [OVN] no response to inactivity probe

[Tony Liu]

Hi,

Since I have 3 OVN DB nodes, should I add 3 rows in connection table
for the inactivity_probe? Or put 3 addresses into one row?

"set-connection" set one row only, and there is no "add-connection".
How should I add 3 rows into the table connection?


Thanks!

Tony

> -Original Message-
> From: Numan Siddique 
> Sent: Tuesday, August 4, 2020 12:36 AM
> To: Tony Liu 
> Cc: ovs-discuss ; ovs-dev  d...@openvswitch.org>
> Subject: Re: [ovs-discuss] [OVN] no response to inactivity probe
> 
> 
> 
> On Tue, Aug 4, 2020 at 9:12 AM Tony Liu   > wrote:
> 
> 
>   In my deployment, on each Neutron server, there are 13 Neutron
> server processes.
>   I see 12 of them (monitor, maintenance, RPC, API) connect to both
> ovn-nb-db
>   and ovn-sb-db. With 3 Neutron server nodes, that's 36 OVSDB clients.
>   Is so many clients OK?
> 
>   Any suggestions how to figure out which side doesn't respond the
> probe,
>   if it's bi-directional? I don't see any activities from logging,
> other than
>   connect/drop and reconnect...
> 
>   BTW, please let me know if this is not the right place to discuss
> Neutron OVN
>   ML2 driver.
> 
> 
>   Thanks!
> 
>   Tony
> 
>   > -Original Message-
>   > From: dev mailto:ovs-dev-
> boun...@openvswitch.org> > On Behalf Of Tony Liu
>   > Sent: Monday, August 3, 2020 7:45 PM
>   > To: ovs-discuss mailto:ovs-
> disc...@openvswitch.org> >; ovs-dev> d...@openvswitch.org  >
>   > Subject: [ovs-dev] [OVN] no response to inactivity probe
>   >
>   > Hi,
>   >
>   > Neutron OVN ML2 driver was disconnected by ovn-nb-db. There are
> many
>   > error messages from ovn-nb-db leader.
>   > 
>   > 2020-08-04T02:31:39.751Z|03138|reconnect|ERR|tcp:10.6.20.81:58620
>  : no
>   > response to inactivity probe after 5 seconds, disconnecting
>   > 2020-08-04T02:31:42.484Z|03139|reconnect|ERR|tcp:10.6.20.81:58300
>  : no
>   > response to inactivity probe after 5 seconds, disconnecting
>   > 2020-08-04T02:31:49.858Z|03140|reconnect|ERR|tcp:10.6.20.81:59582
>  : no
>   > response to inactivity probe after 5 seconds, disconnecting
>   > 2020-08-04T02:31:53.057Z|03141|reconnect|ERR|tcp:10.6.20.83:42626
>  : no
>   > response to inactivity probe after 5 seconds, disconnecting
>   > 2020-08-04T02:31:53.058Z|03142|reconnect|ERR|tcp:10.6.20.82:45412
>  : no
>   > response to inactivity probe after 5 seconds, disconnecting
>   > 2020-08-04T02:31:54.067Z|03143|reconnect|ERR|tcp:10.6.20.81:59416
>  : no
>   > response to inactivity probe after 5 seconds, disconnecting
>   > 2020-08-04T02:31:54.809Z|03144|reconnect|ERR|tcp:10.6.20.81:60004
>  : no
>   > response to inactivity probe after 5 seconds, disconnecting
> 
>   >
>   > Could anyone share a bit details how this inactivity probe works?
> 
> 
> 
> The inactivity probe is sent by both the server and clients
> independently.
> Meaning ovsdb-server will send an inactivity probe every 'x' configured
> seconds to all its connected clients and if it doesn't get a reply from
> the client within some time, it disconnects the connection.
> 
> The inactivity probe from the server side can be configured. Run "ovn-
> nbctl list connection"
> and you will see inactivity_probe column. You can set this column to
> desired value like - ovn-nbctl set connection . inactivity_probe=3
> (for 30 seconds)
> 
> The same thing for SB ovsdb-server.
> 
> Similarly each client (ovn-northd, ovn-controller, neutron server) sends
> inactivity probe every 'y' seconds and if the client doesn't get any
> reply from ovsdb-server it will disconnect the connection and reconnect
> again.
> 
> For ovn-northd you can configured this as - ovn-nbctl set NB_Global .
> options:northd_probe_interval=3
> 
> For ovn-controllers - ovs-vsctl set open . external_ids:ovn-remote-
> probe-interval=3
> 
> There is also a probe interval for openflow connection from ovn-
> controller to ovs-vswitchd which you can configure as ovs-vsctl set
> open . external_ids:ovn-openflow-probe-interval=30 (this is in seconds)
> 
> 
> Regarding the neutron server I think it is set to 60 seconds. Please see
> this -
> https://github.com/openstack/neutron/blob/master/neutron/conf/plugins/ml
> 2/drivers/ovn/ovn_conf.py#L80
> 
> From the logs you shared, it looks like ovsdb-server is not getting the
> probe reply from neutron server after 5 seconds and hence it is
> disconnecting. Not sure what's happening though.
> 
> You can try increasing the inactivity probe interval on the ovsdb-server
> side with the first command I shared.
> Note: If "ovn-nbctl list connection" returns empty, you need to create a
> 

Re: [ovs-dev] [PATCH v4 2/2 ovn] External IP based NAT: NORTHD changes to use applied/exempted external ip

[0-day Robot]

Bleep bloop.  Greetings svc.mail.git, 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: Empty return followed by brace, consider omitting
#50 FILE: northd/ovn-northd.c:8268:
}

WARNING: Line is 80 characters long (recommended limit is 79)
#137 FILE: northd/ovn-northd.c:9552:
lrouter_nat_add_ext_ip_match(, nat, is_v6, false);

WARNING: Line is 80 characters long (recommended limit is 79)
#149 FILE: northd/ovn-northd.c:9597:
lrouter_nat_add_ext_ip_match(, nat, is_v6, false);

Lines checked: 295, Warnings: 3, 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] [ovs-discuss] [OVN] ovn-northd takes much CPU when no configuration update

[Tony Liu]

Hi Han,

Thanks for clarifications! It's crystal clear.

My concern, in general, is blocking. For onv-northd, or OVSDB client,
(I assume all OVSDB clients are using the same library for connection,
proble, etc.?) when handing current event, it won't be interrupted to
handle any incoming event, right? How long does it take to handle a
computing event for big chunk of data? How much data can be buffered
to be computed? Is there estimated maximum time for handle so much data?

In case it takes more than 5s to process an event, then the peer will
drop the connection because of probe timeout.

With incremental-process, if I restore DB, then that still could be a
huge incremental, unless the incremental size is controlled. That's
probably why you recommend to restore to existing cluster, to avoid
huge incremental from restoring to a fresh cluster. Am I right?

What I used to do is to chop big data into pieces and to be handled by
multiple event loops. That way, other events will have a chance to get
processed. So big chunk of data won't cause blocking.

Enlarge probe interval will sort of resolve the issue, but it will lose
the point of probing. Just like that election timer, enlarge the timer
avoids often failover, but it also increases the failover time when real
problem happens. And yes, I agree that it's on control plane and doesn't
break data plane, but just like in networking world, routing convergence
is very important.

I am thinking, in your incremental-processing, if the time for each event
loop can be capped or controlled, that would be very helpful. The side
effect of that option is memory consumption. You will need to buffer more
data. But today, it's lots easier to increase memory to boost performance.


Thanks!

Tony

> -Original Message-
> From: Han Zhou 
> Sent: Tuesday, August 4, 2020 12:34 PM
> To: Tony Liu 
> Cc: Han Zhou ; Numan Siddique ; Ben Pfaff
> ; Leonid Ryzhyk ; ovs-dev  d...@openvswitch.org>; ovs-discuss 
> Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when no
> configuration update
> 
> 
> 
> On Tue, Aug 4, 2020 at 11:40 AM Tony Liu   > wrote:
> 
> 
>   Inline...
> 
>   Thanks!
> 
>   Tony
>   > -Original Message-
>   > From: Han Zhou mailto:hz...@ovn.org> >
>   > Sent: Tuesday, August 4, 2020 11:01 AM
>   > To: Numan Siddique mailto:num...@ovn.org> >; Ben
> Pfaff mailto:b...@ovn.org> >; Leonid
>   > Ryzhyk mailto:lryz...@vmware.com> >
>   > Cc: Tony Liu   >; Han Zhou   >; ovs-
>   > dev mailto:ovs-dev@openvswitch.org> >;
> ovs-discuss mailto:ovs-
> disc...@openvswitch.org> >
>   > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when
> no
>   > configuration update
>   >
>   >
>   >
>   > On Tue, Aug 4, 2020 at 12:38 AM Numan Siddique  
>   >  > > wrote:
>   >
>   >
>   >
>   >
>   >   On Tue, Aug 4, 2020 at 9:02 AM Tony Liu
> mailto:tonyliu0...@hotmail.com>
>   >   > > wrote:
>   >
>   >
>   >   The probe awakes recomputing?
>   >   There is probe every 5 seconds. Without any
> connection
>   > up/down or failover,
>   >   ovn-northd will recompute everything every 5
> seconds, no
>   > matter what?
>   >   Really?
>   >
>   >   Anyways, I will increase the probe interval for now,
> see if
>   > that helps.
>   >
>   >
>   >
>   >   I think we should optimise this case. I am planning to look
> into
>   > this.
>   >
>   >   Thanks
>   >   Numan
>   >
>   >
>   > Thanks Numan.
>   > I'd like to discuss more on this before we move forward to change
>   > anything.
>   >
>   > 1) Regarding the problem itself, the CPU cost triggered by OVSDB
> IDLE
>   > probe when there is no configuration change to compute, I don't
> think it
>   > matters that much in real production. It simply wastes CPU cycles
> when
>   > there is nothing to do, so what harm would it do here? For ovn-
> northd,
>   > since it is the centralized component, we would always ensure
> there is
>   > enough CPU available for ovn-north when computing is needed, and
> this
>   > reservation will be wasted anyway when there is no change to
> compute. So,
>   > I'd avoid making any change specifically only to address this
> issue. I
>   > could be wrong, though. I'd like to hear what would be the real
> concern
>   > if this is not addressed.
> 
>   Is more vCPUs going to help here? Is ovn-northd multi-thread?
> 
> 
> 
> 
> ovn-northd is single threaded. It can be changed to have a separate
> thread for the probe handling, but I don't see any obvious benefit.
> 

Re: [ovs-dev] [PATCH v4 1/2 ovn] External IP based NAT: Add Columns and CLI

[0-day Robot]

Bleep bloop.  Greetings svc.mail.git, I am a robot and I have tried out your 
patch.
Thanks for your contribution.

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


checkpatch:
ERROR: Improper whitespace around control block
#186 FILE: utilities/ovn-nbctl.c:861:
NBREC_ADDRESS_SET_FOR_EACH(iter, ctx->idl) {

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


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 v3 0/2 ovn] External IP based NAT

[svc . mail . git]

Hi Numan,

Just submitted V4. Appreciate your feedback.

Regards,
Ankur


From: Numan Siddique 
Sent: Monday, August 3, 2020 2:45 AM
To: svc.mail.git 
Cc: ovs-dev 
Subject: Re: [ovs-dev] [PATCH v3 0/2 ovn] External IP based NAT



On Thu, Jul 9, 2020 at 5:55 AM Ankur Sharma 
mailto:svc.mail@nutanix.com>> wrote:
Another term for this feature is destination based NAT,
especially in the context of SNAT.

Current NAT implementation is OVN endpoint ip based.
For example,

# ovn-nbctl lr-nat-list router
TYPE EXTERNAL_IPLOGICAL_IP
snat 10.15.24.135   50.0.0.0/24 
[50.0.0.0]

# ovn-nbctl lr-route-list router
IPv4 Routes
0.0.0.0/0 
[0.0.0.0]
10.15.24.1 dst-ip

Above configuration implies that anytime packet from
50.0.0.0/24 
[50.0.0.0]
 leaves logical router space (through default route),
then it will be NATed.

Similarly, if we remove the NAT rule, then packet from
50.0.0.0/24 
[50.0.0.0]
 leaves logical router space, without any NAT.

i.e as of now in OVN, NAT/NON-NAT based communication from an endpoint
with external ips is mutually exclusive. This feature allows
external ips to be specified in NAT rule so that we can decide
which external ips we want to apply a rule on. That ways a given
source ip can talk to external ips with NAT and without NAT as well.

One of the key usecases for this feature if a logical router has
to talk to endpoints outside the logical router space (i.e NS traffic),
but we dont have to do NAT for all the external endpoints.
i.e logical router is peered to (some) external subnets, and non
overlapping ips between logical router and external subnet
space are ensured.

Ankur Sharma (2):
  External IP based NAT: Add Columns and CLI
  External IP based NAT: NORTHD changes to use applied/exempted external

Hi Ankur,

Can you please rebase these patches and submit v4 ? These patches don't apply 
on top of the master.

Thanks
Numan

ip

 northd/ovn-northd.c   |  61 
 ovn-nb.ovsschema  |  14 +-
 ovn-nb.xml|  35 ++
 tests/ovn-nbctl.at 
[ovn-nbctl.at]
|  44 -
 tests/ovn-northd.at 
[ovn-northd.at]
   | 127 ++
 utilities/ovn-nbctl.c | 116 -
 6 files changed, 393 insertions(+), 4 deletions(-)

--
1.8.3.1

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

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

[ovs-dev] [PATCH v4 0/2 ovn] External IP based NAT

[Ankur Sharma]

From: Ankur Sharma 

Another term for this feature is destination based NAT,
especially in the context of SNAT.

Current NAT implementation is OVN endpoint ip based.
For example,

# ovn-nbctl lr-nat-list router
TYPE EXTERNAL_IPLOGICAL_IP
snat 10.15.24.135   50.0.0.0/24

# ovn-nbctl lr-route-list router
IPv4 Routes
0.0.0.0/010.15.24.1 dst-ip

Above configuration implies that anytime packet from
50.0.0.0/24 leaves logical router space (through default route),
then it will be NATed.

Similarly, if we remove the NAT rule, then packet from
50.0.0.0/24 leaves logical router space, without any NAT.

i.e as of now in OVN, NAT/NON-NAT based communication from an endpoint
with external ips is mutually exclusive. This feature allows
external ips to be specified in NAT rule so that we can decide
which external ips we want to apply a rule on. That ways a given
source ip can talk to external ips with NAT and without NAT as well.

One of the key usecases for this feature if a logical router has
to talk to endpoints outside the logical router space (i.e NS traffic),
but we dont have to do NAT for all the external endpoints.
i.e logical router is peered to (some) external subnets, and non
overlapping ips between logical router and external subnet
space are ensured.

Ankur Sharma (2):
  External IP based NAT: Add Columns and CLI
  External IP based NAT: NORTHD changes to use applied/exempted external
ip

 northd/ovn-northd.c   |  61 
 ovn-nb.ovsschema  |  14 +-
 ovn-nb.xml|  35 ++
 tests/ovn-nbctl.at|  44 -
 tests/ovn-northd.at   | 127 ++
 utilities/ovn-nbctl.c | 116 -
 6 files changed, 393 insertions(+), 4 deletions(-)

-- 
1.8.3.1

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

[ovs-dev] [PATCH v4 1/2 ovn] External IP based NAT: Add Columns and CLI

[Ankur Sharma]

From: Ankur Sharma 

This patch adds following columns to NAT table.

a. applied_ext_ips:
   Represents Address Set of External IPs for which
   a NAT rule is applicable.

b. exempted_ext_ips:
   Represents Address Set of External IPs for which
   a NAT rule is NOT applicable.

Additionally, patch adds nbctl cli to set these column values.
ovn-nbctl [--is-applied] lr-nat-update-ext-ip

Signed-off-by: Ankur Sharma 
---
 ovn-nb.ovsschema  |  14 +-
 ovn-nb.xml|  35 +++
 tests/ovn-nbctl.at|  44 ++-
 utilities/ovn-nbctl.c | 116 +-
 4 files changed, 205 insertions(+), 4 deletions(-)

diff --git a/ovn-nb.ovsschema b/ovn-nb.ovsschema
index 0c939b7..84e7faf 100644
--- a/ovn-nb.ovsschema
+++ b/ovn-nb.ovsschema
@@ -1,7 +1,7 @@
 {
 "name": "OVN_Northbound",
-"version": "5.25.0",
-"cksum": "1354137211 26116",
+"version": "5.25.1",
+"cksum": "2404797365 26575",
 "tables": {
 "NB_Global": {
 "columns": {
@@ -403,6 +403,16 @@
  "snat",
  "dnat_and_snat"
]]}}},
+"applied_ext_ips": {"type": {
+"key": {"type": "uuid", "refTable": "Address_Set",
+"refType": "strong"},
+"min": 0,
+"max": 1}},
+"exempted_ext_ips": {"type": {
+"key": {"type": "uuid", "refTable": "Address_Set",
+"refType": "strong"},
+"min": 0,
+"max": 1}},
 "options": {"type": {"key": "string", "value": "string",
  "min": 0, "max": "unlimited"}},
 "external_ids": {
diff --git a/ovn-nb.xml b/ovn-nb.xml
index 5e434d2..7c7ca85 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -2674,6 +2674,41 @@
   
 
 
+
+  It represents Address Set of external ips that NAT rule is applicable to.
+  For SNAT type NAT rules, this refers to destination addresses.
+  For DNAT type NAT rules, this refers to source addresses.
+
+  
+This configuration overrides the default NAT behavior of applying a
+rule solely based on internal IP. Without this configuration, NAT
+happens without considering the external IP (i.e dest/source for
+snat/dnat type rule). With this configuration NAT rule is applied
+ONLY if external ip is in the input Address Set.
+  
+
+
+
+  It represents Address Set of external ips that NAT rule is NOT
+  applicable to.
+  For SNAT type NAT rules, this refers to destination addresses.
+  For DNAT type NAT rules, this refers to source addresses.
+
+  
+This configuration overrides the default NAT behavior of applying a
+rule solely based on internal IP. Without this configuration, NAT
+happens without considering the external IP (i.e dest/source for
+snat/dnat type rule). With this configuration NAT rule is NOT applied
+if external ip is in the input Address Set.
+  
+
+  
+"applied_ext_ips" and "exempted_ext_ips" are mutually
+exclusive to each other. If both Address Sets are set for a rule,
+then the NAT rule is not applied.
+  
+
+
 
   Indicates if a dnat_and_snat rule should lead to connection
   tracking state or not.
diff --git a/tests/ovn-nbctl.at b/tests/ovn-nbctl.at
index 6d66087..40fc1e5 100644
--- a/tests/ovn-nbctl.at
+++ b/tests/ovn-nbctl.at
@@ -685,7 +685,49 @@ snat 40.0.0.3   21-65535 
192.168.1.6
 AT_CHECK([ovn-nbctl lr-nat-del lr0])
 AT_CHECK([ovn-nbctl lr-nat-list lr0], [0], [])
 AT_CHECK([ovn-nbctl lr-nat-del lr0])
-AT_CHECK([ovn-nbctl lr-nat-del lr0 dnat])])
+AT_CHECK([ovn-nbctl lr-nat-del lr0 dnat])
+
+AT_CHECK([ovn-nbctl lr-nat-del lr0])
+
+ovn-nbctl create Address_Set name=allowed_range addresses=\"1.1.1.1\"
+ovn-nbctl create Address_Set name=disallowed_range addresses=\"2.2.2.2\"
+AT_CHECK([ovn-nbctl lr-nat-add lr0 snat 40.0.0.3 192.168.1.6])
+AT_CHECK([ovn-nbctl lr-nat-update-ext-ip lr0 snat 192.168.1.6 
disallowed_range])
+AT_CHECK([ovn-nbctl --is-applied lr-nat-update-ext-ip lr0 snat 192.168.1.6 
allowed_range])
+AT_CHECK([ovn-nbctl lr-nat-update-ext-ip lr0 snat 192.168.1.6 
disallowed_range_tmp], [1], [],
+[ovn-nbctl: disallowed_range_tmp: Address Set name not found
+])
+AT_CHECK([ovn-nbctl --is-applied lr-nat-update-ext-ip lr0 snat 192.168.1.6 
allowed_range_tmp], [1], [],
+[ovn-nbctl: allowed_range_tmp: Address Set name not found
+])
+
+AT_CHECK([ovn-nbctl lr-nat-add lr0 dnat 40.0.0.4 192.168.1.7])
+AT_CHECK([ovn-nbctl lr-nat-update-ext-ip lr0 dnat 40.0.0.4 disallowed_range])
+AT_CHECK([ovn-nbctl --is-applied lr-nat-update-ext-ip lr0 

[ovs-dev] [PATCH v4 2/2 ovn] External IP based NAT: NORTHD changes to use applied/exempted external ip

[Ankur Sharma]

From: Ankur Sharma 

This patch has northd changes which consumes applied/exempted external ip
configuration per NAT rule in logical flow.

Applied/Exempted external ip range adds an additional match criteria in
snat/dnat/unsnat/undant logical flow rules.

For example, if an allowed_external_ip address set ("efgh")
is configured for following NAT rule.
TYPE EXTERNAL_IPLOGICAL_IP
snat 10.15.24.135   50.0.0.10

Then logical flow will look like following:
..(lr_out_snat)...match=(ip &&  && ip4.dst == $efgh), action=(ct_snat(...);)
...(lr_in_unsnat...)match=(ip && . && ip4.src == $efgh), action=(ct_snat;)

Signed-off-by: Ankur Sharma 
---
 northd/ovn-northd.c |  61 +
 tests/ovn-northd.at | 127 
 2 files changed, 188 insertions(+)

diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 03c62ba..17ae6a6 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -8250,6 +8250,23 @@ lrouter_nat_is_stateless(const struct nbrec_nat *nat)
 return false;
 }
 
+static inline void
+lrouter_nat_add_ext_ip_match(struct ds *match, const struct nbrec_nat *nat,
+ bool is_v6, bool is_src)
+{
+struct nbrec_address_set *applied_ext_ips = nat->applied_ext_ips;
+struct nbrec_address_set *exempted_ext_ips = nat->exempted_ext_ips;
+
+ds_put_format(match, " && ip%s.%s %s $%s",
+  is_v6 ? "6" : "4",
+  is_src ? "src" : "dst",
+  applied_ext_ips? "==" : "!=",
+  applied_ext_ips?
+  applied_ext_ips->name :
+  exempted_ext_ips->name);
+return;
+}
+
 /* Builds the logical flow that replies to ARP requests for an 'ip_address'
  * owned by the router. The flow is inserted in table S_ROUTER_IN_IP_INPUT
  * with the given priority.
@@ -9199,6 +9216,18 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
 struct in6_addr ipv6, mask_v6, v6_exact = IN6ADDR_EXACT_INIT;
 bool is_v6 = false;
 bool stateless = lrouter_nat_is_stateless(nat);
+struct nbrec_address_set *applied_ext_ips =
+  nat->applied_ext_ips;
+struct nbrec_address_set *exempted_ext_ips =
+  nat->exempted_ext_ips;
+
+if (applied_ext_ips && exempted_ext_ips) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 1);
+VLOG_WARN_RL(, "NAT rule: "UUID_FMT" not applied, since"
+ "both applied and exempt external ips set",
+ UUID_ARGS(&(nat->header_.uuid)));
+continue;
+}
 
 char *error = ip_parse_masked(nat->external_ip, , );
 if (error || mask != OVS_BE32_MAX) {
@@ -9286,6 +9315,10 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
 ds_put_format(, "ip && ip%s.dst == %s",
   is_v6 ? "6" : "4",
   nat->external_ip);
+if (applied_ext_ips || exempted_ext_ips) {
+lrouter_nat_add_ext_ip_match(, nat, is_v6, true);
+}
+
 if (!strcmp(nat->type, "dnat_and_snat") && stateless) {
ds_put_format(, "ip%s.dst=%s; next;",
  is_v6 ? "6" : "4", nat->logical_ip);
@@ -9315,6 +9348,10 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
   od->l3redirect_port->json_key);
 }
 
+if (applied_ext_ips || exempted_ext_ips) {
+lrouter_nat_add_ext_ip_match(, nat, is_v6, true);
+}
+
 if (!strcmp(nat->type, "dnat_and_snat") && stateless) {
 ds_put_format(, "ip%s.dst=%s; next;",
   is_v6 ? "6" : "4", nat->logical_ip);
@@ -9343,6 +9380,10 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
 ds_put_format(, "ip && ip%s.dst == %s",
   is_v6 ? "6" : "4",
   nat->external_ip);
+if (applied_ext_ips || exempted_ext_ips) {
+lrouter_nat_add_ext_ip_match(, nat, is_v6, true);
+}
+
 ds_clear();
 if (dnat_force_snat_ip) {
 /* Indicate to the future tables that a DNAT has taken
@@ -9386,6 +9427,11 @@ build_lrouter_flows(struct hmap *datapaths, struct hmap 
*ports,
 ds_put_format(, " && is_chassis_resident(%s)",
   od->l3redirect_port->json_key);
 }
+
+if (applied_ext_ips || 

[ovs-dev] Witam

[W.H.O OFFICIAL]

Witam! 

Czy otrzymałeś poprzednią wiadomość, którą dla Ciebie wysłaliśmy? Jesteśmy 
Światową Organizacją Zdrowia czekamy na odpowiedź tak szybko, jak to możliwe. 

Biuro Dyrektora Generalnego 
Światowa Organizacja Zdrowia 

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

Re: [ovs-dev] [ovs-discuss] [OVN] ovn-northd takes much CPU when no configuration update

[Han Zhou]

On Tue, Aug 4, 2020 at 11:40 AM Tony Liu  wrote:

> Inline...
>
> Thanks!
>
> Tony
> > -Original Message-
> > From: Han Zhou 
> > Sent: Tuesday, August 4, 2020 11:01 AM
> > To: Numan Siddique ; Ben Pfaff ; Leonid
> > Ryzhyk 
> > Cc: Tony Liu ; Han Zhou ; ovs-
> > dev ; ovs-discuss 
> > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when no
> > configuration update
> >
> >
> >
> > On Tue, Aug 4, 2020 at 12:38 AM Numan Siddique  >  > wrote:
> >
> >
> >
> >
> >   On Tue, Aug 4, 2020 at 9:02 AM Tony Liu  >  > wrote:
> >
> >
> >   The probe awakes recomputing?
> >   There is probe every 5 seconds. Without any connection
> > up/down or failover,
> >   ovn-northd will recompute everything every 5 seconds, no
> > matter what?
> >   Really?
> >
> >   Anyways, I will increase the probe interval for now, see if
> > that helps.
> >
> >
> >
> >   I think we should optimise this case. I am planning to look into
> > this.
> >
> >   Thanks
> >   Numan
> >
> >
> > Thanks Numan.
> > I'd like to discuss more on this before we move forward to change
> > anything.
> >
> > 1) Regarding the problem itself, the CPU cost triggered by OVSDB IDLE
> > probe when there is no configuration change to compute, I don't think it
> > matters that much in real production. It simply wastes CPU cycles when
> > there is nothing to do, so what harm would it do here? For ovn-northd,
> > since it is the centralized component, we would always ensure there is
> > enough CPU available for ovn-north when computing is needed, and this
> > reservation will be wasted anyway when there is no change to compute. So,
> > I'd avoid making any change specifically only to address this issue. I
> > could be wrong, though. I'd like to hear what would be the real concern
> > if this is not addressed.
>
> Is more vCPUs going to help here? Is ovn-northd multi-thread?
>
>
ovn-northd is single threaded. It can be changed to have a separate thread
for the probe handling, but I don't see any obvious benefit.


> I am probably still missing something here. The probe is there all times,
> every 5s.


The probe is sent only if there is no activity on the OVSDB connection
during the interval, that's why it is called "IDLE" probe. If there is
already interaction during the past interval, no probe will be sent.


> If ovn-northd is in the middle of a computing, is a probe going
> to make ovn-northd restart the computing?


No, it won't. Firstly, it is unlikely that a probe is received during
computing, unless the probe interval is set too short. Secondly, even when
it happens, the current computing will complete and all needed changes will
be enforced to SB DB regardless of the probe received during the computing.
The probe will be handled in the next round of the main loop, and it will
trigger another round of computing which is useless but not harmful either.
There is probably one case I can think of that causes a little latency -
when another NB DB change (say, change2) comes during the computing
triggered by the probe, then the handling for the change2 will be delayed a
little until the computing triggered by the probe completes. But the chance
is rather low, especially if the probe interval is enlarged, and in the
unlucky case, the impact is just a little delay in the change handling.


> Or the probe only triggers
> computing when ovn-northd is idle? Even with the latter case, what's the
> intention to trigger computing by probe?
>
>
It is not triggered intentionally for the probe. It is just because
ovn-northd doesn't distinguish if it is woken up by a probe only or if
there are any changes that need to be processed. Many events can wake up
ovn-northd, and once it is wake up it will compute everything. I agree it
can be optimized (we already optimized this for ovn-controller). I am just
wondering if it worth to be optimized specifically. Or we just get it for
free as a byproduct when implementing incremental-processing, which is
already in the road map.

Does this clarify a little?

Thanks,
Han


> >
> > 2) ovn-northd incremental processing would avoid this CPU problem
> > naturally. So let's discuss how to move forward for incremental
> > processing, which is much more important because it also solves the CPU
> > efficiency when handling the changes, and the IDLE probe problem is just
> > a byproduct. I believe the DDlog branch would have solved this problem.
> > However, it seems we are not sure about the current status of DDlog. As
> > you proposed at the last OVN meeting, an alternative is to implement
> > partial incremental-processing using the I-P engine like ovn-controller.
> > While I have no objection to this, we'd better check with Ben and Leonid
> > on the plan to avoid overlapping and waste of work. @Ben @Leonid, would
> > you mind sharing the status here since you were not at the meeting last
> > week?
>
> 

Re: [ovs-dev] WARNING: suspicious RCU usage in ovs_flow_tbl_destroy

[syzbot]

syzbot has bisected this issue to:

commit 9bf24f594c6acf676fb8c229f152c21bfb915ddb
Author: Eelco Chaudron 
Date:   Fri Jul 31 12:21:34 2020 +

net: openvswitch: make masks cache size configurable

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17461dea90
start commit:   2f631133 net: Pass NULL to skb_network_protocol() when we ..
git tree:   net-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=14c61dea90
console output: https://syzkaller.appspot.com/x/log.txt?x=10c61dea90
kernel config:  https://syzkaller.appspot.com/x/.config?x=91a13b78c7dc258d
dashboard link: https://syzkaller.appspot.com/bug?extid=c0eb9e7cdde04e4eb4be
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=172cd3d490
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11fbd34290

Reported-by: syzbot+c0eb9e7cdde04e4eb...@syzkaller.appspotmail.com
Fixes: 9bf24f594c6a ("net: openvswitch: make masks cache size configurable")

For information about bisection process see: https://goo.gl/tpsmEJ#bisection
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [ovs-discuss] [OVN] stale data complained by ovn-controller after db restore

[Han Zhou]

On Tue, Aug 4, 2020 at 11:31 AM Tony Liu  wrote:

> Is there any difference to restore DB on existing cluster vs. fresh
> cluster,
> in terms of performance?
>
> If I don't have to restore on fresh cluster, which is recommended?
>
> I would suggest to directly restore on top of existing cluster instead of
creating a fresh cluster.


> For now, since ovn-northd always recomputes the whole DB, I guess not much
> difference?
>
> With incremental-process, would restoring to a fresh cluster be better?
>
> No.


> Is it necessary to stop or restart ovn-northd during DB restore?
>
> No.


>
> Thanks!
>
> Tony
>
> > -Original Message-
> > From: Han Zhou 
> > Sent: Tuesday, August 4, 2020 11:13 AM
> > To: Tony Liu 
> > Cc: ovs-discuss ; ovs-dev  > d...@openvswitch.org>
> > Subject: Re: [ovs-dev] [OVN] stale data complained by ovn-controller
> > after db restore
> >
> >
> >
> > On Tue, Aug 4, 2020 at 10:30 AM Tony Liu  >  > wrote:
> >
> >
> >   Hi,
> >
> >   Here is how I restore OVN DB.
> >   * Stop all ovn-nb-db, ovn-sb-db and ovn-northd services.
> >   * Clean up all DB files.
> >   * Start all DB services. Fresh ovn-nb-db and ovn-sb-db clusters are
> > up and
> > running.
> >   * Set DB election timer to 10s.
> >   * Restore DB to ovn-nb-db by ovsdb-client.
> >   * Start all ovn-northd services.
> >
> >   A few minutes after, ovn-sb-db is fully synced with ovn-nb-db.
> >
> >   Now, the client of ovn-sb-db, ovn-controller and nova-compute
> > complaint about
> >   "stale data". The chassis node is not getting updated.
> >   
> >   2020-08-04 09:07:45.892 26 INFO ovsdbapp.backend.ovs_idl.vlog [-]
> > tcp:10.6.20.84:6642  : connected
> >   2020-08-04 09:07:45.895 26 WARNING ovsdbapp.backend.ovs_idl.vlog
> [-]
> > tcp:10.6.20.84:6642  : clustered database server
> > has stale data; trying another server
> >   
> >
> >   Restarting ovn-controller and nova-compute resolve the issue.
> >
> >   Is this expected? As part of the DB restore process, should I
> > restart
> >   ovn-controller and nova-compute on all chassis node?
> >
> >
> >
> >
> > Yes, this is expected if you freshly start a new cluster. (It wouldn't
> > happen if you simply restore the old data on the existing cluster.
> > However, I understand that the scenario of restoring data on a freshly
> > created cluster is a valid use case).
> > For this case, you could either restart ovn-controller, or trigger a
> > client side raft index reset by:
> > ovn-appctl -t ovn-controller sb-cluster-state-reset
> >
> > Similarly for ovn-northd:
> > ovn-appctl -t ovn-northd nb-cluster-state-reset
> > ovn-appctl -t ovn-northd sb-cluster-state-reset
> >
> > To use this command, you will need at least 20.06 of OVN and OVS master.
> >
> >
> > Thanks,
> > Han
> >
> >
> >
> >
> >   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] [ovs-discuss] [OVN] ovn-northd takes much CPU when no configuration update

[Tony Liu]

Inline...

Thanks!

Tony
> -Original Message-
> From: Han Zhou 
> Sent: Tuesday, August 4, 2020 11:01 AM
> To: Numan Siddique ; Ben Pfaff ; Leonid
> Ryzhyk 
> Cc: Tony Liu ; Han Zhou ; ovs-
> dev ; ovs-discuss 
> Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when no
> configuration update
> 
> 
> 
> On Tue, Aug 4, 2020 at 12:38 AM Numan Siddique   > wrote:
> 
> 
> 
> 
>   On Tue, Aug 4, 2020 at 9:02 AM Tony Liu   > wrote:
> 
> 
>   The probe awakes recomputing?
>   There is probe every 5 seconds. Without any connection
> up/down or failover,
>   ovn-northd will recompute everything every 5 seconds, no
> matter what?
>   Really?
> 
>   Anyways, I will increase the probe interval for now, see if
> that helps.
> 
> 
> 
>   I think we should optimise this case. I am planning to look into
> this.
> 
>   Thanks
>   Numan
> 
> 
> Thanks Numan.
> I'd like to discuss more on this before we move forward to change
> anything.
> 
> 1) Regarding the problem itself, the CPU cost triggered by OVSDB IDLE
> probe when there is no configuration change to compute, I don't think it
> matters that much in real production. It simply wastes CPU cycles when
> there is nothing to do, so what harm would it do here? For ovn-northd,
> since it is the centralized component, we would always ensure there is
> enough CPU available for ovn-north when computing is needed, and this
> reservation will be wasted anyway when there is no change to compute. So,
> I'd avoid making any change specifically only to address this issue. I
> could be wrong, though. I'd like to hear what would be the real concern
> if this is not addressed.

Is more vCPUs going to help here? Is ovn-northd multi-thread?

I am probably still missing something here. The probe is there all times,
every 5s. If ovn-northd is in the middle of a computing, is a probe going
to make ovn-northd restart the computing? Or the probe only triggers
computing when ovn-northd is idle? Even with the latter case, what's the
intention to trigger computing by probe?

> 
> 2) ovn-northd incremental processing would avoid this CPU problem
> naturally. So let's discuss how to move forward for incremental
> processing, which is much more important because it also solves the CPU
> efficiency when handling the changes, and the IDLE probe problem is just
> a byproduct. I believe the DDlog branch would have solved this problem.
> However, it seems we are not sure about the current status of DDlog. As
> you proposed at the last OVN meeting, an alternative is to implement
> partial incremental-processing using the I-P engine like ovn-controller.
> While I have no objection to this, we'd better check with Ben and Leonid
> on the plan to avoid overlapping and waste of work. @Ben @Leonid, would
> you mind sharing the status here since you were not at the meeting last
> week?

My point is that, a probe is not supposed to trigger a computing, no matter
it's full or incremental.

> 
> 
> 
> Thanks,
> Han
> 
> 
> 
> 
> 
> 
>   Thanks!
> 
>   Tony
> 
>   > -Original Message-
>   > From: Han Zhou mailto:hz...@ovn.org> >
>   > Sent: Monday, August 3, 2020 8:22 PM
>   > To: Tony Liu   >
>   > Cc: Han Zhou mailto:hz...@ovn.org> >; ovs-
> discuss mailto:ovs-
> disc...@openvswitch.org> >;
>   > ovs-dev mailto:ovs-
> d...@openvswitch.org> >
>   > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU
> when no
>   > configuration update
>   >
>   > Sorry that I didn't make it clear enough. The OVSDB probe
> itself doesn't
>   > take much CPU, but the probe awakes ovn-northd main loop,
> which
>   > recompute everything, which is why you see CPU spike.
>   > It will be solved by incremental-processing, when only
> delta is
>   > processed, and in case of probe handling, there is no
> change in
>   > configuration, so the delta is zero.
>   > For now, please follow the steps to adjust probe interval,
> if the CPU of
>   > ovn-northd (when there is no configuration change) is a
> concern for you.
>   > But please remember that this has no impact to the real CPU
> usage for
>   > handling configuration changes.
>   >
>   >
>   > Thanks,
>   > Han
>   >
>   >
>   > On Mon, Aug 3, 2020 at 8:11 PM Tony Liu
> mailto:tonyliu0...@hotmail.com>
>   >   > > wrote:
>   >
>   >
>   >   Health check (5 sec internal) taking 30%-100% CPU is
> definitely not
>   > acceptable,
> 

Re: [ovs-dev] [OVN] stale data complained by ovn-controller after db restore

[Tony Liu]

Is there any difference to restore DB on existing cluster vs. fresh cluster,
in terms of performance?

If I don't have to restore on fresh cluster, which is recommended?

For now, since ovn-northd always recomputes the whole DB, I guess not much
difference?

With incremental-process, would restoring to a fresh cluster be better?

Is it necessary to stop or restart ovn-northd during DB restore?


Thanks!

Tony

> -Original Message-
> From: Han Zhou 
> Sent: Tuesday, August 4, 2020 11:13 AM
> To: Tony Liu 
> Cc: ovs-discuss ; ovs-dev  d...@openvswitch.org>
> Subject: Re: [ovs-dev] [OVN] stale data complained by ovn-controller
> after db restore
> 
> 
> 
> On Tue, Aug 4, 2020 at 10:30 AM Tony Liu   > wrote:
> 
> 
>   Hi,
> 
>   Here is how I restore OVN DB.
>   * Stop all ovn-nb-db, ovn-sb-db and ovn-northd services.
>   * Clean up all DB files.
>   * Start all DB services. Fresh ovn-nb-db and ovn-sb-db clusters are
> up and
> running.
>   * Set DB election timer to 10s.
>   * Restore DB to ovn-nb-db by ovsdb-client.
>   * Start all ovn-northd services.
> 
>   A few minutes after, ovn-sb-db is fully synced with ovn-nb-db.
> 
>   Now, the client of ovn-sb-db, ovn-controller and nova-compute
> complaint about
>   "stale data". The chassis node is not getting updated.
>   
>   2020-08-04 09:07:45.892 26 INFO ovsdbapp.backend.ovs_idl.vlog [-]
> tcp:10.6.20.84:6642  : connected
>   2020-08-04 09:07:45.895 26 WARNING ovsdbapp.backend.ovs_idl.vlog [-]
> tcp:10.6.20.84:6642  : clustered database server
> has stale data; trying another server
>   
> 
>   Restarting ovn-controller and nova-compute resolve the issue.
> 
>   Is this expected? As part of the DB restore process, should I
> restart
>   ovn-controller and nova-compute on all chassis node?
> 
> 
> 
> 
> Yes, this is expected if you freshly start a new cluster. (It wouldn't
> happen if you simply restore the old data on the existing cluster.
> However, I understand that the scenario of restoring data on a freshly
> created cluster is a valid use case).
> For this case, you could either restart ovn-controller, or trigger a
> client side raft index reset by:
> ovn-appctl -t ovn-controller sb-cluster-state-reset
> 
> Similarly for ovn-northd:
> ovn-appctl -t ovn-northd nb-cluster-state-reset
> ovn-appctl -t ovn-northd sb-cluster-state-reset
> 
> To use this command, you will need at least 20.06 of OVN and OVS master.
> 
> 
> Thanks,
> Han
> 
> 
> 
> 
>   Thanks!
> 
>   Tony
> 
>   ___
>   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 branch-2.13 0/2] Release patches for v2.13.1.

[Ilya Maximets]

On 8/4/20 5:31 PM, William Tu wrote:
> On Tue, Aug 4, 2020 at 7:24 AM Ilya Maximets  wrote:
>>
>> On 8/4/20 3:19 PM, William Tu wrote:
>>> On Mon, Aug 3, 2020 at 2:23 PM Ilya Maximets  wrote:

 On 7/30/20 12:44 AM, Ilya Maximets wrote:
>
> Ilya Maximets (2):
>   Set release date for 2.13.1.
>   Prepare for 2.13.2.
>
>  NEWS | 14 +-
>  configure.ac |  2 +-
>  debian/changelog |  8 +++-
>  3 files changed, 17 insertions(+), 7 deletions(-)
>

 Kind reminder.

 These patches and patches for older branches still needs review.
 If anyone has a spare time slot, please take a look.

>>> Thanks for working on this, this is a lot of work!
>>>
>>> I've reviewed all and acked.
>>
>> Thanks!
>>
>>> We also need to create a tarball for each release and update website.
>>> https://www.openvswitch.org/download/
>>> I can help if you haven't done it yet.
>>
>> I'm going to apply and backport following small patch first:
>> https://patchwork.ozlabs.org/project/openvswitch/patch/20200804015456.4047-1-hepeng.0...@bytedance.com/
>>
>> Right after that I'll push release patches and tags.
>> I also have a script to generate tarballs, so I'll prepare them and the
>> website pull request once releases tagged.
>>
>> Maybe we need to return to the question about just having a link to
>> tarballs generated by github at some point?
> 
> Yes, I think that would be easier.

All release patches tagged and pushed.  Thanks!

Now I'm preparing release tarballs and the website pull request.
Keeping the current way of publishing tarballs for now.
Once website updated I'll send release announcement to ovs-announce.

> 
>>
>>>
 I have run unit and system tests on all release branches (that wasn't
 simple, but more on this later).  2.13.1 also passed through ovn-k8s
 and OpenStack CI systems.

>>>
>>> Yes, I believe there are lots of issues when running system tests.
>>> It would be great to have some public CI running system tests.
>>> Previously I was using Github Actions, I'm curious about how you do it.
>>
>> For now, I just prepared a small script and a VM image to build and test.
>> And actually system tests are not that bad, at least kernel ones.  Some
>> tests are not skipped while should be on older branches, but it's not
>> a big deal.  For now, I had to look at all the failures manually.
>> Userspace testsuite is not that good.  Basically, we cleaned it up
>> somewhere between 2.10-2.12.  So, on older branches it's a mess.
>>
>> Harder case is that older branches requires python2 to build and also
>> requires /usr/bin/python to point to python2.  This is an issue if you're
>> trying to build OVS on some modern distros that doesn't have python2, or
>> have it but uses python3 by default or doesn't have simple 'python'
>> symlink at all.  I had to switch from fedora to rhel just to build.
>> The second build issue is that some older branches doesn't build with
>> openssl >= 1.1.0.  This is tricky.  We will need to decide what to do
>> with that later.  I will send a follow-up email about older branches
>> and what options we have.
>>
> Thanks for sharing the experience.
> William
> 

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

Re: [ovs-dev] [OVN] stale data complained by ovn-controller after db restore

[Han Zhou]

On Tue, Aug 4, 2020 at 10:30 AM Tony Liu  wrote:

> Hi,
>
> Here is how I restore OVN DB.
> * Stop all ovn-nb-db, ovn-sb-db and ovn-northd services.
> * Clean up all DB files.
> * Start all DB services. Fresh ovn-nb-db and ovn-sb-db clusters are up and
>   running.
> * Set DB election timer to 10s.
> * Restore DB to ovn-nb-db by ovsdb-client.
> * Start all ovn-northd services.
>
> A few minutes after, ovn-sb-db is fully synced with ovn-nb-db.
>
> Now, the client of ovn-sb-db, ovn-controller and nova-compute complaint
> about
> "stale data". The chassis node is not getting updated.
> 
> 2020-08-04 09:07:45.892 26 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:
> 10.6.20.84:6642: connected
> 2020-08-04 09:07:45.895 26 WARNING ovsdbapp.backend.ovs_idl.vlog [-] tcp:
> 10.6.20.84:6642: clustered database server has stale data; trying another
> server
> 
>
> Restarting ovn-controller and nova-compute resolve the issue.
>
> Is this expected? As part of the DB restore process, should I restart
> ovn-controller and nova-compute on all chassis node?
>
>
Yes, this is expected if you freshly start a new cluster. (It wouldn't
happen if you simply restore the old data on the existing cluster. However,
I understand that the scenario of restoring data on a freshly created
cluster is a valid use case).
For this case, you could either restart ovn-controller, or trigger a client
side raft index reset by:
ovn-appctl -t ovn-controller sb-cluster-state-reset

Similarly for ovn-northd:
ovn-appctl -t ovn-northd nb-cluster-state-reset
ovn-appctl -t ovn-northd sb-cluster-state-reset

To use this command, you will need at least 20.06 of OVN and OVS master.

Thanks,
Han



> Thanks!
>
> Tony
>
> ___
> 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] [ovs-discuss] [OVN] ovn-northd takes much CPU when no configuration update

[Han Zhou]

On Tue, Aug 4, 2020 at 12:38 AM Numan Siddique  wrote:

>
>
> On Tue, Aug 4, 2020 at 9:02 AM Tony Liu  wrote:
>
>> The probe awakes recomputing?
>> There is probe every 5 seconds. Without any connection up/down or
>> failover,
>> ovn-northd will recompute everything every 5 seconds, no matter what?
>> Really?
>>
>> Anyways, I will increase the probe interval for now, see if that helps.
>>
>
> I think we should optimise this case. I am planning to look into this.
>
> Thanks
> Numan
>

Thanks Numan.
I'd like to discuss more on this before we move forward to change anything.

1) Regarding the problem itself, the CPU cost triggered by OVSDB IDLE probe
when there is no configuration change to compute, I don't think it matters
that much in real production. It simply wastes CPU cycles when there is
nothing to do, so what harm would it do here? For ovn-northd, since it is
the centralized component, we would always ensure there is enough CPU
available for ovn-north when computing is needed, and this reservation will
be wasted anyway when there is no change to compute. So, I'd avoid making
any change specifically only to address this issue. I could be wrong,
though. I'd like to hear what would be the real concern if this is not
addressed.

2) ovn-northd incremental processing would avoid this CPU problem
naturally. So let's discuss how to move forward for incremental processing,
which is much more important because it also solves the CPU efficiency when
handling the changes, and the IDLE probe problem is just a byproduct. I
believe the DDlog branch would have solved this problem. However, it seems
we are not sure about the current status of DDlog. As you proposed at the
last OVN meeting, an alternative is to implement partial
incremental-processing using the I-P engine like ovn-controller. While I
have no objection to this, we'd better check with Ben and Leonid on the
plan to avoid overlapping and waste of work. @Ben @Leonid, would you mind
sharing the status here since you were not at the meeting last week?

Thanks,
Han

>
>
>>
>>
>> Thanks!
>>
>> Tony
>>
>> > -Original Message-
>> > From: Han Zhou 
>> > Sent: Monday, August 3, 2020 8:22 PM
>> > To: Tony Liu 
>> > Cc: Han Zhou ; ovs-discuss > >;
>> > ovs-dev 
>> > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when no
>> > configuration update
>> >
>> > Sorry that I didn't make it clear enough. The OVSDB probe itself doesn't
>> > take much CPU, but the probe awakes ovn-northd main loop, which
>> > recompute everything, which is why you see CPU spike.
>> > It will be solved by incremental-processing, when only delta is
>> > processed, and in case of probe handling, there is no change in
>> > configuration, so the delta is zero.
>> > For now, please follow the steps to adjust probe interval, if the CPU of
>> > ovn-northd (when there is no configuration change) is a concern for you.
>> > But please remember that this has no impact to the real CPU usage for
>> > handling configuration changes.
>> >
>> >
>> > Thanks,
>> > Han
>> >
>> >
>> > On Mon, Aug 3, 2020 at 8:11 PM Tony Liu > >  > wrote:
>> >
>> >
>> >   Health check (5 sec internal) taking 30%-100% CPU is definitely
>> not
>> > acceptable,
>> >   if that's really the case. There must be some blocking (and not
>> > yielding CPU)
>> >   in coding, which is not supposed to be there.
>> >
>> >   Could you point me to the coding for such health check?
>> >   Is it single thread? Does it use any event library?
>> >
>> >
>> >   Thanks!
>> >
>> >   Tony
>> >
>> >   > -Original Message-
>> >   > From: Han Zhou mailto:hz...@ovn.org> >
>> >   > Sent: Saturday, August 1, 2020 9:11 PM
>> >   > To: Tony Liu > >  >
>> >   > Cc: ovs-discuss mailto:ovs-
>> > disc...@openvswitch.org> >; ovs-dev > >   > d...@openvswitch.org  >
>> >   > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when
>> > no
>> >   > configuration update
>> >   >
>> >   >
>> >   >
>> >   > On Fri, Jul 31, 2020 at 4:14 PM Tony Liu <
>> tonyliu0...@hotmail.com
>> > 
>> >   > > >  > > wrote:
>> >   >
>> >   >
>> >   >   Hi,
>> >   >
>> >   >   I see the active ovn-northd takes much CPU (30% - 100%)
>> > when there
>> >   > is no
>> >   >   configuration from OpenStack, nothing happening on all
>> > chassis
>> >   > nodes either.
>> >   >
>> >   >   Is this expected? What is it busy with?
>> >   >
>> >   >
>> >   >
>> >   >
>> >   > Yes, this is expected. It is due to the OVSDB probe between ovn-
>> > northd
>> >   > and NB/SB OVSDB servers, which is used to detect the OVSDB
>> > connection
>> >   > failure.
>> >   > Usually this is not a concern (unlike the probe with a 

[ovs-dev] [OVN] stale data complained by ovn-controller after db restore

[Tony Liu]

Hi,

Here is how I restore OVN DB.
* Stop all ovn-nb-db, ovn-sb-db and ovn-northd services.
* Clean up all DB files.
* Start all DB services. Fresh ovn-nb-db and ovn-sb-db clusters are up and
  running.
* Set DB election timer to 10s.
* Restore DB to ovn-nb-db by ovsdb-client.
* Start all ovn-northd services.

A few minutes after, ovn-sb-db is fully synced with ovn-nb-db.

Now, the client of ovn-sb-db, ovn-controller and nova-compute complaint about
"stale data". The chassis node is not getting updated.

2020-08-04 09:07:45.892 26 INFO ovsdbapp.backend.ovs_idl.vlog [-] 
tcp:10.6.20.84:6642: connected
2020-08-04 09:07:45.895 26 WARNING ovsdbapp.backend.ovs_idl.vlog [-] 
tcp:10.6.20.84:6642: clustered database server has stale data; trying another 
server


Restarting ovn-controller and nova-compute resolve the issue.

Is this expected? As part of the DB restore process, should I restart
ovn-controller and nova-compute on all chassis node?


Thanks!

Tony

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

Re: [ovs-dev] [ovs-discuss] [OVN] ovn-northd takes much CPU when no configuration update

[Tony Liu]

Thanks Numan for looking into it!
Probe is for health check only, it's not supposed to trigger translation,
even with incremental implementation. Translation should be triggered only
when a ovn-northd becomes active.


Tony

> -Original Message-
> From: Numan Siddique 
> Sent: Tuesday, August 4, 2020 12:38 AM
> To: Tony Liu 
> Cc: Han Zhou ; ovs-dev ; ovs-
> discuss 
> Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when no
> configuration update
> 
> 
> 
> On Tue, Aug 4, 2020 at 9:02 AM Tony Liu   > wrote:
> 
> 
>   The probe awakes recomputing?
>   There is probe every 5 seconds. Without any connection up/down or
> failover,
>   ovn-northd will recompute everything every 5 seconds, no matter
> what?
>   Really?
> 
>   Anyways, I will increase the probe interval for now, see if that
> helps.
> 
> 
> 
> I think we should optimise this case. I am planning to look into this.
> 
> Thanks
> Numan
> 
> 
> 
> 
>   Thanks!
> 
>   Tony
> 
>   > -Original Message-
>   > From: Han Zhou mailto:hz...@ovn.org> >
>   > Sent: Monday, August 3, 2020 8:22 PM
>   > To: Tony Liu   >
>   > Cc: Han Zhou mailto:hz...@ovn.org> >; ovs-discuss
> mailto:ovs-disc...@openvswitch.org> >;
>   > ovs-dev mailto:ovs-
> d...@openvswitch.org> >
>   > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when
> no
>   > configuration update
>   >
>   > Sorry that I didn't make it clear enough. The OVSDB probe itself
> doesn't
>   > take much CPU, but the probe awakes ovn-northd main loop, which
>   > recompute everything, which is why you see CPU spike.
>   > It will be solved by incremental-processing, when only delta is
>   > processed, and in case of probe handling, there is no change in
>   > configuration, so the delta is zero.
>   > For now, please follow the steps to adjust probe interval, if the
> CPU of
>   > ovn-northd (when there is no configuration change) is a concern
> for you.
>   > But please remember that this has no impact to the real CPU usage
> for
>   > handling configuration changes.
>   >
>   >
>   > Thanks,
>   > Han
>   >
>   >
>   > On Mon, Aug 3, 2020 at 8:11 PM Tony Liu  
>   >   > > wrote:
>   >
>   >
>   >   Health check (5 sec internal) taking 30%-100% CPU is
> definitely not
>   > acceptable,
>   >   if that's really the case. There must be some blocking (and
> not
>   > yielding CPU)
>   >   in coding, which is not supposed to be there.
>   >
>   >   Could you point me to the coding for such health check?
>   >   Is it single thread? Does it use any event library?
>   >
>   >
>   >   Thanks!
>   >
>   >   Tony
>   >
>   >   > -Original Message-
>   >   > From: Han Zhou mailto:hz...@ovn.org>
>  > >
>   >   > Sent: Saturday, August 1, 2020 9:11 PM
>   >   > To: Tony Liu  
>   >   > >
>   >   > Cc: ovs-discuss mailto:ovs-
> disc...@openvswitch.org>  
>   > disc...@openvswitch.org  > >;
> ovs-dev>   > d...@openvswitch.org 
>  > >
>   >   > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much
> CPU when
>   > no
>   >   > configuration update
>   >   >
>   >   >
>   >   >
>   >   > On Fri, Jul 31, 2020 at 4:14 PM Tony Liu
> mailto:tonyliu0...@hotmail.com>
>   >  >
>   >   >  
>   >   > > > wrote:
>   >   >
>   >   >
>   >   >   Hi,
>   >   >
>   >   >   I see the active ovn-northd takes much CPU (30% -
> 100%)
>   > when there
>   >   > is no
>   >   >   configuration from OpenStack, nothing happening on
> all
>   > chassis
>   >   > nodes either.
>   >   >
>   >   >   Is this expected? What is it busy with?
>   >   >
>   >   >
>   >   >
>   >   >
>   >   > Yes, this is expected. It is due to the OVSDB probe
> between ovn-
>   > northd
>   >   > and NB/SB OVSDB servers, which is used to detect the
> OVSDB
>   > connection
>   >   > failure.
>   >   > Usually this is not a concern (unlike the probe with a
> large
>   > 

Re: [ovs-dev] there are many error logs when processing igmp packet

[Ben Pfaff]

On Tue, Aug 04, 2020 at 11:55:19AM +, Frank Wang(王培辉) wrote:
> Hello, 
> 
> I found there are many error logs as follows in ovs-vswitchd.log:
> Aug  4 18:48:03 node-170 ovs-vswitchd:
> ovs|00100|odp_util(handler171)|ERR|internal error parsing flow key
> recirc_id(0),dp_hash(0),skb_priority(0),in_port(5),skb_mark(0),ct_state(0),c
> t_zone(0),ct_label(0),eth(src=6c:92:bf:14:e9:f8,
> dst=01:00:5e:00:00:16),eth_type(0x0800),ipv4(src=100.7.40.41,dst=224.0.0.22,
> proto=2,tos=0,ttl=1,frag=no)
> 
>It seems parse_l2_5_onward function return ODP_FIT_TOO_LITTLE when it
> processing igmp packet after digging,

ODP_FIT_TOO_LITTLE is expected for IGMP, because the kernel doesn't
parse the IGMP header, whereas userspace does.

>I'm wondering the reason to do this ,how to avoid this?

The log message shows that there is definitely a bug but it does not
sound like it is in parse_l2_5_onward().
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] WARNING: suspicious RCU usage in ovs_flow_tbl_masks_cache_size

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:2f631133 net: Pass NULL to skb_network_protocol() when we ..
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12c1f77090
kernel config:  https://syzkaller.appspot.com/x/.config?x=91a13b78c7dc258d
dashboard link: https://syzkaller.appspot.com/bug?extid=f612c02823acb02ff9bc
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=10e8430a90
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=123549fc90

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

netlink: 'syz-executor210': attribute type 2 has an invalid length.
device  entered promiscuous mode
=
WARNING: suspicious RCU usage
5.8.0-rc7-syzkaller #0 Not tainted
-
net/openvswitch/flow_table.c:940 suspicious rcu_dereference_check() usage!

other info that might help us debug this:


rcu_scheduler_active = 2, debug_locks = 1
2 locks held by syz-executor210/6812:
 #0: 8a8319b0 (cb_lock){}-{3:3}, at: genl_rcv+0x15/0x40 
net/netlink/genetlink.c:741
 #1: 8aa786a8 (ovs_mutex){+.+.}-{3:3}, at: ovs_lock 
net/openvswitch/datapath.c:105 [inline]
 #1: 8aa786a8 (ovs_mutex){+.+.}-{3:3}, at: ovs_dp_cmd_new+0x4db/0xea0 
net/openvswitch/datapath.c:1707

stack backtrace:
CPU: 0 PID: 6812 Comm: syz-executor210 Not tainted 5.8.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 ovs_flow_tbl_masks_cache_size+0xc3/0xe0 net/openvswitch/flow_table.c:940
 ovs_dp_cmd_fill_info+0x4e4/0x880 net/openvswitch/datapath.c:1539
 ovs_dp_cmd_new+0x584/0xea0 net/openvswitch/datapath.c:1728
 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:2359
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2413
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2446
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4402d9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffd71bb22a8 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 004002c8 RCX: 004402d9
RDX:  RSI: 20c0 RDI: 0003
RBP: 006ca018 R08:  R09: 00


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] WARNING: suspicious RCU usage in ovs_flow_tbl_destroy

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:2f631133 net: Pass NULL to skb_network_protocol() when we ..
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12daae2a90
kernel config:  https://syzkaller.appspot.com/x/.config?x=91a13b78c7dc258d
dashboard link: https://syzkaller.appspot.com/bug?extid=c0eb9e7cdde04e4eb4be
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=172cd3d490
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11fbd34290

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

netlink: 'syz-executor399': attribute type 2 has an invalid length.
=
WARNING: suspicious RCU usage
5.8.0-rc7-syzkaller #0 Not tainted
-
net/openvswitch/flow_table.c:521 suspicious rcu_dereference_check() usage!

other info that might help us debug this:


rcu_scheduler_active = 2, debug_locks = 1
1 lock held by syz-executor399/6802:
 #0: 8a8319b0 (cb_lock){}-{3:3}, at: genl_rcv+0x15/0x40 
net/netlink/genetlink.c:741

stack backtrace:
CPU: 0 PID: 6802 Comm: syz-executor399 Not tainted 5.8.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 ovs_flow_tbl_destroy+0x1d6/0x210 net/openvswitch/flow_table.c:521
 ovs_dp_cmd_new+0x8ca/0xea0 net/openvswitch/datapath.c:1747
 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:2359
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2413
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2446
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4402d9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffdfda722f8 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 004002c8 RCX: 004402d9
RDX:  RSI: 20c0 RDI: 0003
RBP: 006ca018 R08:  R09: 004002c8
R10:  R11: 0246 R12: 00401ae0
R13: 00401b70 R14:  R15: 

=
WARNING: suspicious RCU usage
5.8.0-rc7-syzkaller #0 Not tainted
-
net/openvswitch/flow_table.c:522 suspicious rcu_dereference_check() usage!

other info that might help us debug this:


rcu_scheduler_active = 2, debug_locks = 1
1 lock held by syz-executor399/6802:
 #0: 8a8319b0 (cb_lock){}-{3:3}, at: genl_rcv+0x15/0x40 
net/netlink/genetlink.c:741

stack backtrace:
CPU: 0 PID: 6802 Comm: syz-executor399 Not tainted 5.8.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 ovs_flow_tbl_destroy+0x190/0x210 net/openvswitch/flow_table.c:522
 ovs_dp_cmd_new+0x8ca/0xea0 net/openvswitch/datapath.c:1747
 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:2359
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2413
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2446
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4402d9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffdfda722f8 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 004002c8 RCX: 004402d9
RDX: 

Re: [ovs-dev] [PATCH branch-2.13 0/2] Release patches for v2.13.1.

[William Tu]

On Tue, Aug 4, 2020 at 7:24 AM Ilya Maximets  wrote:
>
> On 8/4/20 3:19 PM, William Tu wrote:
> > On Mon, Aug 3, 2020 at 2:23 PM Ilya Maximets  wrote:
> >>
> >> On 7/30/20 12:44 AM, Ilya Maximets wrote:
> >>>
> >>> Ilya Maximets (2):
> >>>   Set release date for 2.13.1.
> >>>   Prepare for 2.13.2.
> >>>
> >>>  NEWS | 14 +-
> >>>  configure.ac |  2 +-
> >>>  debian/changelog |  8 +++-
> >>>  3 files changed, 17 insertions(+), 7 deletions(-)
> >>>
> >>
> >> Kind reminder.
> >>
> >> These patches and patches for older branches still needs review.
> >> If anyone has a spare time slot, please take a look.
> >>
> > Thanks for working on this, this is a lot of work!
> >
> > I've reviewed all and acked.
>
> Thanks!
>
> > We also need to create a tarball for each release and update website.
> > https://www.openvswitch.org/download/
> > I can help if you haven't done it yet.
>
> I'm going to apply and backport following small patch first:
> https://patchwork.ozlabs.org/project/openvswitch/patch/20200804015456.4047-1-hepeng.0...@bytedance.com/
>
> Right after that I'll push release patches and tags.
> I also have a script to generate tarballs, so I'll prepare them and the
> website pull request once releases tagged.
>
> Maybe we need to return to the question about just having a link to
> tarballs generated by github at some point?

Yes, I think that would be easier.

>
> >
> >> I have run unit and system tests on all release branches (that wasn't
> >> simple, but more on this later).  2.13.1 also passed through ovn-k8s
> >> and OpenStack CI systems.
> >>
> >
> > Yes, I believe there are lots of issues when running system tests.
> > It would be great to have some public CI running system tests.
> > Previously I was using Github Actions, I'm curious about how you do it.
>
> For now, I just prepared a small script and a VM image to build and test.
> And actually system tests are not that bad, at least kernel ones.  Some
> tests are not skipped while should be on older branches, but it's not
> a big deal.  For now, I had to look at all the failures manually.
> Userspace testsuite is not that good.  Basically, we cleaned it up
> somewhere between 2.10-2.12.  So, on older branches it's a mess.
>
> Harder case is that older branches requires python2 to build and also
> requires /usr/bin/python to point to python2.  This is an issue if you're
> trying to build OVS on some modern distros that doesn't have python2, or
> have it but uses python3 by default or doesn't have simple 'python'
> symlink at all.  I had to switch from fedora to rhel just to build.
> The second build issue is that some older branches doesn't build with
> openssl >= 1.1.0.  This is tricky.  We will need to decide what to do
> with that later.  I will send a follow-up email about older branches
> and what options we have.
>
Thanks for sharing the experience.
William
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] I NEED YOUR URGENT ATTENTION !!

[Roth Savuth]

Dear friend,

I am Mr Roth Savuth and a personal Accountant Director with Foreign Trade Bank 
of Cambodia (FTB). It is with good spirit of heart that I open up this great 
opportunity to you. A deceased client of mine that shares the same name as 
yours died as a result of heart-related condition on march 2005. His heart 
condition was due to the death of his family members in the tsunami disaster on 
the 26th December 2004 in Sumatra Indonesia where they all lost their lives.

There is a draft account opened here in my bank since 1999 by my late client, a 
national of your country. He was a geologist, a business man, a miner at EMED 
Mining International company here in Cambodia and also a mining consultant to 
several other mining conglomerates operating in china, Taiwan, Japan and 
Vietnam before he passed away on 12th March 2005, leaving nobody as the next of 
kin / inheritor of his account after his death.

The amount in this account is currently $32,640.000.00 (Thirty Two Million, Six 
Hundred And Forty Thousand United States Dollars). There is no risk involved at 
all in this matter, as we are going to adopt a legalized method. I want you to 
know that I have had everything planned out so that we shall come out 
successful. Please endeavor to observe utmost discretion in all matters 
concerning this transaction. Once the funds have been transferred to your 
nominated bank account we shall then share in the ratio of 50% for me, 50% for 
you. I will use my position and influence in our bank to make them release this 
money to you for us to share.

Kindly get back to me for more details.

Yours sincerely
Mr Roth Savuth
Board of Director
Foreign Trade Bank of Cambodia
Phnom Penh.  
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.13 0/2] Release patches for v2.13.1.

[Ilya Maximets]

On 8/4/20 3:19 PM, William Tu wrote:
> On Mon, Aug 3, 2020 at 2:23 PM Ilya Maximets  wrote:
>>
>> On 7/30/20 12:44 AM, Ilya Maximets wrote:
>>>
>>> Ilya Maximets (2):
>>>   Set release date for 2.13.1.
>>>   Prepare for 2.13.2.
>>>
>>>  NEWS | 14 +-
>>>  configure.ac |  2 +-
>>>  debian/changelog |  8 +++-
>>>  3 files changed, 17 insertions(+), 7 deletions(-)
>>>
>>
>> Kind reminder.
>>
>> These patches and patches for older branches still needs review.
>> If anyone has a spare time slot, please take a look.
>>
> Thanks for working on this, this is a lot of work!
> 
> I've reviewed all and acked.

Thanks!

> We also need to create a tarball for each release and update website.
> https://www.openvswitch.org/download/
> I can help if you haven't done it yet.

I'm going to apply and backport following small patch first:
https://patchwork.ozlabs.org/project/openvswitch/patch/20200804015456.4047-1-hepeng.0...@bytedance.com/

Right after that I'll push release patches and tags.
I also have a script to generate tarballs, so I'll prepare them and the
website pull request once releases tagged.

Maybe we need to return to the question about just having a link to
tarballs generated by github at some point?

> 
>> I have run unit and system tests on all release branches (that wasn't
>> simple, but more on this later).  2.13.1 also passed through ovn-k8s
>> and OpenStack CI systems.
>>
> 
> Yes, I believe there are lots of issues when running system tests.
> It would be great to have some public CI running system tests.
> Previously I was using Github Actions, I'm curious about how you do it.

For now, I just prepared a small script and a VM image to build and test.
And actually system tests are not that bad, at least kernel ones.  Some
tests are not skipped while should be on older branches, but it's not
a big deal.  For now, I had to look at all the failures manually.
Userspace testsuite is not that good.  Basically, we cleaned it up
somewhere between 2.10-2.12.  So, on older branches it's a mess.

Harder case is that older branches requires python2 to build and also
requires /usr/bin/python to point to python2.  This is an issue if you're
trying to build OVS on some modern distros that doesn't have python2, or
have it but uses python3 by default or doesn't have simple 'python'
symlink at all.  I had to switch from fedora to rhel just to build.
The second build issue is that some older branches doesn't build with
openssl >= 1.1.0.  This is tricky.  We will need to decide what to do
with that later.  I will send a follow-up email about older branches
and what options we have.

> 
> Thanks,
> William
> 

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

Re: [ovs-dev] [PATCH branch-2.13 0/2] Release patches for v2.13.1.

[William Tu]

On Mon, Aug 3, 2020 at 2:23 PM Ilya Maximets  wrote:
>
> On 7/30/20 12:44 AM, Ilya Maximets wrote:
> >
> > Ilya Maximets (2):
> >   Set release date for 2.13.1.
> >   Prepare for 2.13.2.
> >
> >  NEWS | 14 +-
> >  configure.ac |  2 +-
> >  debian/changelog |  8 +++-
> >  3 files changed, 17 insertions(+), 7 deletions(-)
> >
>
> Kind reminder.
>
> These patches and patches for older branches still needs review.
> If anyone has a spare time slot, please take a look.
>
Thanks for working on this, this is a lot of work!

I've reviewed all and acked.
We also need to create a tarball for each release and update website.
https://www.openvswitch.org/download/
I can help if you haven't done it yet.

> I have run unit and system tests on all release branches (that wasn't
> simple, but more on this later).  2.13.1 also passed through ovn-k8s
> and OpenStack CI systems.
>

Yes, I believe there are lots of issues when running system tests.
It would be great to have some public CI running system tests.
Previously I was using Github Actions, I'm curious about how you do it.

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

Re: [ovs-dev] [PATCH branch-2.5 2/2] Prepare for 2.5.11.

[William Tu]

On Wed, Jul 29, 2020 at 3:42 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---
LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.5 1/2] Set release date for 2.5.10.

[William Tu]

On Wed, Jul 29, 2020 at 3:42 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---

LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.6 2/2] Prepare for 2.6.9.

[William Tu]

On Wed, Jul 29, 2020 at 3:43 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---
LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.6 1/2] Set release date for 2.6.8.

[William Tu]

On Wed, Jul 29, 2020 at 3:43 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---

LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.7 2/2] Prepare for 2.7.12.

[William Tu]

On Wed, Jul 29, 2020 at 3:43 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---

LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.7 1/2] Set release date for 2.7.11.

[William Tu]

On Wed, Jul 29, 2020 at 3:43 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---
LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.8 2/2] Prepare for 2.8.10.

[William Tu]

On Wed, Jul 29, 2020 at 3:44 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---
LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.8 1/2] Set release date for 2.8.9.

[William Tu]

On Wed, Jul 29, 2020 at 3:43 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---
LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.9 2/2] Prepare for 2.9.8.

[William Tu]

On Wed, Jul 29, 2020 at 3:44 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---
LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.9 1/2] Set release date for 2.9.7.

[William Tu]

On Wed, Jul 29, 2020 at 3:43 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---
LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.10 2/2] Prepare for 2.10.6.

[William Tu]

On Wed, Jul 29, 2020 at 3:44 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---

LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.10 1/2] Set release date for 2.10.5.

[William Tu]

On Wed, Jul 29, 2020 at 3:45 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 

LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.11 2/2] Prepare for 2.11.5.

[William Tu]

On Wed, Jul 29, 2020 at 3:45 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---

LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.11 1/2] Set release date for 2.11.4.

[William Tu]

On Wed, Jul 29, 2020 at 3:45 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---
LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.12 2/2] Prepare for 2.12.2.

[William Tu]

On Wed, Jul 29, 2020 at 3:45 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---

LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.12 1/2] Set release date for 2.12.1.

[William Tu]

On Wed, Jul 29, 2020 at 3:45 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---

LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.13 2/2] Prepare for 2.13.2.

[William Tu]

On Wed, Jul 29, 2020 at 3:46 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---
LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH branch-2.13 1/2] Set release date for 2.13.1.

[William Tu]

On Wed, Jul 29, 2020 at 3:46 PM Ilya Maximets  wrote:
>
> Signed-off-by: Ilya Maximets 
> ---

LGTM,
Acked-by: William Tu 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] there are many error logs when processing igmp packet

[王培辉]

Hello, 

I found there are many error logs as follows in ovs-vswitchd.log:
Aug  4 18:48:03 node-170 ovs-vswitchd:
ovs|00100|odp_util(handler171)|ERR|internal error parsing flow key
recirc_id(0),dp_hash(0),skb_priority(0),in_port(5),skb_mark(0),ct_state(0),c
t_zone(0),ct_label(0),eth(src=6c:92:bf:14:e9:f8,
dst=01:00:5e:00:00:16),eth_type(0x0800),ipv4(src=100.7.40.41,dst=224.0.0.22,
proto=2,tos=0,ttl=1,frag=no)

   It seems parse_l2_5_onward function return ODP_FIT_TOO_LITTLE when it
processing igmp packet after digging,
   I'm wondering the reason to do this ,how to avoid this?


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

Re: [ovs-dev] [PATCH v2] tc: Use skip_hw flag when probing tc features

[Tonghao Zhang]

On Tue, Aug 4, 2020 at 2:37 PM Roi Dayan  wrote:
>
> There is no need to pass tc rules to hw when just probing
> for tc features. this will avoid redundant errors from hw drivers
> that may happen.
>
> Signed-off-by: Roi Dayan 
> Acked-By: Vlad Buslov 
Reviewed-by: Tonghao Zhang 
> ---
>
> Notes:
> v2
> - Add missing ack from Vlad
> - Style fix for comment
> - Add build assertion for TC_POLICY_NONE
>
>  lib/netdev-offload-tc.c |  2 ++
>  lib/tc.c| 13 ++---
>  lib/tc.h| 10 ++
>  3 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
> index 2c9c6f4cae8b..18ff380f9861 100644
> --- a/lib/netdev-offload-tc.c
> +++ b/lib/netdev-offload-tc.c
> @@ -1918,6 +1918,7 @@ probe_multi_mask_per_prio(int ifindex)
>
>  memset(, 0, sizeof flower);
>
> +flower.tc_policy = TC_POLICY_SKIP_HW;
>  flower.key.eth_type = htons(ETH_P_IP);
>  flower.mask.eth_type = OVS_BE16_MAX;
>  memset(_mac, 0x11, sizeof flower.key.dst_mac);
> @@ -1965,6 +1966,7 @@ probe_tc_block_support(int ifindex)
>
>  memset(, 0, sizeof flower);
>
> +flower.tc_policy = TC_POLICY_SKIP_HW;
>  flower.key.eth_type = htons(ETH_P_IP);
>  flower.mask.eth_type = OVS_BE16_MAX;
>  memset(_mac, 0x11, sizeof flower.key.dst_mac);
> diff --git a/lib/tc.c b/lib/tc.c
> index c96d095381d7..8761304c92bb 100644
> --- a/lib/tc.c
> +++ b/lib/tc.c
> @@ -65,12 +65,6 @@ VLOG_DEFINE_THIS_MODULE(tc);
>
>  static struct vlog_rate_limit error_rl = VLOG_RATE_LIMIT_INIT(60, 5);
>
> -enum tc_offload_policy {
> -TC_POLICY_NONE,
> -TC_POLICY_SKIP_SW,
> -TC_POLICY_SKIP_HW
> -};
> -
>  static enum tc_offload_policy tc_policy = TC_POLICY_NONE;
>
>  struct tc_pedit_key_ex {
> @@ -2757,6 +2751,7 @@ nl_msg_put_flower_options(struct ofpbuf *request, 
> struct tc_flower *flower)
>  bool is_vlan = eth_type_vlan(flower->key.eth_type);
>  bool is_qinq = is_vlan && eth_type_vlan(flower->key.encap_eth_type[0]);
>  bool is_mpls = eth_type_mpls(flower->key.eth_type);
> +enum tc_offload_policy policy = flower->tc_policy;
>  int err;
>
>  /* need to parse acts first as some acts require changing the matching
> @@ -2882,7 +2877,11 @@ nl_msg_put_flower_options(struct ofpbuf *request, 
> struct tc_flower *flower)
>  }
>  }
>
> -nl_msg_put_u32(request, TCA_FLOWER_FLAGS, 
> tc_get_tc_cls_policy(tc_policy));
> +if (policy == TC_POLICY_NONE) {
> +policy = tc_policy;
> +}
> +
> +nl_msg_put_u32(request, TCA_FLOWER_FLAGS, tc_get_tc_cls_policy(policy));
>
>  if (flower->tunnel) {
>  nl_msg_put_flower_tunnel(request, flower);
> diff --git a/lib/tc.h b/lib/tc.h
> index 028eed5d0658..281231c0d3f1 100644
> --- a/lib/tc.h
> +++ b/lib/tc.h
> @@ -312,6 +312,14 @@ is_tcf_id_eq(struct tcf_id *id1, struct tcf_id *id2)
> && id1->chain == id2->chain;
>  }
>
> +enum tc_offload_policy {
> +TC_POLICY_NONE = 0,
> +TC_POLICY_SKIP_SW,
> +TC_POLICY_SKIP_HW
> +};
> +
> +BUILD_ASSERT_DECL(TC_POLICY_NONE == 0);
> +
>  struct tc_flower {
>  struct tc_flower_key key;
>  struct tc_flower_key mask;
> @@ -337,6 +345,8 @@ struct tc_flower {
>  bool needs_full_ip_proto_mask;
>
>  enum tc_offloaded_state offloaded_state;
> +/* Used to force skip_hw when probing tc features. */
> +enum tc_offload_policy tc_policy;
>  };
>
>  /* assert that if we overflow with a masked write of uint32_t to the last 
> byte
> --
> 2.8.4
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev



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

Re: [ovs-dev] [ovs-discuss] [OVN] ovn-northd takes much CPU when no configuration update

[Numan Siddique]

On Tue, Aug 4, 2020 at 9:02 AM Tony Liu  wrote:

> The probe awakes recomputing?
> There is probe every 5 seconds. Without any connection up/down or failover,
> ovn-northd will recompute everything every 5 seconds, no matter what?
> Really?
>
> Anyways, I will increase the probe interval for now, see if that helps.
>

I think we should optimise this case. I am planning to look into this.

Thanks
Numan


>
>
> Thanks!
>
> Tony
>
> > -Original Message-
> > From: Han Zhou 
> > Sent: Monday, August 3, 2020 8:22 PM
> > To: Tony Liu 
> > Cc: Han Zhou ; ovs-discuss ;
> > ovs-dev 
> > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when no
> > configuration update
> >
> > Sorry that I didn't make it clear enough. The OVSDB probe itself doesn't
> > take much CPU, but the probe awakes ovn-northd main loop, which
> > recompute everything, which is why you see CPU spike.
> > It will be solved by incremental-processing, when only delta is
> > processed, and in case of probe handling, there is no change in
> > configuration, so the delta is zero.
> > For now, please follow the steps to adjust probe interval, if the CPU of
> > ovn-northd (when there is no configuration change) is a concern for you.
> > But please remember that this has no impact to the real CPU usage for
> > handling configuration changes.
> >
> >
> > Thanks,
> > Han
> >
> >
> > On Mon, Aug 3, 2020 at 8:11 PM Tony Liu  >  > wrote:
> >
> >
> >   Health check (5 sec internal) taking 30%-100% CPU is definitely not
> > acceptable,
> >   if that's really the case. There must be some blocking (and not
> > yielding CPU)
> >   in coding, which is not supposed to be there.
> >
> >   Could you point me to the coding for such health check?
> >   Is it single thread? Does it use any event library?
> >
> >
> >   Thanks!
> >
> >   Tony
> >
> >   > -Original Message-
> >   > From: Han Zhou mailto:hz...@ovn.org> >
> >   > Sent: Saturday, August 1, 2020 9:11 PM
> >   > To: Tony Liu  >  >
> >   > Cc: ovs-discuss mailto:ovs-
> > disc...@openvswitch.org> >; ovs-dev  >   > d...@openvswitch.org  >
> >   > Subject: Re: [ovs-discuss] [OVN] ovn-northd takes much CPU when
> > no
> >   > configuration update
> >   >
> >   >
> >   >
> >   > On Fri, Jul 31, 2020 at 4:14 PM Tony Liu <
> tonyliu0...@hotmail.com
> > 
> >   >  >  > > wrote:
> >   >
> >   >
> >   >   Hi,
> >   >
> >   >   I see the active ovn-northd takes much CPU (30% - 100%)
> > when there
> >   > is no
> >   >   configuration from OpenStack, nothing happening on all
> > chassis
> >   > nodes either.
> >   >
> >   >   Is this expected? What is it busy with?
> >   >
> >   >
> >   >
> >   >
> >   > Yes, this is expected. It is due to the OVSDB probe between ovn-
> > northd
> >   > and NB/SB OVSDB servers, which is used to detect the OVSDB
> > connection
> >   > failure.
> >   > Usually this is not a concern (unlike the probe with a large
> > number of
> >   > ovn-controller clients), because ovn-northd is a centralized
> > component
> >   > and the CPU cost when there is no configuration change doesn't
> > matter
> >   > that much. However, if it is a concern, the probe interval
> > (default 5
> >   > sec) can be changed.
> >   > If you change, remember to change on both server side and client
> > side.
> >   > For client side (ovn-northd), it is configured in the NB DB's
> > NB_Global
> >   > table's options:northd_probe_interval. See man page of ovn-nb(5).
> >   > For server side (NB and SB), it is configured in the NB and SB
> > DB's
> >   > Connection table's inactivity_probe column.
> >   >
> >   > Thanks,
> >   > Han
> >   >
> >   >
> >   >
> >   >   
> >   >   2020-07-31T23:08:09.511Z|04267|poll_loop|DBG|wakeup due to
> > [POLLIN]
> >   > on fd 8 (10.6.20.84:44358 
> >  <->10.6.20.84:6641 
> >   >  ) at lib/stream-fd.c:157 (68% CPU
> usage)
> >   >   2020-07-
> > 31T23:08:09.512Z|04268|jsonrpc|DBG|tcp:10.6.20.84:6641
> > 
> >   >  : received request, method="echo",
> > params=[],
> >   > id="echo"
> >   >   2020-07-
> > 31T23:08:09.512Z|04269|jsonrpc|DBG|tcp:10.6.20.84:6641
> > 
> >   >  : send reply, result=[], id="echo"
> >   >   2020-07-31T23:08:12.777Z|04270|poll_loop|DBG|wakeup due to
> > [POLLIN]
> >   > on fd 9 (10.6.20.84:49158 
> >  <->10.6.20.85:6642 

Re: [ovs-dev] [ovs-discuss] [OVN] no response to inactivity probe

[Numan Siddique]

On Tue, Aug 4, 2020 at 9:12 AM Tony Liu  wrote:

> In my deployment, on each Neutron server, there are 13 Neutron server
> processes.
> I see 12 of them (monitor, maintenance, RPC, API) connect to both ovn-nb-db
> and ovn-sb-db. With 3 Neutron server nodes, that's 36 OVSDB clients.
> Is so many clients OK?
>
> Any suggestions how to figure out which side doesn't respond the probe,
> if it's bi-directional? I don't see any activities from logging, other than
> connect/drop and reconnect...
>
> BTW, please let me know if this is not the right place to discuss Neutron
> OVN
> ML2 driver.
>
>
> Thanks!
>
> Tony
>
> > -Original Message-
> > From: dev  On Behalf Of Tony Liu
> > Sent: Monday, August 3, 2020 7:45 PM
> > To: ovs-discuss ; ovs-dev  > d...@openvswitch.org>
> > Subject: [ovs-dev] [OVN] no response to inactivity probe
> >
> > Hi,
> >
> > Neutron OVN ML2 driver was disconnected by ovn-nb-db. There are many
> > error messages from ovn-nb-db leader.
> > 
> > 2020-08-04T02:31:39.751Z|03138|reconnect|ERR|tcp:10.6.20.81:58620: no
> > response to inactivity probe after 5 seconds, disconnecting
> > 2020-08-04T02:31:42.484Z|03139|reconnect|ERR|tcp:10.6.20.81:58300: no
> > response to inactivity probe after 5 seconds, disconnecting
> > 2020-08-04T02:31:49.858Z|03140|reconnect|ERR|tcp:10.6.20.81:59582: no
> > response to inactivity probe after 5 seconds, disconnecting
> > 2020-08-04T02:31:53.057Z|03141|reconnect|ERR|tcp:10.6.20.83:42626: no
> > response to inactivity probe after 5 seconds, disconnecting
> > 2020-08-04T02:31:53.058Z|03142|reconnect|ERR|tcp:10.6.20.82:45412: no
> > response to inactivity probe after 5 seconds, disconnecting
> > 2020-08-04T02:31:54.067Z|03143|reconnect|ERR|tcp:10.6.20.81:59416: no
> > response to inactivity probe after 5 seconds, disconnecting
> > 2020-08-04T02:31:54.809Z|03144|reconnect|ERR|tcp:10.6.20.81:60004: no
> > response to inactivity probe after 5 seconds, disconnecting 
> >
> > Could anyone share a bit details how this inactivity probe works?
>

The inactivity probe is sent by both the server and clients independently.
Meaning ovsdb-server will send an inactivity probe every 'x' configured
seconds
to all its connected clients and if it doesn't get a reply from the client
within some time, it disconnects
the connection.

The inactivity probe from the server side can be configured. Run "ovn-nbctl
list connection"
and you will see inactivity_probe column. You can set this column to
desired value like -
ovn-nbctl set connection . inactivity_probe=3 (for 30 seconds)

The same thing for SB ovsdb-server.

Similarly each client (ovn-northd, ovn-controller, neutron server) sends
inactivity probe every 'y' seconds
and if the client doesn't get any reply from ovsdb-server it will
disconnect the connection and reconnect again.

For ovn-northd you can configured this as - ovn-nbctl set NB_Global .
options:northd_probe_interval=3

For ovn-controllers - ovs-vsctl set open .
external_ids:ovn-remote-probe-interval=3

There is also a probe interval for openflow connection from ovn-controller
to ovs-vswitchd which you can configure as
ovs-vsctl set open . external_ids:ovn-openflow-probe-interval=30 (this is
in seconds)

Regarding the neutron server I think it is set to 60 seconds. Please see
this -
https://github.com/openstack/neutron/blob/master/neutron/conf/plugins/ml2/drivers/ovn/ovn_conf.py#L80

>From the logs you shared, it looks like ovsdb-server is not getting the
probe reply from neutron server after 5 seconds and hence
it is disconnecting. Not sure what's happening though.

You can try increasing the inactivity probe interval on the ovsdb-server
side with the first command I shared.
Note: If "ovn-nbctl list connection" returns empty, you need to create a
connection row like - ovn-nbctl set-connection ptcp:6641:


Thanks
Numan



> From OVN ML2 driver log, I see it connected to the leader, then the
> > connection was closed by leader after 5 or 6 seconds. Is this probe one-
> > way or two-ways?
> > Both sides are not busy, not taking much CPU cycles. Not sure how this
> > could happen. Any thoughts?
> >
> >
> > 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] [PATCH ovn v2 2/2] ovn-northd: Don't send the pkt to conntrack for NAT if its not destined for LB VIP.

[numans]

From: Numan Siddique 

Presently when a logical switch has load balancer(s) associated to it, then the
packet is still sent to conntrack with the action ct_lb on both the ingress
and egress logical switch pipeline even if the destination IP is not LB VIP.

This is because below logical flows are hit:

In the ingress logical switch pipeline:
  - table=9 (ls_in_lb   ), priority=65535, match=(ct.est && !ct.rel && 
!ct.new && !ct.inv), action=(reg0[2] = 1; next;)
  - table=10(ls_in_stateful ), priority=100  , match=(reg0[2] == 1), 
action=(ct_lb;)

In the egress logical switch pipeline:
  - table=3 (ls_out_lb  ), priority=65535, match=(ct.est && !ct.rel && 
!ct.new && !ct.inv), action=(reg0[2] = 1; next;)
  - table=7 (ls_out_stateful), priority=100  , match=(reg0[2] == 1), 
action=(ct_lb;)

This patch avoid unnecessary ct actions by setting the ct_mark to 0x1/0x1 when 
the ct_lb(backends=...) action
is applied for NEW connections and updating the above logical flows to check 
for this mark:

 - table=9 (ls_in_lb), priority=65535, match=(ct.est && !ct.rel && !ct.new && 
!ct.inv && ct.mark == 1/1),
   action=(reg0[2] = 1; next;)

 - table=3 (ls_out_lb), priority=65535, match=(ct.est && !ct.rel && !ct.new && 
!ct.inv && ct.mark == 1/1),
   action=(reg0[2] = 1; next;)

Signed-off-by: Numan Siddique 
---
v1 -> v2
--
 * Rebased to latest master and resolved merge conflicts.

 lib/actions.c|   3 +-
 lib/logical-fields.c |   6 ++-
 northd/ovn-northd.c  |   6 ++-
 tests/ovn.at |  17 +++---
 tests/system-ovn.at  | 122 +--
 5 files changed, 80 insertions(+), 74 deletions(-)

diff --git a/lib/actions.c b/lib/actions.c
index 05fa44b601..1f2520c808 100644
--- a/lib/actions.c
+++ b/lib/actions.c
@@ -1086,7 +1086,8 @@ encode_CT_LB(const struct ovnact_ct_lb *cl,
 if (dst->port) {
 ds_put_format(, ":%"PRIu16, dst->port);
 }
-ds_put_format(, "),commit,table=%d,zone=NXM_NX_REG%d[0..15])",
+ds_put_format(, "),commit,table=%d,zone=NXM_NX_REG%d[0..15],"
+  "exec(set_field:2/3->ct_label))",
   recirc_table, zone_reg);
 }
 
diff --git a/lib/logical-fields.c b/lib/logical-fields.c
index 15342ddedf..bf61df7719 100644
--- a/lib/logical-fields.c
+++ b/lib/logical-fields.c
@@ -126,10 +126,12 @@ ovn_init_symtab(struct shash *symtab)
 expr_symtab_add_field_scoped(symtab, "ct_mark", MFF_CT_MARK, NULL, false,
  WR_CT_COMMIT);
 
-expr_symtab_add_field_scoped(symtab, "ct_label", MFF_CT_LABEL, NULL, false,
- WR_CT_COMMIT);
+expr_symtab_add_field_scoped(symtab, "ct_label", MFF_CT_LABEL, NULL,
+ false, WR_CT_COMMIT);
 expr_symtab_add_subfield_scoped(symtab, "ct_label.blocked", NULL,
 "ct_label[0]", WR_CT_COMMIT);
+expr_symtab_add_subfield_scoped(symtab, "ct_label.natted", NULL,
+"ct_label[1]", WR_CT_COMMIT);
 expr_symtab_add_subfield_scoped(symtab, "ct_label.ecmp_reply_eth", NULL,
 "ct_label[32..79]", WR_CT_COMMIT);
 expr_symtab_add_subfield_scoped(symtab, "ct_label.ecmp_reply_port", NULL,
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index c7b1239adf..293abbff3d 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -5750,10 +5750,12 @@ build_lb(struct ovn_datapath *od, struct hmap *lflows)
  *
  * Send established traffic through conntrack for just NAT. */
 ovn_lflow_add(lflows, od, S_SWITCH_IN_LB, UINT16_MAX - 1,
-  "ct.est && !ct.rel && !ct.new && !ct.inv",
+  "ct.est && !ct.rel && !ct.new && !ct.inv && "
+  "ct_label.natted == 1",
   REGBIT_CONNTRACK_NAT" = 1; next;");
 ovn_lflow_add(lflows, od, S_SWITCH_OUT_LB, UINT16_MAX - 1,
-  "ct.est && !ct.rel && !ct.new && !ct.inv",
+  "ct.est && !ct.rel && !ct.new && !ct.inv && "
+  "ct_label.natted == 1",
   REGBIT_CONNTRACK_NAT" = 1; next;");
 }
 }
diff --git a/tests/ovn.at b/tests/ovn.at
index b0179a8db1..7adc835966 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -197,6 +197,7 @@ ct_label = NXM_NX_CT_LABEL
 ct_label.blocked = ct_label[0]
 ct_label.ecmp_reply_eth = ct_label[32..79]
 ct_label.ecmp_reply_port = ct_label[80..95]
+ct_label.natted = ct_label[1]
 ct_mark = NXM_NX_CT_MARK
 ct_state = NXM_NX_CT_STATE
 ]])
@@ -999,17 +1000,17 @@ ct_lb(192.168.1.2:80, 192.168.1.3:80);
 Syntax error at `192.168.1.2' expecting backends.
 ct_lb(backends=192.168.1.2:80,192.168.1.3:80);
 encodes as group:1
-uses group: id(1), 

[ovs-dev] [PATCH ovn v2 1/2] ovn-northd: Don't send the pkt to conntrack if it is to be routed in egress stage.

[numans]

From: Numan Siddique 

If there is a logical port 'P1' with the IP - 10.0.0.3 and a logical port 'P2' 
with
the IP 20.0.0.3 and if the logical switch of 'P1' has atleast one load balancer
associated with it and atleast one ACL with allow-related action associated 
with it.
Then for every packet from 'P1' to 'P2' after the TCP connection
is established we see a total of 4 recirculations in the datapath on the chassis
claiming 'P1'. This is because,

In the ingress logical switch pipeline, below logical flows are hit
  - table=9 (ls_in_lb   ), priority=65535, match=(ct.est && !ct.rel && 
!ct.new && !ct.inv), action=(reg0[2] = 1; next;)
  - table=10(ls_in_stateful ), priority=100  , match=(reg0[2] == 1), 
action=(ct_lb;)

And in the egress logical switch pipeline, below logical flows are hit
 - table=0 (ls_out_pre_lb  ), priority=100  , match=(ip), action=(reg0[0] = 
1; next;)
 - table=2 (ls_out_pre_stateful), priority=100  , match=(reg0[0] == 1), 
action=(ct_next;)
 - table=3 (ls_out_lb  ), priority=65535, match=(ct.est && !ct.rel && 
!ct.new && !ct.inv), action=(reg0[2] = 1; next;)
 - table=7 (ls_out_stateful), priority=100  , match=(reg0[2] == 1), 
action=(ct_lb;)

In the above example, when the packet enters the egress pipeline and since it 
needs to
enter the router pipeline, we can skip setting reg0[0] if outport is peer port 
of
logical router port. There is no need to send the packet to conntrack in this 
case.

This patch handles this case for router ports. Next patch in the series avoids 
sending to
conntrack with the action - ct_lb if the packet is not destined to the LB VIP.

With the present master for the above example, we see total of 4 recirculations 
on the
chassis claiming the lport 'P1'. With this patch we see only 2 recirculations.

Signed-off-by: Numan Siddique 
---

v1 -> v2

 * No change.

 northd/ovn-northd.8.xml | 33 -
 northd/ovn-northd.c | 39 ++-
 2 files changed, 62 insertions(+), 10 deletions(-)

diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index ed1cd58e70..b741f49347 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -366,6 +366,15 @@
   db="OVN_Northbound"/> table.
 
 
+
+  This table also has a priority-110 flow with the match
+  inport == I for all logical switch
+  datapaths to move traffic to the next table. Where I
+  is the peer of a logical router port. This flow is added to
+  skip the connection tracking of packets which enter from
+  logical router datapath to logical switch datapath.
+
+
 Ingress Table 5: Pre-stateful
 
 
@@ -533,7 +542,20 @@
 
 
   It contains a priority-0 flow that simply moves traffic to the next
-  table.  For established connections a priority 100 flow matches on
+  table.
+
+
+
+  A priority-65535 flow with the match
+  inport == I for all logical switch
+  datapaths to move traffic to the next table. Where I
+  is the peer of a logical router port. This flow is added to
+  skip the connection tracking of packets which enter from
+  logical router datapath to logical switch datapath.
+
+
+
+  For established connections a priority 65534 flow matches on
   ct.est  !ct.rel  !ct.new 
   !ct.inv and sets an action reg0[2] = 1; next; to act
   as a hint for table Stateful to send packets through
@@ -1359,6 +1381,15 @@ output;
   db="OVN_Northbound"/> table.
 
 
+
+  This table also has a priority-110 flow with the match
+  outport == I for all logical switch
+  datapaths to move traffic to the next table. Where I
+  is the peer of a logical router port. This flow is added to
+  skip the connection tracking of packets which will be entering
+  logical router datapath from logical switch datapath for routing.
+
+
 Egress Table 2: Pre-stateful
 
 
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 03c62bafaa..c7b1239adf 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -4850,8 +4850,9 @@ build_lswitch_output_port_sec(struct hmap *ports, struct 
hmap *datapaths,
 }
 
 static void
-build_pre_acl_flows(struct ovn_datapath *od, struct ovn_port *op,
-struct hmap *lflows)
+skip_port_from_conntrack(struct ovn_datapath *od, struct ovn_port *op,
+ enum ovn_stage in_stage, enum ovn_stage out_stage,
+ uint16_t priority, struct hmap *lflows)
 {
 /* Can't use ct() for router ports. Consider the following configuration:
  * lp1(10.0.0.2) on hostA--ls1--lr0--ls2--lp2(10.0.1.2) on hostB, For a
@@ -4867,10 +4868,10 @@ build_pre_acl_flows(struct ovn_datapath *od, struct 
ovn_port *op,
 
 ds_put_format(_in, "ip && inport == %s", op->json_key);
 ds_put_format(_out, "ip && outport == %s", op->json_key);
-ovn_lflow_add_with_hint(lflows, od, S_SWITCH_IN_PRE_ACL, 

[ovs-dev] Маска -- ЦЕНА от 2,80р. за единицу --- Маски защитные ОПТОМ

[торя]

Добрый день!

Предлагаем ОПТОВЫЕ ПОСТАВКИ средств индивидуальной защиты.

Мы продолжаем работать и радуемся открытию бизнеса вместе с Вами! 

Наша команда предлагает специальные цены на самую популярную продукцию СИЗ: 
маски, перчатки, антисептики, рециркуляторы, костюмы, термометры и многое 
другое.

Заказ можно сделать на сайте: http://www.imaskstore.ru

Работаем с государственными учреждениями и компаниями по постоплате.

Доставка в регионы России.

В наличии защитные трехслойные маски

ОПТОВЫЕ ЦЕНЫ при заказе от 100 000 ед.:

При оплате НАЛОМ –2,80р. за ед.

При оплате БЕЗНАЛ (БЕЗ НДС) – 3,40р.

ОПТОВЫЕ ЦЕНЫ при заказе от 2500 до 100 000 ед.:

При оплате НАЛОМ –3,30р. за ед.

При оплате БЕЗНАЛ (БЕЗ НДС) – 3,90р.

В наличии медицинские трехслойные маски

Уточнить наличие, сделать заказ и рассчитать дополнительную скидку Вы можете, 
позвонив нам по телефону или прислав запрос на электронную почту и оставив свой 
номер на сайте.

С Уважением, группа компаний Medimask

Москва:                       +7 (495) 414-29-00
Санкт-Петербург:   +7 (812) 467-46-20

Наш сайт: http://www.imaskstore.ru 

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

Re: [ovs-dev] [PATCH] tc: Use skip_hw flag when probing tc features

[Roi Dayan]

On 2020-08-04 2:44 AM, Ilya Maximets wrote:
> On 8/3/20 12:58 PM, Roi Dayan wrote:
>> There is no need to pass tc rules to hw when just probing
>> for tc features. this will avoid redundant errors from hw drivers
>> that may happen.
> 
> That makes sense.  Thanks!
> Few comments inline.
> 
>>
>> Signed-off-by: Roi Dayan 
>> ---
>>  lib/netdev-offload-tc.c |  2 ++
>>  lib/tc.c| 13 ++---
>>  lib/tc.h|  8 
>>  3 files changed, 16 insertions(+), 7 deletions(-)
>>
>> diff --git a/lib/netdev-offload-tc.c b/lib/netdev-offload-tc.c
>> index 2c9c6f4cae8b..18ff380f9861 100644
>> --- a/lib/netdev-offload-tc.c
>> +++ b/lib/netdev-offload-tc.c
>> @@ -1918,6 +1918,7 @@ probe_multi_mask_per_prio(int ifindex)
>>  
>>  memset(, 0, sizeof flower);
>>  
>> +flower.tc_policy = TC_POLICY_SKIP_HW;
>>  flower.key.eth_type = htons(ETH_P_IP);
>>  flower.mask.eth_type = OVS_BE16_MAX;
>>  memset(_mac, 0x11, sizeof flower.key.dst_mac);
>> @@ -1965,6 +1966,7 @@ probe_tc_block_support(int ifindex)
>>  
>>  memset(, 0, sizeof flower);
>>  
>> +flower.tc_policy = TC_POLICY_SKIP_HW;
>>  flower.key.eth_type = htons(ETH_P_IP);
>>  flower.mask.eth_type = OVS_BE16_MAX;
>>  memset(_mac, 0x11, sizeof flower.key.dst_mac);
>> diff --git a/lib/tc.c b/lib/tc.c
>> index c96d095381d7..8761304c92bb 100644
>> --- a/lib/tc.c
>> +++ b/lib/tc.c
>> @@ -65,12 +65,6 @@ VLOG_DEFINE_THIS_MODULE(tc);
>>  
>>  static struct vlog_rate_limit error_rl = VLOG_RATE_LIMIT_INIT(60, 5);
>>  
>> -enum tc_offload_policy {
>> -TC_POLICY_NONE,
>> -TC_POLICY_SKIP_SW,
>> -TC_POLICY_SKIP_HW
>> -};
>> -
>>  static enum tc_offload_policy tc_policy = TC_POLICY_NONE;
>>  
>>  struct tc_pedit_key_ex {
>> @@ -2757,6 +2751,7 @@ nl_msg_put_flower_options(struct ofpbuf *request, 
>> struct tc_flower *flower)
>>  bool is_vlan = eth_type_vlan(flower->key.eth_type);
>>  bool is_qinq = is_vlan && eth_type_vlan(flower->key.encap_eth_type[0]);
>>  bool is_mpls = eth_type_mpls(flower->key.eth_type);
>> +enum tc_offload_policy policy = flower->tc_policy;
>>  int err;
>>  
>>  /* need to parse acts first as some acts require changing the matching
>> @@ -2882,7 +2877,11 @@ nl_msg_put_flower_options(struct ofpbuf *request, 
>> struct tc_flower *flower)
>>  }
>>  }
>>  
>> -nl_msg_put_u32(request, TCA_FLOWER_FLAGS, 
>> tc_get_tc_cls_policy(tc_policy));
>> +if (policy == TC_POLICY_NONE) {
>> +policy = tc_policy;
>> +}
>> +
>> +nl_msg_put_u32(request, TCA_FLOWER_FLAGS, tc_get_tc_cls_policy(policy));
>>  
>>  if (flower->tunnel) {
>>  nl_msg_put_flower_tunnel(request, flower);
>> diff --git a/lib/tc.h b/lib/tc.h
>> index 028eed5d0658..78f433ceef77 100644
>> --- a/lib/tc.h
>> +++ b/lib/tc.h
>> @@ -312,6 +312,12 @@ is_tcf_id_eq(struct tcf_id *id1, struct tcf_id *id2)
>> && id1->chain == id2->chain;
>>  }
>>  
>> +enum tc_offload_policy {
>> +TC_POLICY_NONE,
> 
> Since now the code actually depends on this value to be zero, it might be
> good to explicitly set it, or have a build assertion.  This will protect us
> from possible issues if someone will try to modify this enum later.
> i.e.
> TC_POLICY_NONE = 0,
> 

great. I did both.

>> +TC_POLICY_SKIP_SW,
>> +TC_POLICY_SKIP_HW
>> +};
>> +
>>  struct tc_flower {
>>  struct tc_flower_key key;
>>  struct tc_flower_key mask;
>> @@ -337,6 +343,8 @@ struct tc_flower {
>>  bool needs_full_ip_proto_mask;
>>  
>>  enum tc_offloaded_state offloaded_state;
>> +/* used to force skip_hw when probing tc features */
> 
> I see that there is a comment below in this file that doesn't follow OVS 
> coding
> style, but, please, use the OVS-style comments for a new code, i.e. start with
> a capital letter and end with a period.
> 

fixed. sent v2.

>> +enum tc_offload_policy tc_policy;
>>  };
>>  
>>  /* assert that if we overflow with a masked write of uint32_t to the last 
>> byte
>>
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev