[dpdk-dev,v6,6/8] net/i40e: add FDIR support for GTP-C and GTP-U
Checks
Commit Message
This patch adds FDIR support for GTP-C and GTP-U. The
input set of GTP-C and GTP-U is TEID.
Signed-off-by: Beilei Xing <beilei.xing@intel.com>
---
drivers/net/i40e/i40e_ethdev.h | 30 +++++
drivers/net/i40e/i40e_fdir.c | 200 ++++++++++++++++++++++---------
drivers/net/i40e/i40e_flow.c | 263 +++++++++++++++++++++++++++++++++++------
3 files changed, 396 insertions(+), 97 deletions(-)
Comments
On 29 September 2017 at 06:19, Beilei Xing <beilei.xing@intel.com> wrote:
> This patch adds FDIR support for GTP-C and GTP-U. The
> input set of GTP-C and GTP-U is TEID.
>
> Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> ---
> drivers/net/i40e/i40e_ethdev.h | 30 +++++
> drivers/net/i40e/i40e_fdir.c | 200 ++++++++++++++++++++++---------
> drivers/net/i40e/i40e_flow.c | 263 +++++++++++++++++++++++++++++++++++------
> 3 files changed, 396 insertions(+), 97 deletions(-)
<snip>
> @@ -1173,10 +1196,69 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf *pf,
> rte_cpu_to_be_16(ETHER_TYPE_ARP))
> payload += sizeof(struct arp_hdr);
> set_idx = I40E_FLXPLD_L2_IDX;
> - break;
> - default:
> - PMD_DRV_LOG(ERR, "unknown pctype %u.", fdir_input->pctype);
> - return -EINVAL;
> + } else if (fdir_input->flow_ext.customized_pctype) {
> + /* If customized pctype is used */
> + cus_pctype = i40e_flow_fdir_find_customized_pctype(pf, pctype);
> + if (cus_pctype->index == I40E_CUSTOMIZED_GTPC ||
> + cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV4 ||
> + cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV6 ||
> + cus_pctype->index == I40E_CUSTOMIZED_GTPU) {
> + udp = (struct udp_hdr *)(raw_pkt + len);
> + udp->dgram_len =
> + rte_cpu_to_be_16(I40E_FDIR_UDP_DEFAULT_LEN);
> +
> + gtp = (struct rte_flow_item_gtp *)
> + ((unsigned char *)udp + sizeof(struct udp_hdr));
> + gtp->v_pt_rsv_flags = 0x30;
0x30 isn't valid for GTP-C, the sequence number must be present in
GTP-C so it will be 0x32 or more. Is this byte actually matched
against by the device using the GTP pctypes?
> + gtp->msg_len =
> + rte_cpu_to_be_16(I40E_FDIR_GTP_DEFAULT_LEN);
> + gtp->teid = fdir_input->flow.gtp_flow.teid;
> + gtp->msg_type = 0x1;
Why use this value?
> +
> + if (cus_pctype->index == I40E_CUSTOMIZED_GTPC)
> + udp->dst_port = rte_cpu_to_be_16(2123);
This will only match half of GTP-C messages. GTP-C messages have a UDP
port destination of 2123, or a UDP source port of 2123. To match all
GTP-C packets you need to look at both.
> + else
> + udp->dst_port = rte_cpu_to_be_16(2152);
> +
> + if (cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV4) {
> + gtp->msg_type = 0xFF;
> + gtp_ipv4 = (struct ipv4_hdr *)
> + ((unsigned char *)gtp +
> + sizeof(struct rte_flow_item_gtp));
This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are
allowed to have a sequence number, which adds an extra 4 bytes to the
GTP header.
> + gtp_ipv4->version_ihl =
> + I40E_FDIR_IP_DEFAULT_VERSION_IHL;
> + gtp_ipv4->next_proto_id = IPPROTO_IP;
> + gtp_ipv4->total_length =
> + rte_cpu_to_be_16(
> + I40E_FDIR_INNER_IP_DEFAULT_LEN);
> + payload = (unsigned char *)gtp_ipv4 +
> + sizeof(struct ipv4_hdr);
> + } else if (cus_pctype->index ==
> + I40E_CUSTOMIZED_GTPU_IPV6) {
> + gtp->msg_type = 0xFF;
> + gtp_ipv6 = (struct ipv6_hdr *)
> + ((unsigned char *)gtp +
> + sizeof(struct rte_flow_item_gtp));
This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are
allowed to have a sequence number, which adds an extra 4 bytes to the
GTP header.
> + gtp_ipv6->vtc_flow =
> + rte_cpu_to_be_32(
> + I40E_FDIR_IPv6_DEFAULT_VTC_FLOW |
> + (0 << I40E_FDIR_IPv6_TC_OFFSET));
> + gtp_ipv6->proto = IPPROTO_NONE;
> + gtp_ipv6->payload_len =
> + rte_cpu_to_be_16(
> + I40E_FDIR_INNER_IPv6_DEFAULT_LEN);
> + gtp_ipv6->hop_limits =
> + I40E_FDIR_IPv6_DEFAULT_HOP_LIMITS;
> + payload = (unsigned char *)gtp_ipv6 +
> + sizeof(struct ipv6_hdr);
> + } else
> + payload = (unsigned char *)gtp +
> + sizeof(struct rte_flow_item_gtp);
> + }
> + } else {
> + PMD_DRV_LOG(ERR, "unknown pctype %u.",
> + fdir_input->pctype);
> + return -1;
> }
>
> /* fill the flexbytes to payload */
<snip>
> -----Original Message-----
> From: Sean Harte [mailto:seanbh@gmail.com]
> Sent: Friday, September 29, 2017 4:15 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 v6 6/8] net/i40e: add FDIR support for GTP-C
> and GTP-U
>
> On 29 September 2017 at 06:19, Beilei Xing <beilei.xing@intel.com> wrote:
> > This patch adds FDIR support for GTP-C and GTP-U. The input set of
> > GTP-C and GTP-U is TEID.
> >
> > Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> > ---
> > drivers/net/i40e/i40e_ethdev.h | 30 +++++
> > drivers/net/i40e/i40e_fdir.c | 200 ++++++++++++++++++++++---------
> > drivers/net/i40e/i40e_flow.c | 263
> +++++++++++++++++++++++++++++++++++------
> > 3 files changed, 396 insertions(+), 97 deletions(-)
>
> <snip>
>
> > @@ -1173,10 +1196,69 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf
> *pf,
> > rte_cpu_to_be_16(ETHER_TYPE_ARP))
> > payload += sizeof(struct arp_hdr);
> > set_idx = I40E_FLXPLD_L2_IDX;
> > - break;
> > - default:
> > - PMD_DRV_LOG(ERR, "unknown pctype %u.", fdir_input->pctype);
> > - return -EINVAL;
> > + } else if (fdir_input->flow_ext.customized_pctype) {
> > + /* If customized pctype is used */
> > + cus_pctype = i40e_flow_fdir_find_customized_pctype(pf, pctype);
> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPC ||
> > + cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV4 ||
> > + cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV6 ||
> > + cus_pctype->index == I40E_CUSTOMIZED_GTPU) {
> > + udp = (struct udp_hdr *)(raw_pkt + len);
> > + udp->dgram_len =
> > +
> > + rte_cpu_to_be_16(I40E_FDIR_UDP_DEFAULT_LEN);
> > +
> > + gtp = (struct rte_flow_item_gtp *)
> > + ((unsigned char *)udp + sizeof(struct udp_hdr));
> > + gtp->v_pt_rsv_flags = 0x30;
>
> 0x30 isn't valid for GTP-C, the sequence number must be present in GTP-C so
> it will be 0x32 or more. Is this byte actually matched against by the device
> using the GTP pctypes?
We construct packets and send the packet to HW to create flow director rule for GTP-C and
GTP-U. Actually I didn’t get error info with 0x30. And in my test, GTP-C packets can hit GTP-C
pctype rule. Will try 0x32 later.
>
> > + gtp->msg_len =
> > + rte_cpu_to_be_16(I40E_FDIR_GTP_DEFAULT_LEN);
> > + gtp->teid = fdir_input->flow.gtp_flow.teid;
> > + gtp->msg_type = 0x1;
>
> Why use this value?
Just for constructing a GTP packet to create a fdir rule for one pctype, can use other values except 0xFF.
>
> > +
> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPC)
> > + udp->dst_port =
> > + rte_cpu_to_be_16(2123);
>
> This will only match half of GTP-C messages. GTP-C messages have a UDP
> port destination of 2123, or a UDP source port of 2123. To match all GTP-C
> packets you need to look at both.
Yes. But the GTP profile for i40e didn't support response message.
>
> > + else
> > + udp->dst_port =
> > + rte_cpu_to_be_16(2152);
> > +
> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV4) {
> > + gtp->msg_type = 0xFF;
> > + gtp_ipv4 = (struct ipv4_hdr *)
> > + ((unsigned char *)gtp +
> > + sizeof(struct
> > + rte_flow_item_gtp));
>
> This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are allowed to have
> a sequence number, which adds an extra 4 bytes to the GTP header.
For the GTP profile, there're 4 pctypes for GTP packets: GTPC, GTPU, GTPIPV4, and GTPIPV6.
HW parse which pctype the GTP packets belonge to.
We construct packet to create a fdir rule for one pctype, after that, all packets whose
pctype matches the rule's pctype will hit the rule.
>
> > + gtp_ipv4->version_ihl =
> > + I40E_FDIR_IP_DEFAULT_VERSION_IHL;
> > + gtp_ipv4->next_proto_id = IPPROTO_IP;
> > + gtp_ipv4->total_length =
> > + rte_cpu_to_be_16(
> > + I40E_FDIR_INNER_IP_DEFAULT_LEN);
> > + payload = (unsigned char *)gtp_ipv4 +
> > + sizeof(struct ipv4_hdr);
> > + } else if (cus_pctype->index ==
> > + I40E_CUSTOMIZED_GTPU_IPV6) {
> > + gtp->msg_type = 0xFF;
> > + gtp_ipv6 = (struct ipv6_hdr *)
> > + ((unsigned char *)gtp +
> > + sizeof(struct
> > + rte_flow_item_gtp));
>
> This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are allowed to have
> a sequence number, which adds an extra 4 bytes to the GTP header.
Same with above.
>
> > + gtp_ipv6->vtc_flow =
> > + rte_cpu_to_be_32(
> > + I40E_FDIR_IPv6_DEFAULT_VTC_FLOW |
> > + (0 << I40E_FDIR_IPv6_TC_OFFSET));
> > + gtp_ipv6->proto = IPPROTO_NONE;
> > + gtp_ipv6->payload_len =
> > + rte_cpu_to_be_16(
> > + I40E_FDIR_INNER_IPv6_DEFAULT_LEN);
> > + gtp_ipv6->hop_limits =
> > + I40E_FDIR_IPv6_DEFAULT_HOP_LIMITS;
> > + payload = (unsigned char *)gtp_ipv6 +
> > + sizeof(struct ipv6_hdr);
> > + } else
> > + payload = (unsigned char *)gtp +
> > + sizeof(struct rte_flow_item_gtp);
> > + }
> > + } else {
> > + PMD_DRV_LOG(ERR, "unknown pctype %u.",
> > + fdir_input->pctype);
> > + return -1;
> > }
> >
> > /* fill the flexbytes to payload */
>
> <snip>
On 29 September 2017 at 10:33, Xing, Beilei <beilei.xing@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: Sean Harte [mailto:seanbh@gmail.com]
>> Sent: Friday, September 29, 2017 4:15 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 v6 6/8] net/i40e: add FDIR support for GTP-C
>> and GTP-U
>>
>> On 29 September 2017 at 06:19, Beilei Xing <beilei.xing@intel.com> wrote:
>> > This patch adds FDIR support for GTP-C and GTP-U. The input set of
>> > GTP-C and GTP-U is TEID.
>> >
>> > Signed-off-by: Beilei Xing <beilei.xing@intel.com>
>> > ---
>> > drivers/net/i40e/i40e_ethdev.h | 30 +++++
>> > drivers/net/i40e/i40e_fdir.c | 200 ++++++++++++++++++++++---------
>> > drivers/net/i40e/i40e_flow.c | 263
>> +++++++++++++++++++++++++++++++++++------
>> > 3 files changed, 396 insertions(+), 97 deletions(-)
>>
>> <snip>
>>
>> > @@ -1173,10 +1196,69 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf
>> *pf,
>> > rte_cpu_to_be_16(ETHER_TYPE_ARP))
>> > payload += sizeof(struct arp_hdr);
>> > set_idx = I40E_FLXPLD_L2_IDX;
>> > - break;
>> > - default:
>> > - PMD_DRV_LOG(ERR, "unknown pctype %u.", fdir_input->pctype);
>> > - return -EINVAL;
>> > + } else if (fdir_input->flow_ext.customized_pctype) {
>> > + /* If customized pctype is used */
>> > + cus_pctype = i40e_flow_fdir_find_customized_pctype(pf, pctype);
>> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPC ||
>> > + cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV4 ||
>> > + cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV6 ||
>> > + cus_pctype->index == I40E_CUSTOMIZED_GTPU) {
>> > + udp = (struct udp_hdr *)(raw_pkt + len);
>> > + udp->dgram_len =
>> > +
>> > + rte_cpu_to_be_16(I40E_FDIR_UDP_DEFAULT_LEN);
>> > +
>> > + gtp = (struct rte_flow_item_gtp *)
>> > + ((unsigned char *)udp + sizeof(struct udp_hdr));
>> > + gtp->v_pt_rsv_flags = 0x30;
>>
>> 0x30 isn't valid for GTP-C, the sequence number must be present in GTP-C so
>> it will be 0x32 or more. Is this byte actually matched against by the device
>> using the GTP pctypes?
>
> We construct packets and send the packet to HW to create flow director rule for GTP-C and
> GTP-U. Actually I didn’t get error info with 0x30. And in my test, GTP-C packets can hit GTP-C
> pctype rule. Will try 0x32 later.
>
>>
>> > + gtp->msg_len =
>> > + rte_cpu_to_be_16(I40E_FDIR_GTP_DEFAULT_LEN);
>> > + gtp->teid = fdir_input->flow.gtp_flow.teid;
>> > + gtp->msg_type = 0x1;
>>
>> Why use this value?
>
> Just for constructing a GTP packet to create a fdir rule for one pctype, can use other values except 0xFF.
>
>>
>> > +
>> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPC)
>> > + udp->dst_port =
>> > + rte_cpu_to_be_16(2123);
>>
>> This will only match half of GTP-C messages. GTP-C messages have a UDP
>> port destination of 2123, or a UDP source port of 2123. To match all GTP-C
>> packets you need to look at both.
>
> Yes. But the GTP profile for i40e didn't support response message.
That's not clear to a user of the rte_flow API
>
>>
>> > + else
>> > + udp->dst_port =
>> > + rte_cpu_to_be_16(2152);
>> > +
>> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV4) {
>> > + gtp->msg_type = 0xFF;
>> > + gtp_ipv4 = (struct ipv4_hdr *)
>> > + ((unsigned char *)gtp +
>> > + sizeof(struct
>> > + rte_flow_item_gtp));
>>
>> This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are allowed to have
>> a sequence number, which adds an extra 4 bytes to the GTP header.
>
> For the GTP profile, there're 4 pctypes for GTP packets: GTPC, GTPU, GTPIPV4, and GTPIPV6.
> HW parse which pctype the GTP packets belonge to.
> We construct packet to create a fdir rule for one pctype, after that, all packets whose
> pctype matches the rule's pctype will hit the rule.
My point is that you can only assume the inner IP header starts at an
offset of sizeof(struct rte_flow_item_gtp) if v_pt_rsv_flags is
exactly 0x30. If you match only those packets then some GTP-U packets
will not be matched. That should be clear to a user of the rte_flow
API.
>
>>
>> > + gtp_ipv4->version_ihl =
>> > + I40E_FDIR_IP_DEFAULT_VERSION_IHL;
>> > + gtp_ipv4->next_proto_id = IPPROTO_IP;
>> > + gtp_ipv4->total_length =
>> > + rte_cpu_to_be_16(
>> > + I40E_FDIR_INNER_IP_DEFAULT_LEN);
>> > + payload = (unsigned char *)gtp_ipv4 +
>> > + sizeof(struct ipv4_hdr);
>> > + } else if (cus_pctype->index ==
>> > + I40E_CUSTOMIZED_GTPU_IPV6) {
>> > + gtp->msg_type = 0xFF;
>> > + gtp_ipv6 = (struct ipv6_hdr *)
>> > + ((unsigned char *)gtp +
>> > + sizeof(struct
>> > + rte_flow_item_gtp));
>>
>> This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are allowed to have
>> a sequence number, which adds an extra 4 bytes to the GTP header.
>
> Same with above.
>
>>
>> > + gtp_ipv6->vtc_flow =
>> > + rte_cpu_to_be_32(
>> > + I40E_FDIR_IPv6_DEFAULT_VTC_FLOW |
>> > + (0 << I40E_FDIR_IPv6_TC_OFFSET));
>> > + gtp_ipv6->proto = IPPROTO_NONE;
>> > + gtp_ipv6->payload_len =
>> > + rte_cpu_to_be_16(
>> > + I40E_FDIR_INNER_IPv6_DEFAULT_LEN);
>> > + gtp_ipv6->hop_limits =
>> > + I40E_FDIR_IPv6_DEFAULT_HOP_LIMITS;
>> > + payload = (unsigned char *)gtp_ipv6 +
>> > + sizeof(struct ipv6_hdr);
>> > + } else
>> > + payload = (unsigned char *)gtp +
>> > + sizeof(struct rte_flow_item_gtp);
>> > + }
>> > + } else {
>> > + PMD_DRV_LOG(ERR, "unknown pctype %u.",
>> > + fdir_input->pctype);
>> > + return -1;
>> > }
>> >
>> > /* fill the flexbytes to payload */
>>
>> <snip>
> -----Original Message-----
> From: Sean Harte [mailto:seanbh@gmail.com]
> Sent: Friday, September 29, 2017 6:10 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 v6 6/8] net/i40e: add FDIR support for GTP-C
> and GTP-U
>
> On 29 September 2017 at 10:33, Xing, Beilei <beilei.xing@intel.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Sean Harte [mailto:seanbh@gmail.com]
> >> Sent: Friday, September 29, 2017 4:15 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 v6 6/8] net/i40e: add FDIR support for
> >> GTP-C and GTP-U
> >>
> >> On 29 September 2017 at 06:19, Beilei Xing <beilei.xing@intel.com> wrote:
> >> > This patch adds FDIR support for GTP-C and GTP-U. The input set of
> >> > GTP-C and GTP-U is TEID.
> >> >
> >> > Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> >> > ---
> >> > drivers/net/i40e/i40e_ethdev.h | 30 +++++
> >> > drivers/net/i40e/i40e_fdir.c | 200 ++++++++++++++++++++++---------
> >> > drivers/net/i40e/i40e_flow.c | 263
> >> +++++++++++++++++++++++++++++++++++------
> >> > 3 files changed, 396 insertions(+), 97 deletions(-)
> >>
> >> <snip>
> >>
> >> > @@ -1173,10 +1196,69 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf
> >> *pf,
> >> > rte_cpu_to_be_16(ETHER_TYPE_ARP))
> >> > payload += sizeof(struct arp_hdr);
> >> > set_idx = I40E_FLXPLD_L2_IDX;
> >> > - break;
> >> > - default:
> >> > - PMD_DRV_LOG(ERR, "unknown pctype %u.", fdir_input-
> >pctype);
> >> > - return -EINVAL;
> >> > + } else if (fdir_input->flow_ext.customized_pctype) {
> >> > + /* If customized pctype is used */
> >> > + cus_pctype = i40e_flow_fdir_find_customized_pctype(pf,
> pctype);
> >> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPC ||
> >> > + cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV4 ||
> >> > + cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV6 ||
> >> > + cus_pctype->index == I40E_CUSTOMIZED_GTPU) {
> >> > + udp = (struct udp_hdr *)(raw_pkt + len);
> >> > + udp->dgram_len =
> >> > +
> >> > + rte_cpu_to_be_16(I40E_FDIR_UDP_DEFAULT_LEN);
> >> > +
> >> > + gtp = (struct rte_flow_item_gtp *)
> >> > + ((unsigned char *)udp + sizeof(struct udp_hdr));
> >> > + gtp->v_pt_rsv_flags = 0x30;
> >>
> >> 0x30 isn't valid for GTP-C, the sequence number must be present in
> >> GTP-C so it will be 0x32 or more. Is this byte actually matched
> >> against by the device using the GTP pctypes?
> >
> > We construct packets and send the packet to HW to create flow
> > director rule for GTP-C and GTP-U. Actually I didn’t get error info
> > with 0x30. And in my test, GTP-C packets can hit GTP-C pctype rule. Will try
> 0x32 later.
> >
> >>
> >> > + gtp->msg_len =
> >> > + rte_cpu_to_be_16(I40E_FDIR_GTP_DEFAULT_LEN);
> >> > + gtp->teid = fdir_input->flow.gtp_flow.teid;
> >> > + gtp->msg_type = 0x1;
> >>
> >> Why use this value?
> >
> > Just for constructing a GTP packet to create a fdir rule for one pctype, can
> use other values except 0xFF.
> >
> >>
> >> > +
> >> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPC)
> >> > + udp->dst_port =
> >> > + rte_cpu_to_be_16(2123);
> >>
> >> This will only match half of GTP-C messages. GTP-C messages have a
> >> UDP port destination of 2123, or a UDP source port of 2123. To match
> >> all GTP-C packets you need to look at both.
> >
> > Yes. But the GTP profile for i40e didn't support response message.
>
> That's not clear to a user of the rte_flow API
Rte_flow is a generic API, I think it should allow users to create rule for response message.
But i40e PMD does not the support response message, if user want to create a rule for i40e like below:
Flow create 0 ingress pattern eth / ipv4 / udp src is 2123 / gtpc / end / actions queue index 4 / end
It will fail. But maybe other PMD can support it.
>
> >
> >>
> >> > + else
> >> > + udp->dst_port =
> >> > + rte_cpu_to_be_16(2152);
> >> > +
> >> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV4) {
> >> > + gtp->msg_type = 0xFF;
> >> > + gtp_ipv4 = (struct ipv4_hdr *)
> >> > + ((unsigned char *)gtp +
> >> > + sizeof(struct
> >> > + rte_flow_item_gtp));
> >>
> >> This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are
> >> allowed to have a sequence number, which adds an extra 4 bytes to the
> GTP header.
> >
> > For the GTP profile, there're 4 pctypes for GTP packets: GTPC, GTPU,
> GTPIPV4, and GTPIPV6.
> > HW parse which pctype the GTP packets belonge to.
> > We construct packet to create a fdir rule for one pctype, after that,
> > all packets whose pctype matches the rule's pctype will hit the rule.
>
> My point is that you can only assume the inner IP header starts at an offset
> of sizeof(struct rte_flow_item_gtp) if v_pt_rsv_flags is exactly 0x30. If you
> match only those packets then some GTP-U packets will not be matched.
> That should be clear to a user of the rte_flow API.
>
No matter if GTP-U packets has a sequence number, once message-type is 0xFF, the pctype
of the packet parsed by i40e HW will be GTPIPV4 or GTPIPV6.
So If I create a flow rule for GTP-U packets with v_pt_rsv_flags 0x30 and message_type is 0xFF,
it means I create a rule for pctype GTPIPV4 or GTPIPV6.
Then GTP-U packets with v_pt_rsv_flags 0x32 can hit the rule because its pctype is also GTPIPV4
or GTPIPV6.
It's just i40e HW's behavior, doesn't mean it's effective for other NICs.
Hope I explain it clearly:)
> >
> >>
> >> > + gtp_ipv4->version_ihl =
> >> > + I40E_FDIR_IP_DEFAULT_VERSION_IHL;
> >> > + gtp_ipv4->next_proto_id = IPPROTO_IP;
> >> > + gtp_ipv4->total_length =
> >> > + rte_cpu_to_be_16(
> >> > + I40E_FDIR_INNER_IP_DEFAULT_LEN);
> >> > + payload = (unsigned char *)gtp_ipv4 +
> >> > + sizeof(struct ipv4_hdr);
> >> > + } else if (cus_pctype->index ==
> >> > + I40E_CUSTOMIZED_GTPU_IPV6) {
> >> > + gtp->msg_type = 0xFF;
> >> > + gtp_ipv6 = (struct ipv6_hdr *)
> >> > + ((unsigned char *)gtp +
> >> > + sizeof(struct
> >> > + rte_flow_item_gtp));
> >>
> >> This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are
> >> allowed to have a sequence number, which adds an extra 4 bytes to the
> GTP header.
> >
> > Same with above.
> >
> >>
> >> > + gtp_ipv6->vtc_flow =
> >> > + rte_cpu_to_be_32(
> >> > + I40E_FDIR_IPv6_DEFAULT_VTC_FLOW |
> >> > + (0 << I40E_FDIR_IPv6_TC_OFFSET));
> >> > + gtp_ipv6->proto = IPPROTO_NONE;
> >> > + gtp_ipv6->payload_len =
> >> > + rte_cpu_to_be_16(
> >> > + I40E_FDIR_INNER_IPv6_DEFAULT_LEN);
> >> > + gtp_ipv6->hop_limits =
> >> > + I40E_FDIR_IPv6_DEFAULT_HOP_LIMITS;
> >> > + payload = (unsigned char *)gtp_ipv6 +
> >> > + sizeof(struct ipv6_hdr);
> >> > + } else
> >> > + payload = (unsigned char *)gtp +
> >> > + sizeof(struct rte_flow_item_gtp);
> >> > + }
> >> > + } else {
> >> > + PMD_DRV_LOG(ERR, "unknown pctype %u.",
> >> > + fdir_input->pctype);
> >> > + return -1;
> >> > }
> >> >
> >> > /* fill the flexbytes to payload */
> >>
> >> <snip>
> -----Original Message-----
> From: Xing, Beilei
> Sent: Friday, September 29, 2017 7:30 PM
> To: Sean Harte <seanbh@gmail.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; Chilikin, Andrey
> <andrey.chilikin@intel.com>; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v6 6/8] net/i40e: add FDIR support for GTP-C
> and GTP-U
>
>
>
> > -----Original Message-----
> > From: Sean Harte [mailto:seanbh@gmail.com]
> > Sent: Friday, September 29, 2017 6:10 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 v6 6/8] net/i40e: add FDIR support for
> > GTP-C and GTP-U
> >
> > On 29 September 2017 at 10:33, Xing, Beilei <beilei.xing@intel.com>
> wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Sean Harte [mailto:seanbh@gmail.com]
> > >> Sent: Friday, September 29, 2017 4:15 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 v6 6/8] net/i40e: add FDIR support
> > >> for GTP-C and GTP-U
> > >>
> > >> On 29 September 2017 at 06:19, Beilei Xing <beilei.xing@intel.com>
> wrote:
> > >> > This patch adds FDIR support for GTP-C and GTP-U. The input set
> > >> > of GTP-C and GTP-U is TEID.
> > >> >
> > >> > Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> > >> > ---
> > >> > drivers/net/i40e/i40e_ethdev.h | 30 +++++
> > >> > drivers/net/i40e/i40e_fdir.c | 200
> ++++++++++++++++++++++---------
> > >> > drivers/net/i40e/i40e_flow.c | 263
> > >> +++++++++++++++++++++++++++++++++++------
> > >> > 3 files changed, 396 insertions(+), 97 deletions(-)
> > >>
> > >> <snip>
> > >>
> > >> > @@ -1173,10 +1196,69 @@ i40e_flow_fdir_construct_pkt(struct
> > >> > i40e_pf
> > >> *pf,
> > >> >
> rte_cpu_to_be_16(ETHER_TYPE_ARP))
> > >> > payload += sizeof(struct arp_hdr);
> > >> > set_idx = I40E_FLXPLD_L2_IDX;
> > >> > - break;
> > >> > - default:
> > >> > - PMD_DRV_LOG(ERR, "unknown pctype %u.",
> fdir_input-
> > >pctype);
> > >> > - return -EINVAL;
> > >> > + } else if (fdir_input->flow_ext.customized_pctype) {
> > >> > + /* If customized pctype is used */
> > >> > + cus_pctype =
> > >> > + i40e_flow_fdir_find_customized_pctype(pf,
> > pctype);
> > >> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPC
> ||
> > >> > + cus_pctype->index ==
> I40E_CUSTOMIZED_GTPU_IPV4 ||
> > >> > + cus_pctype->index ==
> I40E_CUSTOMIZED_GTPU_IPV6 ||
> > >> > + cus_pctype->index ==
> I40E_CUSTOMIZED_GTPU) {
> > >> > + udp = (struct udp_hdr *)(raw_pkt + len);
> > >> > + udp->dgram_len =
> > >> > +
> > >> > + rte_cpu_to_be_16(I40E_FDIR_UDP_DEFAULT_LEN);
> > >> > +
> > >> > + gtp = (struct rte_flow_item_gtp *)
> > >> > + ((unsigned char *)udp +
> sizeof(struct udp_hdr));
> > >> > + gtp->v_pt_rsv_flags = 0x30;
> > >>
> > >> 0x30 isn't valid for GTP-C, the sequence number must be present in
> > >> GTP-C so it will be 0x32 or more. Is this byte actually matched
> > >> against by the device using the GTP pctypes?
> > >
> > > We construct packets and send the packet to HW to create flow
> > > director rule for GTP-C and GTP-U. Actually I didn’t get error info
> > > with 0x30. And in my test, GTP-C packets can hit GTP-C pctype rule.
> > > Will try
> > 0x32 later.
> > >
> > >>
> > >> > + gtp->msg_len =
> > >> > +
> rte_cpu_to_be_16(I40E_FDIR_GTP_DEFAULT_LEN);
> > >> > + gtp->teid =
> fdir_input->flow.gtp_flow.teid;
> > >> > + gtp->msg_type = 0x1;
> > >>
> > >> Why use this value?
> > >
> > > Just for constructing a GTP packet to create a fdir rule for one
> > > pctype, can
> > use other values except 0xFF.
> > >
> > >>
> > >> > +
> > >> > + if (cus_pctype->index ==
> I40E_CUSTOMIZED_GTPC)
> > >> > + udp->dst_port =
> > >> > + rte_cpu_to_be_16(2123);
> > >>
> > >> This will only match half of GTP-C messages. GTP-C messages have a
> > >> UDP port destination of 2123, or a UDP source port of 2123. To
> > >> match all GTP-C packets you need to look at both.
> > >
> > > Yes. But the GTP profile for i40e didn't support response message.
> >
> > That's not clear to a user of the rte_flow API
>
> Rte_flow is a generic API, I think it should allow users to create rule for
> response message.
> But i40e PMD does not the support response message, if user want to create
> a rule for i40e like below:
> Flow create 0 ingress pattern eth / ipv4 / udp src is 2123 / gtpc / end /
> actions queue index 4 / end It will fail. But maybe other PMD can support it.
>
> >
> > >
> > >>
> > >> > + else
> > >> > + udp->dst_port =
> > >> > + rte_cpu_to_be_16(2152);
> > >> > +
> > >> > + if (cus_pctype->index ==
> I40E_CUSTOMIZED_GTPU_IPV4) {
> > >> > + gtp->msg_type = 0xFF;
> > >> > + gtp_ipv4 = (struct ipv4_hdr *)
> > >> > + ((unsigned char *)gtp
> +
> > >> > + sizeof(struct
> > >> > + rte_flow_item_gtp));
> > >>
> > >> This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are
> > >> allowed to have a sequence number, which adds an extra 4 bytes to
> > >> the
> > GTP header.
> > >
> > > For the GTP profile, there're 4 pctypes for GTP packets: GTPC, GTPU,
> > GTPIPV4, and GTPIPV6.
> > > HW parse which pctype the GTP packets belonge to.
> > > We construct packet to create a fdir rule for one pctype, after
> > > that, all packets whose pctype matches the rule's pctype will hit the rule.
> >
> > My point is that you can only assume the inner IP header starts at an
> > offset of sizeof(struct rte_flow_item_gtp) if v_pt_rsv_flags is
> > exactly 0x30. If you match only those packets then some GTP-U packets
> will not be matched.
> > That should be clear to a user of the rte_flow API.
> >
>
> No matter if GTP-U packets has a sequence number, once message-type is
> 0xFF, the pctype of the packet parsed by i40e HW will be GTPIPV4 or
> GTPIPV6.
> So If I create a flow rule for GTP-U packets with v_pt_rsv_flags 0x30 and
> message_type is 0xFF, it means I create a rule for pctype GTPIPV4 or
> GTPIPV6.
> Then GTP-U packets with v_pt_rsv_flags 0x32 can hit the rule because its
> pctype is also GTPIPV4 or GTPIPV6.
> It's just i40e HW's behavior, doesn't mean it's effective for other NICs.
> Hope I explain it clearly:)
>
The key point is : for i40e HW, different packet types can use the same pctype.
> > >
> > >>
> > >> > + gtp_ipv4->version_ihl =
> > >> > +
> I40E_FDIR_IP_DEFAULT_VERSION_IHL;
> > >> > + gtp_ipv4->next_proto_id =
> IPPROTO_IP;
> > >> > + gtp_ipv4->total_length =
> > >> > + rte_cpu_to_be_16(
> > >> > +
> I40E_FDIR_INNER_IP_DEFAULT_LEN);
> > >> > + payload = (unsigned char
> *)gtp_ipv4 +
> > >> > + sizeof(struct
> ipv4_hdr);
> > >> > + } else if (cus_pctype->index ==
> > >> > +
> I40E_CUSTOMIZED_GTPU_IPV6) {
> > >> > + gtp->msg_type = 0xFF;
> > >> > + gtp_ipv6 = (struct ipv6_hdr *)
> > >> > + ((unsigned char *)gtp
> +
> > >> > + sizeof(struct
> > >> > + rte_flow_item_gtp));
> > >>
> > >> This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are
> > >> allowed to have a sequence number, which adds an extra 4 bytes to
> > >> the
> > GTP header.
> > >
> > > Same with above.
> > >
> > >>
> > >> > + gtp_ipv6->vtc_flow =
> > >> > + rte_cpu_to_be_32(
> > >> > +
> I40E_FDIR_IPv6_DEFAULT_VTC_FLOW |
> > >> > + (0 <<
> I40E_FDIR_IPv6_TC_OFFSET));
> > >> > + gtp_ipv6->proto =
> IPPROTO_NONE;
> > >> > + gtp_ipv6->payload_len =
> > >> > + rte_cpu_to_be_16(
> > >> > +
> I40E_FDIR_INNER_IPv6_DEFAULT_LEN);
> > >> > + gtp_ipv6->hop_limits =
> > >> > +
> I40E_FDIR_IPv6_DEFAULT_HOP_LIMITS;
> > >> > + payload = (unsigned char
> *)gtp_ipv6 +
> > >> > + sizeof(struct
> ipv6_hdr);
> > >> > + } else
> > >> > + payload = (unsigned char *)gtp
> +
> > >> > + sizeof(struct
> rte_flow_item_gtp);
> > >> > + }
> > >> > + } else {
> > >> > + PMD_DRV_LOG(ERR, "unknown pctype %u.",
> > >> > + fdir_input->pctype);
> > >> > + return -1;
> > >> > }
> > >> >
> > >> > /* fill the flexbytes to payload */
> > >>
> > >> <snip>
> -----Original Message-----
> From: Sean Harte [mailto:seanbh@gmail.com]
> Sent: Friday, September 29, 2017 6:10 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 v6 6/8] net/i40e: add FDIR support for GTP-C
> and GTP-U
>
> On 29 September 2017 at 10:33, Xing, Beilei <beilei.xing@intel.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Sean Harte [mailto:seanbh@gmail.com]
> >> Sent: Friday, September 29, 2017 4:15 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 v6 6/8] net/i40e: add FDIR support for
> >> GTP-C and GTP-U
> >>
> >> On 29 September 2017 at 06:19, Beilei Xing <beilei.xing@intel.com>
> wrote:
> >> > This patch adds FDIR support for GTP-C and GTP-U. The input set of
> >> > GTP-C and GTP-U is TEID.
> >> >
> >> > Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> >> > ---
> >> > drivers/net/i40e/i40e_ethdev.h | 30 +++++
> >> > drivers/net/i40e/i40e_fdir.c | 200
> ++++++++++++++++++++++---------
> >> > drivers/net/i40e/i40e_flow.c | 263
> >> +++++++++++++++++++++++++++++++++++------
> >> > 3 files changed, 396 insertions(+), 97 deletions(-)
> >>
> >> <snip>
> >>
> >> > @@ -1173,10 +1196,69 @@ i40e_flow_fdir_construct_pkt(struct
> i40e_pf
> >> *pf,
> >> >
> rte_cpu_to_be_16(ETHER_TYPE_ARP))
> >> > payload += sizeof(struct arp_hdr);
> >> > set_idx = I40E_FLXPLD_L2_IDX;
> >> > - break;
> >> > - default:
> >> > - PMD_DRV_LOG(ERR, "unknown pctype %u.",
> fdir_input->pctype);
> >> > - return -EINVAL;
> >> > + } else if (fdir_input->flow_ext.customized_pctype) {
> >> > + /* If customized pctype is used */
> >> > + cus_pctype =
> i40e_flow_fdir_find_customized_pctype(pf, pctype);
> >> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPC
> ||
> >> > + cus_pctype->index ==
> I40E_CUSTOMIZED_GTPU_IPV4 ||
> >> > + cus_pctype->index ==
> I40E_CUSTOMIZED_GTPU_IPV6 ||
> >> > + cus_pctype->index ==
> I40E_CUSTOMIZED_GTPU) {
> >> > + udp = (struct udp_hdr *)(raw_pkt + len);
> >> > + udp->dgram_len =
> >> > +
> >> > + rte_cpu_to_be_16(I40E_FDIR_UDP_DEFAULT_LEN);
> >> > +
> >> > + gtp = (struct rte_flow_item_gtp *)
> >> > + ((unsigned char *)udp +
> sizeof(struct udp_hdr));
> >> > + gtp->v_pt_rsv_flags = 0x30;
> >>
> >> 0x30 isn't valid for GTP-C, the sequence number must be present in
> >> GTP-C so it will be 0x32 or more. Is this byte actually matched
> >> against by the device using the GTP pctypes?
> >
> > We construct packets and send the packet to HW to create flow
> > director rule for GTP-C and GTP-U. Actually I didn’t get error info
> > with 0x30. And in my test, GTP-C packets can hit GTP-C pctype rule. Will
> try 0x32 later.
> >
> >>
> >> > + gtp->msg_len =
> >> > +
> rte_cpu_to_be_16(I40E_FDIR_GTP_DEFAULT_LEN);
> >> > + gtp->teid =
> fdir_input->flow.gtp_flow.teid;
> >> > + gtp->msg_type = 0x1;
> >>
> >> Why use this value?
> >
> > Just for constructing a GTP packet to create a fdir rule for one pctype, can
> use other values except 0xFF.
> >
> >>
> >> > +
> >> > + if (cus_pctype->index ==
> I40E_CUSTOMIZED_GTPC)
> >> > + udp->dst_port =
> >> > + rte_cpu_to_be_16(2123);
> >>
> >> This will only match half of GTP-C messages. GTP-C messages have a
> >> UDP port destination of 2123, or a UDP source port of 2123. To match
> >> all GTP-C packets you need to look at both.
> >
> > Yes. But the GTP profile for i40e didn't support response message.
>
> That's not clear to a user of the rte_flow API
I will clarify some limitation in parsing function description.
>
> >
> >>
> >> > + else
> >> > + udp->dst_port =
> >> > + rte_cpu_to_be_16(2152);
> >> > +
> >> > + if (cus_pctype->index ==
> I40E_CUSTOMIZED_GTPU_IPV4) {
> >> > + gtp->msg_type = 0xFF;
> >> > + gtp_ipv4 = (struct ipv4_hdr *)
> >> > + ((unsigned char *)gtp +
> >> > + sizeof(struct
> >> > + rte_flow_item_gtp));
> >>
> >> This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are
> >> allowed to have a sequence number, which adds an extra 4 bytes to the
> GTP header.
> >
> > For the GTP profile, there're 4 pctypes for GTP packets: GTPC, GTPU,
> GTPIPV4, and GTPIPV6.
> > HW parse which pctype the GTP packets belonge to.
> > We construct packet to create a fdir rule for one pctype, after that,
> > all packets whose pctype matches the rule's pctype will hit the rule.
>
> My point is that you can only assume the inner IP header starts at an offset
> of sizeof(struct rte_flow_item_gtp) if v_pt_rsv_flags is exactly 0x30. If you
> match only those packets then some GTP-U packets will not be matched.
> That should be clear to a user of the rte_flow API.
>
> >
> >>
> >> > + gtp_ipv4->version_ihl =
> >> > +
> I40E_FDIR_IP_DEFAULT_VERSION_IHL;
> >> > + gtp_ipv4->next_proto_id =
> IPPROTO_IP;
> >> > + gtp_ipv4->total_length =
> >> > + rte_cpu_to_be_16(
> >> > +
> I40E_FDIR_INNER_IP_DEFAULT_LEN);
> >> > + payload = (unsigned char
> *)gtp_ipv4 +
> >> > + sizeof(struct
> ipv4_hdr);
> >> > + } else if (cus_pctype->index ==
> >> > +
> I40E_CUSTOMIZED_GTPU_IPV6) {
> >> > + gtp->msg_type = 0xFF;
> >> > + gtp_ipv6 = (struct ipv6_hdr *)
> >> > + ((unsigned char *)gtp +
> >> > + sizeof(struct
> >> > + rte_flow_item_gtp));
> >>
> >> This is only valid if v_pt_rsv_flags is 0x30. GTP-U packets are
> >> allowed to have a sequence number, which adds an extra 4 bytes to the
> GTP header.
> >
> > Same with above.
> >
> >>
> >> > + gtp_ipv6->vtc_flow =
> >> > + rte_cpu_to_be_32(
> >> > +
> I40E_FDIR_IPv6_DEFAULT_VTC_FLOW |
> >> > + (0 <<
> I40E_FDIR_IPv6_TC_OFFSET));
> >> > + gtp_ipv6->proto =
> IPPROTO_NONE;
> >> > + gtp_ipv6->payload_len =
> >> > + rte_cpu_to_be_16(
> >> > +
> I40E_FDIR_INNER_IPv6_DEFAULT_LEN);
> >> > + gtp_ipv6->hop_limits =
> >> > +
> I40E_FDIR_IPv6_DEFAULT_HOP_LIMITS;
> >> > + payload = (unsigned char
> *)gtp_ipv6 +
> >> > + sizeof(struct
> ipv6_hdr);
> >> > + } else
> >> > + payload = (unsigned char *)gtp +
> >> > + sizeof(struct
> rte_flow_item_gtp);
> >> > + }
> >> > + } else {
> >> > + PMD_DRV_LOG(ERR, "unknown pctype %u.",
> >> > + fdir_input->pctype);
> >> > + return -1;
> >> > }
> >> >
> >> > /* fill the flexbytes to payload */
> >>
> >> <snip>
> -----Original Message-----
> From: Sean Harte [mailto:seanbh@gmail.com]
> Sent: Friday, September 29, 2017 6:10 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 v6 6/8] net/i40e: add FDIR support for GTP-C
> and GTP-U
>
> On 29 September 2017 at 10:33, Xing, Beilei <beilei.xing@intel.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Sean Harte [mailto:seanbh@gmail.com]
> >> Sent: Friday, September 29, 2017 4:15 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 v6 6/8] net/i40e: add FDIR support for
> >> GTP-C and GTP-U
> >>
> >> On 29 September 2017 at 06:19, Beilei Xing <beilei.xing@intel.com>
> wrote:
> >> > This patch adds FDIR support for GTP-C and GTP-U. The input set of
> >> > GTP-C and GTP-U is TEID.
> >> >
> >> > Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> >> > ---
> >> > drivers/net/i40e/i40e_ethdev.h | 30 +++++
> >> > drivers/net/i40e/i40e_fdir.c | 200
> ++++++++++++++++++++++---------
> >> > drivers/net/i40e/i40e_flow.c | 263
> >> +++++++++++++++++++++++++++++++++++------
> >> > 3 files changed, 396 insertions(+), 97 deletions(-)
> >>
> >> <snip>
> >>
> >> > @@ -1173,10 +1196,69 @@ i40e_flow_fdir_construct_pkt(struct
> i40e_pf
> >> *pf,
> >> >
> rte_cpu_to_be_16(ETHER_TYPE_ARP))
> >> > payload += sizeof(struct arp_hdr);
> >> > set_idx = I40E_FLXPLD_L2_IDX;
> >> > - break;
> >> > - default:
> >> > - PMD_DRV_LOG(ERR, "unknown pctype %u.",
> fdir_input->pctype);
> >> > - return -EINVAL;
> >> > + } else if (fdir_input->flow_ext.customized_pctype) {
> >> > + /* If customized pctype is used */
> >> > + cus_pctype =
> i40e_flow_fdir_find_customized_pctype(pf, pctype);
> >> > + if (cus_pctype->index == I40E_CUSTOMIZED_GTPC
> ||
> >> > + cus_pctype->index ==
> I40E_CUSTOMIZED_GTPU_IPV4 ||
> >> > + cus_pctype->index ==
> I40E_CUSTOMIZED_GTPU_IPV6 ||
> >> > + cus_pctype->index ==
> I40E_CUSTOMIZED_GTPU) {
> >> > + udp = (struct udp_hdr *)(raw_pkt + len);
> >> > + udp->dgram_len =
> >> > +
> >> > + rte_cpu_to_be_16(I40E_FDIR_UDP_DEFAULT_LEN);
> >> > +
> >> > + gtp = (struct rte_flow_item_gtp *)
> >> > + ((unsigned char *)udp +
> sizeof(struct udp_hdr));
> >> > + gtp->v_pt_rsv_flags = 0x30;
> >>
> >> 0x30 isn't valid for GTP-C, the sequence number must be present in
> >> GTP-C so it will be 0x32 or more. Is this byte actually matched
> >> against by the device using the GTP pctypes?
> >
> > We construct packets and send the packet to HW to create flow
> > director rule for GTP-C and GTP-U. Actually I didn’t get error info
> > with 0x30. And in my test, GTP-C packets can hit GTP-C pctype rule. Will
> try 0x32 later.
I checked with 0x32 for GTP-C, it works well. I will change to use 0x32 for GTP-C.
For GTP-U, for i40e, I will keep 0x30 for GTP-U since different GTP-U packet types
can match the same pctype.
Thanks for your all your comments.
Beilei
@@ -460,6 +460,25 @@ struct i40e_vmdq_info {
#define I40E_FLEX_WORD_MASK(off) (0x80 >> (off))
#define I40E_FDIR_IPv6_TC_OFFSET 20
+/* A structure used to define the input for GTP flow */
+struct i40e_gtp_flow {
+ struct rte_eth_udpv4_flow udp; /* IPv4 UDP fields to match. */
+ uint8_t msg_type; /* Message type. */
+ uint32_t teid; /* TEID in big endian. */
+};
+
+/* A structure used to define the input for GTP IPV4 flow */
+struct i40e_gtp_ipv4_flow {
+ struct i40e_gtp_flow gtp;
+ struct rte_eth_ipv4_flow ip4;
+};
+
+/* A structure used to define the input for GTP IPV6 flow */
+struct i40e_gtp_ipv6_flow {
+ struct i40e_gtp_flow gtp;
+ struct rte_eth_ipv6_flow ip6;
+};
+
/*
* A union contains the inputs for all types of flow
* items in flows need to be in big endian
@@ -474,6 +493,14 @@ union i40e_fdir_flow {
struct rte_eth_tcpv6_flow tcp6_flow;
struct rte_eth_sctpv6_flow sctp6_flow;
struct rte_eth_ipv6_flow ipv6_flow;
+ struct i40e_gtp_flow gtp_flow;
+ struct i40e_gtp_ipv4_flow gtp_ipv4_flow;
+ struct i40e_gtp_ipv6_flow gtp_ipv6_flow;
+};
+
+enum i40e_fdir_ip_type {
+ I40E_FDIR_IPTYPE_IPV4,
+ I40E_FDIR_IPTYPE_IPV6,
};
/* A structure used to contain extend input of flow */
@@ -483,6 +510,9 @@ struct i40e_fdir_flow_ext {
/* It is filled by the flexible payload to match. */
uint8_t is_vf; /* 1 for VF, 0 for port dev */
uint16_t dst_id; /* VF ID, available when is_vf is 1*/
+ bool inner_ip; /* If there is inner ip */
+ enum i40e_fdir_ip_type iip_type; /* ip type for inner ip */
+ bool customized_pctype; /* If customized pctype is used */
};
/* A structure used to define the input for a flow director filter entry */
@@ -71,6 +71,9 @@
#define I40E_FDIR_IPv6_DEFAULT_HOP_LIMITS 0xFF
#define I40E_FDIR_IPv6_PAYLOAD_LEN 380
#define I40E_FDIR_UDP_DEFAULT_LEN 400
+#define I40E_FDIR_GTP_DEFAULT_LEN 384
+#define I40E_FDIR_INNER_IP_DEFAULT_LEN 384
+#define I40E_FDIR_INNER_IPv6_DEFAULT_LEN 344
/* Wait time for fdir filter programming */
#define I40E_FDIR_MAX_WAIT_US 10000
@@ -939,16 +942,34 @@ i40e_fdir_construct_pkt(struct i40e_pf *pf,
return 0;
}
+static struct i40e_customized_pctype *
+i40e_flow_fdir_find_customized_pctype(struct i40e_pf *pf, uint8_t pctype)
+{
+ struct i40e_customized_pctype *cus_pctype;
+ enum i40e_new_pctype i = I40E_CUSTOMIZED_GTPC;
+
+ for (; i < I40E_CUSTOMIZED_MAX; i++) {
+ cus_pctype = &pf->customized_pctype[i];
+ if (pctype == cus_pctype->pctype)
+ return cus_pctype;
+ }
+ return NULL;
+}
+
static inline int
-i40e_flow_fdir_fill_eth_ip_head(const struct i40e_fdir_input *fdir_input,
+i40e_flow_fdir_fill_eth_ip_head(struct i40e_pf *pf,
+ const struct i40e_fdir_input *fdir_input,
unsigned char *raw_pkt,
bool vlan)
{
+ struct i40e_customized_pctype *cus_pctype = NULL;
static uint8_t vlan_frame[] = {0x81, 0, 0, 0};
uint16_t *ether_type;
uint8_t len = 2 * sizeof(struct ether_addr);
struct ipv4_hdr *ip;
struct ipv6_hdr *ip6;
+ uint8_t pctype = fdir_input->pctype;
+ bool is_customized_pctype = fdir_input->flow_ext.customized_pctype;
static const uint8_t next_proto[] = {
[I40E_FILTER_PCTYPE_FRAG_IPV4] = IPPROTO_IP,
[I40E_FILTER_PCTYPE_NONF_IPV4_TCP] = IPPROTO_TCP,
@@ -975,27 +996,30 @@ i40e_flow_fdir_fill_eth_ip_head(const struct i40e_fdir_input *fdir_input,
raw_pkt += sizeof(uint16_t);
len += sizeof(uint16_t);
- switch (fdir_input->pctype) {
- case I40E_FILTER_PCTYPE_L2_PAYLOAD:
+ if (is_customized_pctype) {
+ cus_pctype = i40e_flow_fdir_find_customized_pctype(pf, pctype);
+ if (!cus_pctype)
+ PMD_DRV_LOG(ERR, "unknown pctype %u.",
+ fdir_input->pctype);
+ }
+
+ if (pctype == I40E_FILTER_PCTYPE_L2_PAYLOAD)
*ether_type = fdir_input->flow.l2_flow.ether_type;
- break;
- case I40E_FILTER_PCTYPE_NONF_IPV4_TCP:
- case I40E_FILTER_PCTYPE_NONF_IPV4_UDP:
- case I40E_FILTER_PCTYPE_NONF_IPV4_SCTP:
- case I40E_FILTER_PCTYPE_NONF_IPV4_OTHER:
- case I40E_FILTER_PCTYPE_FRAG_IPV4:
+ else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV4_TCP ||
+ pctype == I40E_FILTER_PCTYPE_NONF_IPV4_UDP ||
+ pctype == I40E_FILTER_PCTYPE_NONF_IPV4_SCTP ||
+ pctype == I40E_FILTER_PCTYPE_NONF_IPV4_OTHER ||
+ pctype == I40E_FILTER_PCTYPE_FRAG_IPV4 ||
+ is_customized_pctype) {
ip = (struct ipv4_hdr *)raw_pkt;
*ether_type = rte_cpu_to_be_16(ETHER_TYPE_IPv4);
ip->version_ihl = I40E_FDIR_IP_DEFAULT_VERSION_IHL;
/* set len to by default */
ip->total_length = rte_cpu_to_be_16(I40E_FDIR_IP_DEFAULT_LEN);
- ip->next_proto_id = fdir_input->flow.ip4_flow.proto ?
- fdir_input->flow.ip4_flow.proto :
- next_proto[fdir_input->pctype];
ip->time_to_live = fdir_input->flow.ip4_flow.ttl ?
- fdir_input->flow.ip4_flow.ttl :
- I40E_FDIR_IP_DEFAULT_TTL;
+ fdir_input->flow.ip4_flow.ttl :
+ I40E_FDIR_IP_DEFAULT_TTL;
ip->type_of_service = fdir_input->flow.ip4_flow.tos;
/**
* The source and destination fields in the transmitted packet
@@ -1004,13 +1028,22 @@ i40e_flow_fdir_fill_eth_ip_head(const struct i40e_fdir_input *fdir_input,
*/
ip->src_addr = fdir_input->flow.ip4_flow.dst_ip;
ip->dst_addr = fdir_input->flow.ip4_flow.src_ip;
+
+ if (!is_customized_pctype)
+ ip->next_proto_id = fdir_input->flow.ip4_flow.proto ?
+ fdir_input->flow.ip4_flow.proto :
+ next_proto[fdir_input->pctype];
+ else if (cus_pctype->index == I40E_CUSTOMIZED_GTPC ||
+ cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV4 ||
+ cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV6 ||
+ cus_pctype->index == I40E_CUSTOMIZED_GTPU)
+ ip->next_proto_id = IPPROTO_UDP;
len += sizeof(struct ipv4_hdr);
- break;
- case I40E_FILTER_PCTYPE_NONF_IPV6_TCP:
- case I40E_FILTER_PCTYPE_NONF_IPV6_UDP:
- case I40E_FILTER_PCTYPE_NONF_IPV6_SCTP:
- case I40E_FILTER_PCTYPE_NONF_IPV6_OTHER:
- case I40E_FILTER_PCTYPE_FRAG_IPV6:
+ } else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV6_TCP ||
+ pctype == I40E_FILTER_PCTYPE_NONF_IPV6_UDP ||
+ pctype == I40E_FILTER_PCTYPE_NONF_IPV6_SCTP ||
+ pctype == I40E_FILTER_PCTYPE_NONF_IPV6_OTHER ||
+ pctype == I40E_FILTER_PCTYPE_FRAG_IPV6) {
ip6 = (struct ipv6_hdr *)raw_pkt;
*ether_type = rte_cpu_to_be_16(ETHER_TYPE_IPv6);
@@ -1021,11 +1054,11 @@ i40e_flow_fdir_fill_eth_ip_head(const struct i40e_fdir_input *fdir_input,
ip6->payload_len =
rte_cpu_to_be_16(I40E_FDIR_IPv6_PAYLOAD_LEN);
ip6->proto = fdir_input->flow.ipv6_flow.proto ?
- fdir_input->flow.ipv6_flow.proto :
- next_proto[fdir_input->pctype];
+ fdir_input->flow.ipv6_flow.proto :
+ next_proto[fdir_input->pctype];
ip6->hop_limits = fdir_input->flow.ipv6_flow.hop_limits ?
- fdir_input->flow.ipv6_flow.hop_limits :
- I40E_FDIR_IPv6_DEFAULT_HOP_LIMITS;
+ fdir_input->flow.ipv6_flow.hop_limits :
+ I40E_FDIR_IPv6_DEFAULT_HOP_LIMITS;
/**
* The source and destination fields in the transmitted packet
* need to be presented in a reversed order with respect
@@ -1038,12 +1071,12 @@ i40e_flow_fdir_fill_eth_ip_head(const struct i40e_fdir_input *fdir_input,
&fdir_input->flow.ipv6_flow.src_ip,
IPV6_ADDR_LEN);
len += sizeof(struct ipv6_hdr);
- break;
- default:
+ } else {
PMD_DRV_LOG(ERR, "unknown pctype %u.",
fdir_input->pctype);
return -1;
}
+
return len;
}
@@ -1058,23 +1091,28 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf *pf,
const struct i40e_fdir_input *fdir_input,
unsigned char *raw_pkt)
{
- unsigned char *payload, *ptr;
+ unsigned char *payload = NULL;
+ unsigned char *ptr;
struct udp_hdr *udp;
struct tcp_hdr *tcp;
struct sctp_hdr *sctp;
+ struct rte_flow_item_gtp *gtp;
+ struct ipv4_hdr *gtp_ipv4;
+ struct ipv6_hdr *gtp_ipv6;
uint8_t size, dst = 0;
uint8_t i, pit_idx, set_idx = I40E_FLXPLD_L4_IDX; /* use l4 by default*/
int len;
+ uint8_t pctype = fdir_input->pctype;
+ struct i40e_customized_pctype *cus_pctype;
/* fill the ethernet and IP head */
- len = i40e_flow_fdir_fill_eth_ip_head(fdir_input, raw_pkt,
+ len = i40e_flow_fdir_fill_eth_ip_head(pf, fdir_input, raw_pkt,
!!fdir_input->flow_ext.vlan_tci);
if (len < 0)
return -EINVAL;
/* fill the L4 head */
- switch (fdir_input->pctype) {
- case I40E_FILTER_PCTYPE_NONF_IPV4_UDP:
+ if (pctype == I40E_FILTER_PCTYPE_NONF_IPV4_UDP) {
udp = (struct udp_hdr *)(raw_pkt + len);
payload = (unsigned char *)udp + sizeof(struct udp_hdr);
/**
@@ -1085,9 +1123,7 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf *pf,
udp->src_port = fdir_input->flow.udp4_flow.dst_port;
udp->dst_port = fdir_input->flow.udp4_flow.src_port;
udp->dgram_len = rte_cpu_to_be_16(I40E_FDIR_UDP_DEFAULT_LEN);
- break;
-
- case I40E_FILTER_PCTYPE_NONF_IPV4_TCP:
+ } else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV4_TCP) {
tcp = (struct tcp_hdr *)(raw_pkt + len);
payload = (unsigned char *)tcp + sizeof(struct tcp_hdr);
/**
@@ -1098,9 +1134,7 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf *pf,
tcp->src_port = fdir_input->flow.tcp4_flow.dst_port;
tcp->dst_port = fdir_input->flow.tcp4_flow.src_port;
tcp->data_off = I40E_FDIR_TCP_DEFAULT_DATAOFF;
- break;
-
- case I40E_FILTER_PCTYPE_NONF_IPV4_SCTP:
+ } else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV4_SCTP) {
sctp = (struct sctp_hdr *)(raw_pkt + len);
payload = (unsigned char *)sctp + sizeof(struct sctp_hdr);
/**
@@ -1111,15 +1145,11 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf *pf,
sctp->src_port = fdir_input->flow.sctp4_flow.dst_port;
sctp->dst_port = fdir_input->flow.sctp4_flow.src_port;
sctp->tag = fdir_input->flow.sctp4_flow.verify_tag;
- break;
-
- case I40E_FILTER_PCTYPE_NONF_IPV4_OTHER:
- case I40E_FILTER_PCTYPE_FRAG_IPV4:
+ } else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV4_OTHER ||
+ pctype == I40E_FILTER_PCTYPE_FRAG_IPV4) {
payload = raw_pkt + len;
set_idx = I40E_FLXPLD_L3_IDX;
- break;
-
- case I40E_FILTER_PCTYPE_NONF_IPV6_UDP:
+ } else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV6_UDP) {
udp = (struct udp_hdr *)(raw_pkt + len);
payload = (unsigned char *)udp + sizeof(struct udp_hdr);
/**
@@ -1130,9 +1160,7 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf *pf,
udp->src_port = fdir_input->flow.udp6_flow.dst_port;
udp->dst_port = fdir_input->flow.udp6_flow.src_port;
udp->dgram_len = rte_cpu_to_be_16(I40E_FDIR_IPv6_PAYLOAD_LEN);
- break;
-
- case I40E_FILTER_PCTYPE_NONF_IPV6_TCP:
+ } else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV6_TCP) {
tcp = (struct tcp_hdr *)(raw_pkt + len);
payload = (unsigned char *)tcp + sizeof(struct tcp_hdr);
/**
@@ -1143,9 +1171,7 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf *pf,
tcp->data_off = I40E_FDIR_TCP_DEFAULT_DATAOFF;
tcp->src_port = fdir_input->flow.udp6_flow.dst_port;
tcp->dst_port = fdir_input->flow.udp6_flow.src_port;
- break;
-
- case I40E_FILTER_PCTYPE_NONF_IPV6_SCTP:
+ } else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV6_SCTP) {
sctp = (struct sctp_hdr *)(raw_pkt + len);
payload = (unsigned char *)sctp + sizeof(struct sctp_hdr);
/**
@@ -1156,14 +1182,11 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf *pf,
sctp->src_port = fdir_input->flow.sctp6_flow.dst_port;
sctp->dst_port = fdir_input->flow.sctp6_flow.src_port;
sctp->tag = fdir_input->flow.sctp6_flow.verify_tag;
- break;
-
- case I40E_FILTER_PCTYPE_NONF_IPV6_OTHER:
- case I40E_FILTER_PCTYPE_FRAG_IPV6:
+ } else if (pctype == I40E_FILTER_PCTYPE_NONF_IPV6_OTHER ||
+ pctype == I40E_FILTER_PCTYPE_FRAG_IPV6) {
payload = raw_pkt + len;
set_idx = I40E_FLXPLD_L3_IDX;
- break;
- case I40E_FILTER_PCTYPE_L2_PAYLOAD:
+ } else if (pctype == I40E_FILTER_PCTYPE_L2_PAYLOAD) {
payload = raw_pkt + len;
/**
* ARP packet is a special case on which the payload
@@ -1173,10 +1196,69 @@ i40e_flow_fdir_construct_pkt(struct i40e_pf *pf,
rte_cpu_to_be_16(ETHER_TYPE_ARP))
payload += sizeof(struct arp_hdr);
set_idx = I40E_FLXPLD_L2_IDX;
- break;
- default:
- PMD_DRV_LOG(ERR, "unknown pctype %u.", fdir_input->pctype);
- return -EINVAL;
+ } else if (fdir_input->flow_ext.customized_pctype) {
+ /* If customized pctype is used */
+ cus_pctype = i40e_flow_fdir_find_customized_pctype(pf, pctype);
+ if (cus_pctype->index == I40E_CUSTOMIZED_GTPC ||
+ cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV4 ||
+ cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV6 ||
+ cus_pctype->index == I40E_CUSTOMIZED_GTPU) {
+ udp = (struct udp_hdr *)(raw_pkt + len);
+ udp->dgram_len =
+ rte_cpu_to_be_16(I40E_FDIR_UDP_DEFAULT_LEN);
+
+ gtp = (struct rte_flow_item_gtp *)
+ ((unsigned char *)udp + sizeof(struct udp_hdr));
+ gtp->v_pt_rsv_flags = 0x30;
+ gtp->msg_len =
+ rte_cpu_to_be_16(I40E_FDIR_GTP_DEFAULT_LEN);
+ gtp->teid = fdir_input->flow.gtp_flow.teid;
+ gtp->msg_type = 0x1;
+
+ if (cus_pctype->index == I40E_CUSTOMIZED_GTPC)
+ udp->dst_port = rte_cpu_to_be_16(2123);
+ else
+ udp->dst_port = rte_cpu_to_be_16(2152);
+
+ if (cus_pctype->index == I40E_CUSTOMIZED_GTPU_IPV4) {
+ gtp->msg_type = 0xFF;
+ gtp_ipv4 = (struct ipv4_hdr *)
+ ((unsigned char *)gtp +
+ sizeof(struct rte_flow_item_gtp));
+ gtp_ipv4->version_ihl =
+ I40E_FDIR_IP_DEFAULT_VERSION_IHL;
+ gtp_ipv4->next_proto_id = IPPROTO_IP;
+ gtp_ipv4->total_length =
+ rte_cpu_to_be_16(
+ I40E_FDIR_INNER_IP_DEFAULT_LEN);
+ payload = (unsigned char *)gtp_ipv4 +
+ sizeof(struct ipv4_hdr);
+ } else if (cus_pctype->index ==
+ I40E_CUSTOMIZED_GTPU_IPV6) {
+ gtp->msg_type = 0xFF;
+ gtp_ipv6 = (struct ipv6_hdr *)
+ ((unsigned char *)gtp +
+ sizeof(struct rte_flow_item_gtp));
+ gtp_ipv6->vtc_flow =
+ rte_cpu_to_be_32(
+ I40E_FDIR_IPv6_DEFAULT_VTC_FLOW |
+ (0 << I40E_FDIR_IPv6_TC_OFFSET));
+ gtp_ipv6->proto = IPPROTO_NONE;
+ gtp_ipv6->payload_len =
+ rte_cpu_to_be_16(
+ I40E_FDIR_INNER_IPv6_DEFAULT_LEN);
+ gtp_ipv6->hop_limits =
+ I40E_FDIR_IPv6_DEFAULT_HOP_LIMITS;
+ payload = (unsigned char *)gtp_ipv6 +
+ sizeof(struct ipv6_hdr);
+ } else
+ payload = (unsigned char *)gtp +
+ sizeof(struct rte_flow_item_gtp);
+ }
+ } else {
+ PMD_DRV_LOG(ERR, "unknown pctype %u.",
+ fdir_input->pctype);
+ return -1;
}
/* fill the flexbytes to payload */
@@ -189,6 +189,40 @@ static enum rte_flow_item_type pattern_fdir_ipv4_sctp[] = {
RTE_FLOW_ITEM_TYPE_END,
};
+static enum rte_flow_item_type pattern_fdir_ipv4_gtpc[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV4,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPC,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+static enum rte_flow_item_type pattern_fdir_ipv4_gtpu[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV4,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPU,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+static enum rte_flow_item_type pattern_fdir_ipv4_gtpu_ipv4[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV4,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPU,
+ RTE_FLOW_ITEM_TYPE_IPV4,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+static enum rte_flow_item_type pattern_fdir_ipv4_gtpu_ipv6[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV4,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPU,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
static enum rte_flow_item_type pattern_fdir_ipv6[] = {
RTE_FLOW_ITEM_TYPE_ETH,
RTE_FLOW_ITEM_TYPE_IPV6,
@@ -216,6 +250,40 @@ static enum rte_flow_item_type pattern_fdir_ipv6_sctp[] = {
RTE_FLOW_ITEM_TYPE_END,
};
+static enum rte_flow_item_type pattern_fdir_ipv6_gtpc[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPC,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+static enum rte_flow_item_type pattern_fdir_ipv6_gtpu[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPU,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+static enum rte_flow_item_type pattern_fdir_ipv6_gtpu_ipv4[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPU,
+ RTE_FLOW_ITEM_TYPE_IPV4,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
+static enum rte_flow_item_type pattern_fdir_ipv6_gtpu_ipv6[] = {
+ RTE_FLOW_ITEM_TYPE_ETH,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_UDP,
+ RTE_FLOW_ITEM_TYPE_GTPU,
+ RTE_FLOW_ITEM_TYPE_IPV6,
+ RTE_FLOW_ITEM_TYPE_END,
+};
+
static enum rte_flow_item_type pattern_fdir_ethertype_raw_1[] = {
RTE_FLOW_ITEM_TYPE_ETH,
RTE_FLOW_ITEM_TYPE_RAW,
@@ -1576,10 +1644,18 @@ static struct i40e_valid_pattern i40e_supported_patterns[] = {
{ pattern_fdir_ipv4_udp, i40e_flow_parse_fdir_filter },
{ pattern_fdir_ipv4_tcp, i40e_flow_parse_fdir_filter },
{ pattern_fdir_ipv4_sctp, i40e_flow_parse_fdir_filter },
+ { pattern_fdir_ipv4_gtpc, i40e_flow_parse_fdir_filter },
+ { pattern_fdir_ipv4_gtpu, i40e_flow_parse_fdir_filter },
+ { pattern_fdir_ipv4_gtpu_ipv4, i40e_flow_parse_fdir_filter },
+ { pattern_fdir_ipv4_gtpu_ipv6, i40e_flow_parse_fdir_filter },
{ pattern_fdir_ipv6, i40e_flow_parse_fdir_filter },
{ pattern_fdir_ipv6_udp, i40e_flow_parse_fdir_filter },
{ pattern_fdir_ipv6_tcp, i40e_flow_parse_fdir_filter },
{ pattern_fdir_ipv6_sctp, i40e_flow_parse_fdir_filter },
+ { pattern_fdir_ipv6_gtpc, i40e_flow_parse_fdir_filter },
+ { pattern_fdir_ipv6_gtpu, i40e_flow_parse_fdir_filter },
+ { pattern_fdir_ipv6_gtpu_ipv4, i40e_flow_parse_fdir_filter },
+ { pattern_fdir_ipv6_gtpu_ipv6, i40e_flow_parse_fdir_filter },
/* FDIR - support default flow type with flexible payload */
{ pattern_fdir_ethertype_raw_1, i40e_flow_parse_fdir_filter },
{ pattern_fdir_ethertype_raw_2, i40e_flow_parse_fdir_filter },
@@ -2302,6 +2378,42 @@ i40e_flow_set_fdir_inset(struct i40e_pf *pf,
return 0;
}
+static uint8_t
+i40e_flow_fdir_get_pctype_value(struct i40e_pf *pf,
+ enum rte_flow_item_type item_type,
+ struct i40e_fdir_filter_conf *filter)
+{
+ struct i40e_customized_pctype *cus_pctype = NULL;
+
+ switch (item_type) {
+ case RTE_FLOW_ITEM_TYPE_GTPC:
+ cus_pctype = i40e_find_customized_pctype(pf,
+ I40E_CUSTOMIZED_GTPC);
+ break;
+ case RTE_FLOW_ITEM_TYPE_GTPU:
+ if (!filter->input.flow_ext.inner_ip)
+ cus_pctype = i40e_find_customized_pctype(pf,
+ I40E_CUSTOMIZED_GTPU);
+ else if (filter->input.flow_ext.iip_type ==
+ I40E_FDIR_IPTYPE_IPV4)
+ cus_pctype = i40e_find_customized_pctype(pf,
+ I40E_CUSTOMIZED_GTPU_IPV4);
+ else if (filter->input.flow_ext.iip_type ==
+ I40E_FDIR_IPTYPE_IPV6)
+ cus_pctype = i40e_find_customized_pctype(pf,
+ I40E_CUSTOMIZED_GTPU_IPV6);
+ break;
+ default:
+ PMD_DRV_LOG(ERR, "Unsupported item type");
+ break;
+ }
+
+ if (cus_pctype)
+ return cus_pctype->pctype;
+
+ return I40E_FILTER_PCTYPE_INVALID;
+}
+
/* 1. Last in item should be NULL as range is not supported.
* 2. Supported patterns: refer to array i40e_supported_patterns.
* 3. Supported flow type and input set: refer to array
@@ -2326,14 +2438,16 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
const struct rte_flow_item_tcp *tcp_spec, *tcp_mask;
const struct rte_flow_item_udp *udp_spec, *udp_mask;
const struct rte_flow_item_sctp *sctp_spec, *sctp_mask;
+ const struct rte_flow_item_gtp *gtp_spec, *gtp_mask;
const struct rte_flow_item_raw *raw_spec, *raw_mask;
const struct rte_flow_item_vf *vf_spec;
- enum i40e_filter_pctype pctype = 0;
+ uint8_t pctype = 0;
uint64_t input_set = I40E_INSET_NONE;
uint16_t frag_off;
enum rte_flow_item_type item_type;
enum rte_flow_item_type l3 = RTE_FLOW_ITEM_TYPE_END;
+ enum rte_flow_item_type cus_proto = RTE_FLOW_ITEM_TYPE_END;
uint32_t i, j;
uint8_t ipv6_addr_mask[16] = {
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
@@ -2351,12 +2465,14 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
uint16_t outer_tpid;
uint16_t ether_type;
uint32_t vtc_flow_cpu;
+ bool outer_ip = true;
int ret;
memset(off_arr, 0, sizeof(off_arr));
memset(len_arr, 0, sizeof(len_arr));
memset(flex_mask, 0, I40E_FDIR_MAX_FLEX_LEN);
outer_tpid = i40e_get_outer_vlan(dev);
+ filter->input.flow_ext.customized_pctype = false;
for (; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
if (item->last) {
rte_flow_error_set(error, EINVAL,
@@ -2430,7 +2546,7 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
ipv4_mask =
(const struct rte_flow_item_ipv4 *)item->mask;
- if (ipv4_spec && ipv4_mask) {
+ if (ipv4_spec && ipv4_mask && outer_ip) {
/* Check IPv4 mask and update input set */
if (ipv4_mask->hdr.version_ihl ||
ipv4_mask->hdr.total_length ||
@@ -2475,9 +2591,22 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
ipv4_spec->hdr.src_addr;
filter->input.flow.ip4_flow.dst_ip =
ipv4_spec->hdr.dst_addr;
+
+ layer_idx = I40E_FLXPLD_L3_IDX;
+ } else if (!ipv4_spec && !ipv4_mask && !outer_ip) {
+ filter->input.flow_ext.inner_ip = true;
+ filter->input.flow_ext.iip_type =
+ I40E_FDIR_IPTYPE_IPV4;
+ } else if ((ipv4_spec || ipv4_mask) && !outer_ip) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ITEM,
+ item,
+ "Invalid inner IPv4 mask.");
+ return -rte_errno;
}
- layer_idx = I40E_FLXPLD_L3_IDX;
+ if (outer_ip)
+ outer_ip = false;
break;
case RTE_FLOW_ITEM_TYPE_IPV6:
@@ -2487,7 +2616,7 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
ipv6_mask =
(const struct rte_flow_item_ipv6 *)item->mask;
- if (ipv6_spec && ipv6_mask) {
+ if (ipv6_spec && ipv6_mask && outer_ip) {
/* Check IPv6 mask and update input set */
if (ipv6_mask->hdr.payload_len) {
rte_flow_error_set(error, EINVAL,
@@ -2538,10 +2667,22 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
else
pctype =
I40E_FILTER_PCTYPE_NONF_IPV6_OTHER;
- }
- layer_idx = I40E_FLXPLD_L3_IDX;
+ layer_idx = I40E_FLXPLD_L3_IDX;
+ } else if (!ipv6_spec && !ipv6_mask && !outer_ip) {
+ filter->input.flow_ext.inner_ip = true;
+ filter->input.flow_ext.iip_type =
+ I40E_FDIR_IPTYPE_IPV6;
+ } else if ((ipv6_spec || ipv6_mask) && !outer_ip) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ITEM,
+ item,
+ "Invalid inner IPv6 mask");
+ return -rte_errno;
+ }
+ if (outer_ip)
+ outer_ip = false;
break;
case RTE_FLOW_ITEM_TYPE_TCP:
tcp_spec = (const struct rte_flow_item_tcp *)item->spec;
@@ -2636,6 +2777,37 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
layer_idx = I40E_FLXPLD_L4_IDX;
break;
+ case RTE_FLOW_ITEM_TYPE_GTPC:
+ case RTE_FLOW_ITEM_TYPE_GTPU:
+ if (!pf->gtp_support) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ITEM,
+ item,
+ "Unsupported protocol");
+ return -rte_errno;
+ }
+
+ gtp_spec = (const struct rte_flow_item_gtp *)item->spec;
+ gtp_mask = (const struct rte_flow_item_gtp *)item->mask;
+
+ if (gtp_spec && gtp_mask) {
+ if (gtp_mask->v_pt_rsv_flags ||
+ gtp_mask->msg_type ||
+ gtp_mask->msg_len ||
+ gtp_mask->teid != UINT32_MAX) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ITEM,
+ item,
+ "Invalid GTP mask");
+ return -rte_errno;
+ }
+
+ filter->input.flow.gtp_flow.teid =
+ gtp_spec->teid;
+ filter->input.flow_ext.customized_pctype = true;
+ cus_proto = item_type;
+ }
+ break;
case RTE_FLOW_ITEM_TYPE_SCTP:
sctp_spec =
(const struct rte_flow_item_sctp *)item->spec;
@@ -2774,43 +2946,58 @@ i40e_flow_parse_fdir_pattern(struct rte_eth_dev *dev,
}
}
- ret = i40e_flow_set_fdir_inset(pf, pctype, input_set);
- if (ret == -1) {
- rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_ITEM, item,
- "Conflict with the first rule's input set.");
- return -rte_errno;
- } else if (ret == -EINVAL) {
- rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_ITEM, item,
- "Invalid pattern mask.");
- return -rte_errno;
+ /* Get customized pctype value */
+ if (filter->input.flow_ext.customized_pctype) {
+ pctype = i40e_flow_fdir_get_pctype_value(pf, cus_proto, filter);
+ if (pctype == I40E_FILTER_PCTYPE_INVALID) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ITEM,
+ item,
+ "Unsupported pctype");
+ return -rte_errno;
+ }
}
- filter->input.pctype = pctype;
+ /* If customized pctype is not used, set fdir configuration.*/
+ if (!filter->input.flow_ext.customized_pctype) {
+ ret = i40e_flow_set_fdir_inset(pf, pctype, input_set);
+ if (ret == -1) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ITEM, item,
+ "Conflict with the first rule's input set.");
+ return -rte_errno;
+ } else if (ret == -EINVAL) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ITEM, item,
+ "Invalid pattern mask.");
+ return -rte_errno;
+ }
- /* Store flex mask to SW */
- ret = i40e_flow_store_flex_mask(pf, pctype, flex_mask);
- if (ret == -1) {
- rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_ITEM,
- item,
- "Exceed maximal number of bitmasks");
- return -rte_errno;
- } else if (ret == -2) {
- rte_flow_error_set(error, EINVAL,
- RTE_FLOW_ERROR_TYPE_ITEM,
- item,
- "Conflict with the first flexible rule");
- return -rte_errno;
- } else if (ret > 0)
- cfg_flex_msk = false;
+ /* Store flex mask to SW */
+ ret = i40e_flow_store_flex_mask(pf, pctype, flex_mask);
+ if (ret == -1) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ITEM,
+ item,
+ "Exceed maximal number of bitmasks");
+ return -rte_errno;
+ } else if (ret == -2) {
+ rte_flow_error_set(error, EINVAL,
+ RTE_FLOW_ERROR_TYPE_ITEM,
+ item,
+ "Conflict with the first flexible rule");
+ return -rte_errno;
+ } else if (ret > 0)
+ cfg_flex_msk = false;
- if (cfg_flex_pit)
- i40e_flow_set_fdir_flex_pit(pf, layer_idx, raw_id);
+ if (cfg_flex_pit)
+ i40e_flow_set_fdir_flex_pit(pf, layer_idx, raw_id);
- if (cfg_flex_msk)
- i40e_flow_set_fdir_flex_msk(pf, pctype);
+ if (cfg_flex_msk)
+ i40e_flow_set_fdir_flex_msk(pf, pctype);
+ }
+
+ filter->input.pctype = pctype;
return 0;
}