On Tue, Oct 30, 2012 at 03:34:32PM -0700, Justin Pettit wrote: > On Oct 22, 2012, at 3:11 PM, Ben Pfaff <b...@nicira.com> wrote: > > We want to avoid quickly reusing OpenFlow port numbers. Previously, > > that was indirectly implemented through dpif-linux, which makes an > > effort to avoid quickly reusing kernel datapath port numbers. This > > commit defeats that, I think, by generally allocating the > > lowest-numbered available OpenFlow port number. Presumably we should > > remove the reuse-avoidance logic from dpif-linux and move it to > > ofproto? > > Good point. I added some logic to ofproto, but I didn't remove the > logic from dpif-linux, since it's not required for this patch. Do you > think it's worth creating a new patch that always looks for the lowest > numbered free port instead?
We can do it as a separate patch. It should mostly be a matter of removing code: if we don't request a particular port number the kernel will select the lowest free port number for us. > > Should port_dump_next() skip and warn about ports for which > > odp_port_to_ofp_port() returns OFPP_NONE? > > I don't know that that would work properly, since init_ports() calls > the port iterator on startup--before we've assigned OpenFlow port > numbers. We could work around this, but I'm not sure it's worth it > for a sanity-check. Thoughts? I didn't realize there was a valid situation where this could happen. Skip it. > > I'm a little uncomfortable with this but I can't quite put a finger on > > the issue, so I'll defer further review of it for the moment. > > Do you have any new thoughts on the patch? No revelations have come to light, so let's call it good. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
