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 CF465A046B for ; Thu, 25 Jul 2019 14:11:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5CF441C312; Thu, 25 Jul 2019 14:11:07 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id BF7E11C293 for ; Thu, 25 Jul 2019 14:11:05 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jul 2019 05:11:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,306,1559545200"; d="scan'208";a="170229371" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga008.fm.intel.com with ESMTP; 25 Jul 2019 05:11:04 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 25 Jul 2019 05:11:04 -0700 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 25 Jul 2019 05:11:03 -0700 Received: from shsmsx105.ccr.corp.intel.com ([10.239.4.158]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.80]) with mapi id 14.03.0439.000; Thu, 25 Jul 2019 20:11:02 +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)" Thread-Topic: i40e vPMD fix out of order Rx read issue Thread-Index: AdVCzJhDNbgBl9FATkWplfpJPawhKgAEGCLw Date: Thu, 25 Jul 2019 12:11:01 +0000 Message-ID: <039ED4275CED7440929022BC67E7061153D71548@SHSMSX105.ccr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYTNmNjkzNzAtYWJkMS00Yjk0LWI4NTQtMzQ0MjIxOTFmMzYxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQ2Z5bEdYUEdzbEVOQVJNdkM1OG1SUTNGb2w0dHdvXC84bHhPWTZDR0JEZjJpZ2RLSFk4K0lHd2pvSDhVcWY0Rm4ifQ== 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" Hi Gavin: in vPMD, we read 4 or 8 packets as batch, we count DD bits for packet rece= ived, but not check the if they are continues or not, we assume it should a= lways be 1000, 1100, 1110, 1111 ....(take batch size is 4 as example) while the out of order read instruction generated by compiler will cause d= river to get un-continues DD bits, like 1011, the descriptor on the hole ac= tually 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. =09 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 >=20 > Hi Qi, >=20 > 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 packet= s. > It does not own the responsibility to keep order(the responsibility lies = with the > protocol stack, like TCP)? >=20 > http://patches.dpdk.org/patch/16665/ >=20 > Best regards, > Gavin >=20 > 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.