From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id A73E9A034F;
	Tue, 28 Dec 2021 15:45:42 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 2D85540040;
	Tue, 28 Dec 2021 15:45:42 +0100 (CET)
Received: from spider.fraudbuster.mobi (spider.fraudbuster.mobi [62.4.12.223])
 by mails.dpdk.org (Postfix) with ESMTP id 543944003C
 for <dev@dpdk.org>; Tue, 28 Dec 2021 15:45:40 +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) server-digest SHA256)
 (No client certificate requested)
 by spider.fraudbuster.mobi (Postfix) with ESMTPSA id 0821722273
 for <dev@dpdk.org>; Tue, 28 Dec 2021 15:45:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fraudbuster.mobi;
 s=rsa-20200712; t=1640702740;
 bh=qd/C87+9cu/CJe6abJZdIsbtaVKCLKqEKHRl/4Ex+ZQ=;
 h=From:Subject:To:References:Date:In-Reply-To:From;
 b=o0ek8kUEdKFCDrKQnWatXQMV0/KAhikNzDP85s/EPVSSx2Ogszz9rY9vZ+4RYHjYr
 QyOYB/qIlbuui2O3IkCGO5lFaQ5FFIFya8+4i8aoK66Tq1tEDgHECbuWysdw6v30QX
 n/oeDjueNu4MG2RSYsFF26dShghA2SwD9DBAIfH38Bo6RMna5TLAVjVoe0jCdA5tJt
 Dbxrhj9iA9ud67dnbPDibp4YkKnORUOMeik9u84dbGcUGZmDRDpnRq83yqO/1Kqs3G
 PsVlZv6Hu/cFnlVQpUS42LKRmmlh03VRTwGF3S9cJwSwgMberLa/22M4m7i5kQt8RX
 d2UoazgvXGNEw==
From: David Bouyeure <david.bouyeure@fraudbuster.mobi>
Subject: [dpdk-dev] net/mlx5: rte_flow_item_gtp restricted to GTPU
To: dev@dpdk.org
References: <20210326104217.3397745-2-junfeng.guo@intel.com>
 <20210326142948.1889704-1-junfeng.guo@intel.com>
 <20210326142948.1889704-2-junfeng.guo@intel.com>
Message-ID: <495fe401-7b39-462c-a698-9d5ee4ded7c5@fraudbuster.mobi>
Date: Tue, 28 Dec 2021 15:45:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <20210326142948.1889704-2-junfeng.guo@intel.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

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.