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.
---
DESIGN | 10 ++++++++++
lib/ofp-util.c | 3 ++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/DESIGN b/DESIGN
index 886994b..c53a8ea 100644
--- 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
--- 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;
--
1.7.7.1
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
