From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0080.outbound.protection.outlook.com [104.47.38.80]) by dpdk.org (Postfix) with ESMTP id 200CD5F36 for ; Thu, 4 Oct 2018 07:59:54 +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=yezN9Id9ZaoPzSSB16ZIbIbxw1y1b0VI/SjRbKkZIq4=; b=ZljkxLXbmaYLfUQfX/JzQM4azVQrC88t9aEJgr1Z38OMWsgttBbcZjufmZTNZ+c1+3i5iox5w88vdSVV+rjkv+LBFahbUNe0onP0/iz3WUknrsRjuCXY8wOd/36fjFJSvapC38bK4I1MpnKRsDlzd+oVGPhw9J9kuCGqWHGFRlw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Jerin.JacobKollanukkaran@cavium.com; Received: from jerin (106.201.57.251) by SN6PR07MB5008.namprd07.prod.outlook.com (2603:10b6:805:ad::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.21; Thu, 4 Oct 2018 05:59:47 +0000 Date: Thu, 4 Oct 2018 11:29:32 +0530 From: Jerin Jacob To: Andrew Rybchenko Cc: Wenzhuo Lu , Jingjing Wu , Bernard Iremonger , John McNamara , Marko Kovacevic , Thomas Monjalon , Ferruh Yigit , Olivier Matz , dev@dpdk.org, shahafs@mellanox.com, "Ananyev, Konstantin" Message-ID: <20181004055930.GA4406@jerin> References: <20180913134707.23698-1-jerin.jacob@caviumnetworks.com> <20181002192451.19119-1-jerin.jacob@caviumnetworks.com> <20181003075712.GA2003@jerin> <20181003171252.GA3193@jerin> <209397d1-f1ee-befb-1593-5adb58045bc5@solarflare.com> <20181003181412.GA8662@jerin> <8195dbcb-4b05-b47b-ebdf-2a8c36fa2974@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8195dbcb-4b05-b47b-ebdf-2a8c36fa2974@solarflare.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Originating-IP: [106.201.57.251] X-ClientProxiedBy: SG2PR03CA0123.apcprd03.prod.outlook.com (2603:1096:4:91::27) To SN6PR07MB5008.namprd07.prod.outlook.com (2603:10b6:805:ad::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f78ef481-f24d-47f6-317d-08d629be99a2 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:SN6PR07MB5008; X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB5008; 3:IdIQeGtlEz9i7fLRpsiEY+lb3kmCkHCb60JsOaLybQrCkufLpXo5XjYjl1D2W3RmRSkdA619BXR65Keok8pgmr2EYbFTPRiV6WHoPHzZO98uPs5Fr9OR22XoHgaoCAE8Lg4X4NJJ0hTY9MZnceCvL1DrQyERrpk2D0DKEj3ZLxgcmpJJxewisiW04QEjaeN7JOsZiGT6e8xPqZFtXoM963hbRWePXFi7X8XHvU0QIUPhZ8ks9dcXwHTSFC9WYFdK; 25:wAsnUmnLhIooD2m+vo3fyLxQfuYl3CrGvYikp27EA4Org1LTDtx+0rg6W1mAtPnT5cs9GMDCzAjOBx9Co3qQHSk2faLjH1RlhDSW/fR18A1QTMza1Gf8knZfnQOB39B6WPXZ3J/HCv/g5T9fORjj3GF5dsLr3qggADLg6lY5iAOKv0Oxl45xEq2Dw7RP9G8Fj378FIi5Hq7AQt2LL6vn0vAwXlqDWN1EmIaxucYATJaHl+ohYX6cBqQ53edKKYLjDX/Tx8XP0pRK2uDOWFkx7zzJjwgWTjb0xLDm9HNCwSTJnET6lQ7iaHrMcgOFe2mdh1yY9aqbFRRRhRzva1qe4w==; 31:2KQroANMpQeJcVACspXJI118uRoscgKdd1QSrXjP/ZYxIFHtXPp2OiTHtwSRTjyYulxzkjRcYbN0Uqh0PlGcBQVpCXdUCXz19Xh71J3NwcuRRdgv8mFwBMh9ehEs1o+o24tLvJno7oTOguu0fm3uyli1iS2MPxTLvRCkAqEruwZwR3RgAW3q5aDzq2VXYYuSiICJXZnkDQsGCyOFXHREzI5qCHQseuNyc+B+xAGSJ1M= X-MS-TrafficTypeDiagnostic: SN6PR07MB5008: X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB5008; 20:9E1dQMMWrIQg/sfy04V4G1ueRtSa91a9TQm7qe4NCbfYb2cboAN/VqxPDgFN4+tNJQCd49R+pbmT1+JpGMkVXyPzr8PoTQI2CIM1Plqatpj3WnfnI9/ikeHweFxg6trVO/l5CCjDZwv/8vX9L5hmffehSjkrZVI7Mcrpdj3PrtazDw53EGdZ1J0/y9ipGxuQZkoPwRm7qS16CRYHForPKsyPXv2Xd1OtLDuheX3pApNeqdtBP3Jztuix+KekaNIz5mm9SzDuMxRTAjx3DOdOZr+qjYkkEsoz4e5mKfzDgglLfbrsEKwIleWzLBMRLOmUciJRwrgcGUS4vqAWWTfykRxpupz6rcomYppSSvE3eNwZkgctbOxtroxONZCMydrV5CaoBmE+BpOmXHHcUPOU1nqQwirkPAd4y4txJSGF6c1JroGUmVtZ9hUhAuei+Xy/HOEzW6gxz2+Z0SPX8ECFlaZaQGWHbzGsOOZunSqeJNuAg6i54gR/UEjB0Jwv/G7AN2Y6Q1lcqc+DOsyeZICuW5y7Cbx0ie2HhJCbKQJp9J+MUIb/dLz/npAuBivH6lPBvDiQESLzPNbtKdnceKY9OmMTO9fXnUhXyTm4nVYIvJw=; 4:5AL4q0rCBXFXebLOgBwrzk6gJ/8dhH4aqW5ieNsKDT6eC6WG7zR8ctKoa7/35j4Smxl7dSre5Nq5DIZnGGCEXjyE+hsclQ2P2X16mwvn1aRkz2RSG0Dj3atBeq+Sol07W+a3nycI1ARHJgO/+ELuQqQfmCl7SuoeB2NrAnbVkVzAhT6z58mP1KdHd2U4Qp5jVmgvIwkhMrRRu5lz2zDBF11cEZupawbTT8taen+c7rfB/MsOp3fiqJhSZN2vnGI4lukSeUXl2wEAZJRrWnpqKIqtfc/extein/DUwHnPBKShEoTU39It+JwGMqjG7I2r X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(228905959029699); X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(3002001)(10201501046)(3231355)(944501410)(52105095)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051); SRVR:SN6PR07MB5008; BCL:0; PCL:0; RULEID:; SRVR:SN6PR07MB5008; X-Forefront-PRVS: 0815F8251E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(396003)(366004)(39860400002)(199004)(189003)(13464003)(52314003)(16526019)(66066001)(5009440100003)(476003)(72206003)(47776003)(478600001)(44832011)(14444005)(6916009)(42882007)(305945005)(26005)(25786009)(446003)(956004)(11346002)(93886005)(6666003)(486006)(5660300001)(186003)(7416002)(7736002)(33656002)(55016002)(54906003)(23726003)(9686003)(76176011)(33716001)(97736004)(316002)(105586002)(4326008)(53546011)(8936002)(6116002)(58126008)(3846002)(2906002)(16586007)(52116002)(6246003)(6496006)(81166006)(81156014)(1076002)(8676002)(229853002)(106356001)(50466002)(386003)(53936002)(68736007)(55236004)(33896004)(18370500001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR07MB5008; H:jerin; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR07MB5008; 23:HGfYTfVLSY45fkO7CBJ/+4HHRpDGh4a1tSLqdxh4a?= =?us-ascii?Q?MpNG5MZyHuyLCQl/I52Gpq4ly6d/r2exwIULgC6u/s1pvPTmA1OF9BRP08hj?= =?us-ascii?Q?uJi45SL3Cw40Mw3hFLFvUO1NOWOE/I+cIlfIhoFthOSAK0/glh4ECbgFYQuD?= =?us-ascii?Q?HYI7+FAmpGEC+Hj9ABh9mTQXA9njNrtbjYFmNNRtyoKBqndSBRunuOcP/1VQ?= =?us-ascii?Q?zQ7+BIKz9uuKODHfJNrWdOAZgLpB85SaL4VRiUrxdjwUrR9VgOM1DtxZbzyN?= =?us-ascii?Q?xICbknFJ3U4t2tyWjKkVFOSss9t+/sxDLMhKpjLmpKmDum17royxZ9KBJd55?= =?us-ascii?Q?gdkProMyGb47G4xaRSR3JaMEHT/62xDT03ulX9v7gObvRtwRQAZVljOhlzkL?= =?us-ascii?Q?2t+FIsTZ5GniRDYmKlf4PJ0UsacQths4c4hHDKgUjgw6U+jHHDcnGqMAUOQ6?= =?us-ascii?Q?1wULlNY1baRm/3nPPhSQMiksTZJ6SmATcs0aC5ig18UUQbPhoL5mcfsby63z?= =?us-ascii?Q?FIJHNYABKuV7HiqKgFuqoWPre7XSAe0b0K/y8cwLohV5UZ+15Wrso9vQFrE9?= =?us-ascii?Q?0FE/fRpa2yGlxLpjVF1WFZMsR8CiPjy1oXfY11fLe9D5WtmwfZNYD78a8ir+?= =?us-ascii?Q?wWNNyTryOMF2LZVp5Zv8oQSinaKwwAkd4SMxyy3LFac7fZdPsyp7t3BPo2Vu?= =?us-ascii?Q?36Lz02GLhof1dLtUhdIXwImwclFbQLAbrPTu6PSWsaqmYFfoZosUUjcPWTCv?= =?us-ascii?Q?+j397GgGfFIp7eNHF5zqehuaOfX8Pwgwf2+JVnqS2Vx3wn5+xndgslCRD1FJ?= =?us-ascii?Q?YHjPJb0iFhzlm6AzyPcvPb2NjseATIS8f+vXA919ET095hjQh6hJMcEpa90Q?= =?us-ascii?Q?8bmli61nY+lPHj11maxLyl7y3MsnL2FOD1zFZCFyas52oQ28DTPHLbzjdMNB?= =?us-ascii?Q?x1tWEtHxRXjzWglHoLOXKSOoNM4XznGMcMa1X76siKHpICLerYYGnLfc2mfJ?= =?us-ascii?Q?3ClX5j5wgNdI/4YsNx1Yws/wqGl2n7lGZhMMAXyv0Yjd4dhJxBA+at6BJJoz?= =?us-ascii?Q?JAQSryt/paZ0afBBTYUlirGglSCrNuc2uz9bKs8T155n78+we9OwInaX+5xt?= =?us-ascii?Q?iupn0/tnnIxVr1VCxnyzw3mqms+5YiJU+dTSct8T1ZWQkzn1Ej1cE470wKTg?= =?us-ascii?Q?YR1LGt1sp8q/3WTR3IKTsFcwizjpdEzwdFDN8sjqcGePCMP975v96twNbig8?= =?us-ascii?Q?c4rxJm3tE6Rrup/CQv0w59vs99C3mE50ENopWygRCrtS5fpQFAH5fsXDOB4w?= =?us-ascii?Q?XO5QXLCQ4uieJ2JawduLMflACUVrN6GHGa9E9jOI3XQ1unoztQTh38FpUEQ0?= =?us-ascii?Q?QjiF03Brjg96br2KBnqWC6bI5+dh+Zqb4NkRWSqRCzXfUY2uNs46b3vetM05?= =?us-ascii?Q?21zFTiCArC+RAdsbchbLEx1nOuqB84bRozb7RDfVs62dhZK8tCGBua8/Bj/C?= =?us-ascii?Q?reH2qA4aKXZEI74mQtpg41TXjNnZfQoOtw=3D?= X-Microsoft-Antispam-Message-Info: 1fkfEoZI6XHWz9PVOQafJFWN0u0cI3MAIMZcZrltnxt2zLB9nW/vVOeVZKPi/8MKTQCWFC4cJwwOCQGXFrPXb5LHzt70l4NmOMPvYLq7oKZZ8C5KLooEETfx7zO1387TkuGzT5ziwt9Y5aBMD8MHZL/0r5++HyEhNnMl8UMN1mJNjnWASq1CTI/PSlidJ5UOB7m1BXW9VjwNMyY8/uEE/U9N8wbfwC9taX4um1Uq+frN5hMsZT/kxZk6qxHsZFQzd2FCBLSzcW082bfVFCKwCepU2zC55a7eimlw/D9tBxZuzpRvgv7wVCfOMaSmC0T+v5MMAdZT14mEUfAo3+U2LcN+2aWE00h6XZFWrfBpRMM= X-Microsoft-Exchange-Diagnostics: 1; SN6PR07MB5008; 6:zXtwf1yiKkPSN9XOcBNTEX5KZaRlnZjHzLi11MmtV9litHKsMJgn8ZYVEeXsvLRpcMM1XtJSaK23fCH5zFSB1fxZA60yKV6TbScl36uYov/p9A8m3ivmcy7Jq2l42qNCrh7REH128F8KdBq/vVyFgR4zw2xY371tIuNasyi9l816+xhra6UVcMks3OyRuLjyjEyxRTKcN3IX8BzfXCvsATOLub8Jq5CsTLzYc8lzweaASbPXcLDMwhdNDpOYgIGNFJ/KdRtflZ6sgCY0V5DSnrABnbXsFpwxo4k2jVvEoIsf4Q9Zr4olzcUN3Dj2qifKco3ZiuBVVIJQzuF4i4/TBvDunw7eo1FbLTuAuXXeWHGKcaW3jdKHoffLD9hKese7oypR0f48wrxXN0+KdPcQIxmrr8ICmmm51pRAZnx9dPL80wEPqYaBmapsJ6XZVKhSAls/MTl5zBOn6tQZokvP3Q==; 5:/3qRn0hqsD5WImMkjVxeIBZ5iABaeVOpQEa1S9jtonQ8dHelAhcpm3EcvTntWpubxp0wK5U5JEJyB8I5zx0hWApgXMyPA9U/pq2A0whLDpeBpO+THBMBLSToR7EA5jCYrRCH9sG5LLckKNulELJnKhK4rVivTG9PV8yYdV/XoO8=; 7:lYOXLJy2gbKGqrj9NzUS/nLbH4Yd+sazdNcxFXJ9ZbPfGO2Otc8WqGLQi3/j+R3ef9P2iVb4JQjfK5QuSz40FO/gbXVfi4193IRbskNypJLIZSVHL+aTijbNfH3PuB3qf2UxRyfYp2XEd0b0pRE/FIcUzUXNiv52GgS+HY7orUU9mCQhRIzjwwR96jkyTDRa1INV3HZ0B8ZnCK2+MMS9XpN3B14BmOuuVCk9eozwkXfRStYBnKlA+ufOgdFfAcKU SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2018 05:59:47.5342 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f78ef481-f24d-47f6-317d-08d629be99a2 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR07MB5008 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: Thu, 04 Oct 2018 05:59:54 -0000 -----Original Message----- > Date: Wed, 3 Oct 2018 22:47:15 +0300 > From: Andrew Rybchenko > To: Jerin Jacob > CC: Wenzhuo Lu , Jingjing Wu , > Bernard Iremonger , John McNamara > , Marko Kovacevic , > Thomas Monjalon , Ferruh Yigit > , Olivier Matz , > dev@dpdk.org, shahafs@mellanox.com, "Ananyev, Konstantin" > > Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: add Rx offload outer UDP > checksum definition > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 > Thunderbird/52.9.1 > > > Hi Jerin, Hi Andrew, > > On 03.10.2018 21:14, Jerin Jacob wrote: > > -----Original Message----- > > > Date: Wed, 3 Oct 2018 21:00:37 +0300 > > > From: Andrew Rybchenko > > > To: Jerin Jacob > > > CC: Wenzhuo Lu , Jingjing Wu , > > > Bernard Iremonger , John McNamara > > > , Marko Kovacevic , > > > Thomas Monjalon , Ferruh Yigit > > > , Olivier Matz , > > > dev@dpdk.org, shahafs@mellanox.com, "Ananyev, Konstantin" > > > > > > Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: add Rx offload outer UDP > > > checksum definition > > > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 > > > Thunderbird/52.9.1 > > > > > > On 03.10.2018 20:12, Jerin Jacob wrote: > > > > -----Original Message----- > > > > > Date: Wed, 3 Oct 2018 13:27:13 +0530 > > > > > From: Jerin Jacob > > > > > To: Andrew Rybchenko > > > > > CC: Wenzhuo Lu , Jingjing Wu , > > > > > Bernard Iremonger , John McNamara > > > > > , Marko Kovacevic , > > > > > Thomas Monjalon , Ferruh Yigit > > > > > , Olivier Matz , > > > > > dev@dpdk.org, shahafs@mellanox.com, "Ananyev, Konstantin" > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: add Rx offload outer UDP > > > > > checksum definition > > > > > User-Agent: Mutt/1.10.1 (2018-07-13) > > > > > > > > > > External Email > > > > > > > > > > -----Original Message----- > > > > > > Date: Wed, 3 Oct 2018 10:34:52 +0300 > > > > > > From: Andrew Rybchenko > > > > > > To: Jerin Jacob , Wenzhuo Lu > > > > > > , Jingjing Wu , Bernard > > > > > > Iremonger , John McNamara > > > > > > , Marko Kovacevic , > > > > > > Thomas Monjalon , Ferruh Yigit > > > > > > , Olivier Matz > > > > > > CC: dev@dpdk.org, shahafs@mellanox.com, "Ananyev, Konstantin" > > > > > > > > > > > > Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: add Rx offload outer UDP > > > > > > checksum definition > > > > > > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 > > > > > > Thunderbird/60.0 > > > > > > > > > > > > > > > > > > On 10/2/18 10:24 PM, Jerin Jacob wrote: > > > > > > > > > > > > Introduced DEV_RX_OFFLOAD_OUTER_UDP_CKSUM Rx offload flag and > > > > > > PKT_RX_EL4_CKSUM_BAD mbuf ol_flags to detect outer UDP checksum > > > > > > failure. > > > > > > > > > > > > - To use hardware Rx outer UDP checksum offload, the user needs to > > > > > > configure DEV_RX_OFFLOAD_OUTER_UDP_CKSUM offload flags in slowpath. > > > > > > > > > > > > - Driver updates the PKT_RX_EL4_CKSUM_BAD mbuf ol_flag on checksum failure > > > > > > similar to the outer L3 PKT_RX_EIP_CKSUM_BAD flag. > > > > > > > > > > > > Signed-off-by: Jerin Jacob > > > > > > > > > > > > 1. I'm not sure that it is OK that mbuf and ethdev changes go in one patch. > > > > > > It seems typically mbuf changes go separately and mbuf changes should > > > > > > be applied to main dpdk repo. > > > > > I don't have strong opinion on this. If there are no other objection, I > > > > > will split the patch further as mbuf and ethdev as you pointed out. > > > > > > > > > > > 2. I'd like to see thought why single bit is used for outer L2 checksum when > > > > > > 2 bits (UNKNOWN, BAD, GOOD, NONE) are used for PKT_RX_L4_CKSUM. > > > > > > May be it is OK, but it would be useful to state explicitly why it is decided > > > > > > to go this way. > > > > > I am following the scheme similar to OUTER IP checksum where we have only > > > > > one bit filed(PKT_RX_EIP_CKSUM_BAD). I will mention in the git commit. > > > > > > > > > > > > > > > > 3. PKT_RX_L4_CKSUM_MASK description says nothing if it is inner or outer. > > > > > > May be it is not directly related to changeset, but I think it would be really > > > > > > useful to clarify it. > > > > > I will update the comment. > > > > Hi Andrew, > > > > > > > > I looked at the other definitions in mbuf.h, according the documentation, > > > > If nothing is mentioned it is treated as inner if the packet is > > > > tunneled else it is outer most. So I would like avoid confusion by > > > > adding "inner" in the exiting PKT_RX_L4_CKSUM_MASK comment. > > > > Technically it is not correct to say "inner" if the packet is not > > > > tunneled. So I am untouching the exiting comment. > > > > > > > Yes, it is incorrect to say that it is inner. How does application find > > > how to treat PKT_RX_L4_CKSUM (inner or outer)? > > > Should it rely on packet type provided in mbuf? > > AFAIK, Finding is it a tunneled packet or not is through ptype or SW has > > to parse the packet. For example, testpmd chooses later method using > > "csum parse-tunnel on " to detect the presence of the tunnel. > > SW parsing of the packet cannot help, since app should be sure > that HW has classified the packet as tunneled and provided information > about inner and outer checksum checks. I thought the question was, How does the application find how to treat PKT_RX_L4_CKSUM (inner or outer)? Obviously, ptype will help here Not sure why SW parsing won't help here if SW parses and find it is an inner packet or it is not a tunneled packet. PKT_RX_L4_CKSUM treat as inner checksum for former case and PKT_RX_L4_CKSUM treated as plain l4 checksum in the latter case. > > > > Is it specified/mentioned somewhere? > > I don't know. It it not directly related to this change set, Olivier may know > > additional details. > > I disagree. You're adding one more offload flag. Yes, it simply follows > existing RX_EIP_CKSUM_BAD pattern. But, IMHO, RX_EIP_CKSUM_BAD > has many open questions. Why should these open questions be preserved > here? It is similar to the code with a bug which is cloned once again with > the bug :) No disagreement here. I choose to follow the existing scheme, because if I do another way around, still I will get the question on why it is different than the outer IPV4 checksum scheme. Looking at the history, the mbuf DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM change went part of ixgbe change d909af8f72ca ("ixgbe: offload VxLAN and NVGRE Rx checksum on X550"). Al east in the HW I know, We can support "two bit" fields for Outer IP checksum and Outer L4 checksum. So I think, the decision was made based on ixgbe capability or probably no one noticed the change as the subject was ixgbe: Anyway, i don't have strong preferences on 1 bit vs 2 bits. I think, 1 bit can be supported by all the HW if supports this feature. Leaving the decision to ethdev and mbuf maintainers. > > If everyone else is fine with the description of Rx checksum offloads and > it is only me who is unhappy with it - no problem. > > Thanks for your patience and I'm sorry that I'm really boring with it. > My goal is just to make it clear and as the result have less bugs in > networking PMDs and applications. No problem. :-) > > Andrew. >