[ovs-dev] [PATCH] ofproto: Recycle least recently used ofport.

Ben Pfaff blp at nicira.com
Thu Sep 26 19:59:09 UTC 2013


On Wed, Sep 25, 2013 at 10:50:13AM -0700, Gurucharan Shetty wrote:
> On Tue, Sep 24, 2013 at 10:52 AM, Ben Pfaff <blp at nicira.com> wrote:
> > On Mon, Aug 26, 2013 at 10:25:39AM -0700, Gurucharan Shetty wrote:
> >> If there is a lot of churn in creation and deletion of
> >> interfaces, we may end up recycling the ofport value of a
> >> recently deleted interface for a newly created interface.
> >> This may result in an old stale openflow rule applying
> >> on the newly created interface.
> >>
> >> With this commit, when a new port is added, try and provide
> >> it an ofport value that has not been used during the current
> >> run. If such value does not exist, provide the least
> >> recently used ofport value.
> >>
> >> Signed-off-by: Gurucharan Shetty <gshetty at nicira.com>

> > I wonder whether we should consider sufficiently old entries (an hour, a
> > day) to be expired.
> I had thought about it. Consider a case where someone is testing OVS with
> adding and deleting interfaces continuously. Initially, he would not have any
>  problems adding his interfaces, but as the test continues, the number of
> interfaces that can be created decreases and I felt that can be confusing.
> 
> With the current implementation, since we have ~65,000 ofport options,
> it feels unlikely that
> we can actually use a very recently deleted interface soon in a real
> world use case.

I meant something a little different.  I agree that it is good to be
able to reuse a recently deleted interface if there is no other
choice.  I was thinking of a different case.  Suppose that we have a
system with only a moderate rate of interface addition and deletion.
At 1/minute, after 45 days of uptime we will have used all the port
numbers once, which means that every port addition after that needs to
examine all 64k possible ports.

But I think it's fine to just leave that until it shows itself as a
real problem.

Thanks,

Ben.



More information about the dev mailing list