Do not clear tunnel metadata on tunnel input. This is used by a later patch.
Signed-off-by: Jarno Rajahalme <jarno.rajaha...@nsn.com>
---
lib/match.c | 4 ----
ofproto/ofproto-dpif.c | 26 ++++++++++++--------------
ofproto/tunnel.c | 3 +--
3 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/lib/match.c b/lib/match.c
index 2aa4e89..222e5d7 100644
--- a/lib/match.c
+++ b/lib/match.c
@@ -133,13 +133,9 @@ match_wc_init(struct match *match, const struct flow *flow)
void
match_init_exact(struct match *match, const struct flow *flow)
{
- ovs_be64 tun_id = flow->tunnel.tun_id;
-
match->flow = *flow;
match->flow.skb_priority = 0;
match->flow.skb_mark = 0;
- memset(&match->flow.tunnel, 0, sizeof match->flow.tunnel);
- match->flow.tunnel.tun_id = tun_id;
flow_wildcards_init_exact(&match->wc);
}
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index 33b09c6..b88a2d4 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -6836,8 +6836,6 @@ action_xlate_ctx_init(struct action_xlate_ctx *ctx,
struct rule_dpif *rule,
uint8_t tcp_flags, const struct ofpbuf *packet)
{
- ovs_be64 initial_tun_id = flow->tunnel.tun_id;
-
/* Flow initialization rules:
* - 'base_flow' must match the kernel's view of the packet at the
* time that action processing starts. 'flow' represents any
@@ -6849,23 +6847,23 @@ action_xlate_ctx_init(struct action_xlate_ctx *ctx,
* to another device without any modifications this will cause us to
* insert a new tag since the original one was stripped off by the
* VLAN device.
- * - Tunnel 'flow' is largely cleared when transitioning between
- * the input and output stages since it does not make sense to output
- * a packet with the exact headers that it was received with (i.e.
- * the destination IP is us). The one exception is the tun_id, which
- * is preserved to allow use in later resubmit lookups and loads into
- * registers.
- * - Tunnel 'base_flow' is completely cleared since that is what the
- * kernel does. If we wish to maintain the original values an action
- * needs to be generated. */
-
+ * - Tunnel metadata as received is retained in both 'flow' and
+ * 'base_flow'. This will prevent packet output with the exact same
+ * headers as it was received with (which would not make sense since
+ * the destination would be us). In effect, this emulates the kernel
+ * behavior of clearing the tunnel metadata before action processing.
+ * Keeping the tunnel fields in 'flow' allows tunnel metadata matching
+ * also in later tables.
+ * Since a kernel action for setting the tunnel metadata will only be
+ * generated with actual tunnel output, changing the tunnel metadata
+ * values in 'flow' (such as tun_id) will only have effect with a later
+ * tunnel output action.
+ */
ctx->ofproto = ofproto;
ctx->flow = *flow;
- memset(&ctx->flow.tunnel, 0, sizeof ctx->flow.tunnel);
ctx->base_flow = ctx->flow;
ctx->base_flow.vlan_tci = initial_vals->vlan_tci;
ctx->base_flow.tunnel.ip_tos = initial_vals->tunnel_ip_tos;
- ctx->flow.tunnel.tun_id = initial_tun_id;
ctx->rule = rule;
ctx->packet = packet;
ctx->may_learn = packet != NULL;
diff --git a/ofproto/tunnel.c b/ofproto/tunnel.c
index 8aa7fbe..8f5435a 100644
--- a/ofproto/tunnel.c
+++ b/ofproto/tunnel.c
@@ -198,8 +198,7 @@ tnl_port_receive(struct flow *flow)
}
flow->in_port = tnl_port->ofport->ofp_port;
- memset(&flow->tunnel, 0, sizeof flow->tunnel);
- flow->tunnel.tun_id = match.in_key;
+ /* Keep flow->tunnel to allow matching on tunnel metadata */
if (pre_flow_str) {
char *post_flow_str = flow_to_string(flow);
--
1.7.10.4
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
