ofp-util: Support OFPP_LOCAL in enqueue actions.

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.

diff --git a/DESIGN b/DESIGN
index 886994b..c53a8ea 100644 (file)
--- a/DESIGN
+++ b/DESIGN
@@ -9,6 +9,16 @@ successful deployment.  The end of this document contains contact
 information that can be used to let us know how we can make Open vSwitch
 more generally useful.
 
+OpenFlow
+========
+
+The OpenFlow 1.0 specification requires the output port of the OFPAT_ENQUEUE
+action to "refer to a valid physical port (i.e. < OFPP_MAX) or OFPP_IN_PORT".
+Although OFPP_LOCAL is not less than OFPP_MAX, it is an 'internal' port which
+can have QoS applied to it in Linux.  Since we allow the OFPAT_ENQUEUE to apply
+to 'internal' ports whose port numbers are less than OFPP_MAX, we interpret
+OFPP_LOCAL as a physical port and support OFPAT_ENQUEUE on it as well.
+
 
 Multiple Table Support
 ======================

diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index 3c004dc..11b0f15 100644 (file)
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -2211,7 +2211,8 @@ validate_actions(const union ofp_action *actions, size_t n_actions,
 
         case OFPUTIL_OFPAT_ENQUEUE:
             port = ntohs(((const struct ofp_action_enqueue *) a)->port);
-            if (port >= max_ports && port != OFPP_IN_PORT) {
+            if (port >= max_ports && port != OFPP_IN_PORT
+                && port != OFPP_LOCAL) {
                 error = ofp_mkerr(OFPET_BAD_ACTION, OFPBAC_BAD_OUT_PORT);
             }
             break;