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 A7DDAA0093 for ; Fri, 11 Mar 2022 10:04:25 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BD8C34113E; Fri, 11 Mar 2022 10:04:24 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by mails.dpdk.org (Postfix) with ESMTP id ADD6D40042; Fri, 11 Mar 2022 10:04:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646989462; x=1678525462; h=message-id:date:subject:to:cc:references:from: in-reply-to:mime-version; bh=Z8s82wwvOToZrBVvP6aJRMHoKfJA0PgUV2+T1Rtjbi8=; b=kwESaHhi79JO7++77ZnB07682QUMCfUVR9RM/mjv0NgZ86qFlkG1m7Lq Gz/Ij0qcQBXBioZ78MeTNS5jNNy+/lCX8xUD1GnLHgltha9COIa0YzvMl WWcaNRHNvw191flVkX2GySYBEGSK7wfe/k/IVD/b6lTUBzPdivj0grXUr 8mtYmuN7z7rMPdv8XSweBizTT3K5NS31ImK7NpzetBJUI+xXLukAhRUVC WmprNk3KdASJoVvD57/JV6NT4jYTlW+fqgQ7h5pz5avW2fn8Ck6wUtZOb tKwW3z6vGNu3f7EowfWgvFnaVpaAakpIo3O73WLfetOukzC05uqTGcGNf g==; X-IronPort-AV: E=McAfee;i="6200,9189,10282"; a="236136625" X-IronPort-AV: E=Sophos;i="5.90,173,1643702400"; d="scan'208,217";a="236136625" Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2022 01:04:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,173,1643702400"; d="scan'208,217";a="816554827" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmsmga005.fm.intel.com with ESMTP; 11 Mar 2022 01:04:20 -0800 Received: from fmsmsx605.amr.corp.intel.com (10.18.126.85) 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.21; Fri, 11 Mar 2022 01:04:20 -0800 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21 via Frontend Transport; Fri, 11 Mar 2022 01:04:20 -0800 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.57.46) 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.21; Fri, 11 Mar 2022 01:04:19 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ldMlXa++ilC0wEcrrOQYjFOAysqqslooLHWtucXTVvC8jUvrXmnZOYkBcNT/9ZEbcUrHx9E4SndcqwICdI8qa3aKcVfdqO+qdAx16u6jyYZawulmAexMG55LnuIwoBFV2ubrv9nvGRDOy+u7VhsVTv0C4wxYH9CQeGEjAVmfW2YoC0VH+Pjw3kb/LFA7tzwPyLKgSQbEFw/UldDeZBn8QgnUj+uY9cuREsyU1dea2wRQtIjgpMZXLoTxnovUpbfTgop9pFXe+UJNnycfumw3ApAzLybkGE19vX8jZmvryNwZTgZvHKLrLbnj1nXaS5dlnAOZePTWcfELXF0vUh6oWA== 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=ne2Fme6nMe8/6mps0CGQ7jf/AnqGfX5of58RKlepu5I=; b=SxFTWruKc7NTHrBN+ZGQH0Tf5rCPXEqusjDRaBMsy1Kepsi3Gs63H+UWRwIqi9jnKDAFDCjQVOB+vSuJtP2R95gkWnplGizHj5otTxtSbqB1BMoAwHXmFKy0WlWmiZ/Bon7YO/ZWxNe0wEvezdxY/EDHkEm5DKHHx1Rknn8My4Iu2MRi+QgI2IQC0+owSLmXTcKD6tdV4xes7iO05PYP5jhxXbS/gUR+o6xV8xjR1SjHqTmeNgXM5UwfKYp0nY5TsxDpL6gDzxZ42q7oJ2HqG683tHn9To5pIO5oiphccuyP6qv1JZ1FsHqgfWgk+Xq828EkmnOhY+iP3dFdHIKEuQ== 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 CY4PR11MB0054.namprd11.prod.outlook.com (10.171.254.155) by BY5PR11MB3957.namprd11.prod.outlook.com (10.255.72.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.21; Fri, 11 Mar 2022 09:04:14 +0000 Received: from CY4PR11MB0054.namprd11.prod.outlook.com ([fe80::9169:317:eb80:8fe]) by CY4PR11MB0054.namprd11.prod.outlook.com ([fe80::9169:317:eb80:8fe%6]) with mapi id 15.20.5017.026; Fri, 11 Mar 2022 09:04:13 +0000 Content-Type: multipart/alternative; boundary="------------sB37U9JS1WOWkVi8CRYcRvi3" Message-ID: <7a4c3525-556c-7a23-d58d-361e41a6220c@intel.com> Date: Fri, 11 Mar 2022 14:34:02 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH v2 2/2] app/testpmd: fix SW L4 checksum in multi-segments Content-Language: en-US To: "Liu, KevinX" , "Zhang, Qi Z" , dev , "Yigit, Ferruh" CC: "Yang, Qiming" , "Yang, SteveX" , "Xing, Beilei" , "Li, Xiaoyun" , dpdk stable , "Zhang, Yuying" References: <20211224150925.3296471-1-kevinx.liu@intel.com> <20211229093702.1930214-1-kevinx.liu@intel.com> <20211229093702.1930214-3-kevinx.liu@intel.com> <6d546177-6bb7-5e0b-817a-7e2551d7a0fb@intel.com> From: "Singh, Aman Deep" In-Reply-To: X-ClientProxiedBy: BM1PR01CA0104.INDPRD01.PROD.OUTLOOK.COM (2603:1096:b00::20) To CY4PR11MB0054.namprd11.prod.outlook.com (2603:10b6:910:79::27) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e4f7a9ff-d56f-40f0-5681-08da033e1ce2 X-MS-TrafficTypeDiagnostic: BY5PR11MB3957:EE_ X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SZYy3NF3LKK3B8t+YCnjAefVRbX5k8T5EgB/M4bmfMFHERlZEUxD/kj+km5u1AGL0LdRU3aYNVwg8n5J6b3QFXx8fFcksV7yaUamhQNSWgCH0baY+uS9MrdwKbId34D32n93Vw5a3RFiwWakFAHAah7NLg689Xw7BGbHG08cHQYMR+v2/8M2zZx2xaw6Lfu3iPN8fazK9dqzTvBlRsMO1oA+XPEnlMvZQMrsKiDpPrKWj9Ir+WEwS2VjT7eqdBR6fiLGL5dbc3I1d3I8RrJhFb4HO+/HPeOYG0WGjy3n/3sAunjMei/kchvgtDGgLx7Ss5py3A/DukWtcX9RNhG6FSx/MgDSeil/XscBB15NQWTpR+9KyLnpaBkEa/V8fq9wGPj1Q9gmhokl+H+WZsbcIm2BbUEB5nE82/rABLXbuY06rEK/ledQw9M4mF+k9F1go+9PlYnvFJc92cmMVZaMnst3LY6MoZC0o+pOX3n5+2ikAnf7Rea+du9AYlqXsXvtRF5QtG0je7cCqM5v4eL7td6naZjRAGbujl48PzklIVloOZooAFMCnSRA89aatu6y3x4WCEZ6L0YHVF20gx0MEgDwEdWgjlzDZO4DlLjghCrmQMoUqwlf5cWU9gYnEBlrCScsq2ROiQQcnZtLTxwtcqW5bayrDZxlDq9CIgbWdjVfKH1mpqL1b6Yia7TERm2yfyAB4PCCXmq8xj6mYqlMcwgGYvdYVyKfaUzpyKMDCZQ= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR11MB0054.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(53546011)(8936002)(110136005)(54906003)(38100700002)(31696002)(316002)(4326008)(33964004)(6666004)(6636002)(450100002)(5660300002)(8676002)(66556008)(66476007)(66946007)(508600001)(6512007)(82960400001)(6506007)(6486002)(107886003)(86362001)(31686004)(186003)(26005)(2616005)(36756003)(83380400001)(2906002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Q1hiTXhveTZpcWZiV05KZWw3ajZ2RlkrcnhTeHlWRVEzRE9kd0tPVW4yV1Fl?= =?utf-8?B?ZERmeXRZcG9waTRwUzBhcjUrOHJmMVRLU3doQ0tiZXFOU1p6NWlYSUdzNkhv?= =?utf-8?B?TUtJVmdkbWY5TERWdGtodG80eGRyWTBVSTZZZnRTSmNWYklQYjg2d0NCZFBG?= =?utf-8?B?ME9mQ3Q0NVg5OU1zL0RtSnFIWkdNeExJZ2hPYm1GVlRaeENxYzJMUGc5SFhn?= =?utf-8?B?ZVRGTlZqQkJod2RldlJ3eGhoV0lGUFF1QU1PZ3NEUkZGOVB0MFFCdjRIcW80?= =?utf-8?B?ZlpVdzZQVTNkS0tiZm9DSExEREZzalB0MzdtK052RGplY09Xd0dDYmtLNzUx?= =?utf-8?B?ZXBqVVBneGRwaE54Zy9PazhFTW1kbWp0NkFTb0w5S0pUUENBbmo5YUI3N0lx?= =?utf-8?B?MHhqTzhvM3d6dS9xTWluS3IwUEMva0JrUXlMMFJuMnZVbjViZXl1eWdFeUxy?= =?utf-8?B?aDFoV0tEMkxkM0FOTDBERGZUbDhtOUxVemJwWWpVSUZUbks0YjRLeUhvY0xP?= =?utf-8?B?a1ZaQ0Rha1dvWE10dUZGMlE4cm5tNWxZUjRiTkNqUzgzUmFTT1Bwc0FaWmlC?= =?utf-8?B?MmUyd0loYjJJQzB6YnlwSEtNQ3gvZ28rdjBrVnhjY3AwNXZNMER5VlprYldF?= =?utf-8?B?WXE2b3lOTTVMMUhpcGRjQnRQS1R6WEIrVmJNVUN1YklISWs3NjFoMm1IUHRj?= =?utf-8?B?R3JTeE43akFkOFVDOGQvdTNxUnh4N0lMNlBwd2cvVU5Zb1BKSVRic0YwaTdC?= =?utf-8?B?dmJUclNDb2JEeXh4bTVjaFowVmRoV2FRNkZFSndwMU1TZmo0SEZVTklmYXV3?= =?utf-8?B?bGF4WXl0cytWZmxHTGhsUjJXek8wVGVBQVJ1UlJueVFsbFdKUCt4U09rL2xm?= =?utf-8?B?dXorWmswUkdhZkJtZlpSRUkrNGJlZGZHOUsvVHk2Q3dnNDRqME81aVd4VXli?= =?utf-8?B?SGRWWkV5NDM3UnFHRm9VUCsxN2RJLzFXMm9keWdtZ0hnSHduYm9IQ1BSVHN5?= =?utf-8?B?NWtPbHlFRUdMZXJhSzJkTDhQYTdkb21rVU5TRVNteVl2QkhtaWtpZ3V3ai9W?= =?utf-8?B?UjZtTmZ5bHdGdGo3QnVCbmdQSEFDMHhSclNha3dyQzN5OUdveGVLSVhOdzI3?= =?utf-8?B?ZHVnNzFJcnVqYlBZeExmWUQwbmtzZWRXQUNNUlloNy9WYkpJOTU0U2FreFlL?= =?utf-8?B?aVdienZ0bGd2NmN0VTN6YVZna015N2w0N1o1Y0lrNmxDUWRhcWRwUGFGZ01z?= =?utf-8?B?TStGVGJRMGFoMkNpdEVoZHlYYUJQcDhzNXN3Q3RpMXlJeENCaXhLd2VnOW5J?= =?utf-8?B?QzFoSG9JNU9IY01ia1JRa3pleVdoYmpkb2JxK1pYYUVEYlZUMXV6cHNZSTA0?= =?utf-8?B?aFkwbEh6UnIwTTlSK0R4ek1yTWJEWTViOHBQV1JvUWhVdlhaL2I4RURWd0pK?= =?utf-8?B?SHEwSzhCRU1OdnhXSk1DWFl2dFgvZ2g1Y0Z5aDczYkd3TzVkUXo3empnekh6?= =?utf-8?B?VG1kQm9ScmN2M3RwRXR0aXpQcHc1VW9QSnE2L1hsZFNzaHdvMk9wczhucEhK?= =?utf-8?B?MWh2cnJtOElvTWgvUTBrSEN4L2VrclJNODFGNWppc0FpQlBJeVcxTXQ3eVNS?= =?utf-8?B?QlI2ak8reHlhV21VK1BvNTlPYlZySVI4dU44c3BodkM1NFNCK0dtUjU2WnZ2?= =?utf-8?B?eldqczJKRkZweXhxTlVadjBZejRhb1BYSms1WGJMYThMUWp6Wm9ETTVPbTVF?= =?utf-8?B?NlFkdHFHTE5rT1ZHS1BtbjRiSzJ5R1RJT3Vsb3YzOThETTVlK0UzQ2JjR3NN?= =?utf-8?B?TXFEMFNmOS94cENKUEFFTytuZ0pHRHIwVzRFcFJmQlNMdjdiYVZwMnlhZXBy?= =?utf-8?B?c0xBODYrS2pWVG5aOGJiTXdrZWtQSkgxOUxtWktXK3FtY1I5alBaQ0JQcG4v?= =?utf-8?B?UkF0bUdZakI4dnY0WnJFK0huSERXSWhmekVwQTNjOUJCdm9rZWhRajkzY0J1?= =?utf-8?B?VlFoVmtva3VoMEROVk11Zm1lbVlDekdmMnVScFovWWlBRmZhVVE1bWpUNDhY?= =?utf-8?B?bzRqaHVHajF5ZjhTZmN4K1BlaDZzOU9qVTZtVGZvNkQ2ZGlCbitGeW40ZHpj?= =?utf-8?B?RmtRZ3J5OGtqckVqMUhGNDNnc0V5VDl4RVdKZEhhekRmaTRkQjludmJWcVNj?= =?utf-8?B?anExejJ3YkpJWFhlQ3VDMjdqb1V2NmViNE4ycXd0M0V1SklJUUlWeW55WlVv?= =?utf-8?Q?KoEFTWILMMlLYzR271CjAazNJKsIMvSF+n3tWONZP4=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: e4f7a9ff-d56f-40f0-5681-08da033e1ce2 X-MS-Exchange-CrossTenant-AuthSource: CY4PR11MB0054.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2022 09:04:13.8172 (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: YWT2ezyObcOc5JQBYNDXijjC48DZ8ambgM8LlCl9VQQpw+mR/HX97oJrlGPbOBBiBiAeN3a5yppKX2/IzK+4/eII3dlk0T81kZwFlnD6BLU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3957 X-OriginatorOrg: intel.com X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org --------------sB37U9JS1WOWkVi8CRYcRvi3 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit On 3/11/2022 1:42 PM, Liu, KevinX wrote: > >> -----Original Message----- >> From: Singh, Aman Deep >> Sent: 2022年3月11日 16:02 >> To: Liu, KevinX; Zhang, Qi Z; >> dev; Yigit, Ferruh >> Cc: Yang, Qiming; Yang, SteveX >> ; Xing, Beilei; Li, Xiaoyun >> ; dpdk stable; Zhang, Yuying >> >> Subject: Re: [PATCH v2 2/2] app/testpmd: fix SW L4 checksum in multi- >> segments >> >> Hi Kevin, >> >> On 3/11/2022 12:34 PM, Liu, KevinX wrote: >>> Hi, Ferruh >>> >>> Yuying has already reviewed it days ago. >>> If you can, I hope you can change the status as soon as possible and try to >> merge the code in RC4. >>> Thank you. >>> >>>> -----Original Message----- >>>> From: Zhang, Yuying >>>> Sent: 2022年3月3日 14:30 >>>> To: Zhang, Qi Z; Liu, KevinX >>>> ; dev >>>> Cc: Yang, Qiming; Yang, SteveX >>>> ; Yigit, Ferruh; >>>> Xing, Beilei; Li, Xiaoyun >>>> ; dpdk stable >>>> Subject: RE: [PATCH v2 2/2] app/testpmd: fix SW L4 checksum in multi- >>>> segments >>>> >>>> LGTM. >>>> >>>>>> -----Original Message----- >>>>>> From: Liu, KevinX >>>>>> Sent: Wednesday, December 29, 2021 5:37 PM >>>>>> To:dev@dpdk.org >>>>>> Cc: Yang, Qiming; Zhang, Qi Z >>>>>> ; Yang, SteveX; >>>>>> Yigit, Ferruh; Liu, KevinX >>>>>> ;stable@dpdk.org >>>>>> Subject: [PATCH v2 2/2] app/testpmd: fix SW L4 checksum in >>>>>> multi-segments >>>>>> >>>>>> Testpmd forwards packets in checksum mode that it needs to >>>>>> calculate the checksum of each layer's protocol. >>>>>> >>>>>> In process_inner_cksums, when parsing tunnel packets, inner L4 >>>>>> offset should be outer_l2_len + outer_l3_len + l2_len + l3_len. >>>>>> >>>>>> In process_outer_cksums, when parsing tunnel packets, outer L4 >>>>>> offset should be outer_l2_len + outer_l3_len. >>>>>> >>>>>> Fixes: e6b9d6411e91 ("app/testpmd: add SW L4 checksum in multi- >>>>>> segments") >>>>>> Cc:stable@dpdk.org >>>>>> >>>>>> Signed-off-by: Kevin Liu >>>> Acked-by: Yuying Zhang Acked-by: Aman Singh >>>> >>>>>> --- >>>>>> app/test-pmd/csumonly.c | 6 +++--- >>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) >>>>>> >>>>>> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c >>>>>> index >>>>>> 02bc3929c7..c235456e58 100644 >>>>>> --- a/app/test-pmd/csumonly.c >>>>>> +++ b/app/test-pmd/csumonly.c >>>>>> @@ -513,7 +513,7 @@ process_inner_cksums(void *l3_hdr, const >> struct >>>>>> testpmd_offload_info *info, ol_flags |= >>>> RTE_MBUF_F_TX_UDP_CKSUM; } >>>>>> else { if (info->is_tunnel) -l4_off = info->l2_len + >>>>>> +l4_off = info->outer_l2_len + >>>>>> info->outer_l3_len + >>>>>> info->l2_len + info->l3_len; >> This seems OK. A similar miss is present for TCP case also. >> Can you please do the same for that. Line 537 >>>>>> else >>>>>> @@ -536,7 +536,7 @@ process_inner_cksums(void *l3_hdr, const >> struct >>>>>> testpmd_offload_info *info, ol_flags |= >>>> RTE_MBUF_F_TX_TCP_CKSUM; } >>>>>> else { if (info->is_tunnel) -l4_off = info->l2_len + >>>>>> info->outer_l3_len + >>>>>> +l4_off = info->outer_l2_len + info- >>>>>>> outer_l3_len + >>>>>> info->l2_len + info->l3_len; >>>>>> else >>>>>> l4_off = info->l2_len + info->l3_len; @@ - >> This change might not be required. As for normal packet (non-tunnel case) >> l4_off = info->l2_len + info->l3_len;  should be valid. >> Please re-check. > I don't understand what you mean. I fix the code under the tunnel case, and I didn't modify the code for the non-tunnel case. Sorry, my bad. >> >>>>>> 625,7 +625,7 @@ process_outer_cksums(void *outer_l3_hdr, struct >>>>>> testpmd_offload_info *info, if (udp_hdr->dgram_cksum != 0) { >>>>>> udp_hdr->dgram_cksum = 0; udp_hdr->dgram_cksum = >>>>>> get_udptcp_checksum(m, outer_l3_hdr, >>>>>> -info->l2_len + info->outer_l3_len, >>>>>> +info->outer_l2_len + info- >>>>>>> outer_l3_len, >>>>>> info->outer_ethertype); >>>>>> } >>>>>> >>>>>> -- >>>>>> 2.33.1 --------------sB37U9JS1WOWkVi8CRYcRvi3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
On 3/11/2022 1:42 PM, Liu, KevinX wrote:


-----Original Message-----
From: Singh, Aman Deep <aman.deep.singh@intel.com>
Sent: 2022年3月11日 16:02
To: Liu, KevinX <kevinx.liu@intel.com>; Zhang, Qi Z <qi.z.zhang@intel.com>;
dev <dev@dpdk.org>; Yigit, Ferruh <ferruh.yigit@intel.com>
Cc: Yang, Qiming <qiming.yang@intel.com>; Yang, SteveX
<stevex.yang@intel.com>; Xing, Beilei <beilei.xing@intel.com>; Li, Xiaoyun
<xiaoyun.li@intel.com>; dpdk stable <stable@dpdk.org>; Zhang, Yuying
<yuying.zhang@intel.com>
Subject: Re: [PATCH v2 2/2] app/testpmd: fix SW L4 checksum in multi-
segments

Hi Kevin,

On 3/11/2022 12:34 PM, Liu, KevinX wrote:

Hi, Ferruh

Yuying has already reviewed it days ago.
If you can, I hope you can change the status as soon as possible and try to

merge the code in RC4.

Thank you.


-----Original Message-----
From: Zhang, Yuying <yuying.zhang@intel.com>
Sent: 2022年3月3日 14:30
To: Zhang, Qi Z <qi.z.zhang@intel.com>; Liu, KevinX
<kevinx.liu@intel.com>; dev <dev@dpdk.org>
Cc: Yang, Qiming <qiming.yang@intel.com>; Yang, SteveX
<stevex.yang@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
Xing, Beilei <beilei.xing@intel.com>; Li, Xiaoyun
<xiaoyun.li@intel.com>; dpdk stable <stable@dpdk.org>
Subject: RE: [PATCH v2 2/2] app/testpmd: fix SW L4 checksum in multi-
segments

LGTM.


-----Original Message-----
From: Liu, KevinX <kevinx.liu@intel.com>
Sent: Wednesday, December 29, 2021 5:37 PM
To: dev@dpdk.org
Cc: Yang, Qiming <qiming.yang@intel.com>; Zhang, Qi Z
<qi.z.zhang@intel.com>; Yang, SteveX <stevex.yang@intel.com>;
Yigit, Ferruh <ferruh.yigit@intel.com>; Liu, KevinX
<kevinx.liu@intel.com>; stable@dpdk.org
Subject: [PATCH v2 2/2] app/testpmd: fix SW L4 checksum in
multi-segments

Testpmd forwards packets in checksum mode that it needs to
calculate the checksum of each layer's protocol.

In process_inner_cksums, when parsing tunnel packets, inner L4
offset should be outer_l2_len + outer_l3_len + l2_len + l3_len.

In process_outer_cksums, when parsing tunnel packets, outer L4
offset should be outer_l2_len + outer_l3_len.

Fixes: e6b9d6411e91 ("app/testpmd: add SW L4 checksum in multi-
segments")
Cc: stable@dpdk.org

Signed-off-by: Kevin Liu <kevinx.liu@intel.com>

Acked-by: Yuying Zhang <yuying.zhang@intel.com>

Acked-by: Aman Singh <aman.deep.singh@intel.com>


---
  app/test-pmd/csumonly.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index
02bc3929c7..c235456e58 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c


              

                
@@ -513,7 +513,7 @@ process_inner_cksums(void *l3_hdr, const


              

            

          

        

        
struct


        

          

            

              

                
testpmd_offload_info *info,  ol_flags |=


              

            

            
RTE_MBUF_F_TX_UDP_CKSUM;  }


            

              

                
else {  if (info->is_tunnel) -l4_off = info->l2_len +
+l4_off = info->outer_l2_len +
   info->outer_l3_len +
   info->l2_len + info->l3_len;


              

            

          

        

        
This seems OK. A similar miss is present for TCP case also.
Can you please do the same for that. Line 537


        

          

            

              

                
  else
@@ -536,7 +536,7 @@ process_inner_cksums(void *l3_hdr, const


              

            

          

        

        
struct


        

          

            

              

                
testpmd_offload_info *info,  ol_flags |=


              

            

            
RTE_MBUF_F_TX_TCP_CKSUM;  }


            

              

                
else {  if (info->is_tunnel) -l4_off = info->l2_len +
info->outer_l3_len +
+l4_off = info->outer_l2_len + info-


                

                  
outer_l3_len +


                

                
   info->l2_len + info->l3_len;
  else
  l4_off = info->l2_len + info->l3_len; @@ -


              

            

          

        

        
This change might not be required. As for normal packet (non-tunnel case)
l4_off = info->l2_len + info->l3_len;  should be valid.
Please re-check.


      

      
I don't understand what you mean. I fix the code under the tunnel case, and I didn't modify the code for the non-tunnel case.

    

    Sorry, my bad.

    

      

      

        



        

          

            

              

                
625,7 +625,7 @@ process_outer_cksums(void *outer_l3_hdr, struct
testpmd_offload_info *info,  if (udp_hdr->dgram_cksum != 0) {
udp_hdr->dgram_cksum = 0;  udp_hdr->dgram_cksum =
get_udptcp_checksum(m, outer_l3_hdr,
-info->l2_len + info->outer_l3_len,
+info->outer_l2_len + info-


                

                  
outer_l3_len,


                

                
  info->outer_ethertype);
  }

--
2.33.1


              

            

          

        

      

    

  


--------------sB37U9JS1WOWkVi8CRYcRvi3--