[dpdk-dev,v2,2/6] ethdev: add GTPC and GTPU items
Checks
Commit Message
This patch adds GTPC and GTPU items to generic rte
flow, and also exposes the following item fields
through the flow command:
- GTPC TEID
- GTPU TEID
Signed-off-by: Beilei Xing <beilei.xing@intel.com>
---
app/test-pmd/cmdline_flow.c | 44 +++++++++++++++++++++++++++++
app/test-pmd/config.c | 2 ++
doc/guides/prog_guide/rte_flow.rst | 26 +++++++++++++++++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 8 ++++++
lib/librte_ether/rte_flow.h | 44 +++++++++++++++++++++++++++++
5 files changed, 124 insertions(+)
Comments
Hi Beilei,
I assume this patch supersedes [1]?
[1] http://dpdk.org/ml/archives/dev/2017-August/073501.html
Thanks for merging testpmd and the API change as a single patch, I still
have a few comments, see below.
(please add "flow API" somewhere in the title by the way)
On Thu, Sep 07, 2017 at 07:20:59PM +0800, Beilei Xing wrote:
> This patch adds GTPC and GTPU items to generic rte
> flow, and also exposes the following item fields
> through the flow command:
>
> - GTPC TEID
> - GTPU TEID
>
> Signed-off-by: Beilei Xing <beilei.xing@intel.com>
Won't there be a need to match nonspecific GTP traffic as well (both GTP-C
and GTP-U a once), since they use the same structure?
I'm not familiar with the protocol at all so I wonder if you should maybe
leave the GTP item in addition to those two.
> ---
> app/test-pmd/cmdline_flow.c | 44 +++++++++++++++++++++++++++++
> app/test-pmd/config.c | 2 ++
> doc/guides/prog_guide/rte_flow.rst | 26 +++++++++++++++++
> doc/guides/testpmd_app_ug/testpmd_funcs.rst | 8 ++++++
> lib/librte_ether/rte_flow.h | 44 +++++++++++++++++++++++++++++
> 5 files changed, 124 insertions(+)
>
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index a17a004..72d159c 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -171,6 +171,10 @@ enum index {
> ITEM_GRE_PROTO,
> ITEM_FUZZY,
> ITEM_FUZZY_THRESH,
> + ITEM_GTPC,
> + ITEM_GTPC_TEID,
> + ITEM_GTPU,
> + ITEM_GTPU_TEID,
You could refactor the TEID parameter since they use the same
structure. Might be useful if you add nonspecific GTP:
ITEM_GTP,
ITEM_GTP_TEID,
ITEM_GTPC,
ITEM_GTPU,
>
> /* Validate/create actions. */
> ACTIONS,
> @@ -451,6 +455,8 @@ static const enum index next_item[] = {
> ITEM_MPLS,
> ITEM_GRE,
> ITEM_FUZZY,
> + ITEM_GTPC,
> + ITEM_GTPU,
> ZERO,
> };
>
> @@ -588,6 +594,18 @@ static const enum index item_gre[] = {
> ZERO,
> };
>
> +static const enum index item_gtpc[] = {
> + ITEM_GTPC_TEID,
> + ITEM_NEXT,
> + ZERO,
> +};
> +
> +static const enum index item_gtpu[] = {
> + ITEM_GTPU_TEID,
> + ITEM_NEXT,
> + ZERO,
> +};
A single array is necessary, item_gtp[].
> +
> static const enum index next_action[] = {
> ACTION_END,
> ACTION_VOID,
> @@ -1421,6 +1439,32 @@ static const struct token token_list[] = {
> .args = ARGS(ARGS_ENTRY(struct rte_flow_item_fuzzy,
> thresh)),
> },
> + [ITEM_GTPC] = {
> + .name = "gtpc",
> + .help = "match GTP header",
> + .priv = PRIV_ITEM(GTPC, sizeof(struct rte_flow_item_gtp)),
> + .next = NEXT(item_gtpc),
> + .call = parse_vc,
> + },
> + [ITEM_GTPC_TEID] = {
> + .name = "teid",
> + .help = "TUNNEL ENDPOINT IDENTIFIER",
Please don't shout, "tunnel endpoint identifier" is fine.
> + .next = NEXT(item_gtpc, NEXT_ENTRY(UNSIGNED), item_param),
> + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_gtp, teid)),
> + },
> + [ITEM_GTPU] = {
> + .name = "gtpu",
> + .help = "match GTP header",
> + .priv = PRIV_ITEM(GTPU, sizeof(struct rte_flow_item_gtp)),
> + .next = NEXT(item_gtpu),
> + .call = parse_vc,
> + },
> + [ITEM_GTPU_TEID] = {
> + .name = "teid",
> + .help = "TUNNEL ENDPOINT IDENTIFIER",
Same comment here, however the a single TEID entry is necessary as
previously described.
> + .next = NEXT(item_gtpu, NEXT_ENTRY(UNSIGNED), item_param),
> + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_gtp, teid)),
> + },
>
> /* Validate/create actions. */
> [ACTIONS] = {
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> index 3ae3e1c..be4c3b9 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -947,6 +947,8 @@ 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)),
Remember to add GTP here assuming it makes sense.
> + 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. */
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 662a912..9e7179a 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -955,6 +955,32 @@ Usage example, fuzzy match a TCPv4 packets:
> | 4 | END |
> +-------+----------+
>
> +Item: ``GTPC``
> +^^^^^^^^^^^^^^
> +
> +Matches a GTP header.
> +
> +- ``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``: TEID.
> +- Default ``mask`` matches teid only.
> +
> +Item: ``GTPU``
> +^^^^^^^^^^^^^^
> +
> +Matches a GTP header.
> +
> +- ``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``: TEID.
> +- Default ``mask`` matches teid only.
> +
You can use a single section to describe all three items at once since they
map to a common structure:
Item: ``GTP``, ``GTPC``, ``GTPU``:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Then elaborate a bit on the the differences between them.
> Actions
> ~~~~~~~
>
> diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> index 2ed62f5..2ca36ad 100644
> --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
> @@ -2696,6 +2696,14 @@ This section lists supported pattern items and their attributes, if any.
>
> - ``thresh {unsigned}``: accuracy threshold.
>
> +- ``gtpc``: match GTP header.
> +
> + - ``teid {unsigned}``: Tunnel endpoint identifier.
Tunnel => tunnel
> +
> +- ``gtpu``: match GTP header.
> +
> + - ``teid {unsigned}``: Tunnel endpoint identifier.
You could also merge all three items here, e.g.:
- ``gtp``, ``gtpc``, ``gtpu``: ...
> +
> Actions list
> ^^^^^^^^^^^^
>
> diff --git a/lib/librte_ether/rte_flow.h b/lib/librte_ether/rte_flow.h
> index bba6169..8b24cac 100644
> --- a/lib/librte_ether/rte_flow.h
> +++ b/lib/librte_ether/rte_flow.h
> @@ -309,6 +309,24 @@ enum rte_flow_item_type {
> * See struct rte_flow_item_fuzzy.
> */
> RTE_FLOW_ITEM_TYPE_FUZZY,
> +
> + /**
> + * Matches a GTP header.
Write "GTP-U" to make clear this is not nonspecific "GTP" matching.
> + *
> + * Configure flow for GTP-C packets.
> + *
> + * See struct rte_flow_item_gtp.
> + */
> + RTE_FLOW_ITEM_TYPE_GTPC,
> +
> + /**
> + * Matches a GTP header.
"GTP-C" here.
> + *
> + * Configure flow for GTP-U packets.
> + *
> + * See struct rte_flow_item_gtp.
> + */
> + RTE_FLOW_ITEM_TYPE_GTPU,
> };
>
> /**
> @@ -735,6 +753,32 @@ static const struct rte_flow_item_fuzzy rte_flow_item_fuzzy_mask = {
> #endif
>
> /**
> + * RTE_FLOW_ITEM_TYPE_GTP.
You need to mention the others, something like:
RTE_FLOW_ITEM_TYPE_GTP, RTE_FLOW_ITEM_TYPE_GTPC and RTE_FLOW_ITEM_TYPE_GTPU.
> + *
> + * Matches a GTP header.
Similarly:
Matches a nonspecific GTP, a GTP-C or a GTP-U header.
> + */
> +struct rte_flow_item_gtp {
> + /**
> + * Version (2b), protocol type (1b), reserved (1b),
> + * Extension header flag (1b),
> + * Sequence number flag (1b),
Extension => extension
sequence => sequence
> + * 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 = {
> + .msg_type = 0x00,
The above field is not necessary since you're not initializing the entire
structure, the rest is set to 0 by default.
> + .teid = RTE_BE32(0xffffffff),
> +};
> +#endif
> +
> +/**
> * Matching pattern item definition.
> *
> * A pattern is formed by stacking items starting from the lowest protocol
> --
> 2.5.5
>
Hi Adrien,
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Thursday, September 7, 2017 8:20 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 v2 2/6] ethdev: add GTPC and GTPU items
>
> Hi Beilei,
>
> I assume this patch supersedes [1]?
>
> [1] http://dpdk.org/ml/archives/dev/2017-August/073501.html
>
> Thanks for merging testpmd and the API change as a single patch, I still have
> a few comments, see below.
>
> (please add "flow API" somewhere in the title by the way)
Thanks for all your comments.
Yes, http://dpdk.org/ml/archives/dev/2017-August/073501.html is superseded and did merging testpmd and API change.
I will update title in next version.
>
> On Thu, Sep 07, 2017 at 07:20:59PM +0800, Beilei Xing wrote:
> > This patch adds GTPC and GTPU items to generic rte flow, and also
> > exposes the following item fields through the flow command:
> >
> > - GTPC TEID
> > - GTPU TEID
> >
> > Signed-off-by: Beilei Xing <beilei.xing@intel.com>
>
> Won't there be a need to match nonspecific GTP traffic as well (both GTP-C
> and GTP-U a once), since they use the same structure?
>
> I'm not familiar with the protocol at all so I wonder if you should maybe leave
> the GTP item in addition to those two.
>
Agree, I will leave the GTP item in next version.
GTP-C and GTP-U use the same structure, the difference between them is UDP port, 2123 is for GTP-C, and 2152 is for GTP-U.
Add GTP-C and GTP -U item since I want to design a user-friendly CLI.
For example, if user wants to add such flow: assign GTP-U packets with TEID 0x123456 to queue 14.
Then use can use following CLI:
flow create 0 ingress pattern eth / ipv4 / udp / gtpu teid is 0x123456 / end actions queue index 14 / end
instead of below CLI to distinguish GTP-C and GTP-U with UDP port:
flow create 0 ingress pattern eth / ipv4 / udp dst spec 2125 dst mask 0 / gtp teid is 0x123456 / end actions queue index 14 / end
And all your other comments will be addressed in next version, thanks.
Beilei
Hi Beilei,
On Tue, Sep 12, 2017 at 06:40:50AM +0000, Xing, Beilei wrote:
> Hi Adrien,
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Thursday, September 7, 2017 8:20 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 v2 2/6] ethdev: add GTPC and GTPU items
> >
> > Hi Beilei,
> >
> > I assume this patch supersedes [1]?
> >
> > [1] http://dpdk.org/ml/archives/dev/2017-August/073501.html
> >
> > Thanks for merging testpmd and the API change as a single patch, I still have
> > a few comments, see below.
> >
> > (please add "flow API" somewhere in the title by the way)
>
> Thanks for all your comments.
> Yes, http://dpdk.org/ml/archives/dev/2017-August/073501.html is superseded and did merging testpmd and API change.
> I will update title in next version.
All right, thanks.
> > On Thu, Sep 07, 2017 at 07:20:59PM +0800, Beilei Xing wrote:
> > > This patch adds GTPC and GTPU items to generic rte flow, and also
> > > exposes the following item fields through the flow command:
> > >
> > > - GTPC TEID
> > > - GTPU TEID
> > >
> > > Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> >
> > Won't there be a need to match nonspecific GTP traffic as well (both GTP-C
> > and GTP-U a once), since they use the same structure?
> >
> > I'm not familiar with the protocol at all so I wonder if you should maybe leave
> > the GTP item in addition to those two.
> >
>
> Agree, I will leave the GTP item in next version.
>
> GTP-C and GTP-U use the same structure, the difference between them is UDP port, 2123 is for GTP-C, and 2152 is for GTP-U.
> Add GTP-C and GTP -U item since I want to design a user-friendly CLI.
>
> For example, if user wants to add such flow: assign GTP-U packets with TEID 0x123456 to queue 14.
> Then use can use following CLI:
> flow create 0 ingress pattern eth / ipv4 / udp / gtpu teid is 0x123456 / end actions queue index 14 / end
> instead of below CLI to distinguish GTP-C and GTP-U with UDP port:
> flow create 0 ingress pattern eth / ipv4 / udp dst spec 2125 dst mask 0 / gtp teid is 0x123456 / end actions queue index 14 / end
I agree with you from a usability standpoint it's much nicer. I have one
question though, could one send GTP-C / GTP-U traffic using nondefault UDP
ports and expect hardware to match it without explicitly specifying a port
in the UDP item, that is, is there some property in GTP-C / GTP-U traffic
outside the UDP port that would theoretically allow a host (even a stateful
one) to tell them apart?
If it really depends on the UDP port only, not specifying one will use
hardware defaults regardless of the item (GTP / GTP-U / GTP-C). However if
like VXLAN, this default value can be modified outside of rte_flow, most
users will have to specify it regardless in order to get consistent results
across various vendors/adapters.
In any case I don't mind three items. GTP encompasses both GTP-U and GTP-C
(possibly two different UDP ports at once), while GTP-U and GTP-C match
exactly one. You only have to describe this properly in the documentation.
Thanks.
Hi Adrien,
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Tuesday, September 12, 2017 6:47 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 v2 2/6] ethdev: add GTPC and GTPU items
>
> Hi Beilei,
>
> On Tue, Sep 12, 2017 at 06:40:50AM +0000, Xing, Beilei wrote:
> > Hi Adrien,
> >
> > > -----Original Message-----
> > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > > Sent: Thursday, September 7, 2017 8:20 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 v2 2/6] ethdev: add GTPC and GTPU
> > > items
> > >
> > > Hi Beilei,
> > >
> > > I assume this patch supersedes [1]?
> > >
> > > [1] http://dpdk.org/ml/archives/dev/2017-August/073501.html
> > >
> > > Thanks for merging testpmd and the API change as a single patch, I
> > > still have a few comments, see below.
> > >
> > > (please add "flow API" somewhere in the title by the way)
> >
> > Thanks for all your comments.
> > Yes, http://dpdk.org/ml/archives/dev/2017-August/073501.html is
> superseded and did merging testpmd and API change.
> > I will update title in next version.
>
> All right, thanks.
>
> > > On Thu, Sep 07, 2017 at 07:20:59PM +0800, Beilei Xing wrote:
> > > > This patch adds GTPC and GTPU items to generic rte flow, and also
> > > > exposes the following item fields through the flow command:
> > > >
> > > > - GTPC TEID
> > > > - GTPU TEID
> > > >
> > > > Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> > >
> > > Won't there be a need to match nonspecific GTP traffic as well (both
> > > GTP-C and GTP-U a once), since they use the same structure?
> > >
> > > I'm not familiar with the protocol at all so I wonder if you should
> > > maybe leave the GTP item in addition to those two.
> > >
> >
> > Agree, I will leave the GTP item in next version.
> >
> > GTP-C and GTP-U use the same structure, the difference between them is
> UDP port, 2123 is for GTP-C, and 2152 is for GTP-U.
> > Add GTP-C and GTP -U item since I want to design a user-friendly CLI.
> >
> > For example, if user wants to add such flow: assign GTP-U packets with
> TEID 0x123456 to queue 14.
> > Then use can use following CLI:
> > flow create 0 ingress pattern eth / ipv4 / udp / gtpu teid is 0x123456
> > / end actions queue index 14 / end instead of below CLI to distinguish
> GTP-C and GTP-U with UDP port:
> > flow create 0 ingress pattern eth / ipv4 / udp dst spec 2125 dst mask
> > 0 / gtp teid is 0x123456 / end actions queue index 14 / end
>
> I agree with you from a usability standpoint it's much nicer. I have one
> question though, could one send GTP-C / GTP-U traffic using nondefault UDP
> ports and expect hardware to match it without explicitly specifying a port in
> the UDP item, that is, is there some property in GTP-C / GTP-U traffic outside
> the UDP port that would theoretically allow a host (even a stateful
> one) to tell them apart?
>
> If it really depends on the UDP port only, not specifying one will use
> hardware defaults regardless of the item (GTP / GTP-U / GTP-C). However if
> like VXLAN, this default value can be modified outside of rte_flow, most
> users will have to specify it regardless in order to get consistent results
> across various vendors/adapters.
As far as I know, there's no other property in GTP-C / GTP-U traffic outside the UDP port to distinguish GTP-C and GTP-U. And I don't think the value can be modified by user just like VXLAN.
>
> In any case I don't mind three items. GTP encompasses both GTP-U and
> GTP-C (possibly two different UDP ports at once), while GTP-U and GTP-C
> match exactly one. You only have to describe this properly in the
> documentation.
OK, I will describe it in documentation.
Beilei
@@ -171,6 +171,10 @@ enum index {
ITEM_GRE_PROTO,
ITEM_FUZZY,
ITEM_FUZZY_THRESH,
+ ITEM_GTPC,
+ ITEM_GTPC_TEID,
+ ITEM_GTPU,
+ ITEM_GTPU_TEID,
/* Validate/create actions. */
ACTIONS,
@@ -451,6 +455,8 @@ static const enum index next_item[] = {
ITEM_MPLS,
ITEM_GRE,
ITEM_FUZZY,
+ ITEM_GTPC,
+ ITEM_GTPU,
ZERO,
};
@@ -588,6 +594,18 @@ static const enum index item_gre[] = {
ZERO,
};
+static const enum index item_gtpc[] = {
+ ITEM_GTPC_TEID,
+ ITEM_NEXT,
+ ZERO,
+};
+
+static const enum index item_gtpu[] = {
+ ITEM_GTPU_TEID,
+ ITEM_NEXT,
+ ZERO,
+};
+
static const enum index next_action[] = {
ACTION_END,
ACTION_VOID,
@@ -1421,6 +1439,32 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY(struct rte_flow_item_fuzzy,
thresh)),
},
+ [ITEM_GTPC] = {
+ .name = "gtpc",
+ .help = "match GTP header",
+ .priv = PRIV_ITEM(GTPC, sizeof(struct rte_flow_item_gtp)),
+ .next = NEXT(item_gtpc),
+ .call = parse_vc,
+ },
+ [ITEM_GTPC_TEID] = {
+ .name = "teid",
+ .help = "TUNNEL ENDPOINT IDENTIFIER",
+ .next = NEXT(item_gtpc, NEXT_ENTRY(UNSIGNED), item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_gtp, teid)),
+ },
+ [ITEM_GTPU] = {
+ .name = "gtpu",
+ .help = "match GTP header",
+ .priv = PRIV_ITEM(GTPU, sizeof(struct rte_flow_item_gtp)),
+ .next = NEXT(item_gtpu),
+ .call = parse_vc,
+ },
+ [ITEM_GTPU_TEID] = {
+ .name = "teid",
+ .help = "TUNNEL ENDPOINT IDENTIFIER",
+ .next = NEXT(item_gtpu, NEXT_ENTRY(UNSIGNED), item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_gtp, teid)),
+ },
/* Validate/create actions. */
[ACTIONS] = {
@@ -947,6 +947,8 @@ 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(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,32 @@ Usage example, fuzzy match a TCPv4 packets:
| 4 | END |
+-------+----------+
+Item: ``GTPC``
+^^^^^^^^^^^^^^
+
+Matches a GTP header.
+
+- ``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``: TEID.
+- Default ``mask`` matches teid only.
+
+Item: ``GTPU``
+^^^^^^^^^^^^^^
+
+Matches a GTP header.
+
+- ``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``: TEID.
+- Default ``mask`` matches teid only.
+
Actions
~~~~~~~
@@ -2696,6 +2696,14 @@ This section lists supported pattern items and their attributes, if any.
- ``thresh {unsigned}``: accuracy threshold.
+- ``gtpc``: match GTP header.
+
+ - ``teid {unsigned}``: Tunnel endpoint identifier.
+
+- ``gtpu``: match GTP header.
+
+ - ``teid {unsigned}``: Tunnel endpoint identifier.
+
Actions list
^^^^^^^^^^^^
@@ -309,6 +309,24 @@ enum rte_flow_item_type {
* See struct rte_flow_item_fuzzy.
*/
RTE_FLOW_ITEM_TYPE_FUZZY,
+
+ /**
+ * 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 +753,32 @@ 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 = {
+ .msg_type = 0x00,
+ .teid = RTE_BE32(0xffffffff),
+};
+#endif
+
+/**
* Matching pattern item definition.
*
* A pattern is formed by stacking items starting from the lowest protocol