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 8164C7E80 for ; Thu, 6 Nov 2014 12:18:32 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 06 Nov 2014 03:21:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,325,1413270000"; d="scan'208";a="618139916" Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82]) by fmsmga001.fm.intel.com with ESMTP; 06 Nov 2014 03:27:56 -0800 Received: from pgsmsx107.gar.corp.intel.com (10.221.44.105) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 6 Nov 2014 19:24:12 +0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 6 Nov 2014 19:24:12 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by shsmsx102.ccr.corp.intel.com ([169.254.2.156]) with mapi id 14.03.0195.001; Thu, 6 Nov 2014 19:24:11 +0800 From: "Liu, Jijiang" To: Olivier MATZ Thread-Topic: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload Thread-Index: AQHP8Yux0VUY397yik2xjVM3DjesSpxPpsiAgAGaY5CAABv8AIACIm/A Date: Thu, 6 Nov 2014 11:24:11 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D858A1@SHSMSX101.ccr.corp.intel.com> References: <1414376006-31402-1-git-send-email-jijiang.liu@intel.com> <1414376006-31402-11-git-send-email-jijiang.liu@intel.com> <54588BF7.309@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D8510E@SHSMSX101.ccr.corp.intel.com> <5459FBB2.1040408@6wind.com> In-Reply-To: <5459FBB2.1040408@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: Thu, 06 Nov 2014 11:18:33 -0000 > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Wednesday, November 5, 2014 6:28 PM > To: Liu, Jijiang > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checks= um > offload >=20 > Hi Jijiang, >=20 > Thank you for your answer. Please find some comments below. >=20 > On 11/05/2014 07:02 AM, Liu, Jijiang wrote: > >> First, the code checks if the mbuf has the flag PKT_RX_TUNNEL_IPV4_HDR= . > >> What is the meaning of this flag? It was added by [3], but there is > >> no description in comments or in the commit log explaining in which > >> case this flag is set by the driver. The name supposes that this flag > >> is set when the received packet is an IPv4 tunnel, but the commit log = talks > about vxlan. > > > > The flag PKT_RX_TUNNEL_IPV4_HDR can be used for all tunneling packet ty= pes > with outer IPV4 header. > > For example: > > IPv4 --> GRE/Teredo/VXLAN --> MAC --> IPv4: > > MAC, IPV4, GRENAT, MAC, IPV4, SCTP, PAY4 MAC, IPV4, GRENAT, MAC, IPV6, > > UDP, PAY4 MAC, IPV4, GRENAT, MAC, IPV6, UDP, PAY4 These tunneling > > packet formats have a common point that is outer IPv4 header here. > > > > Only VXLAN tunneling packet is supported in DPDK for i40e now, so the = commit > log talks about VXLAN . >=20 > Is it possible to have a more formal definition? For instance, is the fol= lowing > definition below correct? >=20 > "the PKT_RX_TUNNEL_IPV4_HDR flag CAN be set by a driver if the packet > contains a tunneling protocol inside an IPv4 header". Yes, correct. > If the definition above is correct, I don't see how this flag can help an= application > to run faster. There is already a flag telling if there is a valid IPv4 h= eader > (PKT_RX_IPV4_HDR). As the PKT_RX_TUNNEL_IPV4_HDR flag does not tell what > is ip->proto, the work done by an application to dissect a packet would b= e exactly > the same with or without this flag. If the PKT_RX_TUNNEL_IPV4_HDR flag is set, which means driver tell applicat= ion that incoming packet is encapsulated packet, and application will proce= ss / analyse the packet according to tunneling format indicated by packet_t= ype. In terms of VXLAN packet format (MAC,IPv4,UDP,VXLAN,MAC,IP,TCP,PAY4), if on= ly the PKT_RX_IPV4_HDR flag is set, and application regard its payload as "= from VXLAN to PAY4", but actually, the real payload is PAY4. =20 > Please, can you give an example showing in which conditions this flag can= help an > application? http://dpdk.org/ml/archives/dev/2014-October/007151.html http://dpdk.org/ml/archives/dev/2014-October/007156.html We used the PKT_RX_TUNNEL_IPV4_HDR in the two patches to help application i= dentify incoming packet is tunneling packet. =20