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

[Justin Pettit]

Do you think we should put that in DESIGN?  Also, we should start chipping away at ambiguities in the OpenFlow spec by filing spec bugs in the ONF bug tracker.  I've been trying to do that with areas that I see.

--Justin


On Nov 18, 2011, at 8:36 PM, Ben Pfaff wrote:

> 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?
>>> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev