[adding ovs-dev back, I hope that's OK--I don't see anything private here] On Thu, Nov 15, 2012 at 05:29:57PM -0800, Gurucharan Shetty wrote: > On Wed, Nov 14, 2012 at 10:02 AM, Ben Pfaff <b...@nicira.com> wrote: > > > On Tue, Nov 06, 2012 at 11:11:31AM -0800, Gurucharan Shetty wrote: > > > Populate the interface table's 'ofport_request' column > > > with the value in the column 'ofport' while saving flows. > > > > > > When vswitchd restarts, it will use the ofport_request > > > value to set the value of ofport. > > > > > > Signed-off-by: Gurucharan Shetty <gshe...@nicira.com> > > > > This seems reasonable. It's going to be slow with a large number of > > ports, though. Did you test how long it takes with, say, 1000 ports? > > Yes. I see that it takes ~25 seconds to set the ofport_request for 1000 > ports. > > It looks to me that this issue can be solved, if vswitchd automatically sets > the 'ofport_request' whenever it creates that port with the same value as > ofport. > Is it not possible? Woudn't it solve the issue?
It would solve the issue, but it raises new issues. For example, if some OVSDB client wanted to request a particular OpenFlow port, then it would race with ovs-vswitchd announcing the current OpenFlow port number. These kinds of races are why we, in general, make each column either read-only or write-only from ovs-vswitchd's perspective. Here is another way that would avoid any race: Have ovs-vswitchd first check the ofport_request column for a port number request, then if that is empty, check the ofport column. Then ovs-vswitchd would tend to maintain the port number that was previously used for a port, in the absence of an explicit user request. (We would also want to make the ofport column persistent, so that restarting ovsdb-server does not clear all the previous port numbers.) What do you think? Thanks, Ben. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
