From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by dpdk.org (Postfix) with ESMTP id 977EDDE0 for ; Mon, 11 Apr 2016 22:36:53 +0200 (CEST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B3731200019; Mon, 11 Apr 2016 20:36:52 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 938C820000E; Mon, 11 Apr 2016 20:36:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1460407012; bh=7Kl/Ajc+Nv4n+6slgxqxydGQxUbG4lRHgSwQ+D9OdTA=; l=2702; h=From:To:CC:Date:References:In-Reply-To:From; b=ueu40tGup+z1tut+ok2syRzL5jSmkkUpZXUqmwSGvFrJSRVefV6COXMKSSCgaWRxB +PwABYEb7LrVBe7vvcpJ0FhCDb9XdYw+XwFEFl5Bh7YHxsGxFOFIV6+86IhKiKY5Jo xsfdNe13VtkCsRBdaEAb3Wp1OUzPAuM48ZbhlaH0= Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 90D3998082; Mon, 11 Apr 2016 20:36:52 +0000 (GMT) Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 11 Apr 2016 15:36:52 -0500 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) with mapi id 15.00.1130.005; Mon, 11 Apr 2016 13:36:52 -0700 From: "Sanford, Robert" To: "Dumitrescu, Cristian" , "dev@dpdk.org" CC: "Liang, Cunming" , "Venkatesan, Venky" , "Richardson, Bruce" Thread-Topic: [dpdk-dev] [PATCH 4/4] port: fix ethdev writer burst too big Thread-Index: AQHRjDKoyc2GDY2FaUGj9fRrdME9ip+FL/cQgABNsgA= Date: Mon, 11 Apr 2016 20:36:52 +0000 Message-ID: References: <3EB4FA525960D640B5BDFFD6A3D89126479A0A65@IRSMSX108.ger.corp.intel.com> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D89126479A0A65@IRSMSX108.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.133.93] Content-Type: text/plain; charset="us-ascii" Content-ID: <36365B38013FEB418C11AAC76770F2EF@akamai.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 4/4] port: fix ethdev writer burst too big 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, 11 Apr 2016 20:36:53 -0000 Hi Cristian, Yes, I mostly agree with your suggestions: 1. We should fix the two obvious bugs (1a and 1b) right away. Jasvinder's patches look fine. 2. We should take no immediate action on the issue I raised about PMDs (vector IXGBE) not enqueuing more than 32 packets. We can discuss and debate; no patch for 16.04, perhaps something in 16.07. Let's start the discussion now, regarding vector IXGBE. You state "Internally it handles packets in batches [of] 32 (as your code snippets suggest), but there is no drop of excess packets taking place." I guess it depends on your definition of "drop". If I pass 33 packets to ixgbe_xmit_pkts_vec(), it will enqueue 32 packets, and return a value of 32. Can we agree on that? -- Regards, Robert On 4/11/16 3:21 PM, "Dumitrescu, Cristian" wrote: >Hi Robert, > >I am doing a quick summary below on the changes proposed by these patches: > >1. [PRIORITY 1] Bug fixing: >a) Fix buffer overflow issue in rte_port_ring.c (writer, writer_nodrop): >double the tx_buf buffer size (applicable for current code approach) >b) Fix issue with handling burst sizes bigger than 32: replace all >declarations of local variable bsz_size from uint32_t to uint64_t > >2. [PRIORITY 2] Treat burst size as a fixed/exact value for the TX burst >(Approach 2) instead of minimal value (current code, Approach 1) for >ethdev ports. Rationale is that some PMDs (like vector IXGBE) _might_ >drop the excess packets in the burst. > >Additional input: >1. Bruce and I looked together at the code, it looks that vector IXGBE is >not doing this (anymore). Internally it handles packets in batches on 32 >(as your code snippets suggest), but there is no drop of excess packets >taking place. > >2. Venky also suggested to keep a larger burst as a single burst >(Approach 1) rather than break the larger burst into a fixed/constant >size burst while buffering the excess packets until complete burst is met >in the future. > >Given this input and also the timing of the release, we think the best >option is: >- urgently send a quick patch to handle the bug fixes now >- keep the existing code (burst size used as minimal burst size >requirement, not constant) as is, at least for now, and if you feel it is >not the best choice, we can continue to debate it for 16.7 release. >What do you think? > >Jasvinder just send the bug fixing patches, hopefully they will make it >into the 16.4 release: >http://www.dpdk.org/ml/archives/dev/2016-April/037392.html >http://www.dpdk.org/ml/archives/dev/2016-April/037393.html > >Many thanks for your work on this, Robert! > >Regards, >Cristian