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 5F780A034D; Mon, 31 Jan 2022 17:50:09 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BEA65411E1; Mon, 31 Jan 2022 17:50:08 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id BB133411C3; Mon, 31 Jan 2022 17:50:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643647806; x=1675183806; h=message-id:date:subject:to:cc:references:from: in-reply-to:mime-version; bh=d6dEsf3LrihR972AMZqCNMlg8qp7C63rsH9GxMNykFc=; b=MDuMwuQYjO2nDq5eQFLbdncle44KSg15cD5x/vEHBD6SKhqq68c0l8Dt neHkydxyrslGLt30n+3GlILuAYI4BV6McCXjZJu4DGgNZGVUD1j16w0r9 Rk6ppbmYKtBV0WLeFNrHmh8p5dcKimysXx3rMI0nvxJNvwg5jE4bcT7LS LA8kSIBpQE9XTAVXgR8wEvSpNzh7UEL8fC+Bo1m9R0tsN8EGnadmHVlwm azMLbflLetI7G2VlgX3cuupV6IVPUcR6FZJ5nL5qunLnsQb2XdU3aiqGn hp7cykA5+ASxp0NO/SpJN0c415VBM1sE5wrvVBfVdkU02S3i8hw8Q0oB+ A==; X-IronPort-AV: E=McAfee;i="6200,9189,10244"; a="227473179" X-IronPort-AV: E=Sophos;i="5.88,331,1635231600"; d="scan'208,217";a="227473179" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2022 08:47:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,331,1635231600"; d="scan'208,217";a="626426559" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga002.fm.intel.com with ESMTP; 31 Jan 2022 08:47:48 -0800 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 31 Jan 2022 08:47:48 -0800 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20 via Frontend Transport; Mon, 31 Jan 2022 08:47:48 -0800 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (104.47.73.173) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.20; Mon, 31 Jan 2022 08:47:47 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ls0Q2oOoRsMqxJ9CDAfYgtGlIanZRrCD+bAgObg4eCpKheMC2U9WzyCJS++Zym7hAZ21PSbCH29AhyY+KOA0HtoTK97NKJDdsOoBQhr+sVIaCBYJF4bLkjg/BExrnUhaSJFySnAowMi0zlRZP4TlSZhy30e0+WwYsCwPuEKQLehZh5vMhDK4+/L38AA75Sq7b9xCtChJFpAzJXvrJG/g2ku+5FpoT8QxjdYjvz0Ipa+VbvuJj6AH3xp/tXixY+xRercdNglTUD6KxvAM7AfrynARqCx0+tnm7TuInWBZzPcBG/ODgUNlHd1BE1rUslNeZZ5F3DpBL6gclIFsUHj3hQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=oL/4fGoLsjDyC3cyF10YhAKVwzcT7Fp5sMZg/qiyp8k=; b=En1glprfnEG6cmfRwBMzo952RT5Wh7Bedy1v2jTCjb8zxAbuVqWZ8c1RGMQWiwtbhXJt5upFXD9bBdYUK1GqMKuFsONI7rPNJU70RtXietQHAImwCMgGwTZXX0kbu586JE721eWhu075IMKOQuhdsTNnEzGN4ZJhqkJ5tNuXf7NsV5eUZEKfWDem6i3XLAo2V736geueDpDDaegRTYuWNedazvgK/f7H5tYdn4PJmJoB/eL9Bour9e8eNZ/msCEBUYoPOoX2pb8Txfo7woh3xEnWGHKB71FjQYE3gIH9frjkcE5Lw1OM/19VJz/UG744jRw+QTcw3hMks7rSP1F+SQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from MWHPR11MB0062.namprd11.prod.outlook.com (2603:10b6:301:67::34) by SA2PR11MB4825.namprd11.prod.outlook.com (2603:10b6:806:111::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.17; Mon, 31 Jan 2022 16:47:43 +0000 Received: from MWHPR11MB0062.namprd11.prod.outlook.com ([fe80::417b:7df4:d3fb:2b0a]) by MWHPR11MB0062.namprd11.prod.outlook.com ([fe80::417b:7df4:d3fb:2b0a%3]) with mapi id 15.20.4930.020; Mon, 31 Jan 2022 16:47:43 +0000 Content-Type: multipart/alternative; boundary="------------L5y100BVRbB2x5jdcGsQBBWs" Message-ID: <8c2f2f5b-e8fe-39cd-52b4-f4111c363924@intel.com> Date: Mon, 31 Jan 2022 22:17:30 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH] app/testpmd: fix GENEVE parsing in csum forward mode Content-Language: en-US To: Raja Zidane , Matan Azrad , "Ferruh Yigit" , "dev@dpdk.org" , Beilei Xing , Qi Zhang CC: "stable@dpdk.org" References: <20211205034450.7888-1-rzidane@nvidia.com> <4787802c-cefe-6d15-817f-6b906451ded8@intel.com> <6b4a6388-92b7-eeb5-f218-b007199e3ddf@intel.com> <9e8ec1b6-4131-8c26-c814-f46d56e76c28@intel.com> From: "Singh, Aman Deep" In-Reply-To: X-ClientProxiedBy: BM1PR0101CA0050.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:19::12) To MWHPR11MB0062.namprd11.prod.outlook.com (2603:10b6:301:67::34) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f1e44a3f-5e24-4677-066e-08d9e4d966d6 X-MS-TrafficTypeDiagnostic: SA2PR11MB4825:EE_ X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 16bKnKMGFNdYerjzaFwlW2fZ0J0WULG2JdiK6FEEjgypbuA6YbQqv86Y8Ki9VSVRJ0KqNqqK9mibOEgq+5w9vkinB4TKWcTgk4f8HzXLMooKXx3RaoRkqmn3NDnCepa2mOEJ2UbMUjbEP+SyED4RrdMJMGvpOfJvzAnqb/VQ9J8FewvJNN+2V7zC/6TzXA6h3KKzzdr2nqB5KQ2FKRsGE5kVbRh+WMeqJqqsBiSRVSojQ2YI1KYGn81KPf0vtuDxWG/3Y2e4znRbEM853KvhOSasM/LWrqFAwN600mL36WrvCVR1fLHSsOhwbgp5HjQRETnQQEsA+MDUxH8SHqva6nK1pOL6A8KSZJPd/ZR2FsqtTgMtWzizyma17bwrXXbaXhs1imtffuy3LwjhQylAaii4MGM3EIh6+FFu4YXop0ETAlefNr2+F/Wxm5cAv7/g9fwpoTZpR9sfmBHz56GXFOEUB91S9yNgkNmB3Xh608WeOXZEvj0A6w8yg49ueSNRX939cPIfGhHMa+yFPfLCU+JQnPC0d+e/RUiKMhatSaslBcr6tVaayJS0ELvez1rCti5r1wSPTFm5GK+kHJ+fJTyyCNJf3hP/p4zudT5c5dvoslcOxJCBBBouFYQneqNkxrxUJrtZ/w7KXnGZdz38YUjZK8v6Sei4FgQ4AmL0NLmm7ouU9iIejzIIRuyqPJW0GWo/sQFUVfFskWroT5MugMcNytCwiXO9U5c7Qp0M+FDw0EqjGEO6fZ1aD2KkFRmYlrZ+mlevE85OxodM+geNOJVK46yIkAjhKEWKTpIgd7H3hbDh1aT96AGu1dN2Tdv3 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB0062.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(36756003)(166002)(31696002)(86362001)(38100700002)(82960400001)(53546011)(33964004)(6506007)(5660300002)(30864003)(31686004)(6512007)(2616005)(110136005)(316002)(508600001)(66946007)(66476007)(8676002)(8936002)(4326008)(966005)(6486002)(66556008)(186003)(83380400001)(26005)(2906002)(6636002)(6666004)(45980500001)(43740500002)(20210929001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?aWRueDB0ZTVLbkwxLzlxclcwZmFoQVYzZTlMKzZpMTYyT1F4b2VTem9KeFJW?= =?utf-8?B?WFgzMEZCM1hZUVJnSzBzdHIzc0xqeXRhQkVsK2FadDBVZXRpYlNXZ1FtTkxG?= =?utf-8?B?dDBpYWhFdVhMaWk5ZGt1ZXRBNlA5T0pLVWI0RGhVYk1tRnRHRGYzZlYzT28z?= =?utf-8?B?UzBFUGtlSHBLRTlDRWFkZW5YeURpRnhXekdDa0VuUU0xQ1RQYXpZOTFWQnRz?= =?utf-8?B?Qjh3RlJWbGo0ZEgrdWdkS1FUbXBSeGt1dW9vNllidWt2YjQ3N1dtN3lZVUxW?= =?utf-8?B?Z0hKeGlmYXkxL0EwOUc3V1JPQXFubVZpWTdGcHkyZU5rUW1RcGtTMHBJOTJZ?= =?utf-8?B?eXVxSUgvUXA1akJGYkNVNXNYMXV6ci9FK29EbStHVGtGV1BLcWQrWWZxM2E2?= =?utf-8?B?bm9zUG9paUN1NEhwbjd5TVNlOFpzODJJSitFWXZzRC9kWHd3WUtZVGNVS2dv?= =?utf-8?B?NXFQTXVoME1nOFI3dDZSMENNQlJoUysreEtDVUJmWGlDSHNZbHBVUWJuMncy?= =?utf-8?B?RCtyRlBHdENhM3BGUzAxanlBcmh0YTQwSjA4Y3ozeS8wWnBiMzIzcGZVRjVC?= =?utf-8?B?U1RiMmNxVUJ1WmRQYmlWV3BBV0U1dDNWdWt1MWN3U0MyT3Qra3FxSzV0WVlj?= =?utf-8?B?LzQ3Rk11YStWRjBQRnBXcjFxb3YyRmFZZm9PelE1WEtRb0NtVWswbi85ZGNx?= =?utf-8?B?OFYxWUV4VXVvQ1JMNVFmc3dVc2RVcXJmTmJqeXFQUzgrb0kyb3pmSjB4QXQ0?= =?utf-8?B?S2JkVnRzaDlLTTdONWlvSTNCQkpQQlQ4VExWQkFmYURZNUtXUU5wQlZtVUVN?= =?utf-8?B?bEt3cFg2MkliNmFpYkNnWG1YNEtmR2tJaGxDMXdXZTNEV1o3WHdhbVdtRDVx?= =?utf-8?B?Wk92Y2FpQlBhbi9RWkMzbWhOUXZkeVBqcXVoOHlRZmpUR3lIaWl2TVN6dUJ3?= =?utf-8?B?blVMYitTblh6MS9EdXVoeWZ4VnpaVGx5cmFRZnBCWGkwSVd4ZDlXNjlmaE1x?= =?utf-8?B?ZU9NSXBhUzNoMkFaQWUxKzRpc0JTNzIvb3NpQTQzMU5jZEE0T1Y0VDZkdkxs?= =?utf-8?B?YTJpZ1picGhuMzhxUWljMnlqdEF0eWFleVZabUMwWW1UOVdFd24rdUM1K2c2?= =?utf-8?B?TVNHREFsUzhwNXA4UVMvVXhuK1RDYVQzeUlmdmpjelRaWEovYmw3RURjZ3Qy?= =?utf-8?B?UDRUcG1Rb25pYTJkS1I1UkZwWFNTMktSZDMxTnV3S2FRbDZzdzFINWEzQjVj?= =?utf-8?B?TlJyL3FibUxFQ1d1QVpOUFFTZVQyTWVOSDRTUkNUSTRBZU4zU0J4L2dIdDJn?= =?utf-8?B?enEreGR3cnlwRHU1dHloZWEvWCtFOWwybTJTNmM4QXFSMFNKKzN2TU1oZTBV?= =?utf-8?B?YlVMb0xlNndQbkEzY0ZsTXJ4SmhyY21YcHM5T2M5ZnBHTTRqUDVHODVBcDA2?= =?utf-8?B?TUFBY2lnSzhJT3FjOGJQMmNqODFlVGkrZHRwWXNtbEZZN1BVM2E4Tk9KT01G?= =?utf-8?B?ZWhpbzdYRUlrUEpLZllTUlNwZWtiQmhLaHBBZVNWUXRlSFFQdGxIVmFOTUYx?= =?utf-8?B?MDFoVktNSS84dGpuV1I1NEZMOGFHOUp3Y1ppdVNkNW5IVXluc1phVmE5WjNV?= =?utf-8?B?Y0JjYStCVUtQTDQxbWc0RmlOb0VNRktpblRFWm9UMVdUcWRUY1YrYlE0UmU0?= =?utf-8?B?RDBiUkZrenVteDZKcDJTVEpnTWM3amdjM1hGdTFId2NYc3Nsa3AxTk9rK0RN?= =?utf-8?B?bWRvT1ByQkV3QitFa1hsaHFUVTJ6bkhDbFlyZE5kNUQ0c3FmUHk4aS9qMEdo?= =?utf-8?B?U3JGNHZVdjAxYk1hdS9XMm5abDMxTVREMzV1WUlDYkQ5Qmwrd29PVWE0R0lr?= =?utf-8?B?QmZpcGtMU1JiMmlNYzZCa25JT1RYRjN4bkp6K09Mcmt3eld4KzBQc215L0dM?= =?utf-8?B?QUtGTjNUNUlJT0dHU2xXbDRTR2hPRDZ5Q1hCbWl2YmhjSzJMaTBoUm8yRVNt?= =?utf-8?B?cU9JZWtLZzZqR0dGMElpOXZDb0ZZb1ZuTmZwLzdqeVFabllLcDEyUm10OVZp?= =?utf-8?B?WDZNM0lvZ2NqeVQxdjlRUTdVdi9mampYSmJPVC9XYjlBSTVWYUN1OVl4SFgz?= =?utf-8?B?VzU0bHRUYUdQRjFINFJzOUhHWU9ycVJPdWFlR1gyZ25PcGZJaURnVVFoS2Fj?= =?utf-8?B?dDBHSDVNTzVhSWVOUXI2ck05U3hoKzZzbzRyRStUMkhhWHhPaXFzWGkrbTM4?= =?utf-8?Q?XFOVgqOjwp4H94ojdFEaGSR4g1zSfisRCI5Bp7bQD4=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: f1e44a3f-5e24-4677-066e-08d9e4d966d6 X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB0062.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2022 16:47:43.6161 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: e/zDaF81uaZVpdwgQ6tWXABNHr7i9B9nFIiOcp/mwfQYP5xAQ5UvnsHh17nVPwGTgCMpq3nesDg3VPw6EBfSdQojZjp6gXckrjKeMHe+UUk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4825 X-OriginatorOrg: intel.com 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 --------------L5y100BVRbB2x5jdcGsQBBWs Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit On 1/30/2022 4:48 PM, Raja Zidane wrote: > I didn't want to remove the default parsing of tunnel as VxLan because I thought it might be used, > Instead I moved it to the end, which makes it detect all supported tunnel through udp_dst_port, > And only if no tunnel was matched it would default to VxLan. > That was the reason geneve weren't detected and parsed as vxlan instead, which is the bug I was trying to solve. We can take help/input from i40 maintainers for it. Hi Beilei Xing, For setting packet_type as Tunnel, what criteria is used by i40 driver. Is it only udp_dst port or any other parameters also. > > -----Original Message----- > From: Singh, Aman Deep > Sent: Thursday, January 20, 2022 12:47 PM > To: Matan Azrad; Ferruh Yigit; Raja Zidane;dev@dpdk.org > Cc:stable@dpdk.org > Subject: Re: [PATCH] app/testpmd: fix GENEVE parsing in csum forward mode > > External email: Use caution opening links or attachments > > > On 1/18/2022 6:49 PM, Matan Azrad wrote: > app/test-pmd/csumonly.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c > index 2aeea243b6..fe810fecdd 100644 > --- a/app/test-pmd/csumonly.c > +++ b/app/test-pmd/csumonly.c > @@ -254,7 +254,10 @@ parse_gtp(struct rte_udp_hdr *udp_hdr, > info->l2_len += RTE_ETHER_GTP_HLEN; > } > > -/* Parse a vxlan header */ > +/* > + * Parse a vxlan header. > + * If a tunnel is detected in 'pkt_type' it will be parsed by default as vxlan. > + */ > static void > parse_vxlan(struct rte_udp_hdr *udp_hdr, > struct testpmd_offload_info *info, @@ -912,17 > +915,18 @@ pkt_burst_checksum_forward(struct fwd_stream *fs) > RTE_MBUF_F_TX_TUNNEL_VXLAN_GPE; > goto tunnel_update; > } > - parse_vxlan(udp_hdr, &info, > - m->packet_type); > + parse_geneve(udp_hdr, &info); > if (info.is_tunnel) { > tx_ol_flags |= > - RTE_MBUF_F_TX_TUNNEL_VXLAN; > + > + RTE_MBUF_F_TX_TUNNEL_GENEVE; > goto tunnel_update; > } > - parse_geneve(udp_hdr, &info); > + /* Always keep last. */ > + parse_vxlan(udp_hdr, &info, > + m->packet_type); > if (info.is_tunnel) { > tx_ol_flags |= > - RTE_MBUF_F_TX_TUNNEL_GENEVE; > + > + RTE_MBUF_F_TX_TUNNEL_VXLAN; > goto tunnel_update; > } > } else if (info.l4_proto == > IPPROTO_GRE) { >>> -----Original Message----- >>> From: Ferruh Yigit >>> Sent: Tuesday, January 18, 2022 3:03 PM >>> To: Matan Azrad; Raja Zidane; >>> dev@dpdk.org >>> Cc:stable@dpdk.org >>> Subject: Re: [PATCH] app/testpmd: fix GENEVE parsing in csum forward >>> mode >>> >>> External email: Use caution opening links or attachments >>> >>> >>> On 1/18/2022 12:55 PM, Matan Azrad wrote: >>>>> -----Original Message----- >>>>> From: Ferruh Yigit >>>>> Sent: Tuesday, January 18, 2022 2:28 PM >>>>> To: Matan Azrad; Raja Zidane >>>>> ;dev@dpdk.org >>>>> Cc:stable@dpdk.org >>>>> Subject: Re: [PATCH] app/testpmd: fix GENEVE parsing in csum >>>>> forward mode >>>>> >>>>> External email: Use caution opening links or attachments >>>>> >>>>> >>>>> On 1/18/2022 11:27 AM, Matan Azrad wrote: >>>>>>> -----Original Message----- >>>>>>> From: Ferruh Yigit >>>>>>> Sent: Tuesday, January 18, 2022 11:52 AM >>>>>>> To: Raja Zidane;dev@dpdk.org >>>>>>> Cc: Matan Azrad;stable@dpdk.org >>>>>>> Subject: Re: [PATCH] app/testpmd: fix GENEVE parsing in csum >>>>>>> forward mode >>>>>>> >>>>>>> External email: Use caution opening links or attachments >>>>>>> >>>>>>> >>>>>>> On 12/5/2021 3:44 AM, Raja Zidane wrote: >>>>>>>> The csum FWD mode parses any received packet to set mbuf >>>>>>>> offloads for the transmitting burst, mainly in the checksum/TSO areas. >>>>>>>> In the case of a tunnel header, the csum FWD tries to detect >>>>>>>> known tunnels by the standard definition using the header'sdata >>>>>>>> and fallback to check the packet type in the mbuf to see if the >>>>>>>> Rx port driver already sign the packet as a tunnel. >>>>>>>> In the fallback case, the csum assumes the tunnel is VXLAN and >>>>>>>> parses the tunnel as VXLAN. >>>>>>> As far as I can see there is a VXLAN port check in >>>>>>> 'parse_vxlan()', why it is not helping? >>>>>>> >>>>>> The problem is not the vxlan check but the tunnel type in mbuf >>>>>> that caused the >>>>> packet to be detected as vxlan(default) before checking GENEVE tunnel case. >>>>> Check is as following: >>>>> >>>>> if (udp_hdr->dst_port != _htons(RTE_VXLAN_DEFAULT_PORT) && >>>>> RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0) >>>>> return; >>>>> >>>>> Do you what is the intention for the >>>>> "RTE_ETH_IS_TUNNEL_PKT(pkt_type) == >>> 0" >>>>> check? >>>>> Why vxlan parsing doesn't stop when it is not default port? >>>> Maybe some drivers set the tunnel type for vxlan packets coming >>>> after non- >>> standard vxlan port. >>> But checking the tunnel flag to say that it is vxlan is too broad, isn't it? >>> And this is the problem you are having. >>> >>> Can there be any way to detect and check non-standard vxlan port? >> Maybe yes, but it is probably more complex solusion. >> >> See this patch: >> https://patches.dpdk.org/project/dpdk/patch/1423819371-24222-13-git-se >> nd-email-olivier.matz@6wind.com/ >> >> comments there: >> 1. check udp destination port, 4789 is the default vxlan port (rfc7348). >> 2. currently, this flag is set by i40e only if the packet is vxlan >> >> And maybe another driver assumes more ports here. >> >> Collecting all the non-standard ports can start from i40 maintainers😊 > I think, here we should check for supported tunnel types only. The i40 driver setting a Tunnel flag, does not means that it VxLan type only. > As in your case those were GENEVE packets getting treated as VxLan. > > Making parse_vxlan() udp_dst_port specific can avoid this issue. > >>>>>>>> When the GENEVE tunnel was added to the known tunnels in csum, >>>>>>>> its parsing trial was wrongly located after the pkt type >>>>>>>> detection, causing the csum to parse the GENEVE header as VXLAN >>>>>>>> when the Rx port set the tunnel packet type. >>>>>>>> >>>>>>>> Locate the GENEVE parsing trial before the packet type detection. >>>>>>>> >>>>>>>> Fixes: ea0e711b8ae0 ("app/testpmd: add GENEVE parsing") >>>>>>>> Cc:stable@dpdk.org >>>>>>>> >>>>>>>> Signed-off-by: Raja Zidane >>>>>>>> --- >>>>>>>> Acked-by: Matan Azrad >>>>>>> Ack should be before '---' to be part of the commit log, >>>>>>> otherwise it is dropped when applied as comment. >>>>>>> --------------L5y100BVRbB2x5jdcGsQBBWs Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit


On 1/30/2022 4:48 PM, Raja Zidane wrote:
I didn't want to remove the default parsing of tunnel as VxLan because I thought it might be used,
Instead I moved it to the end, which makes it detect all supported tunnel through udp_dst_port,
And only if no tunnel was matched it would default to VxLan.
That was the reason geneve weren't detected and parsed as vxlan instead, which is the bug I was trying to solve.
We can take help/input from i40 maintainers for it.
Hi Beilei Xing,
For setting packet_type as Tunnel, what criteria is used by i40 driver. Is it only udp_dst port or any other parameters also.

-----Original Message-----
From: Singh, Aman Deep <aman.deep.singh@intel.com> 
Sent: Thursday, January 20, 2022 12:47 PM
To: Matan Azrad <matan@nvidia.com>; Ferruh Yigit <ferruh.yigit@intel.com>; Raja Zidane <rzidane@nvidia.com>; dev@dpdk.org
Cc: stable@dpdk.org
Subject: Re: [PATCH] app/testpmd: fix GENEVE parsing in csum forward mode

External email: Use caution opening links or attachments


On 1/18/2022 6:49 PM, Matan Azrad wrote:
     app/test-pmd/csumonly.c | 16 ++++++++++------
     1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c 
index 2aeea243b6..fe810fecdd 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -254,7 +254,10 @@ parse_gtp(struct rte_udp_hdr *udp_hdr,
         info->l2_len += RTE_ETHER_GTP_HLEN;
     }

-/* Parse a vxlan header */
+/*
+ * Parse a vxlan header.
+ * If a tunnel is detected in 'pkt_type' it will be parsed by default as vxlan.
+ */
     static void
     parse_vxlan(struct rte_udp_hdr *udp_hdr,
             struct testpmd_offload_info *info, @@ -912,17 
+915,18 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
                                                 RTE_MBUF_F_TX_TUNNEL_VXLAN_GPE;
                                         goto tunnel_update;
                                 }
-                             parse_vxlan(udp_hdr, &info,
-                                         m->packet_type);
+                             parse_geneve(udp_hdr, &info);
                                 if (info.is_tunnel) {
                                         tx_ol_flags |=
-                                             RTE_MBUF_F_TX_TUNNEL_VXLAN;
+
+ RTE_MBUF_F_TX_TUNNEL_GENEVE;
                                         goto tunnel_update;
                                 }
-                             parse_geneve(udp_hdr, &info);
+                             /* Always keep last. */
+                             parse_vxlan(udp_hdr, &info,
+                                         m->packet_type);
                                 if (info.is_tunnel) {
                                         tx_ol_flags |=
-                                             RTE_MBUF_F_TX_TUNNEL_GENEVE;
+
+ RTE_MBUF_F_TX_TUNNEL_VXLAN;
                                         goto tunnel_update;
                                 }
                         } else if (info.l4_proto == 
IPPROTO_GRE) {


        

          
-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@intel.com>
Sent: Tuesday, January 18, 2022 3:03 PM
To: Matan Azrad <matan@nvidia.com>; Raja Zidane <rzidane@nvidia.com>; 
dev@dpdk.org
Cc: stable@dpdk.org
Subject: Re: [PATCH] app/testpmd: fix GENEVE parsing in csum forward 
mode

External email: Use caution opening links or attachments


On 1/18/2022 12:55 PM, Matan Azrad wrote:


          

            

            

              
-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@intel.com>
Sent: Tuesday, January 18, 2022 2:28 PM
To: Matan Azrad <matan@nvidia.com>; Raja Zidane 
<rzidane@nvidia.com>; dev@dpdk.org
Cc: stable@dpdk.org
Subject: Re: [PATCH] app/testpmd: fix GENEVE parsing in csum 
forward mode

External email: Use caution opening links or attachments


On 1/18/2022 11:27 AM, Matan Azrad wrote:


              

                

                

                  
-----Original Message-----
From: Ferruh Yigit <ferruh.yigit@intel.com>
Sent: Tuesday, January 18, 2022 11:52 AM
To: Raja Zidane <rzidane@nvidia.com>; dev@dpdk.org
Cc: Matan Azrad <matan@nvidia.com>; stable@dpdk.org
Subject: Re: [PATCH] app/testpmd: fix GENEVE parsing in csum 
forward mode

External email: Use caution opening links or attachments


On 12/5/2021 3:44 AM, Raja Zidane wrote:


                  

                    
The csum FWD mode parses any received packet to set mbuf 
offloads for the transmitting burst, mainly in the checksum/TSO areas.
In the case of a tunnel header, the csum FWD tries to detect 
known tunnels by the standard definition using the header'sdata 
and fallback to check the packet type in the mbuf to see if the 
Rx port driver already sign the packet as a tunnel.
In the fallback case, the csum assumes the tunnel is VXLAN and 
parses the tunnel as VXLAN.


                  

                  
As far as I can see there is a VXLAN port check in 
'parse_vxlan()', why it is not helping?



                

                
The problem is not the vxlan check but the tunnel type in mbuf 
that caused the


              

              
packet to be detected as vxlan(default) before checking GENEVE tunnel case.
Check is as following:

           if (udp_hdr->dst_port != _htons(RTE_VXLAN_DEFAULT_PORT) &&
                   RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
                   return;

Do you what is the intention for the 
"RTE_ETH_IS_TUNNEL_PKT(pkt_type) ==


            

          

          
0"


          

            

              
check?
Why vxlan parsing doesn't stop when it is not default port?


            

            
Maybe some drivers set the tunnel type for vxlan packets coming 
after non-


          

          
standard vxlan port.
But checking the tunnel flag to say that it is vxlan is too broad, isn't it?
And this is the problem you are having.

Can there be any way to detect and check non-standard vxlan port?


        

        
Maybe yes, but it is probably more complex solusion.

See this patch:
https://patches.dpdk.org/project/dpdk/patch/1423819371-24222-13-git-se
nd-email-olivier.matz@6wind.com/

comments there:
1. check udp destination port, 4789 is the default vxlan port (rfc7348).
2. currently, this flag is set by i40e only if the packet is vxlan

And maybe another driver assumes more ports here.

Collecting all the non-standard ports can start from i40 maintainers😊


      

      
I think, here we should check for supported tunnel types only.  The i40 driver setting a Tunnel flag, does not means that it VxLan type only.
As in your case those were GENEVE packets getting treated as VxLan.

Making parse_vxlan() udp_dst_port specific can avoid this issue.



      

        

          

            

              

                

                  

                    
When the GENEVE tunnel was added to the known tunnels in csum, 
its parsing trial was wrongly located after the pkt type 
detection, causing the csum to parse the GENEVE header as VXLAN 
when the Rx port set the tunnel packet type.

Locate the GENEVE parsing trial before the packet type detection.

Fixes: ea0e711b8ae0 ("app/testpmd: add GENEVE parsing")
Cc: stable@dpdk.org

Signed-off-by: Raja Zidane <rzidane@nvidia.com>
---
Acked-by: Matan Azrad <matan@nvidia.com>


                  

                  
Ack should be before '---' to be part of the commit log, 
otherwise it is dropped when applied as comment.



                  

                    

                  

                

              

            

          

        

      

    

  


--------------L5y100BVRbB2x5jdcGsQBBWs--