On 05/04/2018 17:42, Thomas Monjalon wrote:
05/04/2018 15:51, Declan Doherty:
+/**
+ * RTE_FLOW_ACTION_TYPE_VTEP_ENCAP
+ *
+ * Virtual tunnel end-point encapsulation action data.
+ *
+ * Non-terminating action by default.
+ */
+struct rte_flow_action_vtep_encap {
+ struct rte_flow_action_item {
+ enum rte_flow_item_type type;
+ /**< Flow item type. */
+ const void *item;
+ /**< Flow item definition. */
+ } *pattern;
+ /**<
+ * vTEP pattern specification (list terminated by the END pattern item).
+ */
+};
+
+/**
+ * RTE_FLOW_ACTION_TYP_VTEP_DECAP
+ *
+ * Virtual tunnel end-point decapsulation action data.
+ *
+ * Non-terminating action by default.
+ */
+struct rte_flow_action_vtep_decap {
+ enum rte_flow_item_type type;
+ /**<
+ * Flow item type of virtual tunnel end-point to be decapsulated
+ */
+};
Question about the naming:
Why using the terminology VTEP instead of TUNNEL simply?
I probably miss something, but tunnel encap/decap looks simpler to me.
Initial thought was that the tunnel terminology may conflict with
existing tunnel item types and their uses. In previous terminologies, it
was assumed that to create a tunneled flows, each time a tunnel item has
to be specified in the patterns.
Now with the endpoint concept, the tunnel endpoint will be created once
only, in for each subsequent flows created that is supposed to use the
tunnel, will use the tunnel metadata during the flow creation. Hence
comes the terminology virtual tunnel endpoint (VTEP). It does not harm
to use tunnel instead of vtep except the endpoint term is mission. In
the next patch TUNNEL terminology is used instead of VTEP.