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 96C844252B; Wed, 6 Sep 2023 21:55:22 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 25A36402B4; Wed, 6 Sep 2023 21:55:22 +0200 (CEST) Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by mails.dpdk.org (Postfix) with ESMTP id 2DA16402A9 for ; Wed, 6 Sep 2023 21:55:21 +0200 (CEST) Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-68e2ffd51f2so191203b3a.2 for ; Wed, 06 Sep 2023 12:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1694030120; x=1694634920; 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=dpOzVHo59+NRLAti06QNsgrGoRar2jvOl0YbHWn0VME=; b=QUyronOQieGSpxoZiG8G4ugorB/QUzF/8P8UlX5tW50LWZaGhRlHEXyxT+0OimOR65 YtGGdxHY7urKV3D0z0AKtJyGYwzrWH06jKR5VfHzEc/Pi7I4Wwk0sZfv/hXLlMkpAutS IIL5qAsxj62V1zsKTFMLClcxuKsoTqb1x5Gj0eWMZRMcpQ9Y3/r4m+IM+Aim2nmJbMJo xSYfTmOkhLglkS1j+zN2O/ZLNt+AO7mtUI3SJwUYOfBK2gkaiZmCd0ylmZNi9MJK7+YC kluycnLi9hUyvvNrnzJ/81gfcb5mKth5sh+Qj+U75q/PC0IQ/AZ/JsG6Rws33Ssbog5Y X0gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694030120; x=1694634920; 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=dpOzVHo59+NRLAti06QNsgrGoRar2jvOl0YbHWn0VME=; b=ChI1sPQP1Q3t/eUkWXYIdsbZs4IYasXSakqjj9FeRo062+NkPg4MKe+nvXexLKNXmV y5LvI8MnRUtk12Kaa6slm+2DFymd0FawiM+9jQjgT5vxI9CCSTV7+JhqijIkMSXe1DBX bHliPuvxSHZdOPBtmW521WDskPalnnk2USF2K0ZFOXvHnOp/Og8yMBVqVL1TF1TXLGf9 7Piaa0apeYC8X+5X359D5H2LFRRrHBoS8ULhcDPeJI4Q7q02WLKvDGLC84xD1xZK1D8X hDdQKwl2GQ/lWD14Du+dqmUx1up3rvVIHK17VETaSzPwG002D7cBXnLYLQzcVZEKK6Qm fUhg== X-Gm-Message-State: AOJu0YyQ29aWXLuy1008DRfF0tVLW7E4g3YkIeXXvxgBLNAk4grV+ZDD phlAxoHdKNblzg8kG0SimVB7iGioycJR1Bssp+Y= X-Google-Smtp-Source: AGHT+IHoq/tzjeseK7MyVlKc+8ariOOPwQ2uKBu6m0SzquWTgPj6m+LldXE1jig6nBQf+NgaQiCHMQ== X-Received: by 2002:aa7:98cd:0:b0:68e:3012:fd69 with SMTP id e13-20020aa798cd000000b0068e3012fd69mr2260508pfm.30.1694030119987; Wed, 06 Sep 2023 12:55:19 -0700 (PDT) Received: from hermes.local (204-195-112-131.wavecable.com. [204.195.112.131]) by smtp.gmail.com with ESMTPSA id bf6-20020a056a000d8600b00682a27905b9sm1701097pfb.13.2023.09.06.12.55.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Sep 2023 12:55:19 -0700 (PDT) Date: Wed, 6 Sep 2023 12:55:17 -0700 From: Stephen Hemminger To: dev@dpdk.org Cc: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Subject: Re: [RFC] random: use per lcore state Message-ID: <20230906125517.47fcbc4a@hermes.local> In-Reply-To: <20230906172013.169846-1-stephen@networkplumber.org> References: <20230906172013.169846-1-stephen@networkplumber.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Wed, 6 Sep 2023 10:20:13 -0700 Stephen Hemminger wrote: > static __rte_always_inline > struct rte_rand_state *__rte_rand_get_state(void) > { > - unsigned int idx; > + struct rte_rand_state *rand_state = &RTE_PER_LCORE(rte_rand_state); > + uint64_t seed; > > - idx = rte_lcore_id(); > + seed = __atomic_load_n(&rte_rand_seed, __ATOMIC_RELAXED); > + if (unlikely(seed != rand_state->seed)) { > + rand_state->seed = seed; > > - /* last instance reserved for unregistered non-EAL threads */ > - if (unlikely(idx == LCORE_ID_ANY)) > - idx = RTE_MAX_LCORE; > + seed += rte_thread_self().opaque_id; > + __rte_srand_lfsr258(seed, rand_state); > + } Not sure about this. It would change the semantics of rte_srand so that if passed the same value across multiple runs, it would still generate different values because thread_id is not the same. Using rte_lcore() instead would cause repeatablity but then there would still be a bug if two non-EAL threads used random. Both threads would get the same sequence of numbers, but that is true with current code.