Thread (2 messages) 2 messages, 2 authors, 2013-09-27

Re: [PATCH v2.40 4/7] ofp-actions: Add separate OpenFlow 1.3 action parser

From: Ben Pfaff <hidden>
Date: 2013-09-27 19:41:25

Possibly related (same subject, not in this thread)

On Fri, Sep 27, 2013 at 09:18:33AM +0900, Simon Horman wrote:
From: Joe Stringer <redacted>

This patch adds new ofpact_from_openflow13() and
ofpacts_from_openflow13() functions parallel to the existing ofpact
handling code. In the OpenFlow 1.3 version, push_mpls is handled
differently, but all other actions are handled by the existing code.

For push_mpls, ofpact_push_mpls.ofpact.compat is set to
OFPUTIL_OFPAT13_PUSH_MPLS, which allows correct VLAN+MPLS datapath
behaviour to be determined at odp translation time.

Signed-off-by: Joe Stringer <redacted>
Signed-off-by: Simon Horman <horms@verge.net.au>
I am nervous about this idea of having ofpacts_pull_openflow11_actions()
and ofpacts_pull_openflow11_instructions() try to figure out what
version of OpenFlow is involved.  It is a new and somewhat surprising
requirements that the callers provide not just actions or instructions
but a complete OpenFlow message.  I see that the callers in ovs-ofctl.c
don't satisfy this requirement.

I think that it would be better to make these functions' callers say
what version of OpenFlow they are working with.  One could provide a
helper function like get_version_from_ofpbuf(), which should probably go
in ofp-util.c, but I would want it to fail (assert-fail or segfault or
whatever) if there is no L2 header pointer, instead of returning a
default value (that, in this case anyway, we know must be wrong because
OF1.0 never contains OF1.1+ actions or instructions).

Thanks,

Ben.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help