From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6F86FA034F; Tue, 28 Dec 2021 15:56:51 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EDC7C40040; Tue, 28 Dec 2021 15:56:50 +0100 (CET) Received: from spider.fraudbuster.mobi (spider.fraudbuster.mobi [62.4.12.223]) by mails.dpdk.org (Postfix) with ESMTP id DE5254003C for ; Tue, 28 Dec 2021 15:56:49 +0100 (CET) Received: from [10.8.0.90] (gypsy.fraudbuster.mobi [212.129.1.221]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by spider.fraudbuster.mobi (Postfix) with ESMTPSA id 960A023422 for ; Tue, 28 Dec 2021 15:56:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fraudbuster.mobi; s=rsa-20200712; t=1640703409; bh=ufHBFJFj1eYwECyZ2A/TDSP6EcL5w8zlzRGHnlAxP5k=; h=To:From:Subject:Date:From; b=XPwUNTZvJ8w42w1NbFXJNNsdQNWsF8tGQCaL19lLAxo97CqGspR8kFEpQ0GmVyDPq 4dSRD+nFHZrCsf1AqoL4zs1XVeH4TQbu1T9YZqOaqLne4VQPZqKWKgmSFQXaaOo1ky a1lRp2ovOp6usWZxfTBeWw2QaI21ybt67zotccuu0IoHYdtRHe5+r7LqJQ2/nG0ak1 WM+HH3pZ/IL+jXUvcvxolcpoCcNAZ4Se0x5kRVRB+Hmsxxfvg67xSK9o4PFq4Ma7Ul DFSXcEPmuFFF7kC158/qe5uqVvj1OKR2cAf+jjm29uMPK9+qzpTUtqE10DaG7Hrz1M pDGRXBS6fRpVQ== To: "dev@dpdk.org" From: David Bouyeure Subject: [dpdk-dev] net/mlx5: rte_flow_item_gtp restricted to GTPU Message-ID: <5537fe65-9b3d-d745-557c-ae714ca33bc4@fraudbuster.mobi> Date: Tue, 28 Dec 2021 15:56:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------6C43022E30155FF27F0A96C8" Content-Language: en-US X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org This is a multi-part message in MIME format. --------------6C43022E30155FF27F0A96C8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi everybody, I've implemented some flows offloading through rte_flow, and I'm just finding out that my GTPC packets aren't handled the same way as my GTPU ones by a Mellanox Connect-X6(FLEX_PARSER_PROFILE_ENABLE==3). In others words, the GTP rules that I set are ignoring GTPC packets. The DPDK api doc doesn't say anything about any GTP-C/GTP-U distinction as far as I know, only that there's no way to set some filter against a GTPv2(GTP-C) header. There's a reference to RTE_GTPU_UDP_PORT in dpdk.20.11.2/drivers/net/mlx5/mlx5_flow_dv.c::flow_dv_translate_item_gtp(), and none to RTE_GTPC_UDP_PORT. Do you confirm that mlx5 rte_flow implementation is definitely ignoring GTPC packets? And, if so, for which reason? Thanks a lot. Regards. P.S: sorry for the previous nested message in '[dpdk-dev] [PATCH v3 1/3] net/iavf: support GTPU inner IPv4 for FDIR ' --------------6C43022E30155FF27F0A96C8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi everybody,

I've implemented some flows offloading through rte_flow, and I'm just finding out that my GTPC packets aren't handled the same way as my GTPU ones by a Mellanox Connect-X6(FLEX_PARSER_PROFILE_ENABLE==3).

In others words, the GTP rules that I set are ignoring GTPC packets. The DPDK api doc doesn't say anything about any GTP-C/GTP-U distinction as far as I know, only that there's no way to set some filter against a GTPv2(GTP-C) header.

There's a reference to RTE_GTPU_UDP_PORT in dpdk.20.11.2/drivers/net/mlx5/mlx5_flow_dv.c::flow_dv_translate_item_gtp(), and none to RTE_GTPC_UDP_PORT.

Do you confirm that mlx5 rte_flow implementation is definitely ignoring GTPC packets? And, if so, for which reason?

Thanks a lot.

Regards.

P.S: sorry for the previous nested message in '[dpdk-dev] [PATCH v3 1/3] net/iavf: support GTPU inner IPv4 for FDIR'

--------------6C43022E30155FF27F0A96C8--