SDFAB-193 Fix routing of GTP End Marker packet-outs on fabric-v1model
This change introduces three fixes:
1) We have observed an issue with p4lang/PI and BMv2 where in presence of
multiple metadata fields, the PI implementation for BMv2 provides an
erroneous serialization of the packet-out header, hence affecting the
parsing/forwarding behavior. As a workaround, since we cannot control
the order of fields in the p4runtime.PacketOut message, we modify the
interpreter to only add one field, egress_port or do_forwarding. Both
fields are treated as mutually exclusive by the P4 pipeline, so the
operation is safe. This is against the P4Runtime spec (all fields should
be provided), but supported by BMv2 (unset fields are initialized to
zero).
2) CPU port was not initialized when calling Pipeliner.init()
3) GTP End Marker were being parsed as GTP-U packets with inner IPv4,
causing a parser error (packet too short).
Change-Id: I406870b4a9aa044b5d0b35a56b0bfde4e601a4f6
diff --git a/pipelines/fabric/impl/src/main/resources/include/header.p4 b/pipelines/fabric/impl/src/main/resources/include/header.p4
index ce6fcf8..4b4e315 100644
--- a/pipelines/fabric/impl/src/main/resources/include/header.p4
+++ b/pipelines/fabric/impl/src/main/resources/include/header.p4
@@ -125,7 +125,7 @@
bit<64> timestamp;
}
-#ifdef WITH_SPGW
+
// GTPU v1
header gtpu_t {
bit<3> version; /* version */
@@ -139,6 +139,7 @@
teid_t teid; /* tunnel endpoint id */
}
+#ifdef WITH_SPGW
struct spgw_meta_t {
bit<16> ipv4_len;
teid_t teid;