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

[Tony Liu]

I set the connection target="ptcp:6641:10.6.20.84" for ovn-nb-db
and "ptcp:6642:10.6.20.84" for ovn-sb-db. .84 is the first node
of cluster. Also ovn-openflow-probe-interval=30 on compute node.
It seems helping. Not that many connect/drop/reconnect in logging.
That "commit failure" is also gone.
The issue I reported in another thread "packet drop" seems gone.
And launching VM starts working.

How should I set connection table for all ovn-nb-db and ovn-sb-db
nodes in the cluster to set inactivity_probe?
One row with address 0.0.0.0 seems not working.

Is "external_ids:ovn-remote-probe-interval" in ovsdb-server on
compute node for ovn-controller to probe ovn-sb-db?

Is "external_ids:ovn-openflow-probe-interval" in ovsdb-server on
compute node for ovn-controller to probe ovsdb-server?

What's probe interval for ovsdb-server to probe ovn-controller?


Thanks!

Tony
> -Original Message-
> From: discuss  On Behalf Of Tony
> Liu
> Sent: Wednesday, August 5, 2020 4:29 PM
> To: Han Zhou 
> Cc: ovs-dev ; ovs-discuss  disc...@openvswitch.org>
> Subject: Re: [ovs-discuss] [OVN] no response to inactivity probe
> 
> Hi Han,
> 
> After setting connection target="ptcp:6642:0.0.0.0" for ovn-sb-db, I see
> this error.
> 
> 2020-08-
> 05T23:01:26.819Z|06799|ovsdb_jsonrpc_server|ERR|ptcp:6642:0.0.0.0:
> listen failed: Address already in use  Anything I am missing
> here?
> 
> 
> 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 

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

[Tony Liu]

Hi Han,

After setting connection target="ptcp:6642:0.0.0.0" for ovn-sb-db,
I see this error.

2020-08-05T23:01:26.819Z|06799|ovsdb_jsonrpc_server|ERR|ptcp:6642:0.0.0.0: 
listen failed: Address already in use

Anything I am missing here?


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-
> 

Re: [ovs-dev] packet drop

[Tony Liu]

The drop is caused by flow change.

When packet is dropped.

recirc_id(0),tunnel(tun_id=0x19aca,src=10.6.30.92,dst=10.6.30.22,geneve({class=0x102,type=0x80,len=4,0x20003/0x7fff}),flags(-df+csum+key)),in_port(3),eth(src=fa:16:3e:df:1e:85,dst=00:00:00:00:00:00/01:00:00:00:00:00),eth_type(0x0800),ipv4(proto=1,frag=no),icmp(type=8/0xf8),
 packets:14, bytes:1372, used:0.846s, actions:drop
recirc_id(0),in_port(12),eth(src=fa:16:3e:7d:bb:85,dst=fa:16:3e:df:1e:85),eth_type(0x0800),ipv4(src=192.168.236.152/255.255.255.252,dst=10.6.40.9,proto=1,tos=0/0x3,ttl=64,frag=no),icmp(type=0),
 packets:6, bytes:588, used:8.983s, actions:drop


When packet goes through.

recirc_id(0),tunnel(tun_id=0x19aca,src=10.6.30.92,dst=10.6.30.22,geneve({class=0x102,type=0x80,len=4,0x20003/0x7fff}),flags(-df+csum+key)),in_port(3),eth(src=fa:16:3e:df:1e:85,dst=00:00:00:00:00:00/01:00:00:00:00:00),eth_type(0x0800),ipv4(proto=1,frag=no),icmp(type=8/0xf8),
 packets:3, bytes:294, used:0.104s, actions:12
recirc_id(0),in_port(12),eth(src=fa:16:3e:7d:bb:85,dst=fa:16:3e:df:1e:85),eth_type(0x0800),ipv4(src=192.168.236.152/255.255.255.252,dst=10.6.40.9,proto=1,tos=0/0x3,ttl=64,frag=no),icmp(type=0),
 packets:3, bytes:294, used:0.103s, 
actions:ct_clear,set(tunnel(tun_id=0x1a8ee,dst=10.6.30.92,ttl=64,tp_dst=6081,geneve({class=0x102,type=0x80,len=4,0x1000b}),flags(df|csum|key))),set(eth(src=fa:16:3e:75:b7:e5,dst=52:54:00:0c:ef:b9)),set(ipv4(ttl=63)),3


Is that flow programmed by ovn-controller via ovs-vswitchd?


Thanks!

Tony

> -Original Message-
> From: discuss  On Behalf Of Tony
> Liu
> Sent: Wednesday, August 5, 2020 2:48 PM
> To: ovs-disc...@openvswitch.org; ovs-dev@openvswitch.org
> Subject: [ovs-discuss] packet drop
> 
> Hi,
> 
> I am running ping from external to VM via OVN gateway.
> On the compute node, ICMP request packet is consistently coming into
> interface "ovn-gatewa-1". But there is about 10 out of 25 packet loss on
> tap interface. It's like the switch pauses 10s after every 15s.
> 
> Has anyone experiences such issue?
> Any advice how to look into it?
> 
> 
> 21fed09f-909e-4efc-b117-f5d5fcb636c9
> Bridge br-int
> fail_mode: secure
> datapath_type: system
> Port "ovn-gatewa-0"
> Interface "ovn-gatewa-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.6.30.91"}
> bfd_status: {diagnostic="No Diagnostic", flap_count="1",
> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
> state=up}
> Port "tap2588bb4e-35"
> Interface "tap2588bb4e-35"
> Port "ovn-gatewa-1"
> Interface "ovn-gatewa-1"
> type: geneve
> options: {csum="true", key=flow, remote_ip="10.6.30.92"}
> bfd_status: {diagnostic="No Diagnostic", flap_count="1",
> forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up,
> state=up}
> Port "tap37f6b2d7-cc"
> Interface "tap37f6b2d7-cc"
> Port "tap2c4b3b0f-8b"
> Interface "tap2c4b3b0f-8b"
> Port "tap23245491-a4"
> Interface "tap23245491-a4"
> Port "tap51660269-2c"
> Interface "tap51660269-2c"
> Port "tap276cd1ef-e1"
> Interface "tap276cd1ef-e1"
> Port "tap138526d3-b3"
> Interface "tap138526d3-b3"
> Port "tapd1ae48a1-2d"
> Interface "tapd1ae48a1-2d"
> Port br-int
> Interface br-int
> type: internal
> Port "tapdd08f476-94"
> Interface "tapdd08f476-94"
> 
> 
> 
> Thanks!
> 
> Tony
> 
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovsdb-server: Replace in-memory DB contents at raft install_snapshot.

[Han Zhou]

On Wed, Aug 5, 2020 at 3:04 PM Dumitru Ceara  wrote:
>
> On 8/5/20 11:58 PM, Han Zhou wrote:
> >
> >
> > On Wed, Aug 5, 2020 at 12:48 PM Dumitru Ceara  > > wrote:
> >>
> >> On 8/5/20 7:48 PM, Han Zhou wrote:
> >> >
> >> >
> >> > On Wed, Aug 5, 2020 at 8:28 AM Dumitru Ceara  > 
> >> > >> wrote:
> >> >>
> >> >> Every time a follower has to install a snapshot received from the
> >> >> leader, it should also replace the data in memory. Right now this
only
> >> >> happens when snapshots are installed that also change the schema.
> >> >>
> >> >> This can lead to inconsistent DB data on follower nodes and the
> > snapshot
> >> >> may fail to get applied.
> >> >>
> >> >> CC: Han Zhou mailto:hz...@ovn.org>
> > >>
> >> >> Fixes: bda1f6b60588 ("ovsdb-server: Don't disconnect clients after
> >> > raft install_snapshot.")
> >> >> Signed-off-by: Dumitru Ceara  > 
> >> > >>
> >> >
> >> > Thanks Dumitru! This is a great finding, and sorry for my mistake.
> >> > This patch looks good to me. Just one minor comment below on the test
> >> > case. Otherwise:
> >> >
> >> > Acked-by: Han Zhou mailto:hz...@ovn.org>
> > >>
> >> >
> >>
> >> Thanks Han for the review! I fixed the test case as you suggested and
> >> sent v2.
> >>
> >> I was wondering if this is also the root cause for the issue you
> >> reported a while back during the OVN meeting. In my scenario, if a
> >> follower ends up in this situation, and if the DB gets compacted online
> >> afterwards, the DB file also becomes inconsistent and in some cases
> >> (after the DB server is restarted) all write transactions from clients
> >> are rejected with "ovsdb-error: inconsistent data".
> >>
> > Yes, I believe it is the root cause. I thought this patch was exactly
> > for that issue. Is it also for something else?
> >
>
> This patch is for the issue I described above: inconsistent DB on
> follower followed by online compacting of the DB which corrupts the DB
> file too. I wasn't sure if this was also what you were hitting in your
> deployment, I just wanted to check if there are any other known
> potential issues we need to investigate.
>

OK, I think it should be the same issue. There are no other potential
issues related to "inconsistent data" discovered so far.

> >> Related to that I also sent the following patch to make the
ovsdb-server
> >> storage state available via appctl commands:
> >>
> >>
> >
https://patchwork.ozlabs.org/project/openvswitch/patch/1596467128-13004-1-git-send-email-dce...@redhat.com/
> >>
> >
> > I will take a look.
> >
> > Thanks,
> > Han
> >
>
> Thanks!
> Dumitru
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovsdb: Add unixctl command to show storage status.

[Han Zhou]

On Mon, Aug 3, 2020 at 8:05 AM Dumitru Ceara  wrote:
>
> If a database enters an error state, e.g., in case of RAFT when reading
> the DB file contents if applying the RAFT records triggers constraint
> violations, there's no way to determine this unless a client generates a
> write transaction. Such write transactions would fail with "ovsdb-error:
> inconsistent data".
>
> This commit adds a new command to show the status of the storage that's
> backing a database.
>
> Example, on an inconsistent database:
> $ ovs-appctl -t /tmp/test.ctl ovsdb-server/get-db-storage-status DB
> status: ovsdb error: inconsistent data
>
> Example, on a consistent database:
> $ ovs-appctl -t /tmp/test.ctl ovsdb-server/get-db-storage-status DB
> status: ok
>
> Signed-off-by: Dumitru Ceara 
> ---
>  ovsdb/ovsdb-server.c | 39 +++
>  ovsdb/storage.c  | 10 ++
>  ovsdb/storage.h  |  1 +
>  3 files changed, 50 insertions(+)
>
> diff --git a/ovsdb/ovsdb-server.c b/ovsdb/ovsdb-server.c
> index ef4e996..52107f0 100644
> --- a/ovsdb/ovsdb-server.c
> +++ b/ovsdb/ovsdb-server.c
> @@ -90,6 +90,7 @@ static unixctl_cb_func
ovsdb_server_set_active_ovsdb_server_probe_interval;
>  static unixctl_cb_func ovsdb_server_set_sync_exclude_tables;
>  static unixctl_cb_func ovsdb_server_get_sync_exclude_tables;
>  static unixctl_cb_func ovsdb_server_get_sync_status;
> +static unixctl_cb_func ovsdb_server_get_db_storage_status;
>
>  struct server_config {
>  struct sset *remotes;
> @@ -453,6 +454,9 @@ main(int argc, char *argv[])
>  unixctl_command_register("ovsdb-server/sync-status", "",
>   0, 0, ovsdb_server_get_sync_status,
>   _config);
> +unixctl_command_register("ovsdb-server/get-db-storage-status", "DB",
1, 1,
> + ovsdb_server_get_db_storage_status,
> + _config);
>
>  /* Simulate the behavior of OVS release prior to version 2.5 that
>   * does not support the monitor_cond method.  */
> @@ -1697,6 +1701,41 @@ ovsdb_server_get_sync_status(struct unixctl_conn
*conn, int argc OVS_UNUSED,
>  }
>
>  static void
> +ovsdb_server_get_db_storage_status(struct unixctl_conn *conn,
> +   int argc OVS_UNUSED,
> +   const char *argv[],
> +   void *config_)
> +{
> +struct server_config *config = config_;
> +struct shash_node *node;
> +
> +node = shash_find(config->all_dbs, argv[1]);
> +if (!node) {
> +unixctl_command_reply_error(conn, "Failed to find the
database.");
> +return;
> +}
> +
> +struct db *db = node->data;
> +
> +if (!db->db) {
> +unixctl_command_reply_error(conn, "Failed to find the
database.");
> +return;
> +}
> +
> +struct ds ds = DS_EMPTY_INITIALIZER;
> +char *error = ovsdb_storage_get_error(db->db->storage);
> +
> +if (!error) {
> +ds_put_cstr(, "status: ok");
> +} else {
> +ds_put_format(, "status: %s", error);
> +free(error);
> +}
> +unixctl_command_reply(conn, ds_cstr());
> +ds_destroy();
> +}
> +
> +static void
>  parse_options(int argc, char *argv[],
>struct sset *db_filenames, struct sset *remotes,
>char **unixctl_pathp, char **run_command,
> diff --git a/ovsdb/storage.c b/ovsdb/storage.c
> index 7b4ad16..f662e90 100644
> --- a/ovsdb/storage.c
> +++ b/ovsdb/storage.c
> @@ -198,6 +198,16 @@ ovsdb_storage_get_memory_usage(const struct
ovsdb_storage *storage,
>  }
>  }
>
> +char *
> +ovsdb_storage_get_error(const struct ovsdb_storage *storage)
> +{
> +if (storage->error) {
> +return ovsdb_error_to_string(storage->error);
> +}
> +
> +return NULL;
> +}
> +
>  void
>  ovsdb_storage_run(struct ovsdb_storage *storage)
>  {
> diff --git a/ovsdb/storage.h b/ovsdb/storage.h
> index a223968..02b6e7e 100644
> --- a/ovsdb/storage.h
> +++ b/ovsdb/storage.h
> @@ -42,6 +42,7 @@ const struct uuid *ovsdb_storage_get_sid(const struct
ovsdb_storage *);
>  uint64_t ovsdb_storage_get_applied_index(const struct ovsdb_storage *);
>  void ovsdb_storage_get_memory_usage(const struct ovsdb_storage *,
>  struct simap *usage);
> +char *ovsdb_storage_get_error(const struct ovsdb_storage *);
>
>  void ovsdb_storage_run(struct ovsdb_storage *);
>  void ovsdb_storage_wait(struct ovsdb_storage *);
> --
> 1.8.3.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Thanks Dumitru!
Acked-by: Han Zhou 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovsdb-server: Replace in-memory DB contents at raft install_snapshot.

[Dumitru Ceara]

On 8/5/20 11:58 PM, Han Zhou wrote:
> 
> 
> On Wed, Aug 5, 2020 at 12:48 PM Dumitru Ceara  > wrote:
>>
>> On 8/5/20 7:48 PM, Han Zhou wrote:
>> >
>> >
>> > On Wed, Aug 5, 2020 at 8:28 AM Dumitru Ceara  
>> > >> wrote:
>> >>
>> >> Every time a follower has to install a snapshot received from the
>> >> leader, it should also replace the data in memory. Right now this only
>> >> happens when snapshots are installed that also change the schema.
>> >>
>> >> This can lead to inconsistent DB data on follower nodes and the
> snapshot
>> >> may fail to get applied.
>> >>
>> >> CC: Han Zhou mailto:hz...@ovn.org>
> >>
>> >> Fixes: bda1f6b60588 ("ovsdb-server: Don't disconnect clients after
>> > raft install_snapshot.")
>> >> Signed-off-by: Dumitru Ceara  
>> > >>
>> >
>> > Thanks Dumitru! This is a great finding, and sorry for my mistake.
>> > This patch looks good to me. Just one minor comment below on the test
>> > case. Otherwise:
>> >
>> > Acked-by: Han Zhou mailto:hz...@ovn.org>
> >>
>> >
>>
>> Thanks Han for the review! I fixed the test case as you suggested and
>> sent v2.
>>
>> I was wondering if this is also the root cause for the issue you
>> reported a while back during the OVN meeting. In my scenario, if a
>> follower ends up in this situation, and if the DB gets compacted online
>> afterwards, the DB file also becomes inconsistent and in some cases
>> (after the DB server is restarted) all write transactions from clients
>> are rejected with "ovsdb-error: inconsistent data".
>>
> Yes, I believe it is the root cause. I thought this patch was exactly
> for that issue. Is it also for something else?
> 

This patch is for the issue I described above: inconsistent DB on
follower followed by online compacting of the DB which corrupts the DB
file too. I wasn't sure if this was also what you were hitting in your
deployment, I just wanted to check if there are any other known
potential issues we need to investigate.

>> Related to that I also sent the following patch to make the ovsdb-server
>> storage state available via appctl commands:
>>
>>
> https://patchwork.ozlabs.org/project/openvswitch/patch/1596467128-13004-1-git-send-email-dce...@redhat.com/
>>
> 
> I will take a look.
> 
> Thanks,
> Han
> 

Thanks!
Dumitru

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

Re: [ovs-dev] [PATCH] ovsdb-server: Replace in-memory DB contents at raft install_snapshot.

[Han Zhou]

On Wed, Aug 5, 2020 at 12:48 PM Dumitru Ceara  wrote:
>
> On 8/5/20 7:48 PM, Han Zhou wrote:
> >
> >
> > On Wed, Aug 5, 2020 at 8:28 AM Dumitru Ceara  > > wrote:
> >>
> >> Every time a follower has to install a snapshot received from the
> >> leader, it should also replace the data in memory. Right now this only
> >> happens when snapshots are installed that also change the schema.
> >>
> >> This can lead to inconsistent DB data on follower nodes and the
snapshot
> >> may fail to get applied.
> >>
> >> CC: Han Zhou mailto:hz...@ovn.org>>
> >> Fixes: bda1f6b60588 ("ovsdb-server: Don't disconnect clients after
> > raft install_snapshot.")
> >> Signed-off-by: Dumitru Ceara  > >
> >
> > Thanks Dumitru! This is a great finding, and sorry for my mistake.
> > This patch looks good to me. Just one minor comment below on the test
> > case. Otherwise:
> >
> > Acked-by: Han Zhou mailto:hz...@ovn.org>>
> >
>
> Thanks Han for the review! I fixed the test case as you suggested and
> sent v2.
>
> I was wondering if this is also the root cause for the issue you
> reported a while back during the OVN meeting. In my scenario, if a
> follower ends up in this situation, and if the DB gets compacted online
> afterwards, the DB file also becomes inconsistent and in some cases
> (after the DB server is restarted) all write transactions from clients
> are rejected with "ovsdb-error: inconsistent data".
>
Yes, I believe it is the root cause. I thought this patch was exactly for
that issue. Is it also for something else?

> Related to that I also sent the following patch to make the ovsdb-server
> storage state available via appctl commands:
>
>
https://patchwork.ozlabs.org/project/openvswitch/patch/1596467128-13004-1-git-send-email-dce...@redhat.com/
>

I will take a look.

Thanks,
Han

> Regards,
> Dumitru
>
> >> ---
> >>  ovsdb/ovsdb-server.c| 21 +
> >>  tests/idltest.ovsschema |  9 +
> >>  tests/ovsdb-cluster.at   | 28
> > +---
> >>  tests/ovsdb-idl.at   |  1 +
> >>  4 files changed, 48 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/ovsdb/ovsdb-server.c b/ovsdb/ovsdb-server.c
> >> index ef4e996..fd7891a 100644
> >> --- a/ovsdb/ovsdb-server.c
> >> +++ b/ovsdb/ovsdb-server.c
> >> @@ -543,13 +543,14 @@ parse_txn(struct server_config *config, struct
> > db *db,
> >>const struct ovsdb_schema *schema, const struct json
*txn_json,
> >>const struct uuid *txnid)
> >>  {
> >> -if (schema && (!db->db->schema || strcmp(schema->version,
> >> -
db->db->schema->version))) {
> >> +if (schema) {
> >>  /* We're replacing the schema (and the data).  Destroy the
> > database
> >>   * (first grabbing its storage), then replace it with the new
> > schema.
> >>   * The transaction must also include the replacement data.
> >>   *
> >> - * Only clustered database schema changes go through this
> > path. */
> >> + * Only clustered database schema changes and snapshot
installs
> >> + * go through this path.
> >> + */
> >>  ovs_assert(txn_json);
> >>  ovs_assert(ovsdb_storage_is_clustered(db->db->storage));
> >>
> >> @@ -559,11 +560,15 @@ parse_txn(struct server_config *config, struct
> > db *db,
> >>  return error;
> >>  }
> >>
> >> -ovsdb_jsonrpc_server_reconnect(
> >> -config->jsonrpc, false,
> >> -(db->db->schema
> >> - ? xasprintf("database %s schema changed", db->db->name)
> >> - : xasprintf("database %s connected to storage",
> > db->db->name)));
> >> +if (!db->db->schema ||
> >> +strcmp(schema->version, db->db->schema->version)) {
> >> +ovsdb_jsonrpc_server_reconnect(
> >> +config->jsonrpc, false,
> >> +(db->db->schema
> >> +? xasprintf("database %s schema changed",
db->db->name)
> >> +: xasprintf("database %s connected to storage",
> >> +db->db->name)));
> >> +}
> >>
> >>  ovsdb_replace(db->db,
> > ovsdb_create(ovsdb_schema_clone(schema), NULL));
> >>
> >> diff --git a/tests/idltest.ovsschema b/tests/idltest.ovsschema
> >> index e02b975..e04755e 100644
> >> --- a/tests/idltest.ovsschema
> >> +++ b/tests/idltest.ovsschema
> >> @@ -54,6 +54,15 @@
> >>},
> >>"isRoot" : true
> >>  },
> >> +"indexed": {
> >> +  "columns": {
> >> +"i": {
> >> +  "type": "integer"
> >> +}
> >> +  },
> >> +  "indexes": [["i"]],
> >> +  "isRoot" : true
> >> +},
> >>  "simple": {
> >>"columns": {
> >>  "b": {
> >> diff --git a/tests/ovsdb-cluster.at 
> > b/tests/ovsdb-cluster.at 
> >> index 9714545..06d27c9 100644
> >> --- a/tests/ovsdb-cluster.at 

[ovs-dev] packet drop

[Tony Liu]

Hi,

I am running ping from external to VM via OVN gateway.
On the compute node, ICMP request packet is consistently coming
into interface "ovn-gatewa-1". But there is about 10 out of 25
packet loss on tap interface. It's like the switch pauses 10s
after every 15s.

Has anyone experiences such issue?
Any advice how to look into it?


21fed09f-909e-4efc-b117-f5d5fcb636c9
Bridge br-int
fail_mode: secure
datapath_type: system
Port "ovn-gatewa-0"
Interface "ovn-gatewa-0"
type: geneve
options: {csum="true", key=flow, remote_ip="10.6.30.91"}
bfd_status: {diagnostic="No Diagnostic", flap_count="1", 
forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up, state=up}
Port "tap2588bb4e-35"
Interface "tap2588bb4e-35"
Port "ovn-gatewa-1"
Interface "ovn-gatewa-1"
type: geneve
options: {csum="true", key=flow, remote_ip="10.6.30.92"}
bfd_status: {diagnostic="No Diagnostic", flap_count="1", 
forwarding="true", remote_diagnostic="No Diagnostic", remote_state=up, state=up}
Port "tap37f6b2d7-cc"
Interface "tap37f6b2d7-cc"
Port "tap2c4b3b0f-8b"
Interface "tap2c4b3b0f-8b"
Port "tap23245491-a4"
Interface "tap23245491-a4"
Port "tap51660269-2c"
Interface "tap51660269-2c"
Port "tap276cd1ef-e1"
Interface "tap276cd1ef-e1"
Port "tap138526d3-b3"
Interface "tap138526d3-b3"
Port "tapd1ae48a1-2d"
Interface "tapd1ae48a1-2d"
Port br-int
Interface br-int
type: internal
Port "tapdd08f476-94"
Interface "tapdd08f476-94"



Thanks!

Tony

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

Re: [ovs-dev] [PATCH] ovsdb-server: Replace in-memory DB contents at raft install_snapshot.

[Dumitru Ceara]

On 8/5/20 7:48 PM, Han Zhou wrote:
> 
> 
> On Wed, Aug 5, 2020 at 8:28 AM Dumitru Ceara  > wrote:
>>
>> Every time a follower has to install a snapshot received from the
>> leader, it should also replace the data in memory. Right now this only
>> happens when snapshots are installed that also change the schema.
>>
>> This can lead to inconsistent DB data on follower nodes and the snapshot
>> may fail to get applied.
>>
>> CC: Han Zhou mailto:hz...@ovn.org>>
>> Fixes: bda1f6b60588 ("ovsdb-server: Don't disconnect clients after
> raft install_snapshot.")
>> Signed-off-by: Dumitru Ceara  >
> 
> Thanks Dumitru! This is a great finding, and sorry for my mistake.
> This patch looks good to me. Just one minor comment below on the test
> case. Otherwise:
> 
> Acked-by: Han Zhou mailto:hz...@ovn.org>>
> 

Thanks Han for the review! I fixed the test case as you suggested and
sent v2.

I was wondering if this is also the root cause for the issue you
reported a while back during the OVN meeting. In my scenario, if a
follower ends up in this situation, and if the DB gets compacted online
afterwards, the DB file also becomes inconsistent and in some cases
(after the DB server is restarted) all write transactions from clients
are rejected with "ovsdb-error: inconsistent data".

Related to that I also sent the following patch to make the ovsdb-server
storage state available via appctl commands:

https://patchwork.ozlabs.org/project/openvswitch/patch/1596467128-13004-1-git-send-email-dce...@redhat.com/

Regards,
Dumitru

>> ---
>>  ovsdb/ovsdb-server.c    | 21 +
>>  tests/idltest.ovsschema |  9 +
>>  tests/ovsdb-cluster.at   | 28
> +---
>>  tests/ovsdb-idl.at       |  1 +
>>  4 files changed, 48 insertions(+), 11 deletions(-)
>>
>> diff --git a/ovsdb/ovsdb-server.c b/ovsdb/ovsdb-server.c
>> index ef4e996..fd7891a 100644
>> --- a/ovsdb/ovsdb-server.c
>> +++ b/ovsdb/ovsdb-server.c
>> @@ -543,13 +543,14 @@ parse_txn(struct server_config *config, struct
> db *db,
>>            const struct ovsdb_schema *schema, const struct json *txn_json,
>>            const struct uuid *txnid)
>>  {
>> -    if (schema && (!db->db->schema || strcmp(schema->version,
>> -                                             db->db->schema->version))) {
>> +    if (schema) {
>>          /* We're replacing the schema (and the data).  Destroy the
> database
>>           * (first grabbing its storage), then replace it with the new
> schema.
>>           * The transaction must also include the replacement data.
>>           *
>> -         * Only clustered database schema changes go through this
> path. */
>> +         * Only clustered database schema changes and snapshot installs
>> +         * go through this path.
>> +         */
>>          ovs_assert(txn_json);
>>          ovs_assert(ovsdb_storage_is_clustered(db->db->storage));
>>
>> @@ -559,11 +560,15 @@ parse_txn(struct server_config *config, struct
> db *db,
>>              return error;
>>          }
>>
>> -        ovsdb_jsonrpc_server_reconnect(
>> -            config->jsonrpc, false,
>> -            (db->db->schema
>> -             ? xasprintf("database %s schema changed", db->db->name)
>> -             : xasprintf("database %s connected to storage",
> db->db->name)));
>> +        if (!db->db->schema ||
>> +            strcmp(schema->version, db->db->schema->version)) {
>> +            ovsdb_jsonrpc_server_reconnect(
>> +                config->jsonrpc, false,
>> +                (db->db->schema
>> +                ? xasprintf("database %s schema changed", db->db->name)
>> +                : xasprintf("database %s connected to storage",
>> +                            db->db->name)));
>> +        }
>>
>>          ovsdb_replace(db->db,
> ovsdb_create(ovsdb_schema_clone(schema), NULL));
>>
>> diff --git a/tests/idltest.ovsschema b/tests/idltest.ovsschema
>> index e02b975..e04755e 100644
>> --- a/tests/idltest.ovsschema
>> +++ b/tests/idltest.ovsschema
>> @@ -54,6 +54,15 @@
>>        },
>>        "isRoot" : true
>>      },
>> +    "indexed": {
>> +      "columns": {
>> +        "i": {
>> +          "type": "integer"
>> +        }
>> +      },
>> +      "indexes": [["i"]],
>> +      "isRoot" : true
>> +    },
>>      "simple": {
>>        "columns": {
>>          "b": {
>> diff --git a/tests/ovsdb-cluster.at 
> b/tests/ovsdb-cluster.at 
>> index 9714545..06d27c9 100644
>> --- a/tests/ovsdb-cluster.at 
>> +++ b/tests/ovsdb-cluster.at 
>> @@ -332,15 +332,31 @@ for i in `seq $n`; do
>>      AT_CHECK([ovsdb_client_wait unix:s$i.ovsdb $schema_name connected])
>>  done
>>
>> +AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
>> +      {"op": "insert",
>> +       "table": "indexed",
>> +       "row": {"i": 1}}]]'], [0], [ignore], [ignore])
>> +
>>  # 

[ovs-dev] [PATCH v2] ovsdb-server: Replace in-memory DB contents at raft install_snapshot.

[Dumitru Ceara]

Every time a follower has to install a snapshot received from the
leader, it should also replace the data in memory. Right now this only
happens when snapshots are installed that also change the schema.

This can lead to inconsistent DB data on follower nodes and the snapshot
may fail to get applied.

CC: Han Zhou 
Fixes: bda1f6b60588 ("ovsdb-server: Don't disconnect clients after raft 
install_snapshot.")
Acked-by: Han Zhou 
Signed-off-by: Dumitru Ceara 
---
v2:
- Added Han's Ack.
- Made test more resilient as suggested by Han.
---
 ovsdb/ovsdb-server.c| 21 +
 tests/idltest.ovsschema |  9 +
 tests/ovsdb-cluster.at  | 32 +---
 tests/ovsdb-idl.at  |  1 +
 4 files changed, 52 insertions(+), 11 deletions(-)

diff --git a/ovsdb/ovsdb-server.c b/ovsdb/ovsdb-server.c
index ef4e996..fd7891a 100644
--- a/ovsdb/ovsdb-server.c
+++ b/ovsdb/ovsdb-server.c
@@ -543,13 +543,14 @@ parse_txn(struct server_config *config, struct db *db,
   const struct ovsdb_schema *schema, const struct json *txn_json,
   const struct uuid *txnid)
 {
-if (schema && (!db->db->schema || strcmp(schema->version,
- db->db->schema->version))) {
+if (schema) {
 /* We're replacing the schema (and the data).  Destroy the database
  * (first grabbing its storage), then replace it with the new schema.
  * The transaction must also include the replacement data.
  *
- * Only clustered database schema changes go through this path. */
+ * Only clustered database schema changes and snapshot installs
+ * go through this path.
+ */
 ovs_assert(txn_json);
 ovs_assert(ovsdb_storage_is_clustered(db->db->storage));
 
@@ -559,11 +560,15 @@ parse_txn(struct server_config *config, struct db *db,
 return error;
 }
 
-ovsdb_jsonrpc_server_reconnect(
-config->jsonrpc, false,
-(db->db->schema
- ? xasprintf("database %s schema changed", db->db->name)
- : xasprintf("database %s connected to storage", db->db->name)));
+if (!db->db->schema ||
+strcmp(schema->version, db->db->schema->version)) {
+ovsdb_jsonrpc_server_reconnect(
+config->jsonrpc, false,
+(db->db->schema
+? xasprintf("database %s schema changed", db->db->name)
+: xasprintf("database %s connected to storage",
+db->db->name)));
+}
 
 ovsdb_replace(db->db, ovsdb_create(ovsdb_schema_clone(schema), NULL));
 
diff --git a/tests/idltest.ovsschema b/tests/idltest.ovsschema
index e02b975..e04755e 100644
--- a/tests/idltest.ovsschema
+++ b/tests/idltest.ovsschema
@@ -54,6 +54,15 @@
   },
   "isRoot" : true
 },
+"indexed": {
+  "columns": {
+"i": {
+  "type": "integer"
+}
+  },
+  "indexes": [["i"]],
+  "isRoot" : true
+},
 "simple": {
   "columns": {
 "b": {
diff --git a/tests/ovsdb-cluster.at b/tests/ovsdb-cluster.at
index 9714545..e0758e9 100644
--- a/tests/ovsdb-cluster.at
+++ b/tests/ovsdb-cluster.at
@@ -332,13 +332,29 @@ for i in `seq $n`; do
 AT_CHECK([ovsdb_client_wait unix:s$i.ovsdb $schema_name connected])
 done
 
+AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
+  {"op": "insert",
+   "table": "indexed",
+   "row": {"i": 0}}]]'], [0], [ignore], [ignore])
+
 # Kill one follower (s2) and write some data to cluster, so that the follower 
is falling behind
 printf "\ns2: stopping\n"
 OVS_APP_EXIT_AND_WAIT_BY_TARGET([`pwd`/s2], [s2.pid])
 
+# Delete "i":0 and readd it to get a different UUID for it.
+AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
+  {"op": "delete",
+   "table": "indexed",
+   "where": [["i", "==", 0]]}]]'], [0], [ignore], [ignore])
+
 AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
   {"op": "insert",
-   "table": "simple",
+   "table": "indexed",
+   "row": {"i": 0}}]]'], [0], [ignore], [ignore])
+
+AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
+  {"op": "insert",
+   "table": "indexed",
"row": {"i": 1}}]]'], [0], [ignore], [ignore])
 
 # Compact leader online to generate snapshot
@@ -355,8 +371,18 @@ AT_CHECK([ovsdb_client_wait unix:s2.ovsdb $schema_name 
connected])
 # succeed.
 AT_CHECK([ovsdb-client transact unix:s2.ovsdb '[["idltest",
   {"op": "insert",
-   "table": "simple",
-   "row": {"i": 1}}]]'], [0], [ignore], [ignore])
+   "table": "indexed",
+   "row": {"i": 2}}]]'], [0], [ignore], [ignore])
+
+# The snapshot should overwrite the in-memory contents of the DB on S2
+# without generating any constraint violations. All tree records (0, 1, 2)
+# should be in the DB at this point.
+AT_CHECK([ovsdb-client --no-headings dump unix:s2.ovsdb idltest indexed | 

[ovs-dev] Tablas dinámicas en Excel - Webinar

[9 horas en 3 sesiones de 3 Horas]

Buenos día 
Quise aprovechar la oportunidad de hacerte una invitación para tomar nuestro 
curso de 9 horas en 3 sesiones de 3 Horas :
 
Nombre:Tablas dinámicas en Excel
Fechas y horas: 
Sábado 22 de Agosto - Sábado 29 de Agosto y Sábado 05 de Septiembre
Formato: En línea con interacción en vivo.
Lugar: En Vivo desde su computadora
Instructor: José Chabarría

Nuestro curso está diseñado para enseñarte a importar o construir bases de 
datos correctamente estructuradas para la creación de tablas dinámicas y a 
utilizar todas las herramientas de edición que Excel ofrece para esta 
funcionalidad.

Ejes Temáticos:

- Fundamentos de tablas dinámicas. 
- Creando su primera tabla dinámica.
- Personalizando una tabla dinámica.
- Agrupando, ordenando y filtrando los datos.
- Aplicando fórmulas en tablas dinámicas.
- Utilizando gráficos dinámicos y otras visualizaciones.

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

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

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

o puede enviarnos un Whatsapp. 

Qué tengas un gran día.
Saludos.

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


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

Re: [ovs-dev] [PATCH] net: openvswitch: silence suspicious RCU usage warning

[Eelco Chaudron]

On 5 Aug 2020, at 9:19, xiangxia.m@gmail.com wrote:


From: Tonghao Zhang 

ovs_flow_tbl_destroy always is called from RCU callback
or error path. It is no need to check if rcu_read_lock
or lockdep_ovsl_is_held was held.

ovs_dp_cmd_fill_info always is called with ovs_mutex,
So use the rcu_dereference_ovsl instead of rcu_dereference
in ovs_flow_tbl_masks_cache_size.

Fixes: 9bf24f594c6a ("net: openvswitch: make masks cache size 
configurable")

Cc: Eelco Chaudron 
Reported-by: syzbot+c0eb9e7cdde04e4eb...@syzkaller.appspotmail.com
Reported-by: syzbot+f612c02823acb02ff...@syzkaller.appspotmail.com
Signed-off-by: Tonghao Zhang 


Thanks for fixing this, I was (am) on PTO so did not notice it earlier!

Cheers,

Eelco

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

Re: [ovs-dev] [PATCH] net: openvswitch: silence suspicious RCU usage warning

[David Miller]

From: xiangxia.m@gmail.com
Date: Wed,  5 Aug 2020 15:19:11 +0800

> From: Tonghao Zhang 
> 
> ovs_flow_tbl_destroy always is called from RCU callback
> or error path. It is no need to check if rcu_read_lock
> or lockdep_ovsl_is_held was held.
> 
> ovs_dp_cmd_fill_info always is called with ovs_mutex,
> So use the rcu_dereference_ovsl instead of rcu_dereference
> in ovs_flow_tbl_masks_cache_size.
> 
> Fixes: 9bf24f594c6a ("net: openvswitch: make masks cache size configurable")
> Cc: Eelco Chaudron 
> Reported-by: syzbot+c0eb9e7cdde04e4eb...@syzkaller.appspotmail.com
> Reported-by: syzbot+f612c02823acb02ff...@syzkaller.appspotmail.com
> Signed-off-by: Tonghao Zhang 

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

Re: [ovs-dev] [PATCH ovn] ovn-nbctl: Add some hint for --ecmp in error message.

[Han Zhou]

On Fri, Jun 19, 2020 at 6:25 PM Han Zhou  wrote:
>
> Add the hint to remind user about --ecmp option when needed.
>
> Signed-off-by: Han Zhou 

This patch needs a review. It seems to be forgotten.

Thanks,
Han

> ---
>  tests/ovn-nbctl.at| 2 +-
>  utilities/ovn-nbctl.c | 3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tests/ovn-nbctl.at b/tests/ovn-nbctl.at
> index 14de1a8..54b4ad2 100644
> --- a/tests/ovn-nbctl.at
> +++ b/tests/ovn-nbctl.at
> @@ -1414,7 +1414,7 @@ AT_CHECK([ovn-nbctl lr-route-add lr0 10.0.0.1/24
11.0.0.2])
>
>  dnl Add overlapping route with 10.0.0.1/24
>  AT_CHECK([ovn-nbctl lr-route-add lr0 10.0.0.111/24 11.0.0.1], [1], [],
> -  [ovn-nbctl: duplicate prefix: 10.0.0.0/24 (policy: dst-ip)
> +  [ovn-nbctl: duplicate prefix: 10.0.0.0/24 (policy: dst-ip). Use option
--ecmp to allow this for ECMP routing.
>  ])
>  AT_CHECK([ovn-nbctl lr-route-add lr0 10.0.0.111a/24 11.0.0.1], [1], [],
>[ovn-nbctl: bad prefix argument: 10.0.0.111a/24
> diff --git a/utilities/ovn-nbctl.c b/utilities/ovn-nbctl.c
> index 6ccc702..75fd8f9 100644
> --- a/utilities/ovn-nbctl.c
> +++ b/utilities/ovn-nbctl.c
> @@ -3833,7 +3833,8 @@ nbctl_lr_route_add(struct ctl_context *ctx)
>  }
>
>  if (!may_exist) {
> -ctl_error(ctx, "duplicate prefix: %s (policy: %s)",
> +ctl_error(ctx, "duplicate prefix: %s (policy: %s). Use
option"
> +  " --ecmp to allow this for ECMP routing.",
>prefix, is_src_route ? "src-ip" : "dst-ip");
>  free(next_hop);
>  free(rt_prefix);
> --
> 2.1.0
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovsdb-server: Replace in-memory DB contents at raft install_snapshot.

[Han Zhou]

On Wed, Aug 5, 2020 at 8:28 AM Dumitru Ceara  wrote:
>
> Every time a follower has to install a snapshot received from the
> leader, it should also replace the data in memory. Right now this only
> happens when snapshots are installed that also change the schema.
>
> This can lead to inconsistent DB data on follower nodes and the snapshot
> may fail to get applied.
>
> CC: Han Zhou 
> Fixes: bda1f6b60588 ("ovsdb-server: Don't disconnect clients after raft
install_snapshot.")
> Signed-off-by: Dumitru Ceara 

Thanks Dumitru! This is a great finding, and sorry for my mistake.
This patch looks good to me. Just one minor comment below on the test case.
Otherwise:

Acked-by: Han Zhou 

> ---
>  ovsdb/ovsdb-server.c| 21 +
>  tests/idltest.ovsschema |  9 +
>  tests/ovsdb-cluster.at  | 28 +---
>  tests/ovsdb-idl.at  |  1 +
>  4 files changed, 48 insertions(+), 11 deletions(-)
>
> diff --git a/ovsdb/ovsdb-server.c b/ovsdb/ovsdb-server.c
> index ef4e996..fd7891a 100644
> --- a/ovsdb/ovsdb-server.c
> +++ b/ovsdb/ovsdb-server.c
> @@ -543,13 +543,14 @@ parse_txn(struct server_config *config, struct db
*db,
>const struct ovsdb_schema *schema, const struct json *txn_json,
>const struct uuid *txnid)
>  {
> -if (schema && (!db->db->schema || strcmp(schema->version,
> - db->db->schema->version))) {
> +if (schema) {
>  /* We're replacing the schema (and the data).  Destroy the
database
>   * (first grabbing its storage), then replace it with the new
schema.
>   * The transaction must also include the replacement data.
>   *
> - * Only clustered database schema changes go through this path.
*/
> + * Only clustered database schema changes and snapshot installs
> + * go through this path.
> + */
>  ovs_assert(txn_json);
>  ovs_assert(ovsdb_storage_is_clustered(db->db->storage));
>
> @@ -559,11 +560,15 @@ parse_txn(struct server_config *config, struct db
*db,
>  return error;
>  }
>
> -ovsdb_jsonrpc_server_reconnect(
> -config->jsonrpc, false,
> -(db->db->schema
> - ? xasprintf("database %s schema changed", db->db->name)
> - : xasprintf("database %s connected to storage",
db->db->name)));
> +if (!db->db->schema ||
> +strcmp(schema->version, db->db->schema->version)) {
> +ovsdb_jsonrpc_server_reconnect(
> +config->jsonrpc, false,
> +(db->db->schema
> +? xasprintf("database %s schema changed", db->db->name)
> +: xasprintf("database %s connected to storage",
> +db->db->name)));
> +}
>
>  ovsdb_replace(db->db, ovsdb_create(ovsdb_schema_clone(schema),
NULL));
>
> diff --git a/tests/idltest.ovsschema b/tests/idltest.ovsschema
> index e02b975..e04755e 100644
> --- a/tests/idltest.ovsschema
> +++ b/tests/idltest.ovsschema
> @@ -54,6 +54,15 @@
>},
>"isRoot" : true
>  },
> +"indexed": {
> +  "columns": {
> +"i": {
> +  "type": "integer"
> +}
> +  },
> +  "indexes": [["i"]],
> +  "isRoot" : true
> +},
>  "simple": {
>"columns": {
>  "b": {
> diff --git a/tests/ovsdb-cluster.at b/tests/ovsdb-cluster.at
> index 9714545..06d27c9 100644
> --- a/tests/ovsdb-cluster.at
> +++ b/tests/ovsdb-cluster.at
> @@ -332,15 +332,31 @@ for i in `seq $n`; do
>  AT_CHECK([ovsdb_client_wait unix:s$i.ovsdb $schema_name connected])
>  done
>
> +AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
> +  {"op": "insert",
> +   "table": "indexed",
> +   "row": {"i": 1}}]]'], [0], [ignore], [ignore])
> +
>  # Kill one follower (s2) and write some data to cluster, so that the
follower is falling behind
>  printf "\ns2: stopping\n"
>  OVS_APP_EXIT_AND_WAIT_BY_TARGET([`pwd`/s2], [s2.pid])
>
> +# Delete "i":1 and readd it to get a different UUID for it.
> +AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
> +  {"op": "delete",
> +   "table": "indexed",
> +   "where": [["i", "==", 1]]}]]'], [0], [ignore], [ignore])
> +
>  AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
>{"op": "insert",
> -   "table": "simple",
> +   "table": "indexed",
> "row": {"i": 1}}]]'], [0], [ignore], [ignore])
>
> +AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
> +  {"op": "insert",
> +   "table": "indexed",
> +   "row": {"i": 2}}]]'], [0], [ignore], [ignore])
> +
>  # Compact leader online to generate snapshot
>  AT_CHECK([ovs-appctl -t "`pwd`"/s1 ovsdb-server/compact])
>
> @@ -355,8 +371,14 @@ AT_CHECK([ovsdb_client_wait unix:s2.ovsdb
$schema_name connected])
>  # succeed.
>  AT_CHECK([ovsdb-client transact unix:s2.ovsdb '[["idltest",
>{"op": "insert",
> -   "table": 

Re: [ovs-dev] [PATCH] Remove manpages.mk from git

[Gregory Rose]

On 8/5/2020 4:38 AM, Timothy Redaelli wrote:

manpages.mk is generated at build-time using sodepends.py and so there is no
need to keep it in git.

Signed-off-by: Timothy Redaelli 


Seems like a good idea to me.  Applies cleanly and test build succeeded
with no issues.

Tested-by: Greg Rose 
Acked-by: Greg Rose 


---
  .gitignore  |   1 +
  Makefile.am |   2 +-
  manpages.mk | 266 
  3 files changed, 2 insertions(+), 267 deletions(-)
  delete mode 100644 manpages.mk

diff --git a/.gitignore b/.gitignore
index 2ac9cdac7..f1cdcf124 100644
--- a/.gitignore
+++ b/.gitignore
@@ -55,6 +55,7 @@
  /docs-check
  /install-sh
  /libtool
+/manpages.mk
  /manpage-check
  /missing
  /missing-distfiles
diff --git a/Makefile.am b/Makefile.am
index 27ef9e4b4..8ead17029 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -412,7 +412,7 @@ flake8-check: $(FLAKE8_PYFILES)
  endif
  CLEANFILES += flake8-check
  
-include $(srcdir)/manpages.mk

+-include $(srcdir)/manpages.mk
  $(srcdir)/manpages.mk: $(MAN_ROOTS) build-aux/sodepends.py 
python/build/soutil.py
@PYTHONPATH=$$PYTHONPATH$(psep)$(srcdir)/python $(PYTHON3) 
$(srcdir)/build-aux/sodepends.py -I. -I$(srcdir) $(MAN_ROOTS) >$(@F).tmp
@if cmp -s $(@F).tmp $@; then \
diff --git a/manpages.mk b/manpages.mk
deleted file mode 100644
index dc201484c..0
--- a/manpages.mk
+++ /dev/null
@@ -1,266 +0,0 @@
-# Generated automatically -- do not modify!-*- buffer-read-only: t -*-
-
-ovsdb/ovsdb-client.1: \
-   ovsdb/ovsdb-client.1.in \
-   lib/common-syn.man \
-   lib/common.man \
-   lib/daemon-syn.man \
-   lib/daemon.man \
-   lib/ovs.tmac \
-   lib/ssl-bootstrap-syn.man \
-   lib/ssl-bootstrap.man \
-   lib/ssl-connect-syn.man \
-   lib/ssl-connect.man \
-   lib/ssl-syn.man \
-   lib/ssl.man \
-   lib/table.man \
-   lib/vlog-syn.man \
-   lib/vlog.man \
-   ovsdb/ovsdb-schemas.man
-ovsdb/ovsdb-client.1.in:
-lib/common-syn.man:
-lib/common.man:
-lib/daemon-syn.man:
-lib/daemon.man:
-lib/ovs.tmac:
-lib/ssl-bootstrap-syn.man:
-lib/ssl-bootstrap.man:
-lib/ssl-connect-syn.man:
-lib/ssl-connect.man:
-lib/ssl-syn.man:
-lib/ssl.man:
-lib/table.man:
-lib/vlog-syn.man:
-lib/vlog.man:
-ovsdb/ovsdb-schemas.man:
-
-ovsdb/ovsdb-server.1: \
-   ovsdb/ovsdb-server.1.in \
-   lib/common-syn.man \
-   lib/common.man \
-   lib/coverage-unixctl.man \
-   lib/daemon-syn.man \
-   lib/daemon.man \
-   lib/memory-unixctl.man \
-   lib/ovs.tmac \
-   lib/service-syn.man \
-   lib/service.man \
-   lib/ssl-bootstrap-syn.man \
-   lib/ssl-bootstrap.man \
-   lib/ssl-connect-syn.man \
-   lib/ssl-connect.man \
-   lib/ssl-peer-ca-cert-syn.man \
-   lib/ssl-peer-ca-cert.man \
-   lib/ssl-syn.man \
-   lib/ssl.man \
-   lib/unixctl-syn.man \
-   lib/unixctl.man \
-   lib/vlog-syn.man \
-   lib/vlog-unixctl.man \
-   lib/vlog.man
-ovsdb/ovsdb-server.1.in:
-lib/common-syn.man:
-lib/common.man:
-lib/coverage-unixctl.man:
-lib/daemon-syn.man:
-lib/daemon.man:
-lib/memory-unixctl.man:
-lib/ovs.tmac:
-lib/service-syn.man:
-lib/service.man:
-lib/ssl-bootstrap-syn.man:
-lib/ssl-bootstrap.man:
-lib/ssl-connect-syn.man:
-lib/ssl-connect.man:
-lib/ssl-peer-ca-cert-syn.man:
-lib/ssl-peer-ca-cert.man:
-lib/ssl-syn.man:
-lib/ssl.man:
-lib/unixctl-syn.man:
-lib/unixctl.man:
-lib/vlog-syn.man:
-lib/vlog-unixctl.man:
-lib/vlog.man:
-
-ovsdb/ovsdb-tool.1: \
-   ovsdb/ovsdb-tool.1.in \
-   lib/common-syn.man \
-   lib/common.man \
-   lib/ovs.tmac \
-   lib/vlog-syn.man \
-   lib/vlog.man \
-   ovsdb/ovsdb-schemas.man
-ovsdb/ovsdb-tool.1.in:
-lib/common-syn.man:
-lib/common.man:
-lib/ovs.tmac:
-lib/vlog-syn.man:
-lib/vlog.man:
-ovsdb/ovsdb-schemas.man:
-
-utilities/bugtool/ovs-bugtool.8: \
-   utilities/bugtool/ovs-bugtool.8.in \
-   lib/ovs.tmac
-utilities/bugtool/ovs-bugtool.8.in:
-lib/ovs.tmac:
-
-
-utilities/ovs-dpctl-top.8: \
-   utilities/ovs-dpctl-top.8.in \
-   lib/ovs.tmac
-utilities/ovs-dpctl-top.8.in:
-lib/ovs.tmac:
-
-utilities/ovs-dpctl.8: \
-   utilities/ovs-dpctl.8.in \
-   lib/common.man \
-   lib/dpctl.man \
-   lib/ovs.tmac \
-   lib/vlog.man
-utilities/ovs-dpctl.8.in:
-lib/common.man:
-lib/dpctl.man:
-lib/ovs.tmac:
-lib/vlog.man:
-
-utilities/ovs-ofctl.8: \
-   utilities/ovs-ofctl.8.in \
-   lib/colors.man \
-   lib/common.man \
-   lib/daemon.man \
-   lib/ofp-version.man \
-   lib/ovs.tmac \
-   lib/ssl.man \
-   lib/unixctl.man \
-   lib/vconn-active.man \
-   lib/vlog.man
-utilities/ovs-ofctl.8.in:
-lib/colors.man:
-lib/common.man:
-lib/daemon.man:
-lib/ofp-version.man:
-lib/ovs.tmac:
-lib/ssl.man:
-lib/unixctl.man:
-lib/vconn-active.man:
-lib/vlog.man:
-
-utilities/ovs-pcap.1: \
-   utilities/ovs-pcap.1.in \
-   lib/common-syn.man \
-   lib/common.man \
- 

Re: [ovs-dev] [PATCH v2 1/3] dpif-netdev/avx512: avoid compiling avx512 code if binutils check fails

[Stokes, Ian]

> 
> This commit avoids compiling and linking of avx512 code into the vswitch_la
> library if the binutils check fails. This avoids compiling code into OVS that 
> will not
> be executed due to binutils issue.
> 
> Signed-off-by: Harry van Haaren 
> 

Thanks for the series Harry, it looks ok tom myself, have tested locally on a 
few machines and with Travis for both master and Branch 2.14.

https://travis-ci.org/github/istokes/ovs/builds/715140114
https://travis-ci.org/github/istokes/ovs/builds/715139732

I've pushed this to master and as it would be an issue for 2.14 (and the 
patches are minor) I've pushed there too.

WRT backporting beyond that I'm open to discussion, I guess the same issue 
could occur right? But as there was no AVX512 code previous to 2.14 it wouldn't 
have been visible?

BR
Ian


> ---
> 
> v3:
> - Reword commit title & description
> ---
>  lib/automake.mk | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/lib/automake.mk b/lib/automake.mk index 920c958e3..218dc7313
> 100644
> --- a/lib/automake.mk
> +++ b/lib/automake.mk
> @@ -22,6 +22,7 @@ lib_libopenvswitch_la_LDFLAGS = \
>  $(AM_LDFLAGS)
> 
>  if HAVE_AVX512F
> +if HAVE_LD_AVX512_GOOD
>  # Build library of avx512 code with CPU ISA CFLAGS enabled. This allows the  
> #
> compiler to use the ISA features required for the ISA optimized code-paths.
>  # Use LDFLAGS to compile only static library of this code, as it should be 
> @@ -
> 39,6 +40,7 @@ lib_libopenvswitchavx512_la_SOURCES = \
> lib_libopenvswitchavx512_la_LDFLAGS = \
>   -static
>  endif
> +endif
> 
>  # Build core vswitch libraries as before  lib_libopenvswitch_la_SOURCES = \
> --
> 2.17.1

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

[ovs-dev] [PATCH] ovsdb-server: Replace in-memory DB contents at raft install_snapshot.

[Dumitru Ceara]

Every time a follower has to install a snapshot received from the
leader, it should also replace the data in memory. Right now this only
happens when snapshots are installed that also change the schema.

This can lead to inconsistent DB data on follower nodes and the snapshot
may fail to get applied.

CC: Han Zhou 
Fixes: bda1f6b60588 ("ovsdb-server: Don't disconnect clients after raft 
install_snapshot.")
Signed-off-by: Dumitru Ceara 
---
 ovsdb/ovsdb-server.c| 21 +
 tests/idltest.ovsschema |  9 +
 tests/ovsdb-cluster.at  | 28 +---
 tests/ovsdb-idl.at  |  1 +
 4 files changed, 48 insertions(+), 11 deletions(-)

diff --git a/ovsdb/ovsdb-server.c b/ovsdb/ovsdb-server.c
index ef4e996..fd7891a 100644
--- a/ovsdb/ovsdb-server.c
+++ b/ovsdb/ovsdb-server.c
@@ -543,13 +543,14 @@ parse_txn(struct server_config *config, struct db *db,
   const struct ovsdb_schema *schema, const struct json *txn_json,
   const struct uuid *txnid)
 {
-if (schema && (!db->db->schema || strcmp(schema->version,
- db->db->schema->version))) {
+if (schema) {
 /* We're replacing the schema (and the data).  Destroy the database
  * (first grabbing its storage), then replace it with the new schema.
  * The transaction must also include the replacement data.
  *
- * Only clustered database schema changes go through this path. */
+ * Only clustered database schema changes and snapshot installs
+ * go through this path.
+ */
 ovs_assert(txn_json);
 ovs_assert(ovsdb_storage_is_clustered(db->db->storage));
 
@@ -559,11 +560,15 @@ parse_txn(struct server_config *config, struct db *db,
 return error;
 }
 
-ovsdb_jsonrpc_server_reconnect(
-config->jsonrpc, false,
-(db->db->schema
- ? xasprintf("database %s schema changed", db->db->name)
- : xasprintf("database %s connected to storage", db->db->name)));
+if (!db->db->schema ||
+strcmp(schema->version, db->db->schema->version)) {
+ovsdb_jsonrpc_server_reconnect(
+config->jsonrpc, false,
+(db->db->schema
+? xasprintf("database %s schema changed", db->db->name)
+: xasprintf("database %s connected to storage",
+db->db->name)));
+}
 
 ovsdb_replace(db->db, ovsdb_create(ovsdb_schema_clone(schema), NULL));
 
diff --git a/tests/idltest.ovsschema b/tests/idltest.ovsschema
index e02b975..e04755e 100644
--- a/tests/idltest.ovsschema
+++ b/tests/idltest.ovsschema
@@ -54,6 +54,15 @@
   },
   "isRoot" : true
 },
+"indexed": {
+  "columns": {
+"i": {
+  "type": "integer"
+}
+  },
+  "indexes": [["i"]],
+  "isRoot" : true
+},
 "simple": {
   "columns": {
 "b": {
diff --git a/tests/ovsdb-cluster.at b/tests/ovsdb-cluster.at
index 9714545..06d27c9 100644
--- a/tests/ovsdb-cluster.at
+++ b/tests/ovsdb-cluster.at
@@ -332,15 +332,31 @@ for i in `seq $n`; do
 AT_CHECK([ovsdb_client_wait unix:s$i.ovsdb $schema_name connected])
 done
 
+AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
+  {"op": "insert",
+   "table": "indexed",
+   "row": {"i": 1}}]]'], [0], [ignore], [ignore])
+
 # Kill one follower (s2) and write some data to cluster, so that the follower 
is falling behind
 printf "\ns2: stopping\n"
 OVS_APP_EXIT_AND_WAIT_BY_TARGET([`pwd`/s2], [s2.pid])
 
+# Delete "i":1 and readd it to get a different UUID for it.
+AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
+  {"op": "delete",
+   "table": "indexed",
+   "where": [["i", "==", 1]]}]]'], [0], [ignore], [ignore])
+
 AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
   {"op": "insert",
-   "table": "simple",
+   "table": "indexed",
"row": {"i": 1}}]]'], [0], [ignore], [ignore])
 
+AT_CHECK([ovsdb-client transact unix:s1.ovsdb '[["idltest",
+  {"op": "insert",
+   "table": "indexed",
+   "row": {"i": 2}}]]'], [0], [ignore], [ignore])
+
 # Compact leader online to generate snapshot
 AT_CHECK([ovs-appctl -t "`pwd`"/s1 ovsdb-server/compact])
 
@@ -355,8 +371,14 @@ AT_CHECK([ovsdb_client_wait unix:s2.ovsdb $schema_name 
connected])
 # succeed.
 AT_CHECK([ovsdb-client transact unix:s2.ovsdb '[["idltest",
   {"op": "insert",
-   "table": "simple",
-   "row": {"i": 1}}]]'], [0], [ignore], [ignore])
+   "table": "indexed",
+   "row": {"i": 3}}]]'], [0], [ignore], [ignore])
+
+# The snapshot should overwrite the in-memory contents of the DB on S2
+# without generating any constraint violations.
+AT_CHECK([grep 'Transaction causes multiple rows in "indexed" table to have 
identical values (1) for index on column "i"' -c s2.log], [1], [dnl
+0
+])
 
 for i in `seq $n`; do
 

[ovs-dev] Aw

[Gerhard Schafer]

Haben Sie meine Nachricht bezüglich Ihrer Vergütungskarte erhalten?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [PATCH] Remove manpages.mk from git

[Timothy Redaelli]

manpages.mk is generated at build-time using sodepends.py and so there is no
need to keep it in git.

Signed-off-by: Timothy Redaelli 
---
 .gitignore  |   1 +
 Makefile.am |   2 +-
 manpages.mk | 266 
 3 files changed, 2 insertions(+), 267 deletions(-)
 delete mode 100644 manpages.mk

diff --git a/.gitignore b/.gitignore
index 2ac9cdac7..f1cdcf124 100644
--- a/.gitignore
+++ b/.gitignore
@@ -55,6 +55,7 @@
 /docs-check
 /install-sh
 /libtool
+/manpages.mk
 /manpage-check
 /missing
 /missing-distfiles
diff --git a/Makefile.am b/Makefile.am
index 27ef9e4b4..8ead17029 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -412,7 +412,7 @@ flake8-check: $(FLAKE8_PYFILES)
 endif
 CLEANFILES += flake8-check
 
-include $(srcdir)/manpages.mk
+-include $(srcdir)/manpages.mk
 $(srcdir)/manpages.mk: $(MAN_ROOTS) build-aux/sodepends.py 
python/build/soutil.py
@PYTHONPATH=$$PYTHONPATH$(psep)$(srcdir)/python $(PYTHON3) 
$(srcdir)/build-aux/sodepends.py -I. -I$(srcdir) $(MAN_ROOTS) >$(@F).tmp
@if cmp -s $(@F).tmp $@; then \
diff --git a/manpages.mk b/manpages.mk
deleted file mode 100644
index dc201484c..0
--- a/manpages.mk
+++ /dev/null
@@ -1,266 +0,0 @@
-# Generated automatically -- do not modify!-*- buffer-read-only: t -*-
-
-ovsdb/ovsdb-client.1: \
-   ovsdb/ovsdb-client.1.in \
-   lib/common-syn.man \
-   lib/common.man \
-   lib/daemon-syn.man \
-   lib/daemon.man \
-   lib/ovs.tmac \
-   lib/ssl-bootstrap-syn.man \
-   lib/ssl-bootstrap.man \
-   lib/ssl-connect-syn.man \
-   lib/ssl-connect.man \
-   lib/ssl-syn.man \
-   lib/ssl.man \
-   lib/table.man \
-   lib/vlog-syn.man \
-   lib/vlog.man \
-   ovsdb/ovsdb-schemas.man
-ovsdb/ovsdb-client.1.in:
-lib/common-syn.man:
-lib/common.man:
-lib/daemon-syn.man:
-lib/daemon.man:
-lib/ovs.tmac:
-lib/ssl-bootstrap-syn.man:
-lib/ssl-bootstrap.man:
-lib/ssl-connect-syn.man:
-lib/ssl-connect.man:
-lib/ssl-syn.man:
-lib/ssl.man:
-lib/table.man:
-lib/vlog-syn.man:
-lib/vlog.man:
-ovsdb/ovsdb-schemas.man:
-
-ovsdb/ovsdb-server.1: \
-   ovsdb/ovsdb-server.1.in \
-   lib/common-syn.man \
-   lib/common.man \
-   lib/coverage-unixctl.man \
-   lib/daemon-syn.man \
-   lib/daemon.man \
-   lib/memory-unixctl.man \
-   lib/ovs.tmac \
-   lib/service-syn.man \
-   lib/service.man \
-   lib/ssl-bootstrap-syn.man \
-   lib/ssl-bootstrap.man \
-   lib/ssl-connect-syn.man \
-   lib/ssl-connect.man \
-   lib/ssl-peer-ca-cert-syn.man \
-   lib/ssl-peer-ca-cert.man \
-   lib/ssl-syn.man \
-   lib/ssl.man \
-   lib/unixctl-syn.man \
-   lib/unixctl.man \
-   lib/vlog-syn.man \
-   lib/vlog-unixctl.man \
-   lib/vlog.man
-ovsdb/ovsdb-server.1.in:
-lib/common-syn.man:
-lib/common.man:
-lib/coverage-unixctl.man:
-lib/daemon-syn.man:
-lib/daemon.man:
-lib/memory-unixctl.man:
-lib/ovs.tmac:
-lib/service-syn.man:
-lib/service.man:
-lib/ssl-bootstrap-syn.man:
-lib/ssl-bootstrap.man:
-lib/ssl-connect-syn.man:
-lib/ssl-connect.man:
-lib/ssl-peer-ca-cert-syn.man:
-lib/ssl-peer-ca-cert.man:
-lib/ssl-syn.man:
-lib/ssl.man:
-lib/unixctl-syn.man:
-lib/unixctl.man:
-lib/vlog-syn.man:
-lib/vlog-unixctl.man:
-lib/vlog.man:
-
-ovsdb/ovsdb-tool.1: \
-   ovsdb/ovsdb-tool.1.in \
-   lib/common-syn.man \
-   lib/common.man \
-   lib/ovs.tmac \
-   lib/vlog-syn.man \
-   lib/vlog.man \
-   ovsdb/ovsdb-schemas.man
-ovsdb/ovsdb-tool.1.in:
-lib/common-syn.man:
-lib/common.man:
-lib/ovs.tmac:
-lib/vlog-syn.man:
-lib/vlog.man:
-ovsdb/ovsdb-schemas.man:
-
-utilities/bugtool/ovs-bugtool.8: \
-   utilities/bugtool/ovs-bugtool.8.in \
-   lib/ovs.tmac
-utilities/bugtool/ovs-bugtool.8.in:
-lib/ovs.tmac:
-
-
-utilities/ovs-dpctl-top.8: \
-   utilities/ovs-dpctl-top.8.in \
-   lib/ovs.tmac
-utilities/ovs-dpctl-top.8.in:
-lib/ovs.tmac:
-
-utilities/ovs-dpctl.8: \
-   utilities/ovs-dpctl.8.in \
-   lib/common.man \
-   lib/dpctl.man \
-   lib/ovs.tmac \
-   lib/vlog.man
-utilities/ovs-dpctl.8.in:
-lib/common.man:
-lib/dpctl.man:
-lib/ovs.tmac:
-lib/vlog.man:
-
-utilities/ovs-ofctl.8: \
-   utilities/ovs-ofctl.8.in \
-   lib/colors.man \
-   lib/common.man \
-   lib/daemon.man \
-   lib/ofp-version.man \
-   lib/ovs.tmac \
-   lib/ssl.man \
-   lib/unixctl.man \
-   lib/vconn-active.man \
-   lib/vlog.man
-utilities/ovs-ofctl.8.in:
-lib/colors.man:
-lib/common.man:
-lib/daemon.man:
-lib/ofp-version.man:
-lib/ovs.tmac:
-lib/ssl.man:
-lib/unixctl.man:
-lib/vconn-active.man:
-lib/vlog.man:
-
-utilities/ovs-pcap.1: \
-   utilities/ovs-pcap.1.in \
-   lib/common-syn.man \
-   lib/common.man \
-   lib/ovs.tmac
-utilities/ovs-pcap.1.in:
-lib/common-syn.man:
-lib/common.man:
-lib/ovs.tmac:
-
-lib/ovs.tmac:
-
-utilities/ovs-testcontroller.8: \
-   utilities/ovs-testcontroller.8.in \
-   

Re: [ovs-dev] [PATCH] net: openvswitch: silence suspicious RCU usage warning

[Paolo Abeni]

On Wed, 2020-08-05 at 15:19 +0800, xiangxia.m@gmail.com wrote:
> From: Tonghao Zhang 
> 
> ovs_flow_tbl_destroy always is called from RCU callback
> or error path. It is no need to check if rcu_read_lock
> or lockdep_ovsl_is_held was held.
> 
> ovs_dp_cmd_fill_info always is called with ovs_mutex,
> So use the rcu_dereference_ovsl instead of rcu_dereference
> in ovs_flow_tbl_masks_cache_size.
> 
> Fixes: 9bf24f594c6a ("net: openvswitch: make masks cache size configurable")
> Cc: Eelco Chaudron 
> Reported-by: syzbot+c0eb9e7cdde04e4eb...@syzkaller.appspotmail.com
> Reported-by: syzbot+f612c02823acb02ff...@syzkaller.appspotmail.com
> Signed-off-by: Tonghao Zhang 

Acked-by: Paolo Abeni 

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

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

[0-day Robot]

Bleep bloop.  Greetings Han Zhou, I am a robot and I have tried out your patch.
Thanks for your contribution.

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


checkpatch:
WARNING: Line is 92 characters long (recommended limit is 79)
#370 FILE: ovn-nb.xml:1862:
  

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


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

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

Re: [ovs-dev] [PATCH ovn v2 2/3] actions: Implement new actions lookup_arp_ip and lookup_nd_ip.

[0-day Robot]

Bleep bloop.  Greetings Han Zhou, I am a robot and I have tried out your patch.
Thanks for your contribution.

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


checkpatch:
WARNING: Line is 80 characters long (recommended limit is 79)
#211 FILE: ovn-sb.xml:1452:
  R = lookup_arp_ip(P, A);

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

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


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

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

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

[0-day Robot]

Bleep bloop.  Greetings Han Zhou, I am a robot and I have tried out your patch.
Thanks for your contribution.

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


checkpatch:
WARNING: Line is 84 characters long (recommended limit is 79)
#62 FILE: ovn-nb.xml:1849:
  

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


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

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

[ovs-dev] [PATCH] net: openvswitch: silence suspicious RCU usage warning

[xiangxia . m . yue]

From: Tonghao Zhang 

ovs_flow_tbl_destroy always is called from RCU callback
or error path. It is no need to check if rcu_read_lock
or lockdep_ovsl_is_held was held.

ovs_dp_cmd_fill_info always is called with ovs_mutex,
So use the rcu_dereference_ovsl instead of rcu_dereference
in ovs_flow_tbl_masks_cache_size.

Fixes: 9bf24f594c6a ("net: openvswitch: make masks cache size configurable")
Cc: Eelco Chaudron 
Reported-by: syzbot+c0eb9e7cdde04e4eb...@syzkaller.appspotmail.com
Reported-by: syzbot+f612c02823acb02ff...@syzkaller.appspotmail.com
Signed-off-by: Tonghao Zhang 
---
 net/openvswitch/flow_table.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 6527d84c3ea6..8c12675cbb67 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -518,8 +518,8 @@ void ovs_flow_tbl_destroy(struct flow_table *table)
 {
struct table_instance *ti = rcu_dereference_raw(table->ti);
struct table_instance *ufid_ti = rcu_dereference_raw(table->ufid_ti);
-   struct mask_cache *mc = rcu_dereference(table->mask_cache);
-   struct mask_array *ma = rcu_dereference_ovsl(table->mask_array);
+   struct mask_cache *mc = rcu_dereference_raw(table->mask_cache);
+   struct mask_array *ma = rcu_dereference_raw(table->mask_array);
 
call_rcu(>rcu, mask_cache_rcu_cb);
call_rcu(>rcu, mask_array_rcu_cb);
@@ -937,7 +937,7 @@ int ovs_flow_tbl_num_masks(const struct flow_table *table)
 
 u32 ovs_flow_tbl_masks_cache_size(const struct flow_table *table)
 {
-   struct mask_cache *mc = rcu_dereference(table->mask_cache);
+   struct mask_cache *mc = rcu_dereference_ovsl(table->mask_cache);
 
return READ_ONCE(mc->cache_size);
 }
-- 
2.26.1

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

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

[Han Zhou]

On Wed, Jul 29, 2020 at 10:42 AM Numan Siddique  wrote:

>
>
> On Thu, Jul 23, 2020 at 10:57 AM Han Zhou  wrote:
>
>> Support a new logical router option "always_learn_from_arp_request" that
>> controls
>> behavior when handling ARP requests or IPv4 ND-NS packets.
>>
>> "true" - Always learn the MAC/IP binding and add a new MAC_Binding entry
>> (default behavior)
>>
>> "false" - If there is a MAC_binding for that IP and the MAC is different,
>> or,
>> if TPA of ARP request belongs to any router port on this router, then
>> update/add that MAC/IP binding. Otherwise, don't update/add entries.
>>
>> Reported-by: Girish Moodalbail 
>> Reported-at:
>> https://mail.openvswitch.org/pipermail/ovs-discuss/2020-May/049995.html
>> Signed-off-by: Han Zhou 
>>
>
> Hi Han,
>
> I just gave a quick look. I'll review properly tomorrow.
>
> I just have a few small comments now. I think it's good to add a few tests
> in ovn-northd.at
> to make sure that ovn-northd programs the flows as expected.
>
>
Hi Numan

This patch already updated the existing test case in ovn.at to cover the
scenario when always_learn_from_arp_request is set to false (and also flip
back and forth to verify the mac binding is updated for existed entries).
It verifies the behavior e2e, so I think maybe it is not necessary to add a
separate test case just to check the lflows. What do you think?
I sent v2 which added a test case for the first patch (it was not covered
in the v1). Please take a look:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=194194

Thanks,
Han


> Thanks
> Numan
>
> ---
>>  northd/ovn-northd.8.xml | 109
>> 
>>  northd/ovn-northd.c |  96 +++---
>>  ovn-nb.xml  |  27 
>>  tests/ovn.at|  18 
>>  4 files changed, 217 insertions(+), 33 deletions(-)
>>
>> diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
>> index 9f2c70f..30936ab 100644
>> --- a/northd/ovn-northd.8.xml
>> +++ b/northd/ovn-northd.8.xml
>> @@ -1537,58 +1537,126 @@ output;
>>  
>>For each router port P that owns IP address
>> A,
>>which belongs to subnet S with prefix length
>> L,
>> -  a priority-100 flow is added which matches
>> -  inport == P 
>> -  arp.spa == S/L  arp.op ==
>> 1
>> -  (ARP request) with the
>> -  following actions:
>> +  if the option always_learn_from_arp_request is
>> +  true for this router, a priority-100 flow is
>> added which
>> +  matches inport == P  arp.spa ==
>> +  S/L  arp.op == 1 (ARP
>> request)
>> +  with the following actions:
>> +
>> +
>> +
>> +reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
>> +next;
>> +
>> +
>> +
>> +  If the option always_learn_from_arp_request is
>> +  false, the following two flows are added.
>> +
>> +
>> +
>> +  A priority-110 flow is added which matches inport ==
>> +  P  arp.spa == S/L
>> +   arp.tpa == A  arp.op ==
>> 1
>> +  (ARP request) with the following actions:
>>  
>>
>>  
>>  reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
>> +reg9[3] = 1;
>> +next;
>> +
>> +
>> +
>> +  A priority-100 flow is added which matches inport ==
>> +  P  arp.spa == S/L
>> +   arp.op == 1 (ARP request) with the following
>> +  actions:
>> +
>> +
>> +
>> +reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
>> +reg9[3] = lookup_arp_ip(inport, arp.spa);
>>  next;
>>  
>>
>>  
>>If the logical router port P is a distributed
>> gateway
>>router port, additional match
>> -  is_chassis_resident(cr-P) is added so
>> that
>> -  the resident gateway chassis handles the neighbor lookup.
>> +  is_chassis_resident(cr-P) is added for
>> all
>> +  these flows.
>>  
>>
>>
>>
>>  
>>A priority-100 flow which matches on ARP reply packets and
>> applies
>> -  the actions:
>> +  the actions if the option
>> always_learn_from_arp_request
>> +  is true:
>>  
>>
>>  
>>  reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
>>  next;
>>  
>> +
>> +
>> +  If the option always_learn_from_arp_request
>> +  is false, the above actions will be:
>> +
>> +
>> +
>> +reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
>> +reg9[3] = 1;
>> +next;
>> +
>> +
>>
>>
>>
>>  
>>A priority-100 flow which matches on IPv6 Neighbor Discovery
>> -  advertisement packet and applies the actions:
>> +  advertisement packet and applies the actions if the option
>> +  always_learn_from_arp_request is
>> true:
>>  
>>
>>  
>>  reg9[2] = lookup_nd(inport, nd.target, 

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

[Han Zhou]

Support a new logical router option "always_learn_from_arp_request" that 
controls
behavior when handling ARP requests or IPv4 ND-NS packets.

"true" - Always learn the MAC/IP binding and add a new MAC_Binding entry
(default behavior)

"false" - If there is a MAC_binding for that IP and the MAC is different, or,
if TPA of ARP request belongs to any router port on this router, then
update/add that MAC/IP binding. Otherwise, don't update/add entries.

Reported-by: Girish Moodalbail 
Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-May/049995.html
Signed-off-by: Han Zhou 
---
 northd/ovn-northd.8.xml | 109 
 northd/ovn-northd.c |  96 +++---
 ovn-nb.xml  |  27 
 tests/ovn.at|  18 
 4 files changed, 217 insertions(+), 33 deletions(-)

diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index 508123e..b08293f 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -1537,58 +1537,126 @@ output;
 
   For each router port P that owns IP address A,
   which belongs to subnet S with prefix length L,
-  a priority-100 flow is added which matches
-  inport == P 
-  arp.spa == S/L  arp.op == 1
-  (ARP request) with the
-  following actions:
+  if the option always_learn_from_arp_request is
+  true for this router, a priority-100 flow is added which
+  matches inport == P  arp.spa ==
+  S/L  arp.op == 1 (ARP request)
+  with the following actions:
+
+
+
+reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
+next;
+
+
+
+  If the option always_learn_from_arp_request is
+  false, the following two flows are added.
+
+
+
+  A priority-110 flow is added which matches inport ==
+  P  arp.spa == S/L
+   arp.tpa == A  arp.op == 1
+  (ARP request) with the following actions:
 
 
 
 reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
+reg9[3] = 1;
+next;
+
+
+
+  A priority-100 flow is added which matches inport ==
+  P  arp.spa == S/L
+   arp.op == 1 (ARP request) with the following
+  actions:
+
+
+
+reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
+reg9[3] = lookup_arp_ip(inport, arp.spa);
 next;
 
 
 
   If the logical router port P is a distributed gateway
   router port, additional match
-  is_chassis_resident(cr-P) is added so that
-  the resident gateway chassis handles the neighbor lookup.
+  is_chassis_resident(cr-P) is added for all
+  these flows.
 
   
 
   
 
   A priority-100 flow which matches on ARP reply packets and applies
-  the actions:
+  the actions if the option always_learn_from_arp_request
+  is true:
 
 
 
 reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
 next;
 
+
+
+  If the option always_learn_from_arp_request
+  is false, the above actions will be:
+
+
+
+reg9[2] = lookup_arp(inport, arp.spa, arp.sha);
+reg9[3] = 1;
+next;
+
+
   
 
   
 
   A priority-100 flow which matches on IPv6 Neighbor Discovery
-  advertisement packet and applies the actions:
+  advertisement packet and applies the actions if the option
+  always_learn_from_arp_request is true:
 
 
 
 reg9[2] = lookup_nd(inport, nd.target, nd.tll);
 next;
 
+
+
+  If the option always_learn_from_arp_request
+  is false, the above actions will be:
+
+
+
+reg9[2] = lookup_nd(inport, nd.target, nd.tll);
+reg9[3] = 1;
+next;
+
   
 
   
 
   A priority-100 flow which matches on IPv6 Neighbor Discovery
-  solicitation packet and applies the actions:
+  solicitation packet and applies the actions if the option
+  always_learn_from_arp_request is true:
+
+
+
+reg9[2] = lookup_nd(inport, ip6.src, nd.sll);
+next;
+
+
+
+  If the option always_learn_from_arp_request
+  is false, the above actions will be:
 
 
 
 reg9[2] = lookup_nd(inport, ip6.src, nd.sll);
+reg9[3] = lookup_nd_ip(inport, ip6.src);
 next;
 
   
@@ -1604,21 +1672,28 @@ next;
 
 
   This table adds flows to learn the mac bindings from the ARP and
-  IPv6 Neighbor Solicitation/Advertisement packets if ARP/ND lookup
-  failed in the previous table.
+  IPv6 Neighbor Solicitation/Advertisement packets if it is needed
+  according to the lookup results from the previous stage.
 
 
 
   reg9[2] will be 1 if the lookup_arp/lookup_nd
-  in the previous table was successful, or if there 

[ovs-dev] [PATCH ovn v2 0/3] Avoid ARP flow explosion.

[Han Zhou]

This patch series addresses the problem discussed in [0]. Below options need to
be configured for the gateway routers:

options:always_learn_from_arp_request = false
options:dynamic_neigh_routers = true

[0] - https://mail.openvswitch.org/pipermail/ovs-discuss/2020-May/049994.html

v1->v2:
The v1 series had 7 patches, 4 of them were merged.
In v2, a new test case is added for the patch 1/3.

Han Zhou (3):
  ovn-northd: Support optionally avoid static neighbor flows in routers.
  actions: Implement new actions lookup_arp_ip and lookup_nd_ip.
  ovn-northd.c: Support optionally disabling neighbor learning from ARP
request/NS.

 controller/lflow.c  |   4 +-
 include/ovn/actions.h   |  10 +++
 lib/actions.c   | 112 ++
 northd/ovn-northd.8.xml | 114 +-
 northd/ovn-northd.c | 102 ++-
 ovn-nb.xml  |  40 +++
 ovn-sb.xml  |  55 +++
 tests/ovn.at| 180 
 utilities/ovn-trace.c   |  54 ++-
 9 files changed, 633 insertions(+), 38 deletions(-)

-- 
2.1.0

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

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

[Han Zhou]

Support option:dynamic_neigh_routers for logical routers, so that in
particular use cases static neighbor flows are not prepopulated IP
addresses belonging to neighbor router ports, to avoid flow exploding
problem reported for ovn-kubernetes large scale setup.

Reported-by: Girish Moodalbail 
Reported-at: 
https://mail.openvswitch.org/pipermail/ovs-discuss/2020-May/049995.html
Signed-off-by: Han Zhou 
---
 northd/ovn-northd.8.xml |   5 ++-
 northd/ovn-northd.c |   6 +++
 ovn-nb.xml  |  13 ++
 tests/ovn.at| 112 
 4 files changed, 135 insertions(+), 1 deletion(-)

diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index ed1cd58..508123e 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -2727,7 +2727,10 @@ outport = P;
   Logical_Switch_Port table.  For router ports
   connected to other logical routers, MAC bindings can be known
   statically from the mac and networks
-  column in the Logical_Router_Port table.
+  column in the Logical_Router_Port table.  (Note: the
+  flow is NOT installed for the IP addresses that belong to a neighbor
+  logical router port if the current router has the
+  options:dynamic_neigh_routers set to true)
 
 
 
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 03c62ba..5dd49f9 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -10401,6 +10401,12 @@ build_lrouter_flows(struct hmap *datapaths, struct 
hmap *ports,
 continue;
 }
 
+if (peer->od->nbr &&
+smap_get_bool(>od->nbr->options,
+  "dynamic_neigh_routers", false)) {
+continue;
+}
+
 for (size_t i = 0; i < op->od->n_router_ports; i++) {
 const char *router_port_name = smap_get(
 >od->router_ports[i]->nbsp->options,
diff --git a/ovn-nb.xml b/ovn-nb.xml
index 5e434d2..4c59338 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -1846,6 +1846,19 @@
   connected to the logical router. Default: False.
 
   
+  
+
+  If set to true, the router will resolve neighbor
+  routers' MAC addresses only by dynamic ARP/ND, instead of
+  prepopulating static mappings for all neighbor routers in the ARP/ND
+  Resolution stage.  This reduces number of flows, but requires ARP/ND
+  messages to resolve the IP-MAC bindings when needed.  It is
+  false by default.  It is recommended to set to
+  true when a large number of logical routers are
+  connected to the same logical switch but most of them never need to
+  send traffic between each other.
+
+  
 
 
 
diff --git a/tests/ovn.at b/tests/ovn.at
index b0179a8..654c343 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -21122,3 +21122,115 @@ AT_CHECK([
 
 OVN_CLEANUP([hv1], [hv2])
 AT_CLEANUP
+
+# Test option:dynamic_neigh_routers. No static neighbor flows when enabled, and
+# traffic should still work, with the help of dynamic mac_bindings.
+AT_SETUP([ovn -- Dynamic neighbor between LRs])
+ovn_start
+
+# Logical network:
+# 2 LRs - R1 and R2 that are connected to each other via LS "join"
+# in 10.0.0.0/24 network.
+# R1 is connected to S1 (10.0.1.0/24), R2 is connected to S2 (10.0.2.0/24)
+
+ovn-nbctl lr-add r1 -- set logical_router r1 option:dynamic_neigh_routers=true
+ovn-nbctl lr-add r2 -- set logical_router r2 option:dynamic_neigh_routers=true
+
+ovn-nbctl ls-add s1
+ovn-nbctl ls-add s2
+ovn-nbctl ls-add join
+
+# Connnect r1 to s1.
+ovn-nbctl lrp-add r1 lrp-r1-s1 00:00:00:00:01:01 10.0.1.1/24
+ovn-nbctl lsp-add s1 lsp-s1-r1 -- set Logical_Switch_Port lsp-s1-r1 
type=router \
+options:router-port=lrp-r1-s1 addresses=router
+
+# Connnect r2 to s2.
+ovn-nbctl lrp-add r2 lrp-r2-s2 00:00:00:00:02:01 10.0.2.1/24
+ovn-nbctl lsp-add s2 lsp-s2-r2 -- set Logical_Switch_Port lsp-s2-r2 
type=router \
+options:router-port=lrp-r2-s2 addresses=router
+
+# Connect r1 to join
+ovn-nbctl lrp-add r1 lrp-r1-join 00:00:00:00:03:01 10.0.0.1/24
+ovn-nbctl lsp-add join lsp-join-r1 -- set Logical_Switch_Port lsp-join-r1 \
+type=router options:router-port=lrp-r1-join addresses=router
+
+# Connect r2 to join
+ovn-nbctl lrp-add r2 lrp-r2-join 00:00:00:00:03:02 10.0.0.2/24
+ovn-nbctl lsp-add join lsp-join-r2 -- set Logical_Switch_Port lsp-join-r2 \
+type=router options:router-port=lrp-r2-join addresses=router
+
+#install static routes
+ovn-nbctl lr-route-add r1 10.0.2.0/24 10.0.0.2
+ovn-nbctl lr-route-add r2 10.0.1.0/24 10.0.0.1
+
+# Create logical port p1 in s1
+ovn-nbctl lsp-add s1 p1 \
+-- lsp-set-addresses p1 "f0:00:00:00:01:02 10.0.1.2"
+
+# Create logical port p2 in s2
+ovn-nbctl lsp-add s2 p2 \
+-- lsp-set-addresses p2 "f0:00:00:00:02:02 10.0.2.2"
+
+# Create two hypervisor and create OVS ports 

[ovs-dev] [PATCH ovn v2 2/3] actions: Implement new actions lookup_arp_ip and lookup_nd_ip.

[Han Zhou]

lookup_arp_ip and lookup_nd_ip are added to lookup if an entry exists
in MAC bindings for a given IP address, for IPv4 and IPv6 respectively.

Signed-off-by: Han Zhou 
---
 controller/lflow.c|   4 +-
 include/ovn/actions.h |  10 +
 lib/actions.c | 112 ++
 ovn-sb.xml|  55 +
 tests/ovn.at  |  50 ++
 utilities/ovn-trace.c |  54 ++--
 6 files changed, 281 insertions(+), 4 deletions(-)

diff --git a/controller/lflow.c b/controller/lflow.c
index b2f5857..1515612 100644
--- a/controller/lflow.c
+++ b/controller/lflow.c
@@ -782,13 +782,15 @@ consider_neighbor_flow(struct ovsdb_idl_index 
*sbrec_port_binding_by_name,
 
 uint64_t stub[1024 / 8];
 struct ofpbuf ofpacts = OFPBUF_STUB_INITIALIZER(stub);
+uint8_t value = 1;
 put_load(mac.ea, sizeof mac.ea, MFF_ETH_DST, 0, 48, );
+put_load(, sizeof value, MFF_LOG_FLAGS, MLF_LOOKUP_MAC_BIT, 1,
+ );
 ofctrl_add_flow(flow_table, OFTABLE_MAC_BINDING, 100,
 b->header_.uuid.parts[0], _arp_match,
 , >header_.uuid);
 
 ofpbuf_clear();
-uint8_t value = 1;
 put_load(, sizeof value, MFF_LOG_FLAGS, MLF_LOOKUP_MAC_BIT, 1,
  );
 match_set_dl_src(_arp_match, mac);
diff --git a/include/ovn/actions.h b/include/ovn/actions.h
index 12b7ab0..636cb4b 100644
--- a/include/ovn/actions.h
+++ b/include/ovn/actions.h
@@ -75,9 +75,11 @@ struct ovn_extend_table;
 OVNACT(GET_ARP,   ovnact_get_mac_bind)\
 OVNACT(PUT_ARP,   ovnact_put_mac_bind)\
 OVNACT(LOOKUP_ARP,ovnact_lookup_mac_bind) \
+OVNACT(LOOKUP_ARP_IP, ovnact_lookup_mac_bind_ip) \
 OVNACT(GET_ND,ovnact_get_mac_bind)\
 OVNACT(PUT_ND,ovnact_put_mac_bind)\
 OVNACT(LOOKUP_ND, ovnact_lookup_mac_bind) \
+OVNACT(LOOKUP_ND_IP,  ovnact_lookup_mac_bind_ip) \
 OVNACT(PUT_DHCPV4_OPTS,   ovnact_put_opts)\
 OVNACT(PUT_DHCPV6_OPTS,   ovnact_put_opts)\
 OVNACT(SET_QUEUE, ovnact_set_queue)   \
@@ -301,6 +303,14 @@ struct ovnact_lookup_mac_bind {
 struct expr_field mac;  /* 48-bit Ethernet address. */
 };
 
+/* OVNACT_LOOKUP_ARP_IP, OVNACT_LOOKUP_ND_IP. */
+struct ovnact_lookup_mac_bind_ip {
+struct ovnact ovnact;
+struct expr_field dst;  /* 1-bit destination field. */
+struct expr_field port; /* Logical port name. */
+struct expr_field ip;   /* 32-bit or 128-bit IP address. */
+};
+
 struct ovnact_gen_option {
 const struct gen_opts_map *option;
 struct expr_constant_set value;
diff --git a/lib/actions.c b/lib/actions.c
index 05fa44b..d7ed7a1 100644
--- a/lib/actions.c
+++ b/lib/actions.c
@@ -1902,6 +1902,110 @@ ovnact_lookup_mac_bind_free(
 
 }
 
+
+static void format_lookup_mac_bind_ip(
+const struct ovnact_lookup_mac_bind_ip *lookup_mac,
+struct ds *s, const char *name)
+{
+expr_field_format(_mac->dst, s);
+ds_put_format(s, " = %s(", name);
+expr_field_format(_mac->port, s);
+ds_put_cstr(s, ", ");
+expr_field_format(_mac->ip, s);
+ds_put_cstr(s, ");");
+}
+
+static void
+format_LOOKUP_ARP_IP(const struct ovnact_lookup_mac_bind_ip *lookup_mac,
+ struct ds *s)
+{
+format_lookup_mac_bind_ip(lookup_mac, s, "lookup_arp_ip");
+}
+
+static void
+format_LOOKUP_ND_IP(const struct ovnact_lookup_mac_bind_ip *lookup_mac,
+struct ds *s)
+{
+format_lookup_mac_bind_ip(lookup_mac, s, "lookup_nd_ip");
+}
+
+static void
+encode_lookup_mac_bind_ip(const struct ovnact_lookup_mac_bind_ip *lookup_mac,
+  enum mf_field_id ip_field,
+  const struct ovnact_encode_params *ep,
+  struct ofpbuf *ofpacts)
+{
+const struct arg args[] = {
+{ expr_resolve_field(_mac->port), MFF_LOG_OUTPORT },
+{ expr_resolve_field(_mac->ip), ip_field },
+};
+
+encode_setup_args(args, ARRAY_SIZE(args), ofpacts);
+init_stack(ofpact_put_STACK_PUSH(ofpacts), MFF_ETH_DST);
+
+struct mf_subfield dst = expr_resolve_field(_mac->dst);
+ovs_assert(dst.field);
+
+put_load(0, MFF_LOG_FLAGS, MLF_LOOKUP_MAC_BIT, 1, ofpacts);
+emit_resubmit(ofpacts, ep->mac_bind_ptable);
+
+struct ofpact_reg_move *orm = ofpact_put_REG_MOVE(ofpacts);
+orm->dst = dst;
+orm->src.field = mf_from_id(MFF_LOG_FLAGS);
+orm->src.ofs = MLF_LOOKUP_MAC_BIT;
+orm->src.n_bits = 1;
+
+init_stack(ofpact_put_STACK_POP(ofpacts), MFF_ETH_DST);
+encode_restore_args(args, ARRAY_SIZE(args), ofpacts);
+}
+
+static void
+encode_LOOKUP_ARP_IP(const struct ovnact_lookup_mac_bind_ip *lookup_mac,
+ const struct ovnact_encode_params *ep,
+ struct ofpbuf *ofpacts)
+{
+encode_lookup_mac_bind_ip(lookup_mac, MFF_REG0, ep, ofpacts);
+}
+
+static void

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

[王培辉]

Thanks for your response, ben, 
I found these error logs will occur with hw-offload=true, This error will 
disappear when I disable hardware offload.
It seems there is a bug processing igmp packet when hardware offload enabled.
I'm not familiar with this code,  Could you provide any clue how to debug this 
issue? 

Thanks.

-邮件原件-
发件人: Ben Pfaff [mailto:b...@ovn.org] 
发送时间: 2020年8月5日 0:06
收件人: Frank Wang(王培辉) 
抄送: ovs-disc...@openvswitch.org; ovs-dev@openvswitch.org
主题: Re: [ovs-dev] there are many error logs when processing igmp packet

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_stat
> e(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