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 C52992E81 for ; Wed, 26 Nov 2014 17:23:49 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 26 Nov 2014 08:34:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,463,1413270000"; d="scan'208";a="628651147" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by fmsmga001.fm.intel.com with ESMTP; 26 Nov 2014 08:34:44 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.144]) by IRSMSX110.ger.corp.intel.com ([169.254.15.55]) with mapi id 14.03.0195.001; Wed, 26 Nov 2014 16:34:43 +0000 From: "Ananyev, Konstantin" To: Olivier MATZ , "dev@dpdk.org" Thread-Topic: [PATCH v3 08/13] testpmd: rework csum forward engine Thread-Index: AQHQBRWkd4sswgzhkE+OlOkQVeBEkZxxa1hQgAFe1gCAAAQF4IAAOZsAgAAUgIA= Date: Wed, 26 Nov 2014 16:34:43 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258213BA9DC@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> <2601191342CEEE43887BDE71AB977258213BA869@IRSMSX105.ger.corp.intel.com> <5475E9D4.6000607@6wind.com> In-Reply-To: <5475E9D4.6000607@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 16:23:50 -0000 Hi Oliver, > -----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; Ric= hardson, Bruce > Subject: Re: [PATCH v3 08/13] testpmd: rework csum forward engine >=20 > Hi Konstantin, >=20 > 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 fal= gs. > > 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 > I have no strong opinion too, but I have a preference for 2 different > bit values for these flags: >=20 > - as you say, it's matches the concept (RX and TX flags are separated) >=20 > - 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 >=20 > - 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 an > IPv4 packet 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 f= or 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 pr= opely. So yes, we need to make them a proper TX flags. 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. >=20 > Regards, > Olivier >=20