[ovs-dev] [PATCH 2/2] ovs-save: Set ofport_request while saving flows.

[Ben Pfaff]

[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 <blp at 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 <gshetty at 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.