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 DE85F2C6B for ; Fri, 13 Jan 2017 18:32:41 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP; 13 Jan 2017 09:32:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,222,1477983600"; d="scan'208";a="1082638141" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga001.jf.intel.com with ESMTP; 13 Jan 2017 09:32:39 -0800 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX108.ger.corp.intel.com (163.33.3.3) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 13 Jan 2017 17:32:38 +0000 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.77]) by IRSMSX156.ger.corp.intel.com ([169.254.3.104]) with mapi id 14.03.0248.002; Fri, 13 Jan 2017 17:32:38 +0000 From: "Richardson, Bruce" To: Olivier Matz , "dev@dpdk.org" CC: "thomas.monjalon@6wind.com" , "Ananyev, Konstantin" , "Lu, Wenzhuo" , "Zhang, Helin" Thread-Topic: [dpdk-dev] [RFC 0/9] get Rx and Tx used descriptors Thread-Index: AQHSRjm2XLzlPt7BZ068XOloG9KOzqE27BKAgAAK8oA= Date: Fri, 13 Jan 2017 17:32:38 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B035B88D5D@IRSMSX103.ger.corp.intel.com> References: <1479981261-19512-1-git-send-email-olivier.matz@6wind.com> <20170113174409.2f1be0b5@platinum> In-Reply-To: <20170113174409.2f1be0b5@platinum> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOWRhZTdjMjItYWU5ZS00OWY0LTk0NjYtZGNhYzJiMWQ5N2E5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiJXZ2JCdmYxTlZBOGx2YjF0QlJNa0xpaERzcHVpNjhHVmJUR0VjUzhjV2hZPSJ9 x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC 0/9] get Rx and Tx used descriptors X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 17:32:42 -0000 > -----Original Message----- > From: Olivier Matz [mailto:olivier.matz@6wind.com] > Sent: Friday, January 13, 2017 4:44 PM > To: dev@dpdk.org > Cc: thomas.monjalon@6wind.com; Ananyev, Konstantin > ; Lu, Wenzhuo ; Zhang= , > Helin ; Richardson, Bruce > > Subject: Re: [dpdk-dev] [RFC 0/9] get Rx and Tx used descriptors >=20 > Hi, >=20 > On Thu, 24 Nov 2016 10:54:12 +0100, Olivier Matz > wrote: > > This RFC patchset introduces a new ethdev API function > > rte_eth_tx_queue_count() which is the tx counterpart of > > rte_eth_rx_queue_count(). It implements this API on some Intel drivers > > for reference, and it also optimizes the implementation of > > rte_eth_rx_queue_count(). > > >=20 > I'm planning to send a new version of this patchset, fixing the issues > seen by Ferruh, plus a bug fix in the e1000 implementation. >=20 > Does anyone have any comment about the new API or about questions raised > in the cover letter? Especially about the real meaning of "used > descriptor": should it include the descriptors hold by the driver? For TX, I think we just need used/unused, since for TX any driver will reus= e a slot that has been completed by the NIC, and doesn't hold the mbufs back for buffering at all. For RX, strictly speaking, we should have three categories, rather than trying to work it into 2. I don't see why we can't report a slot as used/unused/unavailable. >=20 > Any comment about the method (binary search to find the used descriptors)= ? I think binary search should work ok, though linear search may work better = for smaller ranges as we can prefetch ahead since we know what we will check ne= xt. Linear can also go backward only if we want accuracy (going forward risks h= aving race conditions between read and NIC write). Overall, though I think binary search should work well enough. >=20 > I'm also wondering about adding rte_eth_tx_descriptor_done() in the API a= t > the same time. >=20 Let me switch the question around - do we need the queue_count APIs at all, and is it not more efficient to just supply the descriptor_done() APIs= ? If an app wants to know the use of the ring, and take some action based on = it, that app is going to have one or more thresholds for taking the action, rig= ht? In that case, rather than scanning descriptors to find the absolute number of free/used descriptors, it would be more efficient for the app to just ch= eck the descriptor on the threshold - and take action based just on that value. Any app that really does need the absolute value of the ring capacity can presumably do its own binary search or linear search to determine the value itself. However, I think just doing a done function should encourage people to use the more efficient solution of just checking the minimum number of descriptors needed. Regards, /Bruce