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 E55A9A0032; Fri, 18 Feb 2022 10:10:14 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B9C9540395; Fri, 18 Feb 2022 10:10:14 +0100 (CET) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id B0F6640150; Fri, 18 Feb 2022 10:10:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1645175413; x=1676711413; h=message-id:date:subject:to:cc:references:from: in-reply-to:mime-version; bh=ytnqUWnP3ObxWZxDsT/mll/ytKZZOBXJKzdBHYEL3Ng=; b=cnrrxAxc94e1GjvdEowr3/YJdQbXPRVxBBOtwqk04VlBFYGMO6zOf0YH cniihZ8IgmVZr4B6DtFqKF6TDtLclYXtZ59O1xUESfDP/F91o6J78C6XI alvkzUgCqChzgUmTpl005c/PgbHujVoe7UzzxsqUeH08j6r4VqBgdlMU4 x664762HLK4SLFYJ4m8q0ySBjLbPGvF+1uXn/156g4NBU8QaIPr74iJif vRZEexzf1XPhtAgZ4daC3vqWV7NBMJRzSNffTj8WcxYNLZ5LHuD2Cu7x4 rwFpOcaBkzlweBYB00fV/uBCXGwfRQGZtYGDGmFfURtjLCV+cdiffq3yi Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10261"; a="231072638" X-IronPort-AV: E=Sophos;i="5.88,378,1635231600"; d="scan'208,217";a="231072638" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2022 01:10:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,378,1635231600"; d="scan'208,217";a="682425143" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by fmsmga001.fm.intel.com with ESMTP; 18 Feb 2022 01:10:11 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 18 Feb 2022 01:10:11 -0800 Received: from fmsmsx604.amr.corp.intel.com (10.18.126.84) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Fri, 18 Feb 2022 01:10:11 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20 via Frontend Transport; Fri, 18 Feb 2022 01:10:11 -0800 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.172) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.20; Fri, 18 Feb 2022 01:10:10 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B3uWE8hA3D1ktKVQr21e9/Q/u1E/EmgKV0/AidKVZFvn4ZDdhet3ZC5X6JcWQ3ChQCvGp99cuLeMfb1WQh70O2hskt8L0dq8ULMqLhoxljZPXLAXkOwmfqx6oaXkcNkLR16loFsNdYeIY0dao3w4OUEMdD4jDU6/FUfNjX33SEcQRKQ3iiDWI7F3lVlgEK5STDgrfl6tMWdAf1zhrvTrntDuTLSBFuTt8KR9lWdjj9jYu2Rdrtwepj6E1P2fdQQJJe2PHHBADZVoSHBguY7M5wF+sTQy6E5+1TFP4jNMUHMX3k080TB3xSF1v+tIRXk1GLuq8NHok7+8hUvNPNMhIA== 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=WhjqszB01oSXJBJrk6sk0Zfwar331pnJkmVQ/74DPRM=; b=JE1FeTzhgCkMFM8/F/rofXfeZOJjeLkhx3JrHWfVbYuMQWluVJHZKCeb0JaNZlEiwobQaBAeONNiIoaqsPq4XxZZ3iDECSCNV1HeF6A71wPNTqErlhZZFJ7uZQxyT7f6sFAOrmAK0/0ThrghwDXLLxP0I8HwMQGiCCTzZ5ID/VYZfXdS4EpiK2THhG/9itoEsj40D79t08GrNSp4LFxZhNF7rkXPb4T9t+QqSUXDwKY4T6n+lvrAemTJQLw1poOzW1O2LXndj7Y1TrmeHZNv7cMu3lX0Mbl5Tws0ZgyW3zqiwsyi2Vo+EJsnmqnpdL1hKMB360UNLTg+p+PC6xcjSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; 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 SN6PR11MB2653.namprd11.prod.outlook.com (2603:10b6:805:63::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.17; Fri, 18 Feb 2022 09:10:08 +0000 Received: from MWHPR11MB0062.namprd11.prod.outlook.com ([fe80::dd62:304e:c73e:224a]) by MWHPR11MB0062.namprd11.prod.outlook.com ([fe80::dd62:304e:c73e:224a%5]) with mapi id 15.20.4995.019; Fri, 18 Feb 2022 09:10:08 +0000 Content-Type: multipart/alternative; boundary="------------CCqgDIcKkrrs9HCB3uZtIsfa" Message-ID: <667368b7-5897-63ef-6512-d2097d626afd@intel.com> Date: Fri, 18 Feb 2022 14:39:57 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH V2] app/testpmd: fix GENEVE parsing in csum forward mode Content-Language: en-US To: Raja Zidane , CC: Matan Azrad , References: <20211205034450.7888-1-rzidane@nvidia.com> <20220216123732.32617-1-rzidane@nvidia.com> From: "Singh, Aman Deep" In-Reply-To: <20220216123732.32617-1-rzidane@nvidia.com> X-ClientProxiedBy: BM1PR01CA0091.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00:1::31) 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: 538899a4-1375-4604-d942-08d9f2be7585 X-MS-TrafficTypeDiagnostic: SN6PR11MB2653:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8rLO14fO9ZTNBrZWMwNV4d+QwhEx431GvNXlVvgPlo6UzdhEF7WCKH5AURoD4CWMx0Py2vqQswgiftvcWNdA1lg59BTf6ot67/7445CFnjkoK9kuIcZWsoNawvdbbJNdudJ7skjCpIzoRzAgfa9PocsIF2oY1vLEtpagdqkkslCpVQ1MFAK7a36/giy/XP2bGSilbT42O3/clio0CwMnRWIDxt9bC+kZy4lICkkyIOm79y9DHK6GGkYI2kLWJGdnTBYLZ22NsAgP7PtuUcPOzu7cvcfUKcN7U18P/u/VhwXwCPbjDt67bHn5tYDv+JwAtJudam1fB4d8POFhUFOtYd8cwn4/IOlWErPUxDi4HbkbHo+Am4LNqW5ijuYkQU0yshzYgz4CPFICxb/6tdx3G4z/wiCEOe4E6aMqp5NXlr53iFomVzY1o/O4icbDzvfupNAXTJMyhOp4Q8uBGm3CO96lhS0mFJmNnKHQKM0BOGsldqQG7UIKQoElgV1MqOegkHHZHs2MaJTYAqtCVhtgE19vBuJNNY5Uv6peKYID3dkvh8UNgB2GwNwden8bichw1dkr+ua2gLvjFirnWNTNG4H4jtMGZNPQKCnJsT9LFXHUr0QdDyJj2I3dLw7AKiIFMR+YlnqioharGe5gaNDIcDZa9JHcoi2GtP7iJqyYBdpmyjkForRTe1tKGUs65mHZzSEX3QxKjAGzwzRsBaP0jrcN/OHix8Y3TOFkPOHjDCY= 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)(38100700002)(6666004)(2906002)(6506007)(82960400001)(33964004)(5660300002)(316002)(6512007)(6486002)(508600001)(83380400001)(186003)(26005)(2616005)(53546011)(86362001)(31686004)(31696002)(8936002)(8676002)(66946007)(66556008)(66476007)(4326008)(36756003)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dytJNHVIb0cwSlREaGNwZmRTMG5rMk9KWDY2SlhvNitNT2tqSDByTm10Zk9h?= =?utf-8?B?RzdVWGJYdkhVQy8xQ09zdUZIY2o1MEpUNjVKbVlRckZJaUtSMjZnZk5NbkVl?= =?utf-8?B?ak5BT1NBeDlIbEZxdVNxYkJJYkhtWFFUVXJXRjB4MFlXcE1Xc09vR2pDbElU?= =?utf-8?B?SWplTjFoN2s5YjU4S2ZkVE1JWWJBYlI2UDFvdzdxbGZJcm9uOUFYQm1Nek9U?= =?utf-8?B?YkJGQ2poOVVsTTArTCtXeVlBNURrNEZoMmVxSzNjM1ZxcWtJV005TE5HOFo1?= =?utf-8?B?ZFJJWlpPNlROT3I4SEQwQkIwOFBKRlpRM1Z6NFNucFBVeFB4VVhRYUhtMnB4?= =?utf-8?B?aFNwWU9xVkozcTdvZ2tmWHRrMjFRYktVQWx0L3ZRZlpwSThXa0IzeWpFLzU4?= =?utf-8?B?ZmZRNE9mR0VuSTBEL0lEV2pnQlJsbVd4WGllZ2JsVHI2UDNpb0hpQkpnWTNB?= =?utf-8?B?L092L0Y0WjhSTVJQemhoMnJWRXdWa3ZSek9zeDlWQUNZT2V4L0pFVzkwcWRV?= =?utf-8?B?enNLdWc5K3B2ZnV4VGl0d3haYzNodi9CcGJxYk1OeU9KR0RNczRtL3JuaDJN?= =?utf-8?B?S1ZoclM3QWxqRlZyRHRjQWxPRkd4LzUzdFh3aWorRmxEYksvczhjb2dpWldU?= =?utf-8?B?VGNPb21zbVdLUVlYaGFKUWVuLzlIQ1NkNUs5YndaNU9PdDcwb3M5N21HVjJu?= =?utf-8?B?NW92OE0xQW5NekVUT3p2ZVRUTUpQTUtxSkdkNFBYNUlHSDg2L0VLSTR4Tngz?= =?utf-8?B?SjZUcXVXNE9aMzdicnM3aDM2eUlLem53OTZacmRQeVg4ODR3RGIzVDg4NndQ?= =?utf-8?B?MmwvMlYyeUhOYURRWXV3Rk9JT3Q1blFpUjcrWXBIN1lSVWNOUkd6YWJpRjlY?= =?utf-8?B?d21Sa1RTLzBCTUp3eHg5MmpVWVYwWldqQ0gvd1Z2c2xEMmlFUTh1MnZVbnFF?= =?utf-8?B?OW13Q3ltR1NHR3M5dGZhVWQzbmVUb1pGRVVqd1EzZGlFSHpvVlpkeFMvMlVs?= =?utf-8?B?TjNUaVdxUWtZWHVzaXM3dDZnVU1DNzJYbEI4QXNtTEZORGozZWJOUUpNd1hK?= =?utf-8?B?bHY3Q3FMQU5tZFgxcUZHVDZLMUJ6R0NqYi96VWxTRXY3MWppREFDUExkTEZh?= =?utf-8?B?L3ZqcksxWXgyRzljd3prSzBNS2dqVWM3dHkzRG9Jb2tHNThieW54SEdSZDlS?= =?utf-8?B?cFNnTzdKU0prbWMxaVpPZ1huT1BqL1VHNVF3VGFJWnJIUEJacXVadkUrTlJu?= =?utf-8?B?aE9jSS9QYTMzeUxJMkFNYjU3ZUowVzFuMWg3dEgyeVJiam5jUUxiVzB1Skdr?= =?utf-8?B?N1lmak0wQU1sS1lyQVd5aElmNFJ3N1JlaXpLem1RSDRNbC9VNmJLTHRXeHpP?= =?utf-8?B?YVVxTENqVE1nSTJGTldSaWUvNTdFb1FxMTR3Y0h3VFJ1U3NpS25uOXo1QkZX?= =?utf-8?B?OTlsTE1JT0JIWXRUR0FnQW9CL2M1MnM1aGR2UHg5bkxEWjNuc253VUZQVXcv?= =?utf-8?B?MkJFMDBrbEtxbHJOSGhuandPQ0VhZktQV2pUUGpzbTg0eGtkbXB1SWdHeXd5?= =?utf-8?B?TGJyMjlncHdJQis4RGxLejM0ZUE1dzdFUExqWVlERWt3N2FaZCs3OU5WVUFr?= =?utf-8?B?NUJ2cUFMWWpKamd5TGJLQnhIQld6R0FUVERiUW5CczZNSHI5Z05ZNEpscFpH?= =?utf-8?B?YkoyMmVhUlJGWmJST3FHTFN5b2hJWnNjaDVzbDEvc0kwRlRZdG5xcjdVRjZH?= =?utf-8?B?bmdENWhBTFhjUmdYOUR5a3NrS1I4STdDaVFVMTZaeCttR2t3L2wvRnlnWS9i?= =?utf-8?B?WUNiY3dpR1A5WWY5eFdXWWpXZVIveDN1YmIvSEJUQzI3RzNieUhBc3FjN0lp?= =?utf-8?B?RXFQeE9zWEZodGtVTHZSWk82WEZqUjhyTS84THV4MXljeTkwVFlVWXJNcmh0?= =?utf-8?B?enJCdFNhNitGOHpXQjB0RGR5cGl6eHh1UktWdjE1WVVOSG1sTVJQejBQNlZR?= =?utf-8?B?MU1pWFVxdG1JR1hGU04zZU5NT2lBY3lkVVAyUnFPclVoYS8ySTVsQlUxakNP?= =?utf-8?B?YVczaEdZZGx3VlZDWmt6eW1XUk5IakF4S2lBZDNKRVNBWVlsajBmaU1xMWxT?= =?utf-8?B?MGJ0amdVeDJjcVdsbkR6Z0ZlUlJwb0JFY2tIU0lLY1JRQlFTekExNEdkUjdU?= =?utf-8?B?cEhGc3JwcCtvblBqOC9xdUZ3bjR6VWtvc0lHc2hSSDJ6alZMd3JjcmV4SDB0?= =?utf-8?Q?YbXHWI8COXFVAXQ2A8MOBBPKSiTiNcVsnspY+U0jt0=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 538899a4-1375-4604-d942-08d9f2be7585 X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB0062.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2022 09:10:08.3112 (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: D64WxbY+DesoHxDlprmQLjfMgp0y3ZeXHQrETZUwSU496QcWGzKsU/v+F/nProsOxU4jb/yuuwhfZXS69Ww7Ty/4WJwjLNQ7Q36wVsevtyQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2653 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 --------------CCqgDIcKkrrs9HCB3uZtIsfa Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 2/16/2022 6:07 PM, 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. > 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. > > Remove the fall back case to VxLan. > Log error of unrecognized tunnel if no tunnel was parsed successfully. > > Fixes: ea0e711b8ae0 ("app/testpmd: add GENEVE parsing") > Cc:stable@dpdk.org > > Signed-off-by: Raja Zidane > --- > V2: Log error when an unrecognized tunnel is found (unknown UDP dst port), instead of parsing it as VxLan by default. > > app/test-pmd/csumonly.c | 23 +++++++++++++---------- > 1 file changed, 13 insertions(+), 10 deletions(-) > > diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c > index 02bc3929c7..210f4263f8 100644 > --- a/app/test-pmd/csumonly.c > +++ b/app/test-pmd/csumonly.c > @@ -255,11 +255,10 @@ parse_gtp(struct rte_udp_hdr *udp_hdr, > info->l2_len += RTE_ETHER_GTP_HLEN; > } > > -/* Parse a vxlan header */ > +/* Parse a vxlan header. */ > static void > parse_vxlan(struct rte_udp_hdr *udp_hdr, > - struct testpmd_offload_info *info, > - uint32_t pkt_type) > + struct testpmd_offload_info *info) > { > struct rte_ether_hdr *eth_hdr; > > @@ -267,8 +266,7 @@ parse_vxlan(struct rte_udp_hdr *udp_hdr, > * default vxlan port (rfc7348) or that the rx offload flag is set > * (i40e only currently) > */ > - if (udp_hdr->dst_port != _htons(RTE_VXLAN_DEFAULT_PORT) && > - RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0) > + if (udp_hdr->dst_port != _htons(RTE_VXLAN_DEFAULT_PORT)) > return; > > update_tunnel_outer(info); > @@ -922,19 +920,24 @@ 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); > + parse_vxlan(udp_hdr, &info); > if (info.is_tunnel) { > tx_ol_flags |= > - RTE_MBUF_F_TX_TUNNEL_GENEVE; > + RTE_MBUF_F_TX_TUNNEL_VXLAN; After adding default case, i suppose swapping of parse_vxlan & parse_geneve is not needed. Can we revert these above changes. > goto tunnel_update; > } > + /* Always keep last. */ > + if (unlikely(RTE_ETH_IS_TUNNEL_PKT( > + m->packet_type) != 0)) { > + TESTPMD_LOG(ERR, "Unknown tunnel packet. UDP dst port: %hu", > + udp_hdr->dst_port); > + } > } else if (info.l4_proto == IPPROTO_GRE) { > struct simple_gre_hdr *gre_hdr; > --------------CCqgDIcKkrrs9HCB3uZtIsfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit


On 2/16/2022 6:07 PM, 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.
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.

Remove the fall back case to VxLan.
Log error of unrecognized tunnel if no tunnel was parsed successfully.

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

Signed-off-by: Raja Zidane <rzidane@nvidia.com>
---
V2: Log error when an unrecognized tunnel is found (unknown UDP dst port), instead of parsing it as VxLan by default.

 app/test-pmd/csumonly.c | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 02bc3929c7..210f4263f8 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -255,11 +255,10 @@ parse_gtp(struct rte_udp_hdr *udp_hdr,
 	info->l2_len += RTE_ETHER_GTP_HLEN;
 }
 
-/* Parse a vxlan header */
+/* Parse a vxlan header. */
 static void
 parse_vxlan(struct rte_udp_hdr *udp_hdr,
-	    struct testpmd_offload_info *info,
-	    uint32_t pkt_type)
+	    struct testpmd_offload_info *info)
 {
 	struct rte_ether_hdr *eth_hdr;
 
@@ -267,8 +266,7 @@ parse_vxlan(struct rte_udp_hdr *udp_hdr,
 	 * default vxlan port (rfc7348) or that the rx offload flag is set
 	 * (i40e only currently)
 	 */
-	if (udp_hdr->dst_port != _htons(RTE_VXLAN_DEFAULT_PORT) &&
-		RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
+	if (udp_hdr->dst_port != _htons(RTE_VXLAN_DEFAULT_PORT))
 		return;
 
 	update_tunnel_outer(info);
@@ -922,19 +920,24 @@ 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);
+				parse_vxlan(udp_hdr, &info);
 				if (info.is_tunnel) {
 					tx_ol_flags |=
-						RTE_MBUF_F_TX_TUNNEL_GENEVE;
+						RTE_MBUF_F_TX_TUNNEL_VXLAN;
After adding default case, i suppose swapping of parse_vxlan & parse_geneve is not needed.
Can we revert these above changes.


 					goto tunnel_update;
 				}
+				/* Always keep last. */
+				if (unlikely(RTE_ETH_IS_TUNNEL_PKT(
+							m->packet_type) != 0)) {
+					TESTPMD_LOG(ERR, "Unknown tunnel packet. UDP dst port: %hu",
+						udp_hdr->dst_port);
+				}
 			} else if (info.l4_proto == IPPROTO_GRE) {
 				struct simple_gre_hdr *gre_hdr;
--------------CCqgDIcKkrrs9HCB3uZtIsfa--