From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 45D611B44D for ; Mon, 22 Apr 2019 09:07:41 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id AE92C40007 for ; Mon, 22 Apr 2019 09:07:40 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 8B95440010; Mon, 22 Apr 2019 09:07:40 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.1 X-Spam-Score: -1.0 Received: from [192.168.1.59] (host-95-192-230-180.mobileonline.telia.com [95.192.230.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 123C840002; Mon, 22 Apr 2019 09:07:37 +0200 (CEST) To: "Wiles, Keith" Cc: "dev@dpdk.org" , "stephen@networkplumber.org" References: <20190408123029.6701-1-mattias.ronnblom@ericsson.com> <20190419212138.17422-1-mattias.ronnblom@ericsson.com> <20190419212138.17422-3-mattias.ronnblom@ericsson.com> <06bef528-e195-0d42-d4e9-f26e5c9880cd@ericsson.com> <4440C41D-23E4-4A46-8C8A-3AA2ECB59C40@intel.com> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: Date: Mon, 22 Apr 2019 09:07:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <4440C41D-23E4-4A46-8C8A-3AA2ECB59C40@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] [RFC v2 2/2] eal: introduce random generator function with upper bound 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: Mon, 22 Apr 2019 07:07:41 -0000 On 2019-04-22 06:33, Wiles, Keith wrote: >> From a performance point of view, the high-loop-count cases are rare enough not to pose a serious threat. For example, being forced to redo rte_rand() more than five times is only a ~3% risk. > > Even a few loops can have an effect on performance when we are talking about micro-seconds plus it leads to indeterminate results. The numbers you reported here are interesting, but I would be happier if you added a limit to the loop. If you state the likely hood of doing 5 loops is only 3% then adding a loop limit would be reasonable, right? > Probability is already effectively putting a limit to the loop. The risk of being stuck for >1us is p=~6e-73. The variations in execution times will in most cases be less than a LLC miss. A loop variable will not have any effect on performance, pollute the code, and hurt uniformity. Here's what rte_rand_max() performance looks like on my Skylake. Average rte_rand_max() latency with worst-case upper_bound: rte_rand_max() w/o loop limit: 47 cc rte_rand_max() w/ max 8 retries: 49 cc rte_rand_max() w/ max 4 retries: 47 cc rte_rand_max() w/ max 2 retries: 40 cc So you need to be very aggressive in limiting the loop count for that loop variable to pay off. Otherwise, you will just be at a loss, doing all that bookkeeping which very rarely turns out to be useful. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 68638A05D3 for ; Mon, 22 Apr 2019 09:07:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5A0971B493; Mon, 22 Apr 2019 09:07:42 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 45D611B44D for ; Mon, 22 Apr 2019 09:07:41 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id AE92C40007 for ; Mon, 22 Apr 2019 09:07:40 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 8B95440010; Mon, 22 Apr 2019 09:07:40 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.4.1 X-Spam-Score: -1.0 Received: from [192.168.1.59] (host-95-192-230-180.mobileonline.telia.com [95.192.230.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 123C840002; Mon, 22 Apr 2019 09:07:37 +0200 (CEST) To: "Wiles, Keith" Cc: "dev@dpdk.org" , "stephen@networkplumber.org" References: <20190408123029.6701-1-mattias.ronnblom@ericsson.com> <20190419212138.17422-1-mattias.ronnblom@ericsson.com> <20190419212138.17422-3-mattias.ronnblom@ericsson.com> <06bef528-e195-0d42-d4e9-f26e5c9880cd@ericsson.com> <4440C41D-23E4-4A46-8C8A-3AA2ECB59C40@intel.com> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: Date: Mon, 22 Apr 2019 09:07:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <4440C41D-23E4-4A46-8C8A-3AA2ECB59C40@intel.com> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] [RFC v2 2/2] eal: introduce random generator function with upper bound 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190422070737.Mq3fF7w0RSTurvWuybIgYKvy6m5AzZ7ujneJ_9Zgsm4@z> On 2019-04-22 06:33, Wiles, Keith wrote: >> From a performance point of view, the high-loop-count cases are rare enough not to pose a serious threat. For example, being forced to redo rte_rand() more than five times is only a ~3% risk. > > Even a few loops can have an effect on performance when we are talking about micro-seconds plus it leads to indeterminate results. The numbers you reported here are interesting, but I would be happier if you added a limit to the loop. If you state the likely hood of doing 5 loops is only 3% then adding a loop limit would be reasonable, right? > Probability is already effectively putting a limit to the loop. The risk of being stuck for >1us is p=~6e-73. The variations in execution times will in most cases be less than a LLC miss. A loop variable will not have any effect on performance, pollute the code, and hurt uniformity. Here's what rte_rand_max() performance looks like on my Skylake. Average rte_rand_max() latency with worst-case upper_bound: rte_rand_max() w/o loop limit: 47 cc rte_rand_max() w/ max 8 retries: 49 cc rte_rand_max() w/ max 4 retries: 47 cc rte_rand_max() w/ max 2 retries: 40 cc So you need to be very aggressive in limiting the loop count for that loop variable to pay off. Otherwise, you will just be at a loss, doing all that bookkeeping which very rarely turns out to be useful.