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 C587EA00C5; Tue, 21 Jun 2022 21:34:00 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 605A04069C; Tue, 21 Jun 2022 21:34:00 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id CE38C40151 for ; Tue, 21 Jun 2022 21:33:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655840036; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=h8A14WyMPQ4TtHHShWzwkYVdpCpprn3W2IlHQpnLwNM=; b=QodDUJoKttmdKWuLaUGVMhFeyrlMNQVNqcc7dvAZ5c6xcvr2ZX5diBzdSpHWnendD61kJ3 NZ4dlMOddAoTtc26aDpYzM8iLl4W642VX+BkLUiWQyFlH/WqiZ7Ur8v6rFjbqVvH9QXEVV KKmhliuYQlRPje4wha6xXB3PHJuWy+I= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-215-PNEEZTOBNK2MrXV2VJM4Nw-1; Tue, 21 Jun 2022 15:33:52 -0400 X-MC-Unique: PNEEZTOBNK2MrXV2VJM4Nw-1 Received: by mail-lf1-f72.google.com with SMTP id q22-20020a0565123a9600b0047f6b8e1babso3408333lfu.21 for ; Tue, 21 Jun 2022 12:33:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=h8A14WyMPQ4TtHHShWzwkYVdpCpprn3W2IlHQpnLwNM=; b=Pl8h762yIOeDZftnJv52Q5/mSrt4ifA5CFXlUUa3fbpEt12EnY8BgUhOU/M2pjl5yW pbjv50+sqzeekH0dg1AsMKVtkCMeoTrfI6bh2nZXP7CmX6gXZduT6kzuBtgAyVe+PQii zPqhE2p1iAPLJh0Pe4ThzQiPC5PsJi3AOXvUxZCOKJSI712mSi7xAVs55t0AtX/eFCCy 4tZaQ0ylkwMBE31By0BjNc/58gpPPFB4oKPYx+q4xjrgk4Jw2xqGZhi7deW2ofS/p4Cw WOTf2j0QYEL+u19g6tD8g6V+DLMn8cQtSL3g9GL7pd/FPu2Raah2ll6mD2cnSeSfjp4D FfiA== X-Gm-Message-State: AJIora+6mal2FEL+fVUcTVRs5KDB6/DB2/0jse6vRlNXei5Mdx4tWHVc 7nm3ga65JsTRKLL7XfbtkXF+MDCrl8MVMD4nQON2JuPScrqTLwu3A+3ZEbkHys69NOZUtORs+70 sZyT9Bgx4gOqmTstUdww= X-Received: by 2002:a05:6512:4010:b0:47f:6fe6:119c with SMTP id br16-20020a056512401000b0047f6fe6119cmr7008091lfb.499.1655840031238; Tue, 21 Jun 2022 12:33:51 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sjdq6LbGuK6VkP3pkj2h8O4Uxu75oNnv8PUMXUF5ehkX00Fb6fvVZlP4XC3kYS/+Tf9HiYMmaebxw6OPyJnbY= X-Received: by 2002:a05:6512:4010:b0:47f:6fe6:119c with SMTP id br16-20020a056512401000b0047f6fe6119cmr7008085lfb.499.1655840031005; Tue, 21 Jun 2022 12:33:51 -0700 (PDT) MIME-Version: 1.0 References: <20220502141058.12707-1-donw@xsightlabs.com> <6401977.6fTUFtlzNn@thomas> <13664031.VsHLxoZxqI@thomas> In-Reply-To: <13664031.VsHLxoZxqI@thomas> From: David Marchand Date: Tue, 21 Jun 2022 21:33:39 +0200 Message-ID: Subject: Re: [PATCH v6] eal: allow worker lcore stacks to be allocated from hugepage memory To: Thomas Monjalon Cc: "Burakov, Anatoly" , Dmitry Kozlyuk , Don Wallwork , dev , Stephen Hemminger , Chengwen Feng , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Bruce Richardson , Honnappa Nagarahalli , nd , "Wang, Haiyue" , Kathleen.Capella@arm.com Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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 Tue, Jun 21, 2022 at 5:00 PM Thomas Monjalon wrote: > > >>> The name of the option should not include "huge". > > >>> What about "--worker-stack" ? > > >>> If disabled (equal zero), the workers should use the default stack memory. > > >>> > > >>> > > >> Wouldn't that have the potential to create confusion? The point of this > > >> change is to allocate worker stacks from hugepages. Removing huge > > >> from the option name could give the impression that the command is > > >> simply to control worker stack size. > > > It means if we control the worker stack size with a DPDK option, > > > DPDK memory will be used. > > > But we cannot force hugepage with this option. > > > Hugepage is not always available and it can be disabled in DPDK. > > > > The command could be rejected if hugepages are not available. > > That's not in the patch currently, but can be added. > > David, Anatoly, Dmitry, what do you think? We have other non compatible EAL options for which combining them trigger an init failure. This is acceptable for me. -- David Marchand