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 F214DA034E; Thu, 6 Jan 2022 13:56:53 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B0E2841152; Thu, 6 Jan 2022 13:56:53 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 975A441151 for ; Thu, 6 Jan 2022 13:56:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1641473811; x=1673009811; h=message-id:date:subject:to:cc:references:from: in-reply-to:mime-version; bh=NVunMKHbKfi0vfoYOwZeaF+QRCMShRkq/reNa8MLNxo=; b=E13WfXZWj89twZt+Ue9pBI4EWtBsSLwPPZdkhzAbmG5D5H87P625R5We raS3AFvCzqGMZldd39/kEdu3Mhck6vDXJEiX7/2oknRqaooCc7fSOsxL6 0wYvX9nxd3iac+JEkQywehVZmTk0POiNfbUSSkny2E4/MHEq6ir0I7+CK Smpr8tSekegGSDUzN/1TCtPPs1NsVmkiIARiWXA5SKxcdN3garzMFp7ev DWEM9MOzEI92Vk+mmtgBCucZH8+2uJJxX3LjZpOUdZChzihCKcpFXydTe gY7PI6gNsx9me6y9ENbfmIHJXpmowYqOuoYuJi/UnFBOZV3PQsWCA85ks Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10217"; a="229978955" X-IronPort-AV: E=Sophos;i="5.88,267,1635231600"; d="scan'208,217";a="229978955" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2022 04:56:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.88,267,1635231600"; d="scan'208,217";a="668433502" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by fmsmga001.fm.intel.com with ESMTP; 06 Jan 2022 04:56:33 -0800 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) 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.20; Thu, 6 Jan 2022 04:56:33 -0800 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20 via Frontend Transport; Thu, 6 Jan 2022 04:56:33 -0800 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.172) 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; Thu, 6 Jan 2022 04:56:32 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M8fTTSikg2Drz2HMwDgaGoCypS3mjKV82v1Dj85Kn+/ix8Lu7GUFBtq4Hc+5gQGcfqgIWwJFCbKPePi0k3fT+mmoLfiNW+dQaLaNlQBe62N/PPCED4AulnoieuG97LDdYx9RtUB6+KjURmjvusQ+7EC6+g93Rk/+Hns71PNi+CnQFU3l1OKPvREAVyMoPUW1+4qGqOA6VtSA0nVmKJEsdpVzvBLI4eE3DI/UWEaWnJOINc68TsD8INXckUSjfOc66hC0+upyR0MrAq6fKuhUMZw/h0jCaTNBzhakPWVh1x+dD9pIuiwNTkICuJo7wlTuqr4BNlaY7Xv/jbMGYE5q2Q== 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=u0NfIkkusibjPTlkbr00a9q/vwivHp0mFezNSB5Le64=; b=mxbiTMRMbE5n5t4BtZZb9QcDMZ42z8UvwGrwBSpIZ4oNKsFF9Kl7cNcvpKzj3CaqV7s2IFPsGMbWRzK/kNqVhQMk6JuePGyLvSqzzR890k7eSs6z+WliMxIc0Nno/knofz1mEHViiFM6DpHCIiGk+uB5Ci6/s9QcOw6CjUqNW/myA7DCN+Q/zy+J9RU2UOWq6L2zkYe/yeMRV0XS9JR4TWzLwH5Riml/zmv5w4FFQW8q5w9p0xRKjECh4BSycf+yQnW5U2tCrI7OvPe90/y9lO/HoMDLQO5zbTDG7hKAPQmClf5urHpQGPChN6XVvfA1hKKPgzbrsAUmvAuIZHIZEw== 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 MWHPR11MB1806.namprd11.prod.outlook.com (2603:10b6:300:10e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.15; Thu, 6 Jan 2022 12:56:30 +0000 Received: from MWHPR11MB0062.namprd11.prod.outlook.com ([fe80::10c4:88fd:5820:cc2c]) by MWHPR11MB0062.namprd11.prod.outlook.com ([fe80::10c4:88fd:5820:cc2c%6]) with mapi id 15.20.4867.009; Thu, 6 Jan 2022 12:56:30 +0000 Content-Type: multipart/alternative; boundary="------------oUl7nlVVHImmEjz30ym3xpCu" Message-ID: <63573c6f-635f-2085-33bd-a143464f30f5@intel.com> Date: Thu, 6 Jan 2022 18:26:18 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.4.1 Subject: Re: [PATCH v4 1/2] net: add functions to calculate UDP/TCP cksum in mbuf To: "Li, Xiaoyun" , "Yigit, Ferruh" , "olivier.matz@6wind.com" , "mb@smartsharesystems.com" , "Ananyev, Konstantin" , "stephen@networkplumber.org" , "Medvedkin, Vladimir" CC: "dev@dpdk.org" References: <20211015051306.320328-1-xiaoyun.li@intel.com> <20211203113805.1025301-1-xiaoyun.li@intel.com> <20211203113805.1025301-2-xiaoyun.li@intel.com> <7ff44b44-ad45-f435-1563-55a80282c210@intel.com> From: "Singh, Aman Deep" In-Reply-To: X-ClientProxiedBy: PN0PR01CA0020.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c01:4e::8) 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: 12c39149-79b9-4259-b4b5-08d9d113f54d X-MS-TrafficTypeDiagnostic: MWHPR11MB1806:EE_ 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: /IKoDNEve4a1ueaHNMmOFAz+cvijHQpNNQ2GZB0RF6xQFnQIo4Se51ef1Ew/TdD1PTL7xYTJZggzbl2UhK0KYR2CfqJQsW8TubvliUbw2s63fxmLW2s8a5rPJPqjCRODQlAAWHa5JRGYf1BDKBZBHJGkSQYvtg3x5II8TGnOsLiPyeM3TtJ2n+MxceJb0W6iNt45LjrHf/8P0Y5rDzCsRSuvQQtOKX8hc7vgumK36tkWPsiD3iu0acpZJcuwxMCTWa1KwmwaNxeWJe0Mk5htNO15NS03kx6/6E5321NHMXYh6qfgxIUwpnQ7p/r4LnMkwWbYZbe/tEOK9XF+MK252kfJwLLHMW/HPOxAg282h+AzSGOpGY4VMwYF3y2yKFK3Ta+RpZzgt9HRmaYfRrRLxOVinNK3/tC0g5pDcUYIqkN9bDyTX284A82RJC4bAuW1+K0Nw34yU+IycVgDZd8nk6fcFrhk2DpBL4xPO1WYbjJlENK5j1I58I5F6Czcin3XuXkTKWS4cs1Xq1qPdQAFCV1lEXro9jKiJgl/se6YiVDmBmPjTbUsXb6KFwXjEEkPKYEVd7+Em3OorO4rNYXGofYnJ7G4YRV5kWG/jbl5RLIhVK/4xVpS3REQzYRQqZ0pYn31k6qsztv30WFrhe9dH1vyRO3yd0SlYBbfkX0/P6a0PtbU8sagrU9ykIDABT8buVyOPXXS35daZY4VDTvQTXHtLyH4xE0gC6Pwm6jTfATKbEkYj+XwpOBZhN1+/lBw 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:(366004)(2906002)(6486002)(6506007)(33964004)(26005)(31696002)(6666004)(53546011)(508600001)(186003)(66556008)(5660300002)(66476007)(921005)(82960400001)(31686004)(83380400001)(2616005)(38100700002)(6512007)(86362001)(36756003)(110136005)(30864003)(8936002)(6636002)(66946007)(8676002)(316002)(4326008)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YSs3MWpnTGt5NmdCQ1ErSzNsYnU5UlIrYjVZUmJVUzR3VkV2eGVhUEVHM0pQ?= =?utf-8?B?ZU0yREViZVhxTDY4TmtBWVo1eW95R1ovc1FneFJrQ2IzZVpjeDc0OGo4Y3c2?= =?utf-8?B?cFJ6dmZtcWgzLy9ZcjNoa05wdGR4TWtUR2RldFdPSGl5S2liWTJaVC9SOEh2?= =?utf-8?B?RDhUNDJqTlBzNjVkdW40dU80V0UwYVZuVFd6bjRKcmhRYVU0cjRuMFl2NGVT?= =?utf-8?B?a0orMEtadXU1UmIxV1Uwa3pNVk9nSnVKQndueDdvd1ZabDRiYzNpRzU0bmlE?= =?utf-8?B?V25YcGxRMk9zMDVtdSs2UUNHL3J4a3BkQ3Jtd0N1b2g1Y0ZiTHBkN290NFF5?= =?utf-8?B?cDcvYVJYYmFMK0gybVBqa0R5eFJpNkd3SytkYm5INEwrNDR5OC9BMmYyYWVJ?= =?utf-8?B?b0Z2NktDbndPdU5SbEp6WUQ1clZMQUkrV2hMYm9SOHFtYlM0NWdXV1JzQTVt?= =?utf-8?B?TVdCNEdXbUdZUU91cittTlRmU2I1ZWo4N1YwZjVEUHpqRDNGWWZ0ZHUvclE0?= =?utf-8?B?bkZwWThQWVl5YzNacjlyVGlXbTBuOUlUWXp5VXpqaGUwZ0UvVjZpM3U5N1k3?= =?utf-8?B?UU9tRTBKOUNjRkpWSXFqWWU2bExrRXcwVTY4V2tidUhySXN5eGY3Mm5PTmR6?= =?utf-8?B?cnFrQ09YblhQcTh4R0Y5YTZ4OE5yN2gzSm1PZzhSTXB6SDVDNWxHYkZZMUgv?= =?utf-8?B?TGRteFh4Qld0b0MzUWFFMTlDb1NLQysrdCtXQ0w2bFhvTkpiejgxajBNV3pM?= =?utf-8?B?L1d1YnIvMEs5U2pYZEJIdmE2NjFkdURpb29JcU5QMFBpSWRYQmRMS1RWK1Fx?= =?utf-8?B?eU9rSWxNQkZBM1U1RmQybzF1QWRFb3FRaVB4ZkNFbU91bDRlT0t4ZFBIY2Za?= =?utf-8?B?YUM4d2htV0E1T3BWbGZSN0xFNHNFNWM5d25RZk1hMUxtdzU1WFE5ZVlnbWZH?= =?utf-8?B?ZysxcGNKV3F5MnlvN2VOWGpuWEl6QTg3U0J2VlhKS3ZMK2x3b0F6c2dKR0Fi?= =?utf-8?B?bEhHK3N2SFY0dkE5NnZFZldXV0tYY3A1UVFMa1BURmVqVXhWaDFrYk5ZU2RV?= =?utf-8?B?dDV2Z1FlcWpJOHcrckxxK1M5R2o3WGNYMkU1NGNtZ2lBQ0RaWlZrOVRoUjVS?= =?utf-8?B?Z1F5VS9SemRpWHJLeExVUG9kUjJQeGQvbVFkQmphTlB5bDNhRzNMcFVsenE1?= =?utf-8?B?cEQ5NFo3ZWRSekk1VzdVeTNwUXVsUHhEVUdJVjRNckNGb1NyenU3SWRFcXJ6?= =?utf-8?B?VWs3OGplcElpQmNDTERVT1ZtYlRmN3ZtVVNRQUJEWWdzYXdlWHhpN1M4dlVU?= =?utf-8?B?cy84NDM4VW9ZK0QrVjJCWjlhWVAyL3dlT0xtd1UvZTJDZDdlcVJqbXZLUFJ2?= =?utf-8?B?Y3pIOVN2Q3pZVitNZnVaM0Foc2lETER3b0VENzRGUE1Za2lueFFiejdRdzI3?= =?utf-8?B?ZmZkSTV2V3ZObmNYTDkxeXpJL3Z4bXNpUE51QWZ2NXVITzU5dHV3OEJxc042?= =?utf-8?B?MmEyd1NoNGpWb0pCNTZaZ2U1SWhacEdlRzkrcGViSTNvWXJ6QzZ5dU5YZ2RU?= =?utf-8?B?K2hSLy9zbW4xc2hZU0tpS2hDOUVwV3BIaEdISUwxUXpXcllDeFpLdzVHWWxV?= =?utf-8?B?aTFBcWJxUFhoTWZXVEp0bUlIZlBUTTZPOWwrdE9relp0OHhOUFY4MExZakdT?= =?utf-8?B?SDhmUkp4NEhDOTcrRVF6ajNUUFR1Q3dmRm1URlRrcFE0STYyaVdLRVJ5dmhQ?= =?utf-8?B?YjlEdGtnN0UyY2hCWk9UdnM4R3hvbXJveVh3bEk5STM0TVB1d3Z4Z1Q4aGx0?= =?utf-8?B?SW5zamczSXN3QVovRGh4a2F3cW1BRkQ5YkV1cWgza0pZNmlrSkJ3cFRUNHpR?= =?utf-8?B?dGNwRWtZTWRmZnA4NGhIWG03MFhjSkkyRlJDN3A2MW1wbTk2WjdEK05YY2Iw?= =?utf-8?B?cEl3NTBlWEV0TE9TWW9LNmx4TmhRYUg1Q0cyaUZUMm93bVJCRlFzMmlEMk9Z?= =?utf-8?B?cFBWaDlOSXFJZURTUjE4dUswL05tUkNhc0pQb1lMNHlDWTU3bmxEYktrRDh4?= =?utf-8?B?bk45Qnl0eHVKSmZYdkV0bElOWWVtWHNFUzlzbHYySnFtUG9ORWtYMlRTejVF?= =?utf-8?B?OGpjUXAwM2pudURxUmhCR1Fxb29lRlROclVtTXMwSitaSDR1ZU4wSDZlV2Fm?= =?utf-8?B?bzNBNHB3akZMRjRFT3A5NEpseldqQ0J1Z1piTlRQNEt4TzQzdS91T3g3T3lE?= =?utf-8?Q?E8aMWo1CuObj+LLF9IdMBQnXQri4MZmSy1qcuanZvU=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 12c39149-79b9-4259-b4b5-08d9d113f54d X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB0062.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2022 12:56:30.4417 (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: sp5fLwgshvZg7YOehvVGDeRarEWaVVUzsn6CrzAPcDTqEDalYkXBBaZRIEQgTBbqWwFP9Ib35+P1FlH7Hu8Wm/56n3xJvNuMVTYyJVjgA0g= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1806 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 --------------oUl7nlVVHImmEjz30ym3xpCu Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 1/4/2022 9:10 PM, Li, Xiaoyun wrote: > Hi > >> -----Original Message----- >> From: Li, Xiaoyun >> Sent: Tuesday, January 4, 2022 15:19 >> To: Singh, Aman Deep; Yigit, Ferruh >> ;olivier.matz@6wind.com; >> mb@smartsharesystems.com; Ananyev, Konstantin >> ;stephen@networkplumber.org; >> Medvedkin, Vladimir >> Cc:dev@dpdk.org >> Subject: RE: [PATCH v4 1/2] net: add functions to calculate UDP/TCP cksum in >> mbuf >> >> Hi >> >>> -----Original Message----- >>> From: Singh, Aman Deep >>> Sent: Wednesday, December 15, 2021 11:34 >>> To: Li, Xiaoyun; Yigit, Ferruh >>> ;olivier.matz@6wind.com; >>> mb@smartsharesystems.com; Ananyev, Konstantin >>> ;stephen@networkplumber.org; >> Medvedkin, >>> Vladimir >>> Cc:dev@dpdk.org >>> Subject: Re: [PATCH v4 1/2] net: add functions to calculate UDP/TCP >>> cksum in mbuf >>> >>> >>> On 12/3/2021 5:08 PM, Xiaoyun Li wrote: >>>> Add functions to call rte_raw_cksum_mbuf() to calculate IPv4/6 >>>> UDP/TCP checksum in mbuf which can be over multi-segments. >>>> >>>> Signed-off-by: Xiaoyun Li Acked-by: Aman Singh >>>> --- >>>> doc/guides/rel_notes/release_22_03.rst | 10 ++ >>>> lib/net/rte_ip.h | 186 +++++++++++++++++++++++++ >>>> lib/net/version.map | 10 ++ >>>> 3 files changed, 206 insertions(+) >>>> >>>> diff --git a/doc/guides/rel_notes/release_22_03.rst >>>> b/doc/guides/rel_notes/release_22_03.rst >>>> index 6d99d1eaa9..7a082c4427 100644 >>>> --- a/doc/guides/rel_notes/release_22_03.rst >>>> +++ b/doc/guides/rel_notes/release_22_03.rst >>>> @@ -55,6 +55,13 @@ New Features >>>> Also, make sure to start the actual text at the margin. >>>> ======================================================= >>>> >>>> +* **Added functions to calculate UDP/TCP checksum in mbuf.** >>>> + * Added the following functions to calculate UDP/TCP checksum of >>> packets >>>> + which can be over multi-segments: >>>> + - ``rte_ipv4_udptcp_cksum_mbuf()`` >>>> + - ``rte_ipv4_udptcp_cksum_mbuf_verify()`` >>>> + - ``rte_ipv6_udptcp_cksum_mbuf()`` >>>> + - ``rte_ipv6_udptcp_cksum_mbuf_verify()`` >>>> >>>> Removed Items >>>> ------------- >>>> @@ -84,6 +91,9 @@ API Changes >>>> Also, make sure to start the actual text at the margin. >>>> ======================================================= >>>> >>>> +* net: added experimental functions >>>> +``rte_ipv4_udptcp_cksum_mbuf()``, >>>> + ``rte_ipv4_udptcp_cksum_mbuf_verify()``, >>>> +``rte_ipv6_udptcp_cksum_mbuf()``, >>>> + ``rte_ipv6_udptcp_cksum_mbuf_verify()`` >>>> >>>> ABI Changes >>>> ----------- >>>> diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h index >>>> c575250852..534f401d26 100644 >>>> --- a/lib/net/rte_ip.h >>>> +++ b/lib/net/rte_ip.h >>>> @@ -400,6 +400,65 @@ rte_ipv4_udptcp_cksum(const struct >> rte_ipv4_hdr >>> *ipv4_hdr, const void *l4_hdr) >>>> return cksum; >>>> } >>>> >>>> +/** >>>> + * @internal Calculate the non-complemented IPv4 L4 checksum of a >>>> +packet */ static inline uint16_t >>>> +__rte_ipv4_udptcp_cksum_mbuf(const >>>> +struct rte_mbuf *m, >>>> + const struct rte_ipv4_hdr *ipv4_hdr, >>>> + uint16_t l4_off) >>>> +{ >>>> + uint16_t raw_cksum; >>>> + uint32_t cksum; >>>> + >>>> + if (l4_off > m->pkt_len) >>>> + return 0; >>>> + >>>> + if (rte_raw_cksum_mbuf(m, l4_off, m->pkt_len - l4_off, >>> &raw_cksum)) >>>> + return 0; >>>> + >>>> + cksum = raw_cksum + rte_ipv4_phdr_cksum(ipv4_hdr, 0); >>>> + >>>> + cksum = ((cksum & 0xffff0000) >> 16) + (cksum & 0xffff); >>> At times, even after above operation "cksum" might stay above 16-bits, >>> ex "cksum = 0x1FFFF" to start with. >>> Can we consider using "return __rte_raw_cksum_reduce(cksum);" >> Will use it in next version. Thanks. >> >> Also, not related to this patch. It means that __rte_ipv4_udptcp_cksum and >> __rte_ipv6_udptcp_cksum have the same issue, right? >> Should anyone fix that? > Forgot the intent here. > rte_raw_cksum_mbuf() already calls __rte_raw_cksum_reduce(). > So actually, it's a result of uint16_t + uint16_t. So it's impossible of your case. There's no need to call __rte_raw_cksum_reduce(). Got it, Thanks. With u16 + u16, max 1-bit overflow only possible. So effective operation here reduces to- cksum = ((cksum & 0x10000) >> 16) + (cksum & 0xffff); >>>> + >>>> + return (uint16_t)cksum; >>>> +} >>>> + >>>> +/** >>>> + * @warning >>>> + * @b EXPERIMENTAL: this API may change without prior notice. >>>> + * >>>> + * Compute the IPv4 UDP/TCP checksum of a packet. >>>> + * >>>> + * @param m >>>> + * The pointer to the mbuf. >>>> + * @param ipv4_hdr >>>> + * The pointer to the contiguous IPv4 header. >>>> + * @param l4_off >>>> + * The offset in bytes to start L4 checksum. >>>> + * @return >>>> + * The complemented checksum to set in the L4 header. >>>> + */ >>>> +__rte_experimental >>>> +static inline uint16_t >>>> +rte_ipv4_udptcp_cksum_mbuf(const struct rte_mbuf *m, >>>> + const struct rte_ipv4_hdr *ipv4_hdr, uint16_t l4_off) >>> { >>>> + uint16_t cksum = __rte_ipv4_udptcp_cksum_mbuf(m, ipv4_hdr, >>> l4_off); >>>> + >>>> + cksum = ~cksum; >>>> + >>>> + /* >>>> + * Per RFC 768: If the computed checksum is zero for UDP, >>>> + * it is transmitted as all ones >>>> + * (the equivalent in one's complement arithmetic). >>>> + */ >>>> + if (cksum == 0 && ipv4_hdr->next_proto_id == IPPROTO_UDP) >>>> + cksum = 0xffff; >>>> + >>>> + return cksum; >>>> +} >>>> + >>>> /** >>>> * Validate the IPv4 UDP or TCP checksum. >>>> * >>>> @@ -426,6 +485,38 @@ rte_ipv4_udptcp_cksum_verify(const struct >>> rte_ipv4_hdr *ipv4_hdr, >>>> return 0; >>>> } >>>> >>>> +/** >>>> + * @warning >>>> + * @b EXPERIMENTAL: this API may change without prior notice. >>>> + * >>>> + * Verify the IPv4 UDP/TCP checksum of a packet. >>>> + * >>>> + * In case of UDP, the caller must first check if >>>> +udp_hdr->dgram_cksum is 0 >>>> + * (i.e. no checksum). >>>> + * >>>> + * @param m >>>> + * The pointer to the mbuf. >>>> + * @param ipv4_hdr >>>> + * The pointer to the contiguous IPv4 header. >>>> + * @param l4_off >>>> + * The offset in bytes to start L4 checksum. >>>> + * @return >>>> + * Return 0 if the checksum is correct, else -1. >>>> + */ >>>> +__rte_experimental >>>> +static inline uint16_t >>>> +rte_ipv4_udptcp_cksum_mbuf_verify(const struct rte_mbuf *m, >>>> + const struct rte_ipv4_hdr *ipv4_hdr, >>>> + uint16_t l4_off) >>>> +{ >>>> + uint16_t cksum = __rte_ipv4_udptcp_cksum_mbuf(m, ipv4_hdr, >>> l4_off); >>>> + >>>> + if (cksum != 0xffff) >>>> + return -1; >>> cksum other than 0xffff, should return error. Is that the intent or I >>> am missing something obvious. >> This is the intent. This function is to verify if the cksum in the packet is correct. >> >> It's different from calling rte_ipv4/6_udptcp_cksum_mbuf(). When calling >> rte_ipv4/6_udptcp_cksum_mbuf(), you need to set the cksum in udp/tcp >> header as 0. Then calculate the cksum. >> >> But here, user should directly call this function with the original packet. Then >> if the udp/tcp cksum is correct, after the calculation (please note that, this is >> calling __rte_ipv4_udptcp_cksum_mbuf(), so the result needs to be ~), it >> should be 0xffff, namely, ~cksum = 0 which means cksum is correct. You can >> see rte_ipv4/6_udptcp_cksum_verify() is doing the same. >> >>>> + >>>> + return 0; >>>> +} >>>> + >>>> /** >>>> * IPv6 Header >>>> */ >>>> @@ -538,6 +629,68 @@ rte_ipv6_udptcp_cksum(const struct >> rte_ipv6_hdr >>> *ipv6_hdr, const void *l4_hdr) >>>> return cksum; >>>> } >>>> >>>> +/** >>>> + * @internal Calculate the non-complemented IPv6 L4 checksum of a >>>> +packet */ static inline uint16_t >>>> +__rte_ipv6_udptcp_cksum_mbuf(const >>>> +struct rte_mbuf *m, >>>> + const struct rte_ipv6_hdr *ipv6_hdr, >>>> + uint16_t l4_off) >>>> +{ >>>> + uint16_t raw_cksum; >>>> + uint32_t cksum; >>>> + >>>> + if (l4_off > m->pkt_len) >>>> + return 0; >>>> + >>>> + if (rte_raw_cksum_mbuf(m, l4_off, m->pkt_len - l4_off, >>> &raw_cksum)) >>>> + return 0; >>>> + >>>> + cksum = raw_cksum + rte_ipv6_phdr_cksum(ipv6_hdr, 0); >>>> + >>>> + cksum = ((cksum & 0xffff0000) >> 16) + (cksum & 0xffff); >>> Same, please check if we can opt for __rte_raw_cksum_reduce(cksum) >>>> + >>>> + return (uint16_t)cksum; >>>> +} >>>> + >>>> +/** >>>> + * @warning >>>> + * @b EXPERIMENTAL: this API may change without prior notice. >>>> + * >>>> + * Process the IPv6 UDP or TCP checksum of a packet. >>>> + * >>>> + * The IPv6 header must not be followed by extension headers. The >>>> +layer 4 >>>> + * checksum must be set to 0 in the L4 header by the caller. >>>> + * >>>> + * @param m >>>> + * The pointer to the mbuf. >>>> + * @param ipv6_hdr >>>> + * The pointer to the contiguous IPv6 header. >>>> + * @param l4_off >>>> + * The offset in bytes to start L4 checksum. >>>> + * @return >>>> + * The complemented checksum to set in the L4 header. >>>> + */ >>>> +__rte_experimental >>>> +static inline uint16_t >>>> +rte_ipv6_udptcp_cksum_mbuf(const struct rte_mbuf *m, >>>> + const struct rte_ipv6_hdr *ipv6_hdr, uint16_t l4_off) >>> { >>>> + uint16_t cksum = __rte_ipv6_udptcp_cksum_mbuf(m, ipv6_hdr, >>> l4_off); >>>> + >>>> + cksum = ~cksum; >>>> + >>>> + /* >>>> + * Per RFC 768: If the computed checksum is zero for UDP, >>>> + * it is transmitted as all ones >>>> + * (the equivalent in one's complement arithmetic). >>>> + */ >>>> + if (cksum == 0 && ipv6_hdr->proto == IPPROTO_UDP) >>>> + cksum = 0xffff; >>>> + >>>> + return cksum; >>>> +} >>>> + >>>> /** >>>> * Validate the IPv6 UDP or TCP checksum. >>>> * >>>> @@ -565,6 +718,39 @@ rte_ipv6_udptcp_cksum_verify(const struct >>> rte_ipv6_hdr *ipv6_hdr, >>>> return 0; >>>> } >>>> >>>> +/** >>>> + * @warning >>>> + * @b EXPERIMENTAL: this API may change without prior notice. >>>> + * >>>> + * Validate the IPv6 UDP or TCP checksum of a packet. >>>> + * >>>> + * In case of UDP, the caller must first check if udp_hdr->dgram_cksum is >> 0: >>>> + * this is either invalid or means no checksum in some situations. >>>> +See 8.1 >>>> + * (Upper-Layer Checksums) in RFC 8200. >>>> + * >>>> + * @param m >>>> + * The pointer to the mbuf. >>>> + * @param ipv6_hdr >>>> + * The pointer to the contiguous IPv6 header. >>>> + * @param l4_off >>>> + * The offset in bytes to start L4 checksum. >>>> + * @return >>>> + * Return 0 if the checksum is correct, else -1. >>>> + */ >>>> +__rte_experimental >>>> +static inline int >>>> +rte_ipv6_udptcp_cksum_mbuf_verify(const struct rte_mbuf *m, >>>> + const struct rte_ipv6_hdr *ipv6_hdr, >>>> + uint16_t l4_off) >>>> +{ >>>> + uint16_t cksum = __rte_ipv6_udptcp_cksum_mbuf(m, ipv6_hdr, >>> l4_off); >>>> + >>>> + if (cksum != 0xffff) >>>> + return -1; >>>> + >>>> + return 0; >>>> +} >>>> + >>>> /** IPv6 fragment extension header. */ >>>> #define RTE_IPV6_EHDR_MF_SHIFT 0 >>>> #define RTE_IPV6_EHDR_MF_MASK 1 >>>> diff --git a/lib/net/version.map b/lib/net/version.map index >>>> 4f4330d1c4..0f2aacdef8 100644 >>>> --- a/lib/net/version.map >>>> +++ b/lib/net/version.map >>>> @@ -12,3 +12,13 @@ DPDK_22 { >>>> >>>> local: *; >>>> }; >>>> + >>>> +EXPERIMENTAL { >>>> + global: >>>> + >>>> + # added in 22.03 >>>> + rte_ipv4_udptcp_cksum_mbuf; >>>> + rte_ipv4_udptcp_cksum_mbuf_verify; >>>> + rte_ipv6_udptcp_cksum_mbuf; >>>> + rte_ipv6_udptcp_cksum_mbuf_verify; >>>> +}; --------------oUl7nlVVHImmEjz30ym3xpCu Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit


On 1/4/2022 9:10 PM, Li, Xiaoyun wrote:
Hi


-----Original Message-----
From: Li, Xiaoyun <xiaoyun.li@intel.com>
Sent: Tuesday, January 4, 2022 15:19
To: Singh, Aman Deep <aman.deep.singh@intel.com>; Yigit, Ferruh
<ferruh.yigit@intel.com>; olivier.matz@6wind.com;
mb@smartsharesystems.com; Ananyev, Konstantin
<konstantin.ananyev@intel.com>; stephen@networkplumber.org;
Medvedkin, Vladimir <vladimir.medvedkin@intel.com>
Cc: dev@dpdk.org
Subject: RE: [PATCH v4 1/2] net: add functions to calculate UDP/TCP cksum in
mbuf

Hi


-----Original Message-----
From: Singh, Aman Deep <aman.deep.singh@intel.com>
Sent: Wednesday, December 15, 2021 11:34
To: Li, Xiaoyun <xiaoyun.li@intel.com>; Yigit, Ferruh
<ferruh.yigit@intel.com>; olivier.matz@6wind.com;
mb@smartsharesystems.com; Ananyev, Konstantin
<konstantin.ananyev@intel.com>; stephen@networkplumber.org;

Medvedkin,

Vladimir <vladimir.medvedkin@intel.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH v4 1/2] net: add functions to calculate UDP/TCP
cksum in mbuf


On 12/3/2021 5:08 PM, Xiaoyun Li wrote:

Add functions to call rte_raw_cksum_mbuf() to calculate IPv4/6
UDP/TCP checksum in mbuf which can be over multi-segments.

Signed-off-by: Xiaoyun Li <xiaoyun.li@intel.com>

Acked-by: Aman Singh <aman.deep.singh@intel.com>
---
  doc/guides/rel_notes/release_22_03.rst |  10 ++
  lib/net/rte_ip.h                       | 186 +++++++++++++++++++++++++
  lib/net/version.map                    |  10 ++
  3 files changed, 206 insertions(+)

diff --git a/doc/guides/rel_notes/release_22_03.rst
b/doc/guides/rel_notes/release_22_03.rst
index 6d99d1eaa9..7a082c4427 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -55,6 +55,13 @@ New Features
       Also, make sure to start the actual text at the margin.
       =======================================================

+* **Added functions to calculate UDP/TCP checksum in mbuf.**
+  * Added the following functions to calculate UDP/TCP checksum of

packets

+    which can be over multi-segments:
+    - ``rte_ipv4_udptcp_cksum_mbuf()``
+    - ``rte_ipv4_udptcp_cksum_mbuf_verify()``
+    - ``rte_ipv6_udptcp_cksum_mbuf()``
+    - ``rte_ipv6_udptcp_cksum_mbuf_verify()``

  Removed Items
  -------------
@@ -84,6 +91,9 @@ API Changes
     Also, make sure to start the actual text at the margin.
     =======================================================

+* net: added experimental functions
+``rte_ipv4_udptcp_cksum_mbuf()``,
+  ``rte_ipv4_udptcp_cksum_mbuf_verify()``,
+``rte_ipv6_udptcp_cksum_mbuf()``,
+  ``rte_ipv6_udptcp_cksum_mbuf_verify()``

  ABI Changes
  -----------
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h index
c575250852..534f401d26 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -400,6 +400,65 @@ rte_ipv4_udptcp_cksum(const struct

rte_ipv4_hdr

*ipv4_hdr, const void *l4_hdr)

  	return cksum;
  }

+/**
+ * @internal Calculate the non-complemented IPv4 L4 checksum of a
+packet  */ static inline uint16_t
+__rte_ipv4_udptcp_cksum_mbuf(const
+struct rte_mbuf *m,
+			     const struct rte_ipv4_hdr *ipv4_hdr,
+			     uint16_t l4_off)
+{
+	uint16_t raw_cksum;
+	uint32_t cksum;
+
+	if (l4_off > m->pkt_len)
+		return 0;
+
+	if (rte_raw_cksum_mbuf(m, l4_off, m->pkt_len - l4_off,

&raw_cksum))

+		return 0;
+
+	cksum = raw_cksum + rte_ipv4_phdr_cksum(ipv4_hdr, 0);
+
+	cksum = ((cksum & 0xffff0000) >> 16) + (cksum & 0xffff);

At times, even after above operation "cksum" might stay above 16-bits,
ex "cksum = 0x1FFFF" to start with.
Can we consider using "return __rte_raw_cksum_reduce(cksum);"

Will use it in next version. Thanks.

Also, not related to this patch. It means that __rte_ipv4_udptcp_cksum and
__rte_ipv6_udptcp_cksum have the same issue, right?
Should anyone fix that?

Forgot the intent here.
rte_raw_cksum_mbuf() already calls __rte_raw_cksum_reduce().
So actually, it's a result of uint16_t + uint16_t. So it's impossible of your case. There's no need to call __rte_raw_cksum_reduce().
Got it, Thanks. With u16 + u16, max 1-bit overflow only possible. So effective operation here reduces to-
cksum = ((cksum & 0x10000) >> 16) + (cksum & 0xffff);

        

          

            
+
+	return (uint16_t)cksum;
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Compute the IPv4 UDP/TCP checksum of a packet.
+ *
+ * @param m
+ *   The pointer to the mbuf.
+ * @param ipv4_hdr
+ *   The pointer to the contiguous IPv4 header.
+ * @param l4_off
+ *   The offset in bytes to start L4 checksum.
+ * @return
+ *   The complemented checksum to set in the L4 header.
+ */
+__rte_experimental
+static inline uint16_t
+rte_ipv4_udptcp_cksum_mbuf(const struct rte_mbuf *m,
+			   const struct rte_ipv4_hdr *ipv4_hdr, uint16_t l4_off)


          

          
{


          

            
+	uint16_t cksum = __rte_ipv4_udptcp_cksum_mbuf(m, ipv4_hdr,


          

          
l4_off);


          

            
+
+	cksum = ~cksum;
+
+	/*
+	 * Per RFC 768: If the computed checksum is zero for UDP,
+	 * it is transmitted as all ones
+	 * (the equivalent in one's complement arithmetic).
+	 */
+	if (cksum == 0 && ipv4_hdr->next_proto_id == IPPROTO_UDP)
+		cksum = 0xffff;
+
+	return cksum;
+}
+
  /**
   * Validate the IPv4 UDP or TCP checksum.
   *
@@ -426,6 +485,38 @@ rte_ipv4_udptcp_cksum_verify(const struct


          

          
rte_ipv4_hdr *ipv4_hdr,


          

            
  	return 0;
  }

+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Verify the IPv4 UDP/TCP checksum of a packet.
+ *
+ * In case of UDP, the caller must first check if
+udp_hdr->dgram_cksum is 0
+ * (i.e. no checksum).
+ *
+ * @param m
+ *   The pointer to the mbuf.
+ * @param ipv4_hdr
+ *   The pointer to the contiguous IPv4 header.
+ * @param l4_off
+ *   The offset in bytes to start L4 checksum.
+ * @return
+ *   Return 0 if the checksum is correct, else -1.
+ */
+__rte_experimental
+static inline uint16_t
+rte_ipv4_udptcp_cksum_mbuf_verify(const struct rte_mbuf *m,
+				  const struct rte_ipv4_hdr *ipv4_hdr,
+				  uint16_t l4_off)
+{
+	uint16_t cksum = __rte_ipv4_udptcp_cksum_mbuf(m, ipv4_hdr,


          

          
l4_off);


          

            
+
+	if (cksum != 0xffff)
+		return -1;


          

          
cksum other than 0xffff, should return error. Is that the intent or I
am missing something obvious.


        

        
This is the intent. This function is to verify if the cksum in the packet is correct.

It's different from calling rte_ipv4/6_udptcp_cksum_mbuf(). When calling
rte_ipv4/6_udptcp_cksum_mbuf(), you need to set the cksum in udp/tcp
header as 0. Then calculate the cksum.

But here, user should directly call this function with the original packet. Then
if the udp/tcp cksum is correct, after the calculation (please note that, this is
calling __rte_ipv4_udptcp_cksum_mbuf(), so the result needs to be ~), it
should be 0xffff, namely, ~cksum = 0 which means cksum is correct. You can
see rte_ipv4/6_udptcp_cksum_verify() is doing the same.



        

          

            
+
+	return 0;
+}
+
  /**
   * IPv6 Header
   */
@@ -538,6 +629,68 @@ rte_ipv6_udptcp_cksum(const struct


          

        

        
rte_ipv6_hdr


        

          
*ipv6_hdr, const void *l4_hdr)


          

            
  	return cksum;
  }

+/**
+ * @internal Calculate the non-complemented IPv6 L4 checksum of a
+packet  */ static inline uint16_t
+__rte_ipv6_udptcp_cksum_mbuf(const
+struct rte_mbuf *m,
+			     const struct rte_ipv6_hdr *ipv6_hdr,
+			     uint16_t l4_off)
+{
+	uint16_t raw_cksum;
+	uint32_t cksum;
+
+	if (l4_off > m->pkt_len)
+		return 0;
+
+	if (rte_raw_cksum_mbuf(m, l4_off, m->pkt_len - l4_off,


          

          
&raw_cksum))


          

            
+		return 0;
+
+	cksum = raw_cksum + rte_ipv6_phdr_cksum(ipv6_hdr, 0);
+
+	cksum = ((cksum & 0xffff0000) >> 16) + (cksum & 0xffff);


          

          
Same, please check if we can opt for __rte_raw_cksum_reduce(cksum)


          

            
+
+	return (uint16_t)cksum;
+}
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Process the IPv6 UDP or TCP checksum of a packet.
+ *
+ * The IPv6 header must not be followed by extension headers. The
+layer 4
+ * checksum must be set to 0 in the L4 header by the caller.
+ *
+ * @param m
+ *   The pointer to the mbuf.
+ * @param ipv6_hdr
+ *   The pointer to the contiguous IPv6 header.
+ * @param l4_off
+ *   The offset in bytes to start L4 checksum.
+ * @return
+ *   The complemented checksum to set in the L4 header.
+ */
+__rte_experimental
+static inline uint16_t
+rte_ipv6_udptcp_cksum_mbuf(const struct rte_mbuf *m,
+			   const struct rte_ipv6_hdr *ipv6_hdr, uint16_t l4_off)


          

          
{


          

            
+	uint16_t cksum = __rte_ipv6_udptcp_cksum_mbuf(m, ipv6_hdr,


          

          
l4_off);


          

            
+
+	cksum = ~cksum;
+
+	/*
+	 * Per RFC 768: If the computed checksum is zero for UDP,
+	 * it is transmitted as all ones
+	 * (the equivalent in one's complement arithmetic).
+	 */
+	if (cksum == 0 && ipv6_hdr->proto == IPPROTO_UDP)
+		cksum = 0xffff;
+
+	return cksum;
+}
+
  /**
   * Validate the IPv6 UDP or TCP checksum.
   *
@@ -565,6 +718,39 @@ rte_ipv6_udptcp_cksum_verify(const struct


          

          
rte_ipv6_hdr *ipv6_hdr,


          

            
  	return 0;
  }

+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Validate the IPv6 UDP or TCP checksum of a packet.
+ *
+ * In case of UDP, the caller must first check if udp_hdr->dgram_cksum is


          

        

        
0:


        

          

            
+ * this is either invalid or means no checksum in some situations.
+See 8.1
+ * (Upper-Layer Checksums) in RFC 8200.
+ *
+ * @param m
+ *   The pointer to the mbuf.
+ * @param ipv6_hdr
+ *   The pointer to the contiguous IPv6 header.
+ * @param l4_off
+ *   The offset in bytes to start L4 checksum.
+ * @return
+ *   Return 0 if the checksum is correct, else -1.
+ */
+__rte_experimental
+static inline int
+rte_ipv6_udptcp_cksum_mbuf_verify(const struct rte_mbuf *m,
+				  const struct rte_ipv6_hdr *ipv6_hdr,
+				  uint16_t l4_off)
+{
+	uint16_t cksum = __rte_ipv6_udptcp_cksum_mbuf(m, ipv6_hdr,


          

          
l4_off);


          

            
+
+	if (cksum != 0xffff)
+		return -1;
+
+	return 0;
+}
+
  /** IPv6 fragment extension header. */
  #define	RTE_IPV6_EHDR_MF_SHIFT	0
  #define	RTE_IPV6_EHDR_MF_MASK	1
diff --git a/lib/net/version.map b/lib/net/version.map index
4f4330d1c4..0f2aacdef8 100644
--- a/lib/net/version.map
+++ b/lib/net/version.map
@@ -12,3 +12,13 @@ DPDK_22 {

  	local: *;
  };
+
+EXPERIMENTAL {
+	global:
+
+	# added in 22.03
+	rte_ipv4_udptcp_cksum_mbuf;
+	rte_ipv4_udptcp_cksum_mbuf_verify;
+	rte_ipv6_udptcp_cksum_mbuf;
+	rte_ipv6_udptcp_cksum_mbuf_verify;
+};


          

        

      

    

  


--------------oUl7nlVVHImmEjz30ym3xpCu--