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 1A95FA034F; Fri, 10 Sep 2021 10:06:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 96E8140041; Fri, 10 Sep 2021 10:06:55 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mails.dpdk.org (Postfix) with ESMTP id CBAF24003E for ; Fri, 10 Sep 2021 10:06:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631261213; 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=BfBcN5+U2fbOIno8FmZ19v/rs1a/0kfIfRkC6YQCiOY=; b=AFdW6QoYc8ziLwJBei/jiXjHLmzR6keZVOkFwWh/k+IvR07nRsOOUhBCBw59rCgGuchBPd wW01Ln2zu+IYBVufhzp6HXxup17WyYxCCkdXnrfv00gXPl8gwyrLPFO7buRAvuqgqIz3hn nogg173ntCbyOFkJfgB4xeiEIj4jDOE= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-387-uHoyN-i0OcacV5yNKOFjVg-1; Fri, 10 Sep 2021 04:06:51 -0400 X-MC-Unique: uHoyN-i0OcacV5yNKOFjVg-1 Received: by mail-lj1-f200.google.com with SMTP id j9-20020a2ea909000000b001dc7f4ec0ffso556642ljq.1 for ; Fri, 10 Sep 2021 01:06:51 -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=BfBcN5+U2fbOIno8FmZ19v/rs1a/0kfIfRkC6YQCiOY=; b=oC3odmH7k9XYKNLdLnhxPlrISc98SSUdGgSFjrfbuhA48EA/kpneicr9uOpYD5qBUA TGTALTD/lGoy3ERwigQgwMIkPmUsY98x/J6v1FUSHIu+jQC9tbGbKCvEpC/jIeEWsAjU YaTkFjQjZKA7AM9m4oML4PwNY2BMQu8rinV9x4pZozZXDMiX693DuMcfgHtcI6hybLTb YEisSEBbWz2jmaprWOUComkEGO2phOd/X6henGW19yqzLMA6M1g+u8uRqp2yrSYhzMcQ dwg8OQc5okQHt9+Ld+LrszpE7XS7wuyYr0mrTPy/Qnn+790aJfl1lKtd8meFKfFFQf0Q M+LA== X-Gm-Message-State: AOAM532o3sbWxJ1xsnqOWzPzM7Djlkw5rZbYRtjZ4kXyS29F62e74cC0 EUq5e7N4ogSQyXreQWb91XUPw14I19W4rwJQb12BNNhBqn043zO5+EKGae+LIkCoQ6Df0YFmlQG QYQa7sm7IIzMv+Nd2DPs= X-Received: by 2002:ac2:4c4c:: with SMTP id o12mr2941968lfk.499.1631261210359; Fri, 10 Sep 2021 01:06:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw27Tu1mRkCP2XdYwR75K43gt8DQQJXZq4RUtKf7WuivTQ7ymmg/D/KFSq1OZYbZoIMQQcitA386qnJUHZ39cc= X-Received: by 2002:ac2:4c4c:: with SMTP id o12mr2941953lfk.499.1631261210094; Fri, 10 Sep 2021 01:06:50 -0700 (PDT) MIME-Version: 1.0 References: <20210909134511.18871-1-david.hunt@intel.com> <20210909134511.18871-2-david.hunt@intel.com> In-Reply-To: From: David Marchand Date: Fri, 10 Sep 2021 10:06:39 +0200 Message-ID: To: Bruce Richardson Cc: David Hunt , dev , Thomas Monjalon 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" Subject: Re: [dpdk-dev] [PATCH v1 1/6] build: increase default of max lcores to 512 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 Sender: "dev" On Fri, Sep 10, 2021 at 9:54 AM Bruce Richardson wrote: > > On Fri, Sep 10, 2021 at 08:51:04AM +0200, David Marchand wrote: > > On Thu, Sep 9, 2021 at 4:38 PM Bruce Richardson > > wrote: > > > > > > On Thu, Sep 09, 2021 at 02:45:06PM +0100, David Hunt wrote: > > > > Modern processors are coming with an ever increasing number of cores, > > > > and 128 does not seem like a sensible max limit any more, especially > > > > when you consider multi-socket systems with Hyper-Threading enabled. > > > > > > > > This patch increases max_lcores default from 128 to 512. > > > > > > > > Signed-off-by: David Hunt > > > > Why should we need this? > > > > --lcores makes it possible to pin 128 lcores to any physical core on > > your system. > > And for applications that have their own thread management, they can > > pin thread, then use rte_thread_register. > > > > Do you have applications that require more than 128 lcores? > > > The trouble is that using the --lcores syntax for mapping high core numbers > to low lcore ids is much more awkward to use. Every case of DPDK use I've > seen uses -c with a coremask, or -l with just giving a few core numbers on > it. This simple scheme won't work with core numbers greater than 128, and > there are already systems available with more than that number of cores. > > Apart from the memory footprint issues - which this patch is already making > a good start in addressing, why would we not increase the default > max_lcores to that seen on real systems? The memory footprint is a major issue to me, and reserving all those lcores won't be needed in any system. We will also have to decide on a "640k ought to be enough" value to avoid ABI issue with the next processor that comes out and has more than 512 cores. Could we wire the -c / -l options to --lcores behavior ? It breaks the 1:1 lcore/physical core assumption, but it solves your usability issue. -- David Marchand