From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jijiang.liu@intel.com>
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
 by dpdk.org (Postfix) with ESMTP id 8164C7E80
 for <dev@dpdk.org>; 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" <jijiang.liu@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>
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" <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 <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: 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