From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 2FB192C51 for ; Thu, 2 Jun 2016 09:49:45 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 02 Jun 2016 00:42:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,405,1459839600"; d="scan'208";a="989449615" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga002.jf.intel.com with ESMTP; 02 Jun 2016 00:42:28 -0700 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX151.ger.corp.intel.com (163.33.192.59) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 2 Jun 2016 08:42:27 +0100 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.10]) by IRSMSX156.ger.corp.intel.com ([10.108.20.68]) with mapi id 14.03.0248.002; Thu, 2 Jun 2016 08:42:27 +0100 From: "Chandran, Sugesh" To: "Ananyev, Konstantin" , Stephen Hemminger , Olivier MATZ CC: Yuanhan Liu , "dev@dpdk.org" , "Richardson, Bruce" , Adrien Mazarguil , "Tan, Jianfeng" Thread-Topic: [dpdk-dev] about rx checksum flags Thread-Index: AQHRuoezRmm+fNew7kKI9gqfLUQ5c5/SoZ8AgAC5KoCAABVVAIAACI2AgAAR1oCAALl4AIABiH1g Date: Thu, 2 Jun 2016 07:42:27 +0000 Message-ID: <2EF2F5C0CC56984AA024D0B180335FCB13DDA800@IRSMSX102.ger.corp.intel.com> References: <574C5B9D.4080006@6wind.com> <20160531080916.GI5641@yliu-dev.sh.intel.com> <574DE1FF.6060402@6wind.com> <20160531132820.4fadfc2e@xeon-e3> <574DFB11.5020701@6wind.com> <20160531150247.15819f1d@xeon-e3> <2601191342CEEE43887BDE71AB97725836B694D3@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725836B694D3@irsmsx105.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDYxNGVkZDktMzgzNi00Mzc0LWE5NmYtOTQ1ZWE2MTU5MDcxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Imx0WmtjcHZENzI0bnFZZlZGNDRCZEFCK2hkbGkrd1F2NHdIZk13XC9Bc1RFPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] about rx checksum flags X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 07:49:45 -0000 Hi Olivier, Thank you for working on this.. A comment on the proposal is given below, =20 Regards _Sugesh > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, > Konstantin > Sent: Wednesday, June 1, 2016 10:07 AM > To: Stephen Hemminger ; Olivier MATZ > > Cc: Yuanhan Liu ; dev@dpdk.org; Richardson, > Bruce ; Adrien Mazarguil > ; Tan, Jianfeng > Subject: Re: [dpdk-dev] about rx checksum flags >=20 >=20 >=20 > > -----Original Message----- > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > > Sent: Tuesday, May 31, 2016 11:03 PM > > To: Olivier MATZ > > Cc: Yuanhan Liu; dev@dpdk.org; Ananyev, Konstantin; Richardson, Bruce; > > Adrien Mazarguil; Tan, Jianfeng > > Subject: Re: [dpdk-dev] about rx checksum flags > > > > On Tue, 31 May 2016 22:58:57 +0200 > > Olivier MATZ wrote: > > > > > Hi Stephen, > > > > > > On 05/31/2016 10:28 PM, Stephen Hemminger wrote: > > > > On Tue, 31 May 2016 21:11:59 +0200 Olivier MATZ > > > > wrote: > > > > > > > >> > > > >> > > > >> On 05/31/2016 10:09 AM, Yuanhan Liu wrote: > > > >>> On Mon, May 30, 2016 at 05:26:21PM +0200, Olivier Matz wrote: > > > >>>> PKT_RX_L4_CKSUM_NONE: the L4 checksum is not correct in the > > > >>>> packet data, but the integrity of the L4 header is verified. > > > >>>> -> the application can process the packet but must not verify = the > > > >>>> checksum by sw. It has to take care to recalculate the cksu= m > > > >>>> if the packet is transmitted (either by sw or using tx > > > >>>> offload) > > > >>> > > > >>> I like the explanation you made at [1] better :) > > > >>> > > > >>> So in general, I think this proposal is good to have. > > > >> > > > >> Thanks everyone for your feedback. > > > >> > > > >> I'll try to send a first patch proposition soon. > > > >> > > > >> Regards, > > > >> Olivier > > > > > > > > I think it is time to ditch the old definitions of Rx checksum and > > > > instead use something more compatiable with virtio (and Linux). I.e > have three values > > > > 1) checksum is know good for packet contents > > > > 2) checksum value one's complement for packet contents > > > > 3) checksum is undetermined > > > > The original definition seems to be Intel HW centric and applies > > > > to a limited range of devices making it unusable by general applica= tion. > > > > > > > > Break the ABI, and ditch the old values (ok mark > > > > PKT_RX_L4_CKSUM_BAD as __deprecated and remove all usage). > > > > > > > > > > Don't you think knowing that a checksum is bad could be useful? > > > > Not really. They should be mark as undetermined, then software can > > recheck for the possibly buggy hardware. >=20 > Hmm, I don't see the point here. > If the HW clearly reports that checksum is invalid (not unknown), why SW = has > to assume it is ' undetermined' and recheck it? > To me that means just wasted cycles. > In general, it sounds like really strange approach to me: > write your SW with assumption that all HW you are going to use will not w= ork > correctly. >=20 > > > > > In that case the application can drop/log the packet without any > > > additional cpu cost. > > > > > > What do you mean by beeing unusable by general application? > > > > Right now application can only see "known bad" or "indeterminate" > > there is no way to no which packets are good. Since good is the > > desired/expected case, software has to checksum every packet. > > > > > > > > I think the "2)" also requires a csum_start + csum_offset in mbuf > > > structure, right? > > > > Not really, it would mean having a way to get the raw one's complement > > sum out of the hardware. This is a good way to support the tunnel > > protocol du jour without having to have firmware support. > > Unfortunately, most hardware vendors don't believe in doing it that way= . >=20 > It might be a good feature to have, but if most HW vendors don't support = it > why to bother? >=20 > > > > > > > Do you also suggest to drop IP checksum flags? > > > > IP checksum offload is mostly useless. If application needs to look at > > IP, it can do whole checksum in very few instructions, the whole > > header is in the same cache line as src/dst so the HW offload is really= no > help. > > [Sugesh] The checksum offload can boost the tunneling performance in OVS. I guess the IP checksum also important as L4. In some cases, UDP checksum i= s zero and no need to validate it. But Ip checksum is present on all the pack= ets and that must be validated all the time. At higher packet rate, the ip checksum offload can= offer slight=20 performance improvement. What do you think?? > > > > > > Will it be possible to manage tunnel checksums? > > > > > > I think this would be a pretty big change. If there is no additional > > > argument than beeing more compatible with virtio/linux, I'm > > > wondering if it's worth breaking the API. Let's wait for other opinio= ns. >=20 > I think that what Olivier proposed is good enough and definitely a step > forward from what we have right now. >=20 > Konstantin >=20 > > > > > > Thanks for your feedback. > > > Olivier