From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id EE6B47FB8 for ; Mon, 17 Nov 2014 07:43:33 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 16 Nov 2014 22:53:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="417464459" Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88]) by FMSMGA003.fm.intel.com with ESMTP; 16 Nov 2014 22:44:32 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 17 Nov 2014 14:52:59 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by shsmsx102.ccr.corp.intel.com ([169.254.2.216]) with mapi id 14.03.0195.001; Mon, 17 Nov 2014 14:52:58 +0800 From: "Liu, Jijiang" To: Olivier MATZ , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload Thread-Index: AQHP8Yux0VUY397yik2xjVM3DjesSpxPpsiAgAGaY5CAABv8AIAIEl8ggAAq4wCAAVxhEIAB236AgAFSGSD//7WkAIAB+JNw//+ZsICABQb3cA== Date: Mon, 17 Nov 2014 06:52:57 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9BAC0@SHSMSX101.ccr.corp.intel.com> References: <1414376006-31402-1-git-send-email-jijiang.liu@intel.com> <176980123.CbUgamS8oi@xps13> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D992F8@SHSMSX101.ccr.corp.intel.com> <3175184.TxKMqZeb6U@xps13> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9B646@SHSMSX101.ccr.corp.intel.com> <5465C6DD.4000000@6wind.com> In-Reply-To: <5465C6DD.4000000@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload 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: Mon, 17 Nov 2014 06:43:35 -0000 > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Friday, November 14, 2014 5:10 PM > To: Liu, Jijiang; Thomas Monjalon > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checks= um > offload >=20 > Hi Jijiang, >=20 > On 11/14/2014 09:15 AM, Liu, Jijiang wrote: > > > > Thomas Monjalon wrote: > >> > >> You mean that PKT_TX_VXLAN_CKSUM request hardware checksumming of > >> outer L3, outer L4, inner L3 and inner L4? > >> So maybe the name and comments are not enough clear. > > > > Yes, PKT_TX_VXLAN_CKSUM request hardware checksum of outerL3, outer L4, > inner L3 and inner L4. >=20 > I don't understand: it looks in contradiction with our previous > discussion: >=20 > Olivier Matz wrote: > > > > Liu, Jijiang wrote: > >> > >> Olivier Matz wrote: > >>> What is the > >>> meaning of this flag? Is it enough to checksum outer L3, inner L3, > >>> and inner L4 as specified in commit log? If yes, why are the other > >>> flags PKT_TX_IPV4_CSUM, PKT_TX_UDP_CKSUM, (...) added in the mbuf > later? > >>> In my comprehension, these flags are needed in addition to > >>> PKT_TX_VXLAN_CKSUM to do the checksum of the inner headers. > >> > >> Yes, these flags(PKT_TX_IPV4_CSUM, PKT_TX_UDP_CKSUM) are needed by > >> HW offload of non-tunneling and tunneling packet. > > > > OK, so I understand that when PKT_TX_VXLAN_CKSUM is set, if the driver > > supports it, it will process IP and UDP checksum of outer header, > > using l2_len and l3_len. >=20 > So you say that PKT_TX_VXLAN_CKSUM is enough for all inner and outer head= ers, > but also that PKT_TX_IPV4_CSUM, PKT_TX_UDP_CKSUM are needed. > What occurs if we don't set them? >=20 > Now let's say you have an application that receives a TCP packet, then > encaspulate it in vxlan, and forward it. You want to regenerate the check= sum for > the new outer headers, but you don't need to change the inner ones. > You say that setting the PKT_TX_VXLAN_CKSUM will request the hw to proces= s > inner and outer checksum. This is not required in that case. > Also, do you need to set the pseudo header checksum in the TCP inner head= er? Anyway, I explain the checksum mechanism here again. In my VXLAN patch set, for an VXLAN packet TX checksum offload, the logics= below: 1. only set outer L3/L4 header TX checksum tx_checksum set 0x3(0r 0x1) 0 In this case, the PKT_TX_VXLAN_CKSUM flag is not set as we don't set inne= r flags(PKT_TX_IPV4_CSUM, PKT_TX_UDP_CKSUM), so we don't need to change inn= er ones, driver think it is the ordinary packet, =20 HW will do outer L3/L4 checksum offload.=20 2. only set inner L3/L4 header TX checksum tx_checksum set 0x30 0 In this case, the PKT_TX_VXLAN_CKSUM flag is set, so driver think it is V= XLAN packet, and we don't need to change outer ones because we don't set ou= ter flags here (PKT_TX_IPV4_CSUM, PKT_TX_UDP_CKSUM). 3. set outer L3/L4 TX checksum and inner L3&L4 TX checksum=20 tx_checksum set 0x31(0x33) 0 in this case, the PKT_TX_VXLAN_CKSUM flag is set, driver think it is VXLAN = packet, and we need to change outer and inner as both outer and inner flags= are set. I'm reviewing your TSO patch to see if your logic is correct in the checksu= m engine. > Regards, > Olivier