From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 065AB569C for ; Wed, 1 Jun 2016 11:06:41 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 01 Jun 2016 02:06:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,400,1459839600"; d="scan'208";a="988709892" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by orsmga002.jf.intel.com with ESMTP; 01 Jun 2016 02:06:38 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX154.ger.corp.intel.com (163.33.192.96) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 1 Jun 2016 10:06:37 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.51]) by irsmsx155.ger.corp.intel.com ([169.254.14.34]) with mapi id 14.03.0248.002; Wed, 1 Jun 2016 10:06:37 +0100 From: "Ananyev, Konstantin" To: 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: AQHRuoeqCEhgizk4I0Opz4AI8t1XMJ/SoZ8AgAC5KoCAABVVAIAACI6AgAAR1YCAAMc6YA== Date: Wed, 1 Jun 2016 09:06:36 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B694D3@irsmsx105.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> In-Reply-To: <20160531150247.15819f1d@xeon-e3> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: Wed, 01 Jun 2016 09:06:42 -0000 > -----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; Ad= rien Mazarguil; Tan, Jianfeng > Subject: Re: [dpdk-dev] about rx checksum flags >=20 > On Tue, 31 May 2016 22:58:57 +0200 > Olivier MATZ wrote: >=20 > > 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 packe= t > > >>>> data, but the integrity of the L4 header is verified. > > >>>> -> the application can process the packet but must not verify th= e > > >>>> checksum by sw. It has to take care to recalculate the cksum > > >>>> if the packet is transmitted (either by sw or using tx offloa= d) > > >>> > > >>> 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 in= stead > > > use something more compatiable with virtio (and Linux). I.e have thre= e 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 application. > > > > > > 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? >=20 > Not really. They should be mark as undetermined, then software can rechec= k > for the possibly buggy hardware. 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 work correctly.=20 >=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? >=20 > 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/e= xpected > case, software has to checksum every packet. >=20 > > > > I think the "2)" also requires a csum_start + csum_offset in > > mbuf structure, right? >=20 > Not really, it would mean having a way to get the raw one's complement su= m > 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 ven= dors > don't believe in doing it that way. It might be a good feature to have, but if most HW vendors don't support it why to bother? >=20 >=20 > > Do you also suggest to drop IP checksum flags? >=20 > IP checksum offload is mostly useless. If application needs to look > at IP, it can do whole checksum in very few instructions, the whole heade= r > is in the same cache line as src/dst so the HW offload is really no help. >=20 > > > > 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 opinions. I think that what Olivier proposed is good enough and definitely a step forward from what we have right now. Konstantin > > > > Thanks for your feedback. > > Olivier