From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710075.outbound.protection.outlook.com [40.107.71.75]) by dpdk.org (Postfix) with ESMTP id BF9AD9B67 for ; Mon, 8 Oct 2018 15:09:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xoionp+WcF+QBbeDceguXnCPU2n++PBH7zKMYJ44NEI=; b=IP/N0nZz/WonAKE/v2Cypgwes7rfo+jIbG/JlRcX/CdDbhWiqMKDy8F6WI8RQVHuqfiKhUpLAp/+f1Ffg05wihOiMUoXLTU8Zy2/uDMLO0ezqQelSpj7uPGg9Oj7xgGR1jYBMuzMKJIDWC32K74oVnJNVLkM0xlrXLc9RDLwyOs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (122.167.112.78) by DM6PR07MB5001.namprd07.prod.outlook.com (2603:10b6:5:25::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.27; Mon, 8 Oct 2018 13:09:08 +0000 Date: Mon, 8 Oct 2018 18:38:55 +0530 From: Jerin Jacob To: Thomas Monjalon Cc: Ferruh Yigit , "Ananyev, Konstantin" , Andrew Rybchenko , "Lu, Wenzhuo" , "Wu, Jingjing" , "Iremonger, Bernard" , "Mcnamara, John" , "Kovacevic, Marko" , Olivier Matz , "dev@dpdk.org" , "shahafs@mellanox.com" , "didier.pallard@6wind.com" Message-ID: <20181008130854.GA11965@jerin> References: <20180913134707.23698-1-jerin.jacob@caviumnetworks.com> <80a5780a-f66b-ad7c-8327-37644c69efda@intel.com> <20181008122509.GA5158@jerin> <2286504.krVn7HG0xW@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2286504.krVn7HG0xW@xps> User-Agent: Mutt/1.10.1 (2018-07-13) X-Originating-IP: [122.167.112.78] X-ClientProxiedBy: SG2PR06CA0118.apcprd06.prod.outlook.com (2603:1096:1:1d::20) To DM6PR07MB5001.namprd07.prod.outlook.com (2603:10b6:5:25::22) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bfd3d525-7c4a-49c9-7f0c-08d62d1f3e83 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DM6PR07MB5001; X-Microsoft-Exchange-Diagnostics: 1; DM6PR07MB5001; 3:qRuKacbSvBxWAD2sNIODv4rj+X7tL468bZZkUF8vQG12Ta6qtv2XTCKXtgowsZ8dvxKIZj+s65JIYOovnjsI56D8OjfholK9Uf8RMkm6WL4hgqCU9wPIMvF/x9ChS0guPg5w5EPx1xgRL2wa/dF77paM/u/jhNYuxqkg8RpOb5eLqWjydAxjzOyVbbIg+aYv2RE1GgMfvIPlMgwKGXbhciO2m7iA8mG3avt6vCR0lmq34dRstKdU1cL9ZJVO9taJ; 25:fqLTGntwoEN4mF6ewhzGPvd1EC0VN/+leGmj8nk+EzOPRxFmAK/TCXKAGj5hjdkKtbizQR6sIA82q+pMaBivcEWmDr0FhOKT42iKStJaGApAjAesOtjRGseCC9NviMekQB18MaykAueBwzTbyN1MIOreyoJ5uC2g/vG7Ls5R5/JzEKfCRHseLHOx/k0wN2SxD/aCAnbwt6rzhDC0Pu50Y1pjXeMcHSjCBgNsxegtfJmjawXXbJCYJJdUP9cH1lbK+g7wFjeMC3N+yTOCfTs/rgnQHnqNU8QbDJiwiDqPqpBPbk6nM2bwcVYhZ/31hkgMjMGA5X8QXqRboIO5C6P1GQ==; 31:uuwv/xrHcr9iMa7w8Q/UMG0+jm4Bj04QxD6SVz36reGRP4GGEbWiljlw2oeJ3ufwkCzxyl6tnbrbhwYtwTUkwAtV3AjisiIJnl7kGOU9Hh6+Zs9laVLerwyavTBd3vGxNG6n8lo2lPQZAafzXjuEzkmI08VqRVw1dhKjHPS/lvr6bkX9XlyKxX8Q7DNVft5BXYclxiIadDbNYrRWxRCX+xD9WEC9KKqYT2LmC4OxqQs= X-MS-TrafficTypeDiagnostic: DM6PR07MB5001: X-Microsoft-Exchange-Diagnostics: 1; DM6PR07MB5001; 20:6klRFA59ZuHHGoLFYTAHgxaZSYQIHjq62AliECDFkBw4XyTkxJSaa4nSC0vYG0+HpB6rq5jJSOgsZsotcqqIoIUaQJvgYua2cQ4ckDyPfNqaHIKoMG9t+WtuqZPLjeRitpQUpS9FpKSyIk8bZdNH797+TJwZU0VeHu8omL2PP/CJ17kvcu6Oi+bXakGzgSSynxgAY7+a7PIIn731tQyqeC/xf/qSAzDHzpcctZEkmyXlqt4olBSFtBb2inBADi92rSXKjVO/qlW1As0H9WcfHEEVUcxeo2o8iAWJJqyffK/jyetrWNvt1HhrI+xpAxNMJ5EPcnUS7L3BM9Unlh6tbwYa0B+oCC5KNsEp6RsBTXrGApReSuVEy+qA0AVig2hUbg9NsTyIX1Ef9I1B1r9qvwJAHYhq828ndwoZXdhxun09BWGqapSZeVPJy2xWokPDbfs9DVQvVBTFGb/7t/emoryd7ryGURQEuyPKUlm+jwvOE9zvhjTWpTAn9phSSQs9A+Lf/mFr1d86sVeSxXGbEz+nlOTRhwTzu68e9ua83mIq1q7jiS6llKyOx9YWiwGDNRCvOicRHhdnIR9ErTZd8kPqyUNymNZn3eVD7Vmkxl0= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(228905959029699)(211171220733660); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(3231355)(944501410)(52105095)(10201501046)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051); SRVR:DM6PR07MB5001; BCL:0; PCL:0; RULEID:; SRVR:DM6PR07MB5001; X-Microsoft-Exchange-Diagnostics: 1; DM6PR07MB5001; 4:ifWcEkjuwPVDD1akiQMKt3hoJB1wrG1UgpZO+bdjIWYEaxPB0o3Ef8bSMppHDYuYcCoMmtjxa79YJsr83Fct8hwak0jVz9eaN/qgO86r9sjpeMMdC85tzqvo7e72CPK6c2j4Y9MBl6jprPVkqamAa4yLLwyCx8EJPVt6qaVJAUYPV0GGtu9pTg3jPBNLVDkU8GOJgaa5e/QLaaU+wXuVZRlqwO5UH+1KSKLlZQcafDt74e6qcKYju4VH99+bIPYgChsUD7tb2CXKe/l4WfVtyLrqK0zwvySYSMXolCoPorogQDL8s87jVMXlcGwrVojvo3S8Vfv9y23nvXCs0fv7ssu9dc/7R34EXSGZh1A6Gn8= X-Forefront-PRVS: 081904387B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(346002)(39860400002)(136003)(13464003)(57704003)(189003)(199004)(97736004)(6916009)(33656002)(5660300001)(6666003)(6246003)(81166006)(81156014)(16526019)(478600001)(26005)(186003)(4326008)(16586007)(105586002)(14444005)(229853002)(25786009)(93886005)(42882007)(8676002)(106356001)(72206003)(53546011)(305945005)(386003)(44832011)(1076002)(2906002)(446003)(11346002)(956004)(476003)(47776003)(486006)(7736002)(66066001)(23726003)(3846002)(6116002)(33896004)(52116002)(76176011)(55016002)(6496006)(54906003)(50466002)(9686003)(33716001)(8936002)(316002)(68736007)(58126008)(53936002)(7416002)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR07MB5001; H:jerin; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM6PR07MB5001; 23:X+sLmuJIEcBhbUcN1eaPze5ykwUtUg87zSJ/obsdG?= =?us-ascii?Q?M9qtoD5WSm3Sl/ahvCJBlsFwTzyq4miQoUCCUOcH6RY+/twy4WjfdA0r3lIP?= =?us-ascii?Q?DblDyIgDdLlfW+XkWmKr3re1w66mPHkmh7f7/L6/Klxeyk0/YeOrwGl4xepe?= =?us-ascii?Q?190CZZsQ7HsbKuCrSjlXMKoZT9FwyrogZf7z2yTuj8o43g3srLoMP7PvqLTZ?= =?us-ascii?Q?S15IO8AVYJJ6c3iw1oLjiYkePFJRDKrhz8vsm2Nb0W8PZq76SypO4JloKP8B?= =?us-ascii?Q?dMx/PfOfmR/+Xcid4vVl0wY1UlYVouk039mV5WMnY7k/EaJaP0cy2gYBQYro?= =?us-ascii?Q?AKWC+Isi7CNDxWQpG5cp0rJwbK1qu11IBUR1lsRS1uDcfOV9C1WOdRbgRGl9?= =?us-ascii?Q?L681kMbr1FTUE6o7A7sKERBQjdk3n+hnu6i3CY7m2kGM4gFNsz4UmdjwL+iC?= =?us-ascii?Q?Mr2xCGYxiPBfKYHWk9N3J6s6gnIN53B61o3kReUuOHBN+4DE16YYUZ3+T5g1?= =?us-ascii?Q?24Wkb9Y6bpDdw74VDCL5OLIjbInFBVl5djwUd3c8z0vpWzzezIU0m3RQgZnB?= =?us-ascii?Q?O/YlZ2Vsw4MSFwntXUyc8vZi4ceifXNwZWqRDsnruZ3mWX/7bssoZIQJZMBh?= =?us-ascii?Q?zHn/2hh2TTpffT2GYCp9hVArD8GuLNIQRbHWPGIhrZMesoAiRQjY28Q1hOL9?= =?us-ascii?Q?fylroBnA5MVhPXj53+uX4XRACiISDOVRGk8h3LRhzL2MGqOkcFaopIhs8x57?= =?us-ascii?Q?4k12mXCGH0ujOCONFhm74pRP6R4A5YnFKzC1SY8ajKa85vNB4u0Xf98DeIiD?= =?us-ascii?Q?HRcMKgiXaG5ADgKGvaDYGYwKwyythb9oKtq5iS+QRdTpK+mP3WSMBkjpBtqI?= =?us-ascii?Q?vCsKeArxIIHXHKYpvNNV8tpygIUH+EQVaz5ucM77lLdqyLq6+NB8waIDYuIK?= =?us-ascii?Q?uzko1+As8Pi4PLxcFApPt2JlJoGhLKRNQFPxZ0KITU9B24iWNbr6vpbHOTSP?= =?us-ascii?Q?i6+01sABmVvpSE6xzQRuudsOyLyuf5e97+WwTNDbCHTjVT+3+SwbkAy0zHcp?= =?us-ascii?Q?440jE1k/Pl/HdBxTIBlm5s+1xwWu78JLWUWlrPbSg4dJ3OPhoYQsi5xMY79h?= =?us-ascii?Q?wdBWu7E3SOBU/SS8zmCT7ke7itBneVlPe+idHw/R2P+jUvIzRRdzZ20mVODz?= =?us-ascii?Q?eWsm1stHI1OxNURb/GmLFo+fraI+bLzpw84dduf3a7RCsuchEeYX8ZxDzPyp?= =?us-ascii?Q?kayGgn4tqdSC7CuhjPbQxwXl6KElqjtkw3bswGBrrqRJIrghu7M7WNp8pi5Y?= =?us-ascii?Q?MxOCbZYSuJuAREfvuYwp1fJaJ4jdV6E8BSLnSgzu7mG+Uw3wOJAR6WJvuhj7?= =?us-ascii?Q?6C7IgABW0Yryfw0N40gfp9U/47U+hCeq0v9tSyphOvnc5mHscGI8AYTfKBFe?= =?us-ascii?Q?tBIwNs3V012RQTihZmHR3PAthKbSnE=3D?= X-Microsoft-Antispam-Message-Info: UWigHaYM6so5CdOq3OCizIew1KrOveAxhgqw536dJ9tH8hZaQCPsO/Tb2dh55x/YC4xV5WSvhwmvHxT6rGnCM8lTuUXnOfGreDVHlXo5Yvq+cXhwND3qV6MIQUCHZfHFcUuc4s2GWt68AeSaLMpjk6AsExXeUjG2wFlArfeEBw4iUP+YolOyPqsKStOlbLeJf6tkYcjQI7WbSeQUj/ZjD36T+Cy3W1myCm88AzCHWfEq4TCekYmMV4nEuUo2vejcT/HRp3oNo2WYf7f+SS26+Nc2h+rGkbLtggPBiBxJg6HDHhGFXe4Yr5AnMXBU0esoms+GeIRPOkQu9wKrOkfBX6XGhaUrSRIzGlJvs/yktoc= X-Microsoft-Exchange-Diagnostics: 1; DM6PR07MB5001; 6:e+FUn8ykCVIGWdgckzAMJvYloInYvjNPasfn87Cd7vWEj1MG3aQ5X3iM7grFrr+Tsuwrri4fL55kXj3fFbmWa3doUzOyOTM7XS88i9YkMWYbahxS57FrByx4RB8AtfhnXTtf1RnMAtgjx7NrDdSAAeJpB0x66TDMnFUMEQoxXqGMRtv4+Ku07rFXmGce1d8kRxw6EdeK+gT6Pg2XSaiBn2Po63PLtihG8qyrpLDXWTw/7/D3iM2cvRLmV5SSD++dgH6qIu+jIw+g+zQe3TxLIFS/Ov4JFCaKQw9PQ9PitvWvzTIRGjQ7CqJ/0oWDRWXIJ4vgCdDd33q3R8PvQmlVpvwYRIjhP5TntfZJbOB18+tpQY5E+/YNAyn2pvIGNZ6Gl5dU6CMuAt6FrRmEFy6YT2s2cNA43Jpv2TbLlkjiO9I4p2it70/ha5VDgBMFqhLCUXD/c+ADTRd1+/SLUmqZMA==; 5:wQdg2punV7q9EmAwvwVa9DX81gjz5MNxWWT3rVJRwH0K0PZeJEdXzQY5n1IXSV2xDK/HFBb7l+IKuBUEaW9ZVqx3/+k1XH1vZje7zHPiKoLE0j2jJQx6o8vPFjeWIYuEfrUy9d7a4tv1fDPJEoWBoEbzGrN1ajXeMK+plEGJsW4=; 7:XLktxeKBVOn0OgS9cKSok6LoKOBfZ2ZEW9FZzx5f4PfLl9DCsw9z7qmNidxDKk47Tn4MH588JfMmJmKBJB02I3F3yCrw4Ru4sLaGfBXGdPaCoc5FbVMGsyEleQ5iDx63X63u709zfeIybKfw0kTJ/ituOL2OFSC+OeMajlOgmKURGJHht3v7mGN4VD/gAcNUQIBFKPCj+nzwq/FPfr7r2LuicBKtd2Ktw5KI9RyqZ8xChWZzKTh3KJ1Py0UrLxr1 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Oct 2018 13:09:08.7911 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bfd3d525-7c4a-49c9-7f0c-08d62d1f3e83 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR07MB5001 Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: add Rx offload outer UDP checksum definition X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 13:09:17 -0000 -----Original Message----- > Date: Mon, 08 Oct 2018 15:03:49 +0200 > From: Thomas Monjalon > To: Jerin Jacob > Cc: Ferruh Yigit , "Ananyev, Konstantin" > , Andrew Rybchenko > , "Lu, Wenzhuo" , "Wu, > Jingjing" , "Iremonger, Bernard" > , "Mcnamara, John" , > "Kovacevic, Marko" , Olivier Matz > , "dev@dpdk.org" , > "shahafs@mellanox.com" , "didier.pallard@6wind.com" > > Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: add Rx offload outer UDP > checksum definition > > 08/10/2018 14:25, Jerin Jacob: > > From: Ferruh Yigit > > > On 10/8/2018 12:55 PM, Jerin Jacob wrote: > > > > From: Ferruh Yigit > > > >> On 10/8/2018 10:37 AM, Jerin Jacob wrote: > > > >>> From: Thomas Monjalon > > > >>>> 08/10/2018 10:24, Jerin Jacob: > > > >>>>> From: Ferruh Yigit > > > >>>>>> On 10/6/2018 1:18 PM, Ananyev, Konstantin wrote: > > > >>>>>>> From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > > >>>>>>>> From: Thomas Monjalon > > > >>>>>>>>> However, we should re-visit the flag PKT_RX_EIP_CKSUM_BAD. > > > >>>>>>>> > > > >>>>>>>> Do we need to block this patch due to the exiting PKT_RX_EIP_CKSUM_BAD > > > >>>>>>>> definition? > > > >>>>>>>> > > > >>>>>>>> I already added the author of the PKT_RX_EIP_CKSUM_BAD flag and ethdev and mbuf > > > >>>>>>>> maintainers in this list. So what else I need make forward progress > > > >>>>>>>> on this patch? > > > >>>>>>>> > > > >>>>>>>> I think, the definition of PKT_RX_EIP_CKSUM_BAD based on HW capability. It > > > >>>>>>>> is safe to assume that ALL HW can support CKSUM BAD if the feature is > > > >>>>>>>> available and hence it is more portable. > > > >>>>>>> > > > >>>>>>> Yes, as I remember PKT_RX_EIP_CKSUM_BAD is based on DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM. > > > >>>>>> > > > >>>>>> Switching to two bit won't reduce the portability, HW supports only reporting > > > >>>>>> CKSUM_BAD can set BAD || UNKNOWN. > > > >>>>> > > > >>>>> UNKNOWN is not a bit. It is represented as 0. It spec has 2 bit, then > > > >>>>> driver need to report GOOD as well. > > > >>>>> > > > >>>>> Same applies for PKT_RX_EL4_CKSUM as well. > > > >>>>> > > > >>>>>> > > > >>>>>> And I think patch is not blocked by PKT_RX_EIP_CKSUM_BAD, it can be changed > > > >>>>>> separately, for this patch question is can we represent PKT_RX_EL4_CKSUM_* with > > > >>>>>> two bits, to have BAD/GOOD/UNKNOWN? > > > >>>> > > > >>>> Yes, exact. > > > >>>> > > > >>>> PKT_RX_EIP_CKSUM_BAD must be left aside. > > > >>>> We should just avoid taking it as a reference. > > > >>>> And we can reconsider its definition later. > > > >>> > > > >>> OK. > > > >>> > > > >>> IMO, Using 2 bit scheme for tunneled checksum has following performance > > > >>> issue from driver side. > > > >>> > > > >>> Driver need to mark the packet as GOOD. All the HW can support > > > >>> detection of BAD. That not necessary mean GOOD in case of tunnel packet, > > > >>> so driver has to detect the packet is tunneled and packet is not BAD > > > >>> then mark GOOD. > > > >> > > > >> Yes UNKNOWN is not a bit, but a state, why don't use it? Why driver has to check > > > >> it is GOOD? > > > > > > > > The application is going to check is it GOOD or not. Not the driver, > > > > Right? My concern was, If application starts dropping the packet instead checking the BAD, if > > > > it checks == !GOOD. > > > > > > Got it, but when 2 bits state introduced, app should check if check == BAD for > > > drop decision, because it is not GOOD || BAD anymore. > > > > Got it. > > > > > > > > > > > > >> > > > >> 0x0 => UNKNOWN > > > >> 0x1 => BAD > > > >> 0x2 => GOOD > > > >> 0x3 => ? (invalid perhaps) > > > >> > > > >> HW that supports detecting good packets can set BAD || GOOD state, HW can detect > > > >> only BAD packet can set BAD || UNKNOWN state. > > > >> > > > >> If BAD is not set, there is an ambiguity of state, lets clarify it in lower > > > >> level, if it is UNKNOWN, let application know it is UNKNOWN. > > > > > > > > OK. > > > > > > > > How about the following then? > > > > > > > > /** > > > > * Mask of bits used to determine the status of outer RX L4 checksum. > > > > * - PKT_RX_EL4_CKSUM_UNKNOWN: no information about the outer RX L4 checksum > > > > * - PKT_RX_EL4_CKSUM_BAD: the outer L4 checksum in the packet is wrong > > > > * - PKT_RX_EL4_CKSUM_GOOD: the outer L4 checksum in the packet is valid > > > > * - PKT_RX_EL4_CKSUM_INVALID: invalid outer L4 checksum state. > > > > * > > > > * The detection of PKT_RX_EL4_CKSUM_GOOD shall be based on the given > > > > * HW capability, At minimum, the PMD should support > > > > * PKT_RX_EL4_CKSUM_UNKNOWN and PKT_RX_EL4_CKSUM_BAD states > > > > * if the offload is available. > > > > */ > > > > #define PKT_RX_EL4_CKSUM_MASK ((1ULL << 21) | (1ULL << 22)) > > > > > > > > #define PKT_RX_IP_CKSUM_UNKNOWN 0 > > > > #define PKT_RX_IP_CKSUM_BAD (1ULL << 21) > > > > #define PKT_RX_IP_CKSUM_GOOD (1ULL << 22) > > > > #define PKT_RX_IP_CKSUM_INVALID ((1ULL << 21) | (1ULL << 22)) > > > > > > Looks good to me. > > > > If there is no objection with above flag definition, I will send the v3 with that. > > Just one objection about the name. > Why naming it EL4 and commenting as outer L4? > I think we should choose between "external" and "outer". > Convention seems to be choosing "outer" word. > So I suggest PKT_RX_OUTER_L4_CKSUM_*. OK. I will change to PKT_RX_OUTER_L4_CKSUM_* > > >