From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 1F3E35A15 for ; Wed, 21 Jan 2015 09:01:52 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 21 Jan 2015 00:01:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="443074644" Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98]) by FMSMGA003.fm.intel.com with ESMTP; 20 Jan 2015 23:48:32 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by PGSMSX106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 21 Jan 2015 16:01:42 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.64]) by shsmsx102.ccr.corp.intel.com ([169.254.2.238]) with mapi id 14.03.0195.001; Wed, 21 Jan 2015 16:01:41 +0800 From: "Liu, Jijiang" To: "Olivier MATZ (olivier.matz@6wind.com)" Thread-Topic: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine Thread-Index: AQHQFSv0txinLaq/UEmWgzF3v0CZupyLMv5ggABvM4CAJx3DUIABUNAAgACeQOD//4WHgIAB0/cg//+qC4CAAY+2AIAEp+6QgAAfSgCAAWHEQIAAEm0AgAGBl0CAAd+OAIAB1D0AgARtd4CAABpDgIAAsRWAgAC/3gCAAE+EAIAADooAgAFIeJA= Date: Wed, 21 Jan 2015 08:01:40 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB56B3@SHSMSX101.ccr.corp.intel.com> References: <1418173403-30202-1-git-send-email-jijiang.liu@intel.com> <2601191342CEEE43887BDE71AB977258213D34AE@irsmsx105.ger.corp.intel.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA7CC5@SHSMSX101.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258213D3897@irsmsx105.ger.corp.intel.com> <54AFB13E.2080200@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA85A1@SHSMSX101.ccr.corp.intel.com> <54B3B35A.5030803@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DA8E36@SHSMSX101.ccr.corp.intel.com> <54B4EB92.40209@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB0789@SHSMSX101.ccr.corp.intel.com> <2601191342CEEE43887BDE71AB977258213D4FCF@irsmsx105.ger.corp.intel.com> <54B94A18.5030700@6wind.com> <2601191342CEEE43887BDE71AB977258213DCD25@irsmsx105.ger.corp.intel.com> <54BD16F1.6050409@6wind.com> <2601191342CEEE43887BDE71AB977258213DDF46@irsmsx105.ger.corp.intel.com> <54BE4C70.7050406@6wind.com> <2601191342CEEE43887BDE71AB977258213DE5FB@irsmsx105.ger.corp.intel.com> <54BE9B56.7050108@6wind.com> In-Reply-To: <54BE9B56.7050108@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 v3 0/3] enhance TX checksum command and csum forwarding engine 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, 21 Jan 2015 08:01:53 -0000 Hi, > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Wednesday, January 21, 2015 2:16 AM > To: Ananyev, Konstantin; Liu, Jijiang > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and > csum forwarding engine >=20 > Hi Konstantin, > > > >> Case 4) and case 9) would fill the hardware registers exactly the same= . > > > > No, they wouldn't. > > Please read corresponding section of FVL spec and i40e_rxtx.c For case > > 4) we only need to setup TDD (TX data descriptor) with the following > values: > > IIPT, IPLEN, L4T, L4LEN > > For case 9) we need to setup both TDD and TCD (TX context descriptor) > with the following values: > > TDD: IIPT, IPLEN, L4T, L4LEN > > TCD: EIPT, EIPLEN, L4TUNT, L4TUNLEN > > > >> To me, it's just an API question. > > > > No, it is not. > > > > I still don't understand why you are so eager to 'forbid' it. > > Yes we support it for FVL, but no one forces you to use it. >=20 > Well, how would you describe this 2 ways of doing the same thing in the > offload API? Would you talk about the i40e registers? It's not because i4= 0e > has 2 ways to do the same operation that the DPDK should do the same. >=20 > How will you explain to a user how to choose between these 2 cases? Talk about B method in http://dpdk.org/ml/archives/dev/2014-December/009213= .html again. DPDK Never supports a NIC that can recognize tunneling packet for TX side = before 1.8, right? So when we need to support TX checksum offload for tunneling packet, and w= e have to choose B.2. After introducing i40e(FVL), FVL is able to recognize tunneling packet and= support outer IP, or inner IP or outer IP and inner IP TX checksum for tu= nneling packet. And you agree on "outer and inner at the same time", why do you object "onl= y inner"?=20 Actually, B.2 method is a software workaround using L2 length when NIC can'= t recognize tunneling packet. When NIC is able to recognize tunneling packet, I think you shouldn't take = B.2 as a standard to 'forbid' other method. > Having to support these 2 different cases for the same thing will complex= ify > all future drivers that will not work the same way than i40e. >=20 > >>> As one of possible use-cases: HW VLAN tags insertion for both inner = and > outer packets. > >>> FVL can do that, though as I know our PMD doesn't implement it yet. > >>> For that, we'll need to specify at least: > >>> outer_l2_len, outer_l3_len, l2_len. > >>> While PKT_TX_OUTER_* might stay cleared. > >> > >> If a VLAN flag has to be inserted in outer header, a new flag > >> PKT_TX_OUTER_INSERT_VLAN would be added. So my specification > would > >> still be correct: > >> > >> The driver should look at mb->outer_lX_len only if a > >> PKT_TX_OUTER_* flag is present. > >> > > > > Introducing PKT_TX_OUTER_INSERT_VLAN is ok. > > Though I still think we'll need TX_*_TUNNEL flags and no need to 'forbi= d' > case 9). > > BTW, as I can see linux i40e driver for tunnelling packets uses case 9)= , not > case 4), right? >=20 > I need to check this. >=20 > Regards, > Olivier