[ovs-dev] [PATCH v2] vswitch.ovsschema: Add datapath_types and port_types.

Ben Pfaff blp at nicira.com
Thu Mar 26 05:29:58 UTC 2015


On Wed, Mar 25, 2015 at 12:29:56PM +0000, O Mahony, Billy wrote:
> I have verified the modified code works as expected when run with/without --dpdk on the vswitchd command line.
> 
> I'm wondering why there is a call to 'discover_types' in two places?

I made a mistake, sorry.  Thanks for pointing it out.  I sent out a fix:
        http://openvswitch.org/pipermail/dev/2015-March/052868.html

> I think it might be to do with something that I could not figure out
> when I was trying to ensure discover_types was not called more often
> that necessary.
> 
> I had initially tried to align the call to 'discover_types' with the
> 'initial_config_done' flag in 'bridge_run'. However on the first
> invocation (the first 3 in fact) 'cfg' was NULL (i.e. there was no
> record in Open_vSwitch table). 

It will be null (all the database will be empty) until the IDL manages
to retrieve the database contents from the server.  This takes a few
trips through the main loop; I guess you tended to see 3 trips, but it
can certainly vary.

> Then on the 4th invocation the idl sequence number is bumped and
> 'bridge_reconfigure' is handed an empty ' ovsrec_open_vswitch' which
> is then commited to the db before vswitchd daemonizes.

It shouldn't be empty at this point unless the database hasn't been
initialized.  There was a bug in the ovs-sandbox script that made this
likely for casual developer testing with "make sandbox"; I sent out a
fix for that:
        http://openvswitch.org/pipermail/dev/2015-March/052867.html

> However, and this is what I could not get, was that handing the empty
> ' ovsrec_open_vswitch' ('null_cfg') to discover_types when doing the
> initial config did not update the Open_vSwitch table as desired - I
> was expecting discover_types to update the idl record and the the
> commit on 'daemonize_txn' to do the needful.  ( I had removed the
> separate txn create/commit from discover_types at this point).

If null_cfg gets handed to bridge_reconfigure(), that means there's no
real record to modify (none has been added to the database; the database
is empty).



More information about the dev mailing list