From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id 42E1F1B584 for ; Fri, 5 Apr 2019 22:50:34 +0200 (CEST) Received: by mail-pl1-f194.google.com with SMTP id w24so3656731plp.2 for ; Fri, 05 Apr 2019 13:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=avFgMRPg5DjgvhUQr0q29ktMnbtDivARo7nS7fD0X8Y=; b=cmwdzcCsZe3oqcJosaTplqaVK9ZI6lGs+GfzEUpZzmavspR6tmbZ7cK4TkIkF83xX/ wz/5z/dn/eHwIZTWTI2c5kLP0HmZECPilObXi1077FrgwKco1vo3mnfyxWs2IxvpB4eU YjM4BDqC4RXhx4Sugk1iGfki4Byy5e1tJ+e/UTa1bih0auOAxry1Cx0DFtq4D4uTN6YF dv2qKn5dd7K2YhSdmi5phiGgXxdP11SUgwfZg2g4LsXiRnR1aEuQYREUiBAu4arbW6kC evUUXxwl1RN0d2wcn6+o44cKr93Kp+NEfkEZHxNxEFM76qMKvO4HGINGrQZ9RfHrB7au r3Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=avFgMRPg5DjgvhUQr0q29ktMnbtDivARo7nS7fD0X8Y=; b=iJDnTqh86BL+lCzU2qN4bPU94uwHGkky9GnkzyR9XuZ9CjzhuRI+0+TaIuyBhRuffV qEDKpyVFjcFG+OsNVY8AXVfScGuGm+Kwi0ZIUtNsP7+tzZ5EhAy/ddO2/f84FUjkR2CL I43SG8DZOK311KZUVx27L1LGHnyvftjQKZCTP88GOC4PLy+t7clE345RcZyjqlHJfMRz TWulsCuMk3nJizS0hvZ/E/mTP3bMsElqsn/97NUHTtQqwkMumdKs7iOlF/HqUOs+YSjt vMQLq7bIzVxEg0qoS2pleQYpM4LIrtBSQOq7mZp2YlpfpCUvx2fIgt8awXKNcCZDPklx py2w== X-Gm-Message-State: APjAAAXcjtknxttBMFPzwt6pz5aT+Ro+U51+wQAQf9Ugi5zikdQVW2z1 KB533luyTz70iHBkSdadtXSMeTBQZsM= X-Google-Smtp-Source: APXvYqz8c/ExGrJ+e8Uma78viE8zJnW40lr9IrpuIVkWvJa5sZpJQ+MmpFtbq+kbCdybENHvWgQTmA== X-Received: by 2002:a17:902:b484:: with SMTP id y4mr15160619plr.88.1554497433048; Fri, 05 Apr 2019 13:50:33 -0700 (PDT) Received: from shemminger-XPS-13-9360 ([167.220.102.127]) by smtp.gmail.com with ESMTPSA id m2sm33449641pgr.74.2019.04.05.13.50.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 05 Apr 2019 13:50:32 -0700 (PDT) Date: Fri, 5 Apr 2019 13:50:30 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: dev@dpdk.org Message-ID: <20190405135030.09c5291a@shemminger-XPS-13-9360> In-Reply-To: References: <20190405134542.28618-1-mattias.ronnblom@ericsson.com> <20190405095738.145a622d@shemminger-XPS-13-9360> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC] eal: make rte_rand() MT safe 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, 05 Apr 2019 20:50:34 -0000 On Fri, 5 Apr 2019 20:04:28 +0200 Mattias R=C3=B6nnblom wrote: > On 2019-04-05 18:57, Stephen Hemminger wrote: > >=20 > > rand48 is a terrible PRNG, why not use something better? > >=20 > > Similar discussion in Linux kernel pointed at: > > http://www.pcg-random.org/posts/some-prng-implementations.html > >=20 > > Mail thread here: > > https://www.spinics.net/lists/netdev/msg560231.html > > =20 >=20 > DPDK was already using lrand48(), I primarily wanted to address=20 > lrand48()'s lack of MT safety, nothing else. >=20 > That said, maybe the easiest way to maintain the current API, provide MT= =20 > safety and have something portable is for DPDK to carry its own random=20 > number generator, instead of relying on libc. >=20 > Maybe an ARC4 port from BSD? But instead of pulling entropy from the=20 > kernel, let the user give the seed, like the current DPDK APIs permit. >=20 > You could deprecate rte_srand(), but I would vote against such a move,=20 > because its sometimes useful to able to have something that is "random",= =20 > yet reproducible. Read the discussion link about ARC4. http://www.pcg-random.org/ As a general-purpose PRNG, it is rather slow, and it is also slow by the standards of modern cryptographic PRNGs and is also considered too weak to use for cryptographic purposes. It is, however, of historical interest and can be useful in testing to see how sensitive a algorithms are to PRNG speed. Using ARC4 replaces a one legacy one with another. 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 488B4A0679 for ; Fri, 5 Apr 2019 22:50:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 628581B586; Fri, 5 Apr 2019 22:50:35 +0200 (CEST) Received: from mail-pl1-f194.google.com (mail-pl1-f194.google.com [209.85.214.194]) by dpdk.org (Postfix) with ESMTP id 42E1F1B584 for ; Fri, 5 Apr 2019 22:50:34 +0200 (CEST) Received: by mail-pl1-f194.google.com with SMTP id w24so3656731plp.2 for ; Fri, 05 Apr 2019 13:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=avFgMRPg5DjgvhUQr0q29ktMnbtDivARo7nS7fD0X8Y=; b=cmwdzcCsZe3oqcJosaTplqaVK9ZI6lGs+GfzEUpZzmavspR6tmbZ7cK4TkIkF83xX/ wz/5z/dn/eHwIZTWTI2c5kLP0HmZECPilObXi1077FrgwKco1vo3mnfyxWs2IxvpB4eU YjM4BDqC4RXhx4Sugk1iGfki4Byy5e1tJ+e/UTa1bih0auOAxry1Cx0DFtq4D4uTN6YF dv2qKn5dd7K2YhSdmi5phiGgXxdP11SUgwfZg2g4LsXiRnR1aEuQYREUiBAu4arbW6kC evUUXxwl1RN0d2wcn6+o44cKr93Kp+NEfkEZHxNxEFM76qMKvO4HGINGrQZ9RfHrB7au r3Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=avFgMRPg5DjgvhUQr0q29ktMnbtDivARo7nS7fD0X8Y=; b=iJDnTqh86BL+lCzU2qN4bPU94uwHGkky9GnkzyR9XuZ9CjzhuRI+0+TaIuyBhRuffV qEDKpyVFjcFG+OsNVY8AXVfScGuGm+Kwi0ZIUtNsP7+tzZ5EhAy/ddO2/f84FUjkR2CL I43SG8DZOK311KZUVx27L1LGHnyvftjQKZCTP88GOC4PLy+t7clE345RcZyjqlHJfMRz TWulsCuMk3nJizS0hvZ/E/mTP3bMsElqsn/97NUHTtQqwkMumdKs7iOlF/HqUOs+YSjt vMQLq7bIzVxEg0qoS2pleQYpM4LIrtBSQOq7mZp2YlpfpCUvx2fIgt8awXKNcCZDPklx py2w== X-Gm-Message-State: APjAAAXcjtknxttBMFPzwt6pz5aT+Ro+U51+wQAQf9Ugi5zikdQVW2z1 KB533luyTz70iHBkSdadtXSMeTBQZsM= X-Google-Smtp-Source: APXvYqz8c/ExGrJ+e8Uma78viE8zJnW40lr9IrpuIVkWvJa5sZpJQ+MmpFtbq+kbCdybENHvWgQTmA== X-Received: by 2002:a17:902:b484:: with SMTP id y4mr15160619plr.88.1554497433048; Fri, 05 Apr 2019 13:50:33 -0700 (PDT) Received: from shemminger-XPS-13-9360 ([167.220.102.127]) by smtp.gmail.com with ESMTPSA id m2sm33449641pgr.74.2019.04.05.13.50.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 05 Apr 2019 13:50:32 -0700 (PDT) Date: Fri, 5 Apr 2019 13:50:30 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: dev@dpdk.org Message-ID: <20190405135030.09c5291a@shemminger-XPS-13-9360> In-Reply-To: References: <20190405134542.28618-1-mattias.ronnblom@ericsson.com> <20190405095738.145a622d@shemminger-XPS-13-9360> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [RFC] eal: make rte_rand() MT safe 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: <20190405205030.QC7g9tWJGDi2UjkjOUm19GgURCk6HcvusHMBWLMeaw0@z> On Fri, 5 Apr 2019 20:04:28 +0200 Mattias R=C3=B6nnblom wrote: > On 2019-04-05 18:57, Stephen Hemminger wrote: > >=20 > > rand48 is a terrible PRNG, why not use something better? > >=20 > > Similar discussion in Linux kernel pointed at: > > http://www.pcg-random.org/posts/some-prng-implementations.html > >=20 > > Mail thread here: > > https://www.spinics.net/lists/netdev/msg560231.html > > =20 >=20 > DPDK was already using lrand48(), I primarily wanted to address=20 > lrand48()'s lack of MT safety, nothing else. >=20 > That said, maybe the easiest way to maintain the current API, provide MT= =20 > safety and have something portable is for DPDK to carry its own random=20 > number generator, instead of relying on libc. >=20 > Maybe an ARC4 port from BSD? But instead of pulling entropy from the=20 > kernel, let the user give the seed, like the current DPDK APIs permit. >=20 > You could deprecate rte_srand(), but I would vote against such a move,=20 > because its sometimes useful to able to have something that is "random",= =20 > yet reproducible. Read the discussion link about ARC4. http://www.pcg-random.org/ As a general-purpose PRNG, it is rather slow, and it is also slow by the standards of modern cryptographic PRNGs and is also considered too weak to use for cryptographic purposes. It is, however, of historical interest and can be useful in testing to see how sensitive a algorithms are to PRNG speed. Using ARC4 replaces a one legacy one with another.