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 86DF842570; Mon, 11 Sep 2023 18:06:40 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 318C7402D6; Mon, 11 Sep 2023 18:06:40 +0200 (CEST) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by mails.dpdk.org (Postfix) with ESMTP id 7F857402CE for ; Mon, 11 Sep 2023 18:06:38 +0200 (CEST) Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2bcb0b973a5so75203351fa.3 for ; Mon, 11 Sep 2023 09:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1694448398; x=1695053198; 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=rdVW0fUv6pdwTn8va0vbJMCikqcdTPiEgxBZb57J6TI=; b=K9dRGqDsTUHzvzQRbs/+qDNvackAJoL1DDyD9ckbOwrbVd2mfKEbf3jcpZbRy8bJuQ FJxyWM+nyqVcZ9fL2QhhCr0h+zbJSGbuqOCHmJwPq4kqUveWJuvYuh7NOVz9axBSsF8u aG8U6aZ07SZQpOsy0VlewzwF2G7p0/ADCm4d3z+VP5oZFijXxCbJnDaPzUBLAa16Y51j CRUu+D0WDP/G0odtVCGx4melJDXenxjZreHpptbYL+HnhtR516K28Q91j3VIwOXDD7i1 EDPa+L3hkWMQWvY0jHyDIDy7L8RFyulW6LUt3q0IbDMUfHlV8fbuAiMi4MIrx8ssOcgz LFHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694448398; x=1695053198; 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=rdVW0fUv6pdwTn8va0vbJMCikqcdTPiEgxBZb57J6TI=; b=thx/Xgj/X79MhUQ9zLm2uK/Vlrb8D3hT5nCB8PH2dko+bs9fTO3qSLwYvVsSjAbGUp XWK9plECi/qixgqUWPTwi4sfYGLHC4qW977YsObl+ftI59flpoZj4Ix0AYATsCZoDqF6 /bEO94Y1oKpjn1V4QFgMXhGWt5OW99WE5jpB7ZY2i443Zc2VgqC2x/gq3qUJiEawNbUf VZxGd16emk9axM4FTb9BYJQAwmKD3HhS7jAeE3d87SnAO4KtrMkt6mWpvmM5QPQxb9tC eljheVlGrKuo5piDptk8b2JxcVG7AjIghxUjMgCWvFGaOQgG0NJnZvRgap0ZfzEfyDlb Pamg== X-Gm-Message-State: AOJu0YyDry8h0M+BTG273z1Uclc4ULEm73YpquJhUXAa/H1P3uYAdSdN UKCyS1+i1t/Mwty0Rsy1OXJwtA== X-Google-Smtp-Source: AGHT+IEYJ0VBMDmToHTlW80t7Xxd6U3DfAIJ0Gycp72KU0veAaOm4rxQEaF9xv3zJdmLjO6sxI7TNg== X-Received: by 2002:a05:651c:155:b0:2bc:d5f1:b9cf with SMTP id c21-20020a05651c015500b002bcd5f1b9cfmr7696684ljd.27.1694448397521; Mon, 11 Sep 2023 09:06:37 -0700 (PDT) Received: from fedora ([79.140.208.123]) by smtp.gmail.com with ESMTPSA id i23-20020a1709063c5700b00992d70f8078sm5577346ejg.106.2023.09.11.09.06.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Sep 2023 09:06:37 -0700 (PDT) Date: Mon, 11 Sep 2023 09:06:34 -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: <20230911090634.05f8d9fd@fedora> In-Reply-To: <0ad62259-650c-09be-b999-3420bc59dc56@lysator.liu.se> References: <20230906172013.169846-1-stephen@networkplumber.org> <20230906160004.333b0488@hermes.local> <0ad62259-650c-09be-b999-3420bc59dc56@lysator.liu.se> 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 Fri, 8 Sep 2023 09:04:29 +0200 Mattias R=C3=B6nnblom wrote: > > 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. =20 >=20 > Using TLS will penalize every thread in the process, not only EAL=20 > threads and registered non-EAL threads, and worse: not only threads > that are using the API in question. >=20 > Every thread will carry the TLS memory around, increasing the process=20 > memory footprint. >=20 > Thread creation will be slower, since TLS memory is allocated *and=20 > initialized*, lazy user code-level initialization or not. >=20 > On my particular Linux x86_64 system, pthread creation overhead looks=20 > something like: >=20 > 8 us w/o any user code-level use of TLS > 11 us w/ 16 kB of TLS > 314 us w/ 2 MB of TLS. Agree that TLS does cause potentially more pages to get allocated on thread creation, but that argument doesn't make sense here. The rand state is small, and DPDK applications should not be creating threads after startup. Thread creation is an expensive set of system calls.