From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by dpdk.space (Postfix) with ESMTP id 68638A05D3
	for <public@inbox.dpdk.org>; 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 <dev@dpdk.org>; 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 <dev@dpdk.org>; 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" <keith.wiles@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
 "stephen@networkplumber.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>
 <EEB37E32-4A14-442E-96BF-12AA76CF1C51@intel.com>
 <06bef528-e195-0d42-d4e9-f26e5c9880cd@ericsson.com>
 <4440C41D-23E4-4A46-8C8A-3AA2ECB59C40@intel.com>
From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= <mattias.ronnblom@ericsson.com>
Message-ID: <e55398f8-3fcb-7c12-2a60-6174194e8692@ericsson.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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.