From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <helin.zhang@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id A77AC5ADF
 for <dev@dpdk.org>; Fri, 23 Jan 2015 09:47:56 +0100 (CET)
Received: from orsmga002.jf.intel.com ([10.7.209.21])
 by orsmga101.jf.intel.com with ESMTP; 23 Jan 2015 00:47:43 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.09,453,1418112000"; d="scan'208";a="674661259"
Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105])
 by orsmga002.jf.intel.com with ESMTP; 23 Jan 2015 00:47:41 -0800
Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by
 PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server (TLS)
 id 14.3.195.1; Fri, 23 Jan 2015 16:47:38 +0800
Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.231]) by
 SHSMSX152.ccr.corp.intel.com ([169.254.6.173]) with mapi id 14.03.0195.001;
 Fri, 23 Jan 2015 16:47:37 +0800
From: "Zhang, Helin" <helin.zhang@intel.com>
To: "Liu, Jijiang" <jijiang.liu@intel.com>, Olivier Matz
 <olivier.matz@6wind.com>
Thread-Topic: [RFC 04/16] i40e: remove the use of PKT_TX_UDP_TUNNEL_PKT flag
Thread-Index: AQHQNdMnOU6MMCBSoke6hM9aJHGnDpzNWGYwgAAGsLA=
Date: Fri, 23 Jan 2015 08:47:37 +0000
Message-ID: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7ECFC1@SHSMSX104.ccr.corp.intel.com>
References: <1421883395-27235-1-git-send-email-olivier.matz@6wind.com>
 <1421883395-27235-5-git-send-email-olivier.matz@6wind.com>
 <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB631A@SHSMSX101.ccr.corp.intel.com>
In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB631A@SHSMSX101.ccr.corp.intel.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] [RFC 04/16] i40e: remove the use of
	PKT_TX_UDP_TUNNEL_PKT flag
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: Fri, 23 Jan 2015 08:47:57 -0000

Hi guys

> -----Original Message-----
> From: Liu, Jijiang
> Sent: Friday, January 23, 2015 4:06 PM
> To: Olivier Matz; Zhang, Helin
> Cc: Ananyev, Konstantin; dev@dpdk.org
> Subject: RE: [RFC 04/16] i40e: remove the use of PKT_TX_UDP_TUNNEL_PKT
> flag
>=20
> Hi,
>=20
> > -----Original Message-----
> > From: Olivier Matz [mailto:olivier.matz@6wind.com]
> > Sent: Thursday, January 22, 2015 7:36 AM
> > To: dev@dpdk.org
> > Cc: olivier.matz@6wind.com; Ananyev, Konstantin; Liu, Jijiang
> > Subject: [RFC 04/16] i40e: remove the use of PKT_TX_UDP_TUNNEL_PKT
> > flag
> >
> > The definition of the flag in rte_mbuf.h was:
> >   TX packet is an UDP tunneled packet. It must be specified when using
> >   outer checksum offload (PKT_TX_OUTER_IP_CKSUM)
> >
> > This flag was used to tell the NIC that the offload type is UDP
> > (I40E_TXD_CTX_UDP_TUNNELING flag). In the datasheet, it says it's
> > required to specify the tunnel type in the register. However, some
> > tests (see [1]) showed that it also works without this flag.
> >
> > Moreover, it is not explained how the hardware use this information.
> > From a network perspective, this information is useless for
> > calculating the outer IP checksum as it does not depend on the payload.
> >
> > Having this flag in the API would force the application to specify the
> > tunnel type for something that looks only useful for this PMD. It will
> > limit the number of possible tunnel types (we would need a flag for
> > each tunnel type) and therefore prevent to support outer IP checksum fo=
r
> proprietary tunnels.
> >
> > Finally, if a hardware advertises "I support outer IP checksum", it
> > must be supported for any payload types.
> >
> > [1] http://dpdk.org/ml/archives/dev/2015-January/011380.html
> >
> > Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
> > ---
> >  lib/librte_pmd_i40e/i40e_rxtx.c | 6 ++----
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/lib/librte_pmd_i40e/i40e_rxtx.c
> > b/lib/librte_pmd_i40e/i40e_rxtx.c index 9acdeee..0786255 100644
> > --- a/lib/librte_pmd_i40e/i40e_rxtx.c
> > +++ b/lib/librte_pmd_i40e/i40e_rxtx.c
> > @@ -482,7 +482,7 @@ i40e_txd_enable_checksum(uint64_t ol_flags,
> >  	}
> >
> >  	/* UDP tunneling packet TX checksum offload */
> > -	if (unlikely(ol_flags & PKT_TX_UDP_TUNNEL_PKT)) {
> > +	if (unlikely(ol_flags & PKT_TX_OUTER_IP_CKSUM)) {
>=20
> This way will disable  FVL TX checksum offload capability of inner IP and=
 inner
> L4 using B.1 method.
>=20
> Again, the B.1 in
> http://dpdk.org/ml/archives/dev/2014-December/009213.html should be
> supported and allowed.
>=20
> Helin, you are i40e maintainer, what's your point?

Can we list all the possible checksum cases (with or without hardware offlo=
ads)?
1. Outer IP (hw csum) + inner IP (hw csum) + L4 (hw csum)
2. Outer IP (hw csum) + inner IP (hw csum) + L4 (sw csum)
3. Outer IP (hw csum) + inner IP (sw csum) + L4 (hw csum)
4. Outer IP (hw csum) + inner IP (sw csum) + L4 (sw csum)
5. Outer IP (sw csum) + inner IP (hw csum) + L4 (hw csum)
6. Outer IP (sw csum) + inner IP (hw csum) + L4 (sw csum)
7. Outer IP (sw csum) + inner IP (sw csum) + L4 (hw csum)
8. Outer IP (sw csum) + inner IP (sw csum) + L4 (sw csum)

Does any hardware support all of these cases? If yes, I think we should to =
have a solution
to support all of them.

>=20
>=20
> >  		*td_offset |=3D (outer_l2_len >> 1)
> >  				<< I40E_TX_DESC_LENGTH_MACLEN_SHIFT; @@ -497,7
> +497,6 @@
> > i40e_txd_enable_checksum(uint64_t ol_flags,
> >  		/* Now set the ctx descriptor fields */
> >  		*cd_tunneling |=3D (outer_l3_len >> 2) <<
> >  				I40E_TXD_CTX_QW0_EXT_IPLEN_SHIFT |
> > -				I40E_TXD_CTX_UDP_TUNNELING |
> >  				(l2_len >> 1) <<
> >  				I40E_TXD_CTX_QW0_NATLEN_SHIFT;
> >
>=20
>=20
>=20
> > @@ -1165,8 +1164,7 @@ i40e_calc_context_desc(uint64_t flags)  {
> >  	uint64_t mask =3D 0ULL;
> >
> > -	if (flags | PKT_TX_UDP_TUNNEL_PKT)
> > -		mask |=3D PKT_TX_UDP_TUNNEL_PKT;
> > +	mask |=3D PKT_TX_OUTER_IP_CKSUM;
> >
> >  #ifdef RTE_LIBRTE_IEEE1588
> >  	mask |=3D PKT_TX_IEEE1588_TMST;
> > --
> > 2.1.3