On Fri, Nov 16, 2012 at 9:16 AM, Ben Pfaff <b...@nicira.com> wrote: > [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.
I do not understand the race here. According to the man page, "The port number must be requested in the same transaction that creates the port". So, if no one has requested the port number while creating the port, wouldn't it be possible to simply populate the 'ofport_request' column after vswitchd decides the 'ofport' in the same transaction (only when ofport_request is empty)?Currently, if a OVSDB client populates 'ofport_request' column after the port is created, there is no effect. We can see the effect only after vswitchd is restarted. I do not know the implementation details here, so I could be completely off. > 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? > I am fine with this. > > Thanks, > > Ben. >
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
