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 A1C78E6D for ; Fri, 10 Jun 2016 18:15:51 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP; 10 Jun 2016 09:15:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,450,1459839600"; d="scan'208";a="717062139" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by FMSMGA003.fm.intel.com with ESMTP; 10 Jun 2016 09:15:49 -0700 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.10]) by IRSMSX107.ger.corp.intel.com ([169.254.10.96]) with mapi id 14.03.0248.002; Fri, 10 Jun 2016 17:15:48 +0100 From: "Chandran, Sugesh" To: 'Olivier Matz' , "Ananyev, Konstantin" , Stephen Hemminger CC: Yuanhan Liu , "dev@dpdk.org" , "Richardson, Bruce" , Adrien Mazarguil , "Tan, Jianfeng" Thread-Topic: [dpdk-dev] about rx checksum flags Thread-Index: AQHRuoezRmm+fNew7kKI9gqfLUQ5c5/SoZ8AgAC5KoCAABVVAIAACI2AgAAR1oCAALl4AIABiH1ggAHYrACAB6B3AIAAQJYAgALnWCA= Date: Fri, 10 Jun 2016 16:15:48 +0000 Message-ID: <2EF2F5C0CC56984AA024D0B180335FCB13DDDEB3@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> <2EF2F5C0CC56984AA024D0B180335FCB13DDA800@IRSMSX102.ger.corp.intel.com> <57517B5C.4040206@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13DDC6C0@IRSMSX102.ger.corp.intel.com> <57581762.4070003@6wind.com> In-Reply-To: <57581762.4070003@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzg3MzU5YTQtOWU4ZC00ZjY3LWIwNDMtMDNmMzRkYTcyNDIzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS45LjYuNiIsIlRydXN0ZWRMYWJlbEhhc2giOiJ1aVg2blJ4eEZTaUxtOXNybmxJUEo2VWdoQjJFcDJ6dmZDTG8xQjl6VlVjPSJ9 x-ctpclassification: CTP_PUBLIC x-originating-ip: [163.33.239.182] 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: Fri, 10 Jun 2016 16:15:52 -0000 Regards _Sugesh > -----Original Message----- > From: Olivier Matz [mailto:olivier.matz@6wind.com] > Sent: Wednesday, June 8, 2016 2:02 PM > To: Chandran, Sugesh ; Ananyev, Konstantin > ; Stephen Hemminger > > Cc: Yuanhan Liu ; dev@dpdk.org; Richardson, > Bruce ; Adrien Mazarguil > ; Tan, Jianfeng > Subject: Re: [dpdk-dev] about rx checksum flags >=20 > Hi, >=20 > On 06/08/2016 10:22 AM, Chandran, Sugesh wrote: > >>> I guess the IP checksum also important as L4. In some cases, UDP > >>> checksum is zero and no need to validate it. But Ip checksum is > >>> present on all the packets and that must be validated all the time. > >>> At higher packet rate, the ip checksum offload can offer slight > >>> performance > >> improvement. What do you think?? > >>> > >> > >> Agree, in some situations (and this is even more true with packet > >> types / smartnics), the application could process without accessing > >> the packet data if we keep the IP cksum flags. > > [Sugesh] True, If that's the case, Will you considering to implement > > IP checksum flags as well along with L4? > > As you said , this will be useful when we offload packet lookup itself > > into the NICs(May be when using Flow director) ? >=20 > Yes, I plan to implement the same rx status flags (good, bad, unknown, > none) for rx IP checksum too. [Sugesh] That's great!, Thank you Olivier. >=20 > Regards, > Olivier