From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <konstantin.ananyev@intel.com> Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id B2D475A15 for <dev@dpdk.org>; Wed, 21 Jan 2015 12:52:29 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 21 Jan 2015 03:46:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,441,1418112000"; d="scan'208";a="515346896" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga003.jf.intel.com with ESMTP; 21 Jan 2015 03:45:29 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.81]) by IRSMSX102.ger.corp.intel.com ([169.254.2.28]) with mapi id 14.03.0195.001; Wed, 21 Jan 2015 11:52:09 +0000 From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com> To: Olivier MATZ <olivier.matz@6wind.com>, "Liu, Jijiang" <jijiang.liu@intel.com> Thread-Topic: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine Thread-Index: AQHQFSvOf5ZHcwOIQ0S6LPFf4KIhoZyLUqAAgADVrYCAJ+m7AIAAhGKAgAAcY4CAAAaCgIABXQMAgAAfBJCAAZMJAIAEQKUAgACGkwCAAQFCAIAAcvAAgAEemACAAkDH8IAB1gMAgARiT1CAACVrgIAAHEZAgAFUrACAADW5sIAAKFUAgADmvACAABNcgIAAK4yQ Date: Wed, 21 Jan 2015 11:52:08 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258213DE8F0@irsmsx105.ger.corp.intel.com> References: <1418173403-30202-1-git-send-email-jijiang.liu@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> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB56B3@SHSMSX101.ccr.corp.intel.com> <54BF6D21.3010506@6wind.com> In-Reply-To: <54BF6D21.3010506@6wind.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" <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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 21 Jan 2015 11:52:30 -0000 > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Wednesday, January 21, 2015 9:11 AM > To: Liu, Jijiang > Cc: Ananyev, Konstantin; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and cs= um forwarding engine >=20 > Hi Jijiang, >=20 > On 01/21/2015 09:01 AM, Liu, Jijiang wrote: > >>> 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. > >> > >> Well, how would you describe this 2 ways of doing the same thing in th= e > >> offload API? Would you talk about the i40e registers? It's not because= i40e > >> has 2 ways to do the same operation that the DPDK should do the same. > >> > >> 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/00= 9213.html again. > > > > DPDK Never supports a NIC that can recognize tunneling packet for TX s= ide before 1.8, right? >=20 > When you say "recognize tunnel", if you mean offlading checksum of > tunnel headers, I agree. >=20 > If you mean recognizing a tunnel packet in rx, I also agree > it's new to dpdk-1.8, but I think it's unrelated to what we > are talking about, which is tx checksum. A DPDK application > is able to generate tunnel packets by itself and offload the > checksums to the NIC. >=20 > > So when we need to support TX checksum offload for tunneling packet, a= nd we have to choose B.2. >=20 > I don't see why we should choose either B.1 or B.2 (I guess you want > to say B.1 here, right?). >=20 > The m->lX_len are not filled in rx today. If one day they are, it won't > prevent the application to configure the lX_len fields and offload > flags according to the API. >=20 > > 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 tunneling packet. > > And you agree on "outer and inner at the same time", why do you object = "only inner"? > > > > 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 t= ake B.2 as a standard to 'forbid' other method. >=20 > Again, I'm not sure there is a link between "recognizing tunneling > packets" and tx checksum offload of tunnels.=20 I think what Jijiang doesn't talk about RX here. What he is trying to say that with B.2 (case 4) we hide from HW the fact th= at the packet is tunnelling. We just using the fact, that to calculate cksum for inner packet only, HW d= oesn't need to know is it a tunnelling packet or not. All it needs is a proper values of l2_len and l3_len.=20 >=20 > Regards, > Olivier