From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 717DB2E8B for ; Wed, 26 Nov 2014 13:14:35 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 26 Nov 2014 04:25:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,462,1413270000"; d="scan'208";a="628538371" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga001.fm.intel.com with ESMTP; 26 Nov 2014 04:25:29 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.144]) by IRSMSX101.ger.corp.intel.com ([169.254.1.105]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 12:25:24 +0000 From: "Ananyev, Konstantin" To: Olivier MATZ , "dev@dpdk.org" Thread-Topic: [PATCH v3 08/13] testpmd: rework csum forward engine Thread-Index: AQHQBRWkd4sswgzhkE+OlOkQVeBEkZxxa1hQgAFe1gCAAAQF4A== Date: Wed, 26 Nov 2014 12:25:23 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258213BA869@IRSMSX105.ger.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-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 12:14:36 -0000 > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Wednesday, November 26, 2014 11:15 AM > 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 informati= on 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 a= ny other way we can overcome it > > (apart from make TX function itself to parse a packet, which is obvious= ly 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 co= nvention. > > > > 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 not 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. Ok, thanks. >=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? Yes, I believe it should be set only for hw checksum and tso. > 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 > flags 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 Thought about that too. >>From one side, it is a bit out of our concept: separate RX and TX falgs. >>From other side, it allows us to save 2 bits in the ol_flags. Don't have any strong opinion here. What do you think? =20 >=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