From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2B900A046B for ; Sat, 27 Jul 2019 03:32:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D77BA1C4DD; Sat, 27 Jul 2019 03:32:53 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 216731C4C3 for ; Sat, 27 Jul 2019 03:32:51 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2019 18:32:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,313,1559545200"; d="scan'208";a="161485994" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga007.jf.intel.com with ESMTP; 26 Jul 2019 18:32:50 -0700 Received: from fmsmsx111.amr.corp.intel.com (10.18.116.5) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 26 Jul 2019 18:32:50 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx111.amr.corp.intel.com (10.18.116.5) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 26 Jul 2019 18:32:49 -0700 Received: from shsmsx105.ccr.corp.intel.com ([169.254.11.15]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.80]) with mapi id 14.03.0439.000; Sat, 27 Jul 2019 09:32:47 +0800 From: "Zhang, Qi Z" To: "Gavin Hu (Arm Technology China)" , "Richardson, Bruce" , "Ananyev, Konstantin" CC: "users@dpdk.org" , Honnappa Nagarahalli , "Phil Yang (Arm Technology China)" , "Ruifeng Wang (Arm Technology China)" Thread-Topic: i40e vPMD fix out of order Rx read issue Thread-Index: AdVCzJhDNbgBl9FATkWplfpJPawhKgAEGCLwAC59RaAAIKjSIA== Date: Sat, 27 Jul 2019 01:32:46 +0000 Message-ID: <039ED4275CED7440929022BC67E7061153D7485E@SHSMSX105.ccr.corp.intel.com> References: <039ED4275CED7440929022BC67E7061153D71548@SHSMSX105.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzhlNDcyMjYtNWY5My00NjRmLTg1ZGMtOWZhZTE2ZDU3YjVmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiVDNNN1J2WXpPT0xuXC93VERSQXBZSE9JSEMrcms2bGJHVHRqVWNiT0dVNVhXZ0F6d3Zhc1QwNVwvSWlrZmFlNWkxIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-users] i40e vPMD fix out of order Rx read issue X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" > -----Original Message----- > From: Gavin Hu (Arm Technology China) [mailto:Gavin.Hu@arm.com] > Sent: Friday, July 26, 2019 6:01 PM > To: Zhang, Qi Z ; Richardson, Bruce > ; Ananyev, Konstantin > > Cc: users@dpdk.org; Honnappa Nagarahalli > ; Phil Yang (Arm Technology China) > ; Ruifeng Wang (Arm Technology China) > > Subject: RE: i40e vPMD fix out of order Rx read issue >=20 > Hi Qi, >=20 > Thanks for your explanation! > I did some testing and found the barriers caused a big drop in RFC2544 ND= R > performance on aarch64, how about it on X86? For x86, I think we don't have performance drop, the memory barrier just ch= ange the compiler's behavior to avoid generate out of order read instructio= ns, and x86 guarantee no out of read execution, so it does not add new inst= ructions that cost CPU cycles. > Is it possible to count DD bits in a way of surviving across the out-of-o= rder > descriptors reading? I think it is possible, but this will impact performance on x86,=20 but for aarch64, you can try out to see if that benefit and do proper optim= ization on related vPMD implementation. >=20 > Best Regards, > Gavin >=20 > > -----Original Message----- > > From: Zhang, Qi Z > > Sent: Thursday, July 25, 2019 8:11 PM > > To: Gavin Hu (Arm Technology China) ; Richardson, > > Bruce ; Ananyev, Konstantin > > > > Cc: users@dpdk.org; Honnappa Nagarahalli > > ; Phil Yang (Arm Technology China) > > > > Subject: RE: i40e vPMD fix out of order Rx read issue > > > > Hi Gavin: > > > > in vPMD, we read 4 or 8 packets as batch, we count DD bits for packet > > received, but not check the if they are continues or not, we assume it > > should always be 1000, 1100, 1110, 1111 ....(take batch size is 4 as > > example) while the out of order read instruction generated by compiler > > will cause driver to get un-continues DD bits, like 1011, the > > descriptor on the hole actually is invalid since when it is read , > > descriptor is not write back yet, but we still process this as 1110, it= cause an > corrupted mbuf returned. > > > > hope this is helpful. > > > > Regards > > Qi > > > > > -----Original Message----- > > > From: Gavin Hu (Arm Technology China) [mailto:Gavin.Hu@arm.com] > > > Sent: Thursday, July 25, 2019 5:57 PM > > > To: Zhang, Qi Z ; Richardson, Bruce > > > ; Ananyev, Konstantin > > > > > > Cc: users@dpdk.org; Honnappa Nagarahalli > > > ; Phil Yang (Arm Technology China) > > > > > > Subject: i40e vPMD fix out of order Rx read issue > > > > > > Hi Qi, > > > > > > I am working on optimizing the i40e vPMD on aarch64 and I see this > > > patch relevant. > > > Could you illuminate what issue this patch was fixing? > > > I understand the PMD works at the driver layer, for delivery of L2 pa= ckets. > > > It does not own the responsibility to keep order(the responsibility > > > lies with > > the > > > protocol stack, like TCP)? > > > > > > http://patches.dpdk.org/patch/16665/ > > > > > > Best regards, > > > Gavin > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > > > confidential and may also be privileged. If you are not the intended > > > recipient, please notify the sender immediately and do not disclose > > > the contents to any other person, use it for any purpose, or store > > > or copy the information in any medium. Thank you. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended reci= pient, > please notify the sender immediately and do not disclose the contents to = any > other person, use it for any purpose, or store or copy the information in= any > medium. Thank you.