On Thu, Jun 14, 2012 at 05:31:07PM -0700, Mehak Mahajan wrote: > I have taken care of the json connection. > The reason to propagate the changed information to the top was in future if > any other configurable options for the socket get added, we can just modify > all the options and then reconnect once (though i cannot foresee any such > parameters as of now). Hence I have taken this change out.
OK, thanks. > However in case of the controller it may not be possible to make these > changes unless I can call rconn_disconnect() followed directly by > reconnect(). > [As of now I am calling rconn_connect (I assumed that rconn_disconnect > modifies the 'target' in some way and hence needs to be re-written to rconn > using rconn_set_target__() before the reconnect()). > Also it seems to be the norm to repopulate all the data structures from > what was just read from the db, in case anything has changed. Hence I > called rconn_connect() instead of reconnect()] > rconn_set_dscp() does not get passed the 'target' and 'name'. I still don't understand how the above adds up to rconn_reconnect() being inappropriate following a DSCP change. It seems to me that it does exactly what we want if the DSCP changes: it drops the connection and reconnects to the existing target. Can you explain? > As for the ovs-schema, the current documentation reads > "The connection must be reset for the new DSCP values to take effect." ... > for both the Manager and Controller dscp configuration. Though we are still > resetting the connection, I am not sure if this needs to be explicitly > stated in man page as the user does not need to do anything now? Your documentation update seems OK to me (although you can delete the sentence about 8 seconds, since I think we've fixed that). I was talking about vswitch.ovsschema. You can drop that change, since as far as I can see it isn't useful. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
