On Wed, Nov 21, 2012 at 10:25:46AM -0800, Gurucharan Shetty wrote: > > > > I think that you have uncovered a pre-existing bug in ovs-vswitchd. > > ovs-vswitchd is supposed to set the ofport column to -1 only if there is > > an error that prevents the port from being created. But it sounds like, > > instead, we populate every ofport column with -1 before we attempt to > > add the ports. This is probably a mistake. I would think that, > > instead, we should only modify ofport once we either know the new > > OpenFlow port number or know that the port cannot be created. I think > > that would resolve the problem. Can you take a look at solving it that > > way? > Okay. I will look at that. But do you know the reason why the following > happens > in my notes. > > " - In ovsdb_idl_txn_commit, ovsdb_idl_txn_disassemble is called which > changes all the rows associated with "all other" interfaces to their > "old" values (the old values have ofport as +ve) in the memory." > > I haven't been able to figure out the reason for doing a thing like that.
This is because we cannot be sure that the commit will be effective. The database supports many clients all working concurrently, which means that any update we ship to the database could be invalidated, wholly or partially, by some other client acting before us. ovsdb_idl_txn_commit() tries to document this: * Committing a transaction rolls back all of the changes that it made to the * IDL's copy of the database. If the transaction commits successfully, then * the database server will send an update and, thus, the IDL will be updated * with the committed changes. */ but it may not draw enough attention to it (the above is at the end of a very long comment) and it doesn't describe the reason. Maybe I should update it. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
