OK, that's good enough for me. I've been thinking of creating a section in the ovs-vswitchd manpage that describes Open vSwitch interpretations of the OpenFlow text, in places where it's not entirely clear. Would you mind starting it out, by adding a sentence or so that mentions our interpretation of OFPP_LOCAL as a physical port?
Thanks, Ben. On Fri, Nov 18, 2011 at 08:07:17PM -0800, Ethan Jackson wrote: > I suppose it depends on how you interpret the term physical port. It > certainly isn't a nic, but it does have a linux device which I assume > you can attach linux QoS to. In that sense, it is more of a physical > port then OFPP_NONE, or OFPP_FLOOD. > > I don't think we should take a strict interpretation of "physical > port" because it would be difficult to enforce. Any number of the > ports in the range [1, 1024] may not be physical (tap devices, vifs, > tunnels, internal ports, etc). The current code allows these but > doesn't allow OFPP_LOCAL which feels inconsistent to me. > > Ethan > > On Fri, Nov 18, 2011 at 19:43, Ben Pfaff <b...@nicira.com> wrote: > > On Fri, Nov 18, 2011 at 07:03:38PM -0800, Ethan Jackson wrote: > >> According to the specification the enqueue action should refer to > >> "a valid physical port", or OFPP_IN_PORT. ?It would be strange to > >> attach a queueing discipline to the local port, but I see no reason > >> to restrict it. > > > > Is OFPP_LOCAL a physical port? > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
