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 2B18742529; Wed, 6 Sep 2023 18:25:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 25FBA4027E; Wed, 6 Sep 2023 18:25:42 +0200 (CEST) Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by mails.dpdk.org (Postfix) with ESMTP id 9AA3B4027C for ; Wed, 6 Sep 2023 18:25:40 +0200 (CEST) Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1bdf4752c3cso24343005ad.2 for ; Wed, 06 Sep 2023 09:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1694017540; x=1694622340; 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=SSK6D+ytUum2Mn8DwkJ94rxlXdECP/w+bYgrLEf0ytI=; b=WGQpAEXNtA3UEBzQb1Kp15qE53E43qAmVvfu9Bt+C8Oa9yf8wP0MJULJPjgKWjrDF3 GlHgUPEAX0VIFX4ci2hvgvuZuT6ZHbbuw7FkPV4/dT0+WFJ34w6wWWYBrx38D6NLRXUg Au5VbC4BJrtNTLCU7DbZW/B+yJ+VdNy/jlZwa+wyWIsNY+xZ315CHEaEc+bTOpHFuekv 50j0yuo78zicg5KGxYtYdd3PAn/rHesfSnNnuJQgC8Pg4d9D+K6uc+H1W3oO7fmQ/ls0 2eXdx2SqGVQle+TCb4GyiRSuli/YK/2znfNgI5nsbrFt+jMwDXZu8TcSGRSrFZGtPvyq vqJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694017540; x=1694622340; 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=SSK6D+ytUum2Mn8DwkJ94rxlXdECP/w+bYgrLEf0ytI=; b=I+v6FlSNU01qa3rSwAVu5j1yg+OWKIF7G9TRsaShdMuRam+IjhCpIvlN07ALUD7FI0 TckkEwSZ7WSEbEoEXO1kH+5k9sFIxw4N4Zje9VrPyDrwEvO39E4p6MBAqRxBK1jGVp6E 86cMb7b0T/PQ56cUk/Ucu6/JU3CrZWmAAEc3zEKRWQdfiHaV/9A2WDZ49Yblm1YafkJZ Zk/OLijGg6PU2vJT6MAvuFovG2SavZKQClOdnHENLGnRAjT1YIE+xYmAZwjEqeybOdvc MALLIIX7wcWx3WkN2GXP45ztR39JP25GPig2PM9qZuA3x+yMsFFXVVp7o8QMbcH6SdOC iF0A== X-Gm-Message-State: AOJu0Yx4vfOOq8oaBYTpesq83qU1zl3ML7l7E79LRcFSxHTYHpJNJHWj bZxDkMECUPz4hyOKgKiH7A6Vmg== X-Google-Smtp-Source: AGHT+IH3Psuax1bZG6o16tT8rnGeC4nhXIv8Rx2/haCANzTv+sn1zC1Y9O4cf3UWSPyqBBSqtn+2gw== X-Received: by 2002:a17:903:1c8:b0:1bb:59a0:3d34 with SMTP id e8-20020a17090301c800b001bb59a03d34mr16754732plh.30.1694017539612; Wed, 06 Sep 2023 09:25:39 -0700 (PDT) Received: from hermes.local (204-195-112-131.wavecable.com. [204.195.112.131]) by smtp.gmail.com with ESMTPSA id u2-20020a170902e80200b001b9da42cd7dsm11209791plg.279.2023.09.06.09.25.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Sep 2023 09:25:39 -0700 (PDT) Date: Wed, 6 Sep 2023 09:25:37 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: Morten =?UTF-8?B?QnLDuHJ1cA==?= , thomas@monjalon.net, david.marchand@redhat.com, mattias.ronnblom@ericsson.com, bruce.richardson@intel.com, olivier.matz@6wind.com, andrew.rybchenko@oktetlabs.ru, honnappa.nagarahalli@arm.com, konstantin.v.ananyev@yandex.ru, dev@dpdk.org Subject: Re: [PATCH] eal: add cache guard to per-lcore PRNG state Message-ID: <20230906092537.609d6462@hermes.local> In-Reply-To: <86202387-4424-e4d8-64df-531a580bebd4@lysator.liu.se> References: <20230904092632.12675-1-mb@smartsharesystems.com> <86202387-4424-e4d8-64df-531a580bebd4@lysator.liu.se> 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, 4 Sep 2023 13:57:19 +0200 Mattias R=C3=B6nnblom wrote: > On 2023-09-04 11:26, Morten Br=C3=B8rup wrote: > > The per-lcore random state is frequently updated by their individual > > lcores, so add a cache guard to prevent CPU cache thrashing. > > =20 >=20 > "to prevent false sharing in case the CPU employs a next-N-lines (or=20 > similar) hardware prefetcher" >=20 > In my world, cache trashing and cache line contention are two different=20 > things. >=20 > Other than that, > Acked-by: Mattias R=C3=B6nnblom Could the per-lcore state be thread local? Something like this: =46rom 3df5e28a7e5589d05e1eade62a0979e84697853d Mon Sep 17 00:00:00 2001 From: Stephen Hemminger Date: Wed, 6 Sep 2023 09:22:42 -0700 Subject: [PATCH] random: use per lcore state Move the random number state into thread local storage. This has a several benefits. - no false cache sharing from cpu prefetching - fixes initialization of random state for non-DPDK threads - fixes unsafe usage of random state by non-DPDK threads The initialization of random number state is done by the lcore (lazy initialization). Signed-off-by: Stephen Hemminger --- lib/eal/common/rte_random.c | 35 +++++++++++++++++------------------ 1 file changed, 17 insertions(+), 18 deletions(-) diff --git a/lib/eal/common/rte_random.c b/lib/eal/common/rte_random.c index 53636331a27b..62f36038ac52 100644 --- a/lib/eal/common/rte_random.c +++ b/lib/eal/common/rte_random.c @@ -19,13 +19,14 @@ struct rte_rand_state { uint64_t z3; uint64_t z4; uint64_t z5; -} __rte_cache_aligned; + uint64_t seed; +}; =20 -/* One instance each for every lcore id-equipped thread, and one - * additional instance to be shared by all others threads (i.e., all - * unregistered non-EAL threads). - */ -static struct rte_rand_state rand_states[RTE_MAX_LCORE + 1]; +/* Global random seed */ +static uint64_t rte_rand_seed; + +/* Per lcore random state. */ +static RTE_DEFINE_PER_LCORE(struct rte_rand_state, rte_rand_state); =20 static uint32_t __rte_rand_lcg32(uint32_t *seed) @@ -76,16 +77,14 @@ __rte_srand_lfsr258(uint64_t seed, struct rte_rand_stat= e *state) state->z3 =3D __rte_rand_lfsr258_gen_seed(&lcg_seed, 4096UL); state->z4 =3D __rte_rand_lfsr258_gen_seed(&lcg_seed, 131072UL); state->z5 =3D __rte_rand_lfsr258_gen_seed(&lcg_seed, 8388608UL); + + state->seed =3D seed; } =20 void rte_srand(uint64_t seed) { - unsigned int lcore_id; - - /* add lcore_id to seed to avoid having the same sequence */ - for (lcore_id =3D 0; lcore_id < RTE_MAX_LCORE; lcore_id++) - __rte_srand_lfsr258(seed + lcore_id, &rand_states[lcore_id]); + __atomic_store_n(&rte_rand_seed, seed, __ATOMIC_RELAXED); } =20 static __rte_always_inline uint64_t @@ -119,15 +118,15 @@ __rte_rand_lfsr258(struct rte_rand_state *state) static __rte_always_inline struct rte_rand_state *__rte_rand_get_state(void) { - unsigned int idx; - - idx =3D rte_lcore_id(); + struct rte_rand_state *rand_state =3D &RTE_PER_LCORE(rte_rand_state); + uint64_t seed; =20 - /* last instance reserved for unregistered non-EAL threads */ - if (unlikely(idx =3D=3D LCORE_ID_ANY)) - idx =3D RTE_MAX_LCORE; + /* did seed change */ + seed =3D __atomic_load_n(&rte_rand_seed, __ATOMIC_RELAXED); + if (unlikely(seed !=3D rand_state->seed)) + __rte_srand_lfsr258(seed, rand_state); =20 - return &rand_states[idx]; + return rand_state; } =20 uint64_t --=20 2.39.2