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