From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B710B42570; Mon, 11 Sep 2023 18:02:26 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4D50B402D6; Mon, 11 Sep 2023 18:02:26 +0200 (CEST) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by mails.dpdk.org (Postfix) with ESMTP id 348F6402CE for ; Mon, 11 Sep 2023 18:02:25 +0200 (CEST) Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-40078c4855fso49284665e9.3 for ; Mon, 11 Sep 2023 09:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1694448144; x=1695052944; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=vIicgAUQrcd62L4MNE4jscrB5+UXtSJT1VOj3vnCffs=; b=SUgZ4ATRmavlx9Kre1pCKaE63m3x2HWB96Nvwlz3sShNYfmCVs1H+xqTmQjJMYqwWM Tg4TQVwkPKt8UviI8h4CXvaTG2Av/c/8XwVl0Om+D94PDzamMyrVKIl3loo/JoLwmylN xvfzbK5OxReTOc1X4KCQFTAAPJoo1VKRMdN+1hvsr6ReqevkNtg739pVXz2MU9cLXzOn X+T263jheRr9VYTTuf/UfqtE/jFepiZAonNS3Y63OUXJK/DvxXxW0yk87WUlOxP2IPYE sYU5YunHNTlr2R71ecK/YGQO6NTU5p19QQLhhVZtgadKuEvbIvakeunt57Ur/Y1HX1qh a1VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694448144; x=1695052944; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vIicgAUQrcd62L4MNE4jscrB5+UXtSJT1VOj3vnCffs=; b=Sz5wdqQoKfe5TnwJEtQde1jqhdqETMYuOfg7028a8V8Vt6XO4OtL8M79N7i24Ra3BW u771jvgzdAaUp4LzcHkDsOjbvls9USFpNuCjbUf/v0NWN5dzBwN4udIMb1fuYzldGHOn sTq/6mNuo6tF7ObeEarO7lJAnqlTqzmOF4IlujxamsowBPBgEVFfqkdfuvsFbPyKkLB0 jHSDo8wHvQmV9n2QOkPudtOaGBMGeGQb9D46utAF0p0RwV5A98KZx19MV4+CHTL1O1m7 t++mVC70mJdvPEVGW7P+frTPbL2cSkhCel2DESKyWQ31kAAthyoHRj0akrCMLvY4wNqn TG8A== X-Gm-Message-State: AOJu0YxMzMsATe+Yl+nO6+aR3pz12dM9uQdqCEdHZQD4RrW5tX4ML4n4 Yuq+w3BTPut3X+kpeTuhjwMbnw== X-Google-Smtp-Source: AGHT+IHM9zhHaEf5eE545LhHwHi4CeyqB+1kyxDyp/1u5su80SU5EXo52cN3b5Uv2210CEshUNo7CA== X-Received: by 2002:adf:ec82:0:b0:317:5e55:f06f with SMTP id z2-20020adfec82000000b003175e55f06fmr7328333wrn.10.1694448144537; Mon, 11 Sep 2023 09:02:24 -0700 (PDT) Received: from fedora ([79.140.208.123]) by smtp.gmail.com with ESMTPSA id u12-20020aa7d98c000000b0052a1d98618bsm4826838eds.54.2023.09.11.09.02.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Sep 2023 09:02:24 -0700 (PDT) Date: Mon, 11 Sep 2023 09:02:18 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= , Konstantin Ananyev , dev@dpdk.org, Mattias =?UTF-8?B?UsO2bm5ibG9t?= Subject: Re: [RFC] random: use per lcore state Message-ID: <20230911090218.40b3f058@fedora> In-Reply-To: References: <20230906172013.169846-1-stephen@networkplumber.org> <741c94a4-65f9-c044-b3fc-3b8c28922d48@yandex.ru> <4d00a500-a054-b11b-6135-49e4ef7965f2@lysator.liu.se> <98CBD80474FA8B44BF855DF32C47DC35D87B91@smartserver.smartshare.dk> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, 11 Sep 2023 11:00:46 +0200 Mattias R=C3=B6nnblom wrote: > > uint64_t rte_rand_r(struct rte_rand_state * const state); > > void rte_srand_r(struct rte_rand_state * const state, uint64_t > > seed); uint64_t rte_rand_max_r(struct rte_rand_state * const state, > > uint64_t upper_bound); double rte_drand_r(struct rte_rand_state * > > const state, void); > >=20 > > For this to work, we would have to make struct rte_rand_state > > public, and the application would need to allocate it. (At least > > one instance per thread that uses it, obviously.)=20 >=20 > Yes, and that will come at a pretty severe API complexity cost. >=20 > Besides the obvious complexities, it may also lead the user to > believe the rte_rand() is not MT safe for any thread, since that's > how it works in glibc (rand() versus rand_r()). Actual rand state implementation could be hidden by having an allocation/create/new function.