Hi, I have a query with respect to the design of ovs-vswitchd .( please forgive me for my long email )
I was going through the code and there were some design concepts which I came across - 1) *IDL *- there is code generated pertaining to the DB schema that is defined. For example the code in *vswithd-idl.[ch]* files. 2) the ovs-vswitchd does a lot of things ( with respect to open flow etc ) - I am currently looking at the "*OVSDB- monitor*" aspect of it , wherein the vswitchd is monitoring the ovsrec_openVswitch table ( all columns ) . ( Actually it monitors all tables but bridge.c file only looks at the master table first row - since there is constraint of only 1 row addition to it ) 3) So every time we do an operation using ovs-vsctl , there is an update ( JSON-RPC ) received by the ovs-vswitchd. 4) It then calls the APIs provided in the *ovsdb-idl.c* file which parses the received JSON RPC message and populates/updates the idl. 5) My understanding is that this idl is having the current snapshot of the database. So its kind of an in memory db. 6) On top of this , the ovs-vswitchd also maintains a hash list of bridges - "*all_bridges*" and whenever an event of monitor happens , the vswitchd compares data from updated idl with the locally maintained hash list , and then updates information ( for example -*add_del_bridges*( ) traverses idl and all_bridges ). The queries which I have are - A) What was the need for defining the master table ovsrec_openVswitch ( which has references to most of the other tables ) . Is it for ease of implementation - so that with every update - just the first row of the ovsrec_openVswitch table is enough for processing. Or is there any special case that this design caters to ? B) What is the need to maintain 2 in memory databases in the vswitchd - one which is available through the idl and the other through the hash list (all_bridges ) ? The ovsdb-client also monitors and it does not go the idl way for its printing (over the console - do_monitor() ). So every update JSON RPC message has all the information required to identify what the updates pertains to - i) could be an addition , where it will just have a "new" json object. ii) could be a delete - where it will just have a "old" json object. iii) could be an update - where both "old" and "new" json objects will be there to point out the exact column that gets updated. Thanks in advance. Best Regards, Rishi Raj _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
