From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 83CB858EC for ; Mon, 30 Jul 2018 17:30:50 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 25F6AB00095; Mon, 30 Jul 2018 15:30:49 +0000 (UTC) Received: from [192.168.1.16] (85.187.13.33) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 30 Jul 2018 16:30:34 +0100 To: Jerin Jacob , "Ananyev, Konstantin" CC: Thomas Monjalon , "dev@dpdk.org" , "Yigit, Ferruh" , "shahafs@mellanox.com" References: <20180729124409.3669-1-jerin.jacob@caviumnetworks.com> <2601191342CEEE43887BDE71AB977258DF51F641@irsmsx105.ger.corp.intel.com> <20180730093555.GA22823@jerin> <1687236.JLa48GYJ5r@xps> <2601191342CEEE43887BDE71AB977258DF51F702@irsmsx105.ger.corp.intel.com> <20180730111823.GA30059@jerin> <2601191342CEEE43887BDE71AB977258DF51F775@irsmsx105.ger.corp.intel.com> <20180730144031.GA14898@jerin> From: Andrew Rybchenko Message-ID: <3cbcc295-1b3c-fd22-f5ae-0478f370ab68@solarflare.com> Date: Mon, 30 Jul 2018 18:30:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180730144031.GA14898@jerin> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [85.187.13.33] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24000.003 X-TM-AS-Result: No-24.269400-8.000000-10 X-TMASE-MatchedRID: rYpa/RC+czH4ECMHJTM/uSa1MaKuob8Pt3aeg7g/usAutoY2UtFqGCZK RIFpXA+BNNAbhni610En5flxzz7NDuyt+a9Mtf+eEhGH3CRdKUVKgIbix5+XxMK34UPgqNydX76 nsPTfwCT9yL6hHwS2FSsRTIOb60EpHvtWdNrtrGpjoaO27r+3fbBH/AqZyGLZc/T3GfQUvxlG8d s4ogWonIYtODbHEOdRvQWxE/4ZRcdgNTke+eoi14QnnAFRgjn98boZEVitthg4v/3Wd2CNuebGU 8GB3wTONiXZiw5no5tQTXrOpS5fGqFoka5IFiLkM8ORI7N4NZablYigUqC4Fn7atTPsdldu9Tva dhXG9g0oCQN8hlDNTdJFF2xeePNlkyJNOjqnOUWcnm0v4tsY45tB9i95I0IKYsz9F4FLBTAPcl+ 7fpAjYUYytG/fSlnKN3/IvTQZMHoEzeXnrjwsy8qXjImgj58b8NhBCxf6R8ObSCvttIEONj9RhD VQ/mzMpLlrQ8YxD52Rk6XtYogiau9c69BWUTGwL+25vAeQJJfcyHXbbFd0K2LiArXOsLgQC24oE Z6SpSkj80Za3RRg8Mxh05Pftq44xhlG2tqNuDWP3kCQLPPnsTBC2ty6DyiF3kRYkQbxsFY= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--24.269400-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24000.003 X-MDID: 1532964650-J0iAIFxJvGYH Subject: Re: [dpdk-dev] [PATCH] examples: remove Rx checksum offload 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, 30 Jul 2018 15:30:50 -0000 On 30.07.2018 17:40, Jerin Jacob wrote: > -----Original Message----- >> Date: Mon, 30 Jul 2018 14:12:12 +0000 >> From: "Ananyev, Konstantin" >> To: Jerin Jacob >> CC: Thomas Monjalon , "dev@dpdk.org" , >> "Yigit, Ferruh" , "shahafs@mellanox.com" >> >> Subject: RE: [dpdk-dev] [PATCH] examples: remove Rx checksum offload >> >> >>> -----Original Message----- >>>> Date: Mon, 30 Jul 2018 11:00:02 +0000 >>>> From: "Ananyev, Konstantin" >>>> To: Thomas Monjalon , Jerin Jacob >>>> >>>> CC: "dev@dpdk.org" , "Yigit, Ferruh" >>>> , "shahafs@mellanox.com" >>>> Subject: RE: [dpdk-dev] [PATCH] examples: remove Rx checksum offload >>>> >>>> External Email >>>> >>>>> -----Original Message----- >>>>> From: Thomas Monjalon [mailto:thomas@monjalon.net] >>>>> Sent: Monday, July 30, 2018 10:51 AM >>>>> To: Jerin Jacob ; Ananyev, Konstantin >>>>> Cc: dev@dpdk.org; Yigit, Ferruh ; shahafs@mellanox.com >>>>> Subject: Re: [dpdk-dev] [PATCH] examples: remove Rx checksum offload >>>>> >>>>> 30/07/2018 11:35, Jerin Jacob: >>>>>> From: "Ananyev, Konstantin" >>>>>>>> As of now, application does not check PKT_RX_*_CKSUM_* flags per >>>>>>>> packet, so it does not matter DEV_RX_OFFLOAD_CHECKSUM enabled or not. >>>>>>>> >>>>>>>> Removing DEV_RX_OFFLOAD_CHECKSUM offload so that driver can save a few >>>>>>>> cycles if possible. >>>>>>> Personally, I'd move in other direction: keep RX checksum offload and add >>>>>>> checks inside sample apps to handle (drop) packets with invalid checksum. >>>>>> OK. Till someones add the DROP logic in application, Can we take >>>>>> this patch? Because there is no point in enabling DEV_RX_OFFLOAD_CHECKSUM >>>>>> without DROP or any meaning full action in application. >>>> Probably, but at least it gives users a right estimation how long the proper >>>> RX/TX routine would take. >>> For estimation, application can add any flag they want in local setup. >>> It does not need to be upstream with out feature complete. >>> >>>> From other side what the point to disable these flags now, if we know that >>> At least nicvf Rx routines are crafted based DEV_RX_OFFLOAD_CHECKSUM >>> flags. If driver Rx routine crafted such case it will be useful. >>> >>>> we are doing wrong thing and will have to re-enable them again in future? >>> But it is not correct now either. Right? >> Yes, right now invalid cksum information is simply ignored. >> As you pointed - some PMD select RX routine based on checksum offload flags. >> Yes, removing these flags might produce better performance numbers. >> But from my perspective - it would be an artificial and temporary improvement, >> as for l3fwd like apps we'll need to revert it back and add code to drop invalid packets. > IMO, It is OK get a performance hit when do that support in l3fwd. There > is no harm in removing the DEV_RX_OFFLOAD_CHECKSUM flag for now and it > is correct from application perspective.(you are enabling an offload when > you are using it, else don't enable it. I believe, this was philosophy for > enabling Rx/Tx offloads) > > Since it is going in circles, I leave decision to ethdev maintainers. I think that IPv4 checksum offload is essential for l3fwd. So, it should be enabled and taken into account. I'm not sure about TCP and UDP checksum offloads. It is not l3fwd business to take a look at upper layers. In any case, there is no agreement on the patch and it is already RC3 stage of the release. There is no rush to apply it since it is not a critical bug fix. I agree with Konstantin here. Andrew >> Konstantin >> >>>>> If there is no patch sent to use this offload on August 1st, >>>>> then I will apply this patch to remove the offload request. >>>>> >>>> Isn't it too late to do such things right now? >>>> We are in RC3 stage and doesn't look like a critical issue. >>> Yes. We can add it when have we proper fix. Currently, it signaling a wrong >>> interpretation to application. >>> >>> >>>> Konstantin >>>> >>>>