[ovs-dev] [PATCH] ofp-util: Support OFPP_LOCAL in enqueue actions.

Ben Pfaff blp at nicira.com
Sat Nov 19 04:36:19 UTC 2011


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 <blp at 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?
> >



More information about the dev mailing list