From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 60DD7255 for ; Mon, 26 Jan 2015 15:17:16 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga103.fm.intel.com with ESMTP; 26 Jan 2015 06:11:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,469,1418112000"; d="scan'208";a="676018828" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga002.jf.intel.com with ESMTP; 26 Jan 2015 06:17:12 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.81]) by IRSMSX103.ger.corp.intel.com ([169.254.3.242]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 14:15:13 +0000 From: "Ananyev, Konstantin" To: Olivier MATZ , "Liu, Jijiang" , "Zhang, Helin" Thread-Topic: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and csum forwarding engine Thread-Index: AQHQFSvOf5ZHcwOIQ0S6LPFf4KIhoZyLUqAAgADVrYCAJ+m7AIAAhGKAgAAcY4CAAAaCgIABXQMAgAAfBJCAAZMJAIAEQKUAgACGkwCAAQFCAIAAcvAAgAEemACAAkDH8IAB1gMAgARiT1CAACVrgIAAHEZAgAFUrACAADW5sIAAKFUAgACV94CAAMyvAIAHCkRwgAA0QACAAIdbAIAAAJsQ Date: Mon, 26 Jan 2015 14:15:12 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258213DF90B@irsmsx105.ger.corp.intel.com> References: <1418173403-30202-1-git-send-email-jijiang.liu@intel.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> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB55DB@SHSMSX101.ccr.corp.intel.com> <54BFC4D6.2010903@6wind.com> <2601191342CEEE43887BDE71AB977258213DF71B@irsmsx105.ger.corp.intel.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01DB6FD2@SHSMSX101.ccr.corp.intel.com> <54C64A10.2010906@6wind.com> In-Reply-To: <54C64A10.2010906@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.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jan 2015 14:17:17 -0000 Hi Olivier, > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Monday, January 26, 2015 2:07 PM > To: Liu, Jijiang; Ananyev, Konstantin; Zhang, Helin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 0/3] enhance TX checksum command and cs= um forwarding engine >=20 > Hi, >=20 > On 01/26/2015 07:02 AM, Liu, Jijiang wrote: > >> I tried to repeat Olivier test-cases on my box. > >> Though, I didn't use test-pmd cusmonly and i40ePMD logic, but filled = TCD and > >> TDD mostly from hardcoded values. > >> That's what I got: > >> > >> 4 input packets: > >> a) ETHER/IPv4/UDP/VXLAN/ETHER/IPV4/TCP > >> b) ETHER/IPv4/GRE/ETHER/IPV4/TCP > >> c) ETHER/IPv4/GRE/IPV4/TCP > >> d) ETHER/IPv4/IPV4/TCP > >> > >> 1/ L4TUNT=3D=3D1(I40E_TXD_CTX_UDP_TUNNELING): > >> a),b): all checksums ok > >> c),d): not transmitted by HW. > >> > >> 2/ L4TUNT=3D=3D2(I40E_TXD_CTX_GRE_TUNNELING): > >> a) b),c): all checksums ok > >> d): not transmitted by HW. > >> > >> 3/ L4TUNT=3D=3D0(UNKNOWN): > >> a),b),c),d): all checksums ok > >> > >> So yes, it seems that L4TUNT=3D=3D0 works perfectly ok for all cases, = as long as > >> L4TUNLEN and other TCD values are setup properly. > >> Which makes me think, that probably we can do what you suggested: jus= t use > >> L4TUNT=3D0 for all cases. > >> Though as Jijiang said, we waiting for confirmation from FVL guys, tha= t there are > >> no hidden implications with that approach. > > > > Yes, the L4TUNT=3D0 is ok for all cases. >=20 > Great! Thanks for testing on your side too. >=20 > > But we still need to get confirmation from FVL guys, probably there are= some issues in HW/FW. > > I and Helin will confirm this with FVL guys ASAP. >=20 > OK, thank you. >=20 > >> Another thing - IPIP seems to work ok by HW. > >> There is something wrong on our (PMD/test-pmd) side. > >> I think at least we have to remove the following check: > >> if (!l2_len) { > >> PMD_DRV_LOG(DEBUG, "L2 length set to 0"); > >> return; > >> } > >> in i40e_txd_enable_checksum(). > > > > Yes, for IPIP, the check should be removed. >=20 > Yes, I think these lines should be removed for 2 reasons: > - it may be the cause of ipip tunnel not working > - we shouldn't do these kind of tests in dataplane. I think we have to > suppose that the data passed to the PMD is valid. >=20 > I'll redo the test with ipip tomorrow with this fix and let you > know the result. If it works, I'll add this in the next version > of the patch. While you are on this, can I suggest you'll add debug logging for TCD and T= DD we are writing to the TX ring? Something like that: + PMD_TX_LOG(DEBUG, "mbuf: %p, TCD[%u]:\n" + "tunneling_params: %#x;\n" + "l2tag2: %#hx;\n" + "rsvd: %#hx;\n" + "type_cmd_tso_mss: %#lx;\n", + tx_pkt, tx_id, + ctx_txd->tunneling_params, + ctx_txd->l2tag2, + ctx_txd->rsvd, + ctx_txd->type_cmd_tso_mss); And same for TDD.=20 It helped me a lot to figure out what is going on, when I did my tests. Probably would be useful for other people too. Konstantin >=20 > Regards, > Olivier