[dpdk-dev,v5,4/8] ethdev: add GTP items to support flow API
Checks
Commit Message
This patch adds GTP, GTPC and GTPU items for
generic flow API, and also exposes item fields
through the flow command.
Signed-off-by: Beilei Xing <beilei.xing@intel.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
---
app/test-pmd/cmdline_flow.c | 40 ++++++++++++++++++++++
app/test-pmd/config.c | 3 ++
doc/guides/prog_guide/rte_flow.rst | 18 ++++++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 +++
lib/librte_ether/rte_flow.h | 52 +++++++++++++++++++++++++++++
5 files changed, 117 insertions(+)
Comments
On 28 September 2017 at 09:13, Beilei Xing <beilei.xing@intel.com> wrote:
> This patch adds GTP, GTPC and GTPU items for
> generic flow API, and also exposes item fields
> through the flow command.
>
> Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> ---
> app/test-pmd/cmdline_flow.c | 40 ++++++++++++++++++++++
> app/test-pmd/config.c | 3 ++
> doc/guides/prog_guide/rte_flow.rst | 18 ++++++++++
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 +++
> lib/librte_ether/rte_flow.h | 52 +++++++++++++++++++++++++++++
> 5 files changed, 117 insertions(+)
<snip>
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -955,6 +955,24 @@ Usage example, fuzzy match a TCPv4 packets:
> | 4 | END |
> +-------+----------+
>
> +Item: ``GTP``, ``GTPC``, ``GTPU``
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Matches a GTP header.
> +
> +Note: GTP, GTPC and GTPU use the same structure. Since only UDP destination port
> +is used to distinguish GTP_C (port is 2123) and GTP_U packets (port is 2152),
> +GTPC and GTPU item are defined for a user-friendly API when creating GTP-C and
> +GTP-U flow.
In GTPv1-C, request messages are sent from any port to port 2123, and
in the response message the ports are reversed (in GTPv2-C, it's a
little more complicated). Is the intention to only match requests?
It's not clear.
Also, it should be mentioned that GTPv0 is not included (it uses port 3386)
> +
> +- ``v_pt_rsv_flags``: version (3b), protocol type (1b), reserved (1b),
> + extension header flag (1b), sequence number flag (1b), N-PDU number
> + flag (1b).
> +- ``msg_type``: message type.
> +- ``msg_len``: message length.
> +- ``teid``: tunnel endpoint identifier.
> +- Default ``mask`` matches teid only.
> +
> Actions
> ~~~~~~~
>
<snip>
> /**
> + * RTE_FLOW_ITEM_TYPE_GTP.
> + *
> + * Matches a GTP header.
> + */
> +struct rte_flow_item_gtp {
> + /**
> + * Version (2b), protocol type (1b), reserved (1b),
> + * Extension header flag (1b),
> + * Sequence number flag (1b),
> + * N-PDU number flag (1b).
> + */
> + uint8_t v_pt_rsv_flags;
The version field has 3 bits, not 2 (it was correct above). The
meaning of the 5 flags in this byte is different in GTPv2-C compared
to GTPv1-C. Is the intention to only support GTPv1? If so that should
be stated. If GTPv2 is supported, then the teid field below is not
present in a few cases and matching on it could cause some strange
behaviour.
> + uint8_t msg_type; /**< Message type. */
> + rte_be16_t msg_len; /**< Message length. */
> + rte_be32_t teid; /**< Tunnel endpoint identifier. */
> +};
> +
> +/** Default mask for RTE_FLOW_ITEM_TYPE_GTP. */
> +#ifndef __cplusplus
> +static const struct rte_flow_item_gtp rte_flow_item_gtp_mask = {
> + .teid = RTE_BE32(0xffffffff),
> +};
> +#endif
> +
> +/**
> * Matching pattern item definition.
> *
> * A pattern is formed by stacking items starting from the lowest protocol
> --
> 2.5.5
>
> -----Original Message-----
> From: Sean Harte [mailto:seanbh@gmail.com]
> Sent: Thursday, September 28, 2017 9:43 PM
> To: Xing, Beilei <beilei.xing@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Chilikin, Andrey
> <andrey.chilikin@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v5 4/8] ethdev: add GTP items to support
> flow API
>
> On 28 September 2017 at 09:13, Beilei Xing <beilei.xing@intel.com> wrote:
> > This patch adds GTP, GTPC and GTPU items for generic flow API, and
> > also exposes item fields through the flow command.
> >
> > Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> > Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > ---
> > app/test-pmd/cmdline_flow.c | 40 ++++++++++++++++++++++
> > app/test-pmd/config.c | 3 ++
> > doc/guides/prog_guide/rte_flow.rst | 18 ++++++++++
> > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 4 +++
> > lib/librte_ether/rte_flow.h | 52
> +++++++++++++++++++++++++++++
> > 5 files changed, 117 insertions(+)
> <snip>
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -955,6 +955,24 @@ Usage example, fuzzy match a TCPv4 packets:
> > | 4 | END |
> > +-------+----------+
> >
> > +Item: ``GTP``, ``GTPC``, ``GTPU``
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Matches a GTP header.
> > +
> > +Note: GTP, GTPC and GTPU use the same structure. Since only UDP
> > +destination port is used to distinguish GTP_C (port is 2123) and
> > +GTP_U packets (port is 2152), GTPC and GTPU item are defined for a
> > +user-friendly API when creating GTP-C and GTP-U flow.
>
> In GTPv1-C, request messages are sent from any port to port 2123, and in the
> response message the ports are reversed (in GTPv2-C, it's a little more
> complicated). Is the intention to only match requests?
> It's not clear.
>
> Also, it should be mentioned that GTPv0 is not included (it uses port 3386)
Thanks for the comments, will clarify them in next version.
>
> > +
> > +- ``v_pt_rsv_flags``: version (3b), protocol type (1b), reserved
> > +(1b),
> > + extension header flag (1b), sequence number flag (1b), N-PDU number
> > + flag (1b).
> > +- ``msg_type``: message type.
> > +- ``msg_len``: message length.
> > +- ``teid``: tunnel endpoint identifier.
> > +- Default ``mask`` matches teid only.
> > +
> > Actions
> > ~~~~~~~
> >
> <snip>
> > /**
> > + * RTE_FLOW_ITEM_TYPE_GTP.
> > + *
> > + * Matches a GTP header.
> > + */
> > +struct rte_flow_item_gtp {
> > + /**
> > + * Version (2b), protocol type (1b), reserved (1b),
> > + * Extension header flag (1b),
> > + * Sequence number flag (1b),
> > + * N-PDU number flag (1b).
> > + */
> > + uint8_t v_pt_rsv_flags;
>
> The version field has 3 bits, not 2 (it was correct above). The meaning of the 5
> flags in this byte is different in GTPv2-C compared to GTPv1-C. Is the
> intention to only support GTPv1? If so that should be stated. If GTPv2 is
> supported, then the teid field below is not present in a few cases and
> matching on it could cause some strange behaviour.
Thanks for the correction, I will change version filed in next version.
And yes, we only support GTPv1 only, will clarify it.
>
> > + uint8_t msg_type; /**< Message type. */
> > + rte_be16_t msg_len; /**< Message length. */
> > + rte_be32_t teid; /**< Tunnel endpoint identifier. */ };
> > +
> > +/** Default mask for RTE_FLOW_ITEM_TYPE_GTP. */ #ifndef __cplusplus
> > +static const struct rte_flow_item_gtp rte_flow_item_gtp_mask = {
> > + .teid = RTE_BE32(0xffffffff),
> > +};
> > +#endif
> > +
> > +/**
> > * Matching pattern item definition.
> > *
> > * A pattern is formed by stacking items starting from the lowest
> > protocol
> > --
> > 2.5.5
> >
@@ -171,6 +171,10 @@ enum index {
ITEM_GRE_PROTO,
ITEM_FUZZY,
ITEM_FUZZY_THRESH,
+ ITEM_GTP,
+ ITEM_GTP_TEID,
+ ITEM_GTPC,
+ ITEM_GTPU,
/* Validate/create actions. */
ACTIONS,
@@ -451,6 +455,9 @@ static const enum index next_item[] = {
ITEM_MPLS,
ITEM_GRE,
ITEM_FUZZY,
+ ITEM_GTP,
+ ITEM_GTPC,
+ ITEM_GTPU,
ZERO,
};
@@ -588,6 +595,12 @@ static const enum index item_gre[] = {
ZERO,
};
+static const enum index item_gtp[] = {
+ ITEM_GTP_TEID,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -1421,6 +1434,33 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_fuzzy,
thresh)),
},
+ [ITEM_GTP] = {
+ .name = "gtp",
+ .help = "match GTP header",
+ .priv = PRIV_ITEM(GTP, sizeof(struct rte_flow_item_gtp)),
+ .next = NEXT(item_gtp),
+ .call = parse_vc,
+ },
+ [ITEM_GTP_TEID] = {
+ .name = "teid",
+ .help = "tunnel endpoint identifier",
+ .next = NEXT(item_gtp, NEXT_ENTRY(UNSIGNED), item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_gtp, teid)),
+ },
+ [ITEM_GTPC] = {
+ .name = "gtpc",
+ .help = "match GTP header",
+ .priv = PRIV_ITEM(GTPC, sizeof(struct rte_flow_item_gtp)),
+ .next = NEXT(item_gtp),
+ .call = parse_vc,
+ },
+ [ITEM_GTPU] = {
+ .name = "gtpu",
+ .help = "match GTP header",
+ .priv = PRIV_ITEM(GTPU, sizeof(struct rte_flow_item_gtp)),
+ .next = NEXT(item_gtp),
+ .call = parse_vc,
+ },
/* Validate/create actions. */
[ACTIONS] = {
@@ -949,6 +949,9 @@ static const struct {
MK_FLOW_ITEM(MPLS, sizeof(struct rte_flow_item_mpls)),
MK_FLOW_ITEM(GRE, sizeof(struct rte_flow_item_gre)),
MK_FLOW_ITEM(FUZZY, sizeof(struct rte_flow_item_fuzzy)),
+ MK_FLOW_ITEM(GTP, sizeof(struct rte_flow_item_gtp)),
+ MK_FLOW_ITEM(GTPC, sizeof(struct rte_flow_item_gtp)),
+ MK_FLOW_ITEM(GTPU, sizeof(struct rte_flow_item_gtp)),
};
/** Compute storage space needed by item specification. */
@@ -955,6 +955,24 @@ Usage example, fuzzy match a TCPv4 packets:
| 4 | END |
+-------+----------+
+Item: ``GTP``, ``GTPC``, ``GTPU``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches a GTP header.
+
+Note: GTP, GTPC and GTPU use the same structure. Since only UDP destination port
+is used to distinguish GTP_C (port is 2123) and GTP_U packets (port is 2152),
+GTPC and GTPU item are defined for a user-friendly API when creating GTP-C and
+GTP-U flow.
+
+- ``v_pt_rsv_flags``: version (3b), protocol type (1b), reserved (1b),
+ extension header flag (1b), sequence number flag (1b), N-PDU number
+ flag (1b).
+- ``msg_type``: message type.
+- ``msg_len``: message length.
+- ``teid``: tunnel endpoint identifier.
+- Default ``mask`` matches teid only.
+
Actions
~~~~~~~
@@ -2696,6 +2696,10 @@ This section lists supported pattern items and their attributes, if any.
- ``thresh {unsigned}``: accuracy threshold.
+- ``gtp``, ``gtpc``, ``gtpu``: match GTP header.
+
+ - ``teid {unsigned}``: tunnel endpoint identifier.
+
Actions list
^^^^^^^^^^^^
@@ -309,6 +309,33 @@ enum rte_flow_item_type {
* See struct rte_flow_item_fuzzy.
*/
RTE_FLOW_ITEM_TYPE_FUZZY,
+
+ /**
+ * Matches a GTP header.
+ *
+ * Configure flow for GTP packets.
+ *
+ * See struct rte_flow_item_gtp.
+ */
+ RTE_FLOW_ITEM_TYPE_GTP,
+
+ /**
+ * Matches a GTP header.
+ *
+ * Configure flow for GTP-C packets.
+ *
+ * See struct rte_flow_item_gtp.
+ */
+ RTE_FLOW_ITEM_TYPE_GTPC,
+
+ /**
+ * Matches a GTP header.
+ *
+ * Configure flow for GTP-U packets.
+ *
+ * See struct rte_flow_item_gtp.
+ */
+ RTE_FLOW_ITEM_TYPE_GTPU,
};
/**
@@ -735,6 +762,31 @@ static const struct rte_flow_item_fuzzy rte_flow_item_fuzzy_mask = {
#endif
/**
+ * RTE_FLOW_ITEM_TYPE_GTP.
+ *
+ * Matches a GTP header.
+ */
+struct rte_flow_item_gtp {
+ /**
+ * Version (2b), protocol type (1b), reserved (1b),
+ * Extension header flag (1b),
+ * Sequence number flag (1b),
+ * N-PDU number flag (1b).
+ */
+ uint8_t v_pt_rsv_flags;
+ uint8_t msg_type; /**< Message type. */
+ rte_be16_t msg_len; /**< Message length. */
+ rte_be32_t teid; /**< Tunnel endpoint identifier. */
+};
+
+/** Default mask for RTE_FLOW_ITEM_TYPE_GTP. */
+#ifndef __cplusplus
+static const struct rte_flow_item_gtp rte_flow_item_gtp_mask = {
+ .teid = RTE_BE32(0xffffffff),
+};
+#endif
+
+/**
* Matching pattern item definition.
*
* A pattern is formed by stacking items starting from the lowest protocol