On Fri, Nov 16, 2012 at 10:06:05AM -0800, Gurucharan Shetty wrote: > 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".
Yes, that's true. But personally I consider that a regrettable limitation of the current implementation. In the future, I would like to eliminate this limitation, and so I aim to avoid making it harder to fix. > 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 agree that you are correct if one considers this limitation to be permanent (and possibly desirable). > 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. OK, would you mind implementing it that way? Thanks, Ben. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
