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 7775D4252D; Thu, 7 Sep 2023 01:00:09 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0A4C3402B0; Thu, 7 Sep 2023 01:00:09 +0200 (CEST) Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) by mails.dpdk.org (Postfix) with ESMTP id D97A14027D for ; Thu, 7 Sep 2023 01:00:07 +0200 (CEST) Received: by mail-pg1-f181.google.com with SMTP id 41be03b00d2f7-573c62b3cd2so317787a12.3 for ; Wed, 06 Sep 2023 16:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1694041207; x=1694646007; 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=M46kUwxhaWWuEV+w75pVa9sNCTMjLt9TqZLrR4eW5o0=; b=Mrdch2PvLuOJ8CuKVmyc4tW1xAaKRW+dGjpjfNi/WyBcEt5uoPA3JLHIRQjdY45x4U 85qdd8nWjc9hGpdVgrWS7xJk06JK1xYQsDfEpBWrWVGJH/czE5UcwS7IBwW7L7mMmxKf 6k+8Fa/NjahJ19zCQ1PmQS01W0sKYIKEFlE8DEzRMq2eP50LcmT0nfboNM+KfTe67x1R jPjhC0a0/pjeSQps1zfjEZVKosiynTlTQZ7r0mro7Bkmv/TRAOi81aQyI5GN/kj2xbHR RQEP44ANCi7vLXvCj5dRwInW3GIZrI/Ou5f7yRD2RJpjiLlCPIka45WY0//SLmT3rDez /UOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694041207; x=1694646007; 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=M46kUwxhaWWuEV+w75pVa9sNCTMjLt9TqZLrR4eW5o0=; b=fVdcsUL0sU0FuCAdzZ46IkaAqL6mB2pAEqOueVGblpRT+tQohsTK3G8COP39ayv9nK s6yUgyA+eaFzqm5TupafjuN3ZS4h8TugOZYYTxElymmTOuL1lMPFBkOyAaWVL+P7wRsQ PzBpS203qains1QSEc1hnKhVllSPSf+F7c3o0dpL3WU6Hx3+DKoz9jO7NAt06JK9WIdR 33Cyolc27s+zp1oyDh0ylHx+NiVGJYsWkieZoDd3KeaN91mxJvGBLOSgomGW2hBMpsga mNQT9wvcStykLwMLTV2ixE0e+oT3A1gIDSMWjfmTKWfnqK6VRQgwRw4dHZ5O/FEaA5Ai w5VA== X-Gm-Message-State: AOJu0YxR3zJYM85bjxJf0i1ZOZ7W2MJCAqBpzclMi7DwDhVk8hu2eIis OEjG2ViBa7LjzLQwShvNGYNTtoIM3tqCVbVlGbo= X-Google-Smtp-Source: AGHT+IEcxPckTFdaFluamkPXiMoSz16/kXD2IzqDNjwvrF/Ts8ypWTjwi0obn7y3l/LCbzjy+WWQBQ== X-Received: by 2002:a05:6a20:d430:b0:12f:bb22:ad3b with SMTP id il48-20020a056a20d43000b0012fbb22ad3bmr13966354pzb.62.1694041206755; Wed, 06 Sep 2023 16:00:06 -0700 (PDT) Received: from hermes.local (204-195-112-131.wavecable.com. [204.195.112.131]) by smtp.gmail.com with ESMTPSA id d22-20020aa78696000000b00686bf824b3bsm11306802pfo.136.2023.09.06.16.00.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Sep 2023 16:00:06 -0700 (PDT) Date: Wed, 6 Sep 2023 16:00:04 -0700 From: Stephen Hemminger To: Mattias =?UTF-8?B?UsO2bm5ibG9t?= Cc: dev@dpdk.org, Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Morten =?UTF-8?B?QnLDuHJ1cA==?= Subject: Re: [RFC] random: use per lcore state Message-ID: <20230906160004.333b0488@hermes.local> In-Reply-To: References: <20230906172013.169846-1-stephen@networkplumber.org> 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 Wed, 6 Sep 2023 22:02:54 +0200 Mattias R=C3=B6nnblom wrote: > On 2023-09-06 19:20, Stephen Hemminger wrote: > > Move the random number state into thread local storage. =20 >=20 > Me and Morten discussed TLS versus other alternatives in some other=20 > thread. The downside of TLS that Morten pointed out, from what I recall,= =20 > is that lazy initialization is *required* (since the number of threads=20 > is open-ended), and the data ends up in non-huge page memory. It was=20 > also unclear to me what the memory footprint implications would be,=20 > would large per-lcore data structures be put in TLS. More specifically,=20 > if they would be duplicated across all threads, even non-lcore threads. But current method is unsafe on non-lcore threads. Two non-lcore threads calling rte_rand() will clash on state without any locking protection. Also, right now the array is sized at 129 entries to allow for the maximum number of lcores. When the maximum is increased to 512 or 1024 the problem will get worse.