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 3A12F2E81 for ; Thu, 27 Nov 2014 09:36:08 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 27 Nov 2014 00:36:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,468,1413270000"; d="scan'208";a="638939458" Received: from pgsmsx103.gar.corp.intel.com ([10.221.44.82]) by fmsmga002.fm.intel.com with ESMTP; 27 Nov 2014 00:34:08 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 27 Nov 2014 16:34:07 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.86]) with mapi id 14.03.0195.001; Thu, 27 Nov 2014 16:34:05 +0800 From: "Liu, Jijiang" To: "Ananyev, Konstantin" , Olivier MATZ , "dev@dpdk.org" Thread-Topic: [PATCH v3 08/13] testpmd: rework csum forward engine Thread-Index: AQHQBRWmer6OyI02Pky5cGdSWsvK9pxyMg8AgAASAwCAABPAgIAAKeAAgAAbyYCAAZF4sA== Date: Thu, 27 Nov 2014 08:34:05 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9ED8F@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> <2601191342CEEE43887BDE71AB977258213BA869@IRSMSX105.ger.corp.intel.com> <5475E9D4.6000607@6wind.com> <2601191342CEEE43887BDE71AB977258213BA9DC@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213BA9DC@IRSMSX105.ger.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: "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: Thu, 27 Nov 2014 08:36:08 -0000 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Thursday, November 27, 2014 12:35 AM > To: Olivier MATZ; 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 Oliver, >=20 > > -----Original Message----- > > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > > Sent: Wednesday, November 26, 2014 2:55 PM > > To: Ananyev, Konstantin; dev@dpdk.org > > Cc: Walukiewicz, Miroslaw; Liu, Jijiang; Liu, Yong; jigsaw@gmail.com; > > Richardson, Bruce > > Subject: Re: [PATCH v3 08/13] testpmd: rework csum forward engine > > > > Hi Konstantin, > > > > On 11/26/2014 01:25 PM, Ananyev, Konstantin wrote: > > >> 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: > > >> > > >> #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 f= algs. > > > 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? > > > > I have no strong opinion too, but I have a preference for 2 different > > bit values for these flags: > > > > - as you say, it's matches the concept (RX and TX flags are separated) > > > > - 64 bits is a lot, we have some time before there is no more available > > bit... and I hope we it will never occur because it would become > > complex for an application to handle them all > > > > - it will avoid to send a packet with a bad info: > > - we receive a Ether/IP6/IP4/L4/data packet > > - the driver sets PKT_RX_IPV6_HDR > > - the stack decapsulates IP6 > > - the stack sends the packet, it has the PKT_TX_IPV6 flag but it's a= n > > IPv4 packet >=20 > Ah yes, you right, if we keep them the same, then upper layer always has = to clear > PKT_RX_IPV4_HDR | PKT_RX_IPV6_HDR before setting TX offload flags and > passing packet to the PMD for TX. > And if the upper layer wouldn't do that - it might cause a problem. > With your example above - if at last step the stack sets PKT_TX_IP_CKSUM= for > the packet, then PMD will receive an mbuf with (PKT_TX_IPV6 | > PKT_TX_IP_CKSUM) set. > Though from PKT_TX_IP_CKSUM/ PKT_TX_IPV6/ PKT_TX_IPV4 only one can be > set, as they are mutually exclusive. > So i40e PMD will get confused and might not be able to arm TX descriptor > propely. > So yes, we need to make them a proper TX flags. I have changed definitions of the two flags in the patch of rework VXLAN TX= checksum. > Thanks for spotting it. > Konstantin >=20 > > > > This is not a real problem as the flag will not be used by the > > driver/hardware (it's only mandatory for hw cksum / tso), but > > it can be confusing. > > > > Regards, > > Olivier > >