From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jijiang.liu@intel.com>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by dpdk.org (Postfix) with ESMTP id 50195231C
 for <dev@dpdk.org>; Wed, 26 Nov 2014 14:48:22 +0100 (CET)
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
 by fmsmga102.fm.intel.com with ESMTP; 26 Nov 2014 05:59:18 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,462,1413270000"; d="scan'208";a="628576881"
Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98])
 by fmsmga001.fm.intel.com with ESMTP; 26 Nov 2014 05:59:15 -0800
Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by
 pgsmsx106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server (TLS)
 id 14.3.195.1; Wed, 26 Nov 2014 21:59:13 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
 SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id 14.03.0195.001;
 Wed, 26 Nov 2014 21:59:13 +0800
From: "Liu, Jijiang" <jijiang.liu@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>, "Ananyev, Konstantin"
 <konstantin.ananyev@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [PATCH v3 08/13] testpmd: rework csum forward engine
Thread-Index: AQHQBRWmer6OyI02Pky5cGdSWsvK9pxyMg8AgAASAwCAALKjIA==
Date: Wed, 26 Nov 2014 13:59:11 +0000
Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9EA9A@SHSMSX101.ccr.corp.intel.com>
References: <1415984609-2484-1-git-send-email-olivier.matz@6wind.com>
 <1416524335-22753-1-git-send-email-olivier.matz@6wind.com>
 <1416524335-22753-9-git-send-email-olivier.matz@6wind.com>
 <2601191342CEEE43887BDE71AB977258213BA62A@IRSMSX105.ger.corp.intel.com>
 <5475B622.8030705@6wind.com>
In-Reply-To: <5475B622.8030705@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: "jigsaw@gmail.com" <jigsaw@gmail.com>
Subject: Re: [dpdk-dev] [PATCH v3 08/13] testpmd: rework csum forward 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, 26 Nov 2014 13:48:22 -0000



> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz@6wind.com]
> Sent: Wednesday, November 26, 2014 7:15 PM
> To: Ananyev, Konstantin; dev@dpdk.org
> Cc: Walukiewicz, Miroslaw; Liu, Jijiang; Liu, Yong; jigsaw@gmail.com; Ric=
hardson,
> Bruce
> Subject: Re: [PATCH v3 08/13] testpmd: rework csum forward engine
>=20
> Hi Konstantin,
>=20
> On 11/26/2014 11:10 AM, Ananyev, Konstantin wrote:
> > As I can see you removed code that sets up TX_PKT_IPV4 and TX_PKT_IPV6 =
 of
> ol_flags.
> > I think that we need to keep it.
> > The reason for that is:
> > With FVL, to make HW TX checksum offload work, SW is responsible to pro=
vide
> to the HW information about L3 header.
> > Possible values are:
> > - IPv4 hdr with HW checksum calculation
> > - IPV4 hdr (checksum done by SW)
> > - IPV6 hdr
> > - unknown
> > So let say to for the packet: ETHER_HDR/IPV6_HDR/TCP_HDR/DATA To
> > request HW TCP checksum offload,  SW have to provide to HW information
> > that it is a packet with IPV6 header (plus as for ixgbe: l2_hdr_len, l3=
_hdr_len,
> l4_type, l4_hdr_len).
> > That's why TX_PKT_IPV4 and TX_PKT_IPV6   were introduced.
> >
> > Yes, it is  a change in public API for HW TX offload, but I don't see
> > any other way we can overcome it (apart from make TX function itself to=
 parse
> a packet, which is obviously not a good choice).
> > Note that existing apps working on existing HW (ixgbe/igb/em) are not a=
ffected.
> > Though apps that supposed to be run on FVL HW too have to follow new
> convention.
> >
> > So I suggest we keep setting these flags in csumonly.c
>=20
> Right, I missed these flags.
> It's indeed an API change, but maybe it makes sense, and setting it is no=
t a big
> cost for the application.
>=20
> So I would also need to slightly modify the API help in the following
> patches:
>   - [04/13] mbuf: add help about TX checksum flags
>   - [10/13] mbuf: generic support for TCP segmentation offload
>=20
> I'll send a v4 this afternoon that integrates this change.

After your patch is applied, I will send a patch of  i40e driver change for=
 VXLAN Tx checksum.
=20
> Do you know precisely when the flags PKT_TX_IPV4 and PKT_TX_IPV6 must be
> set by the application? Is it only the hw checksum and tso use case?
> If yes, I'll add it in the API help too.
>=20
> By the way (this is probably off-topic), but I'm wondering if the TX flag=
s should
> have the same values than the RX flags:
>=20
>    #define PKT_TX_IPV4          PKT_RX_IPV4_HDR
>    #define PKT_TX_IPV6          PKT_RX_IPV6_HDR
>=20
> > Apart from that , the patch looks good to me.
> > And yes, we would need to change the  the way we handle TX offload for
> tunnelled packets.
>=20
> Thank you very much Konstantin for your review.
>=20
> Regards,
> Olivier