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 8EC42A0C46; Tue, 14 Sep 2021 12:00:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7EB314068F; Tue, 14 Sep 2021 12:00:47 +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 234B24003C for ; Tue, 14 Sep 2021 12:00:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631613645; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=l1TZJQJQRbEgy/jYYU276+M5JeKTlTeA/kCUt65qYVY=; b=eRAwH0aApNHT4dyL7vmQVnlGEiFc5WgJidNgmE6WwoPWtAXQF6JQM2LpMPLbuxFS3ANaab /3+Oc3cgmX0ghswDhD9Eidt7EdJTwV60KS4Xydi5vk/NZDmgOfsSOTVx3UC9dyH458Cgmw afv0bES3SEvJf23c9GYBpCmHT3TNoDY= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-223-UWsFS1AyO0eJb4QThd4akw-1; Tue, 14 Sep 2021 06:00:44 -0400 X-MC-Unique: UWsFS1AyO0eJb4QThd4akw-1 Received: by mail-lf1-f72.google.com with SMTP id c24-20020ac25318000000b003f257832dfdso2896031lfh.20 for ; Tue, 14 Sep 2021 03:00:43 -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:content-transfer-encoding; bh=l1TZJQJQRbEgy/jYYU276+M5JeKTlTeA/kCUt65qYVY=; b=GeVQuKtNECPN6HhhL+2X9oMQR4ovUgKYNpGdJcsE+ie5HPJjjiWU8xN68jtYdO2G/7 L461gUlUz79Klt4x7ju85FdPGfbJ91Yg72pOp5/98WhqmF2cq+kcZ+PxWJ1bOdU/JkN5 uMabhgp5RU9QeV8l0jp1Qhfl0R0CpVRphDepC9+pHLjWU9BOb2Sp0OUkUGzvUhDv1Lym lO2cqCyttPKxK/dMHFTNtVdGXF1Slwl6kQyrVuk9E+53ugwbyTG/UYRgp7Viq9JqCgjc Rv+qzWtbH6X8kMm5vMTau5BcXOE2XI2oEkWUbzZMHhXu9a/eqeNQ2VzTtkP1nLo2FkZS ipGg== X-Gm-Message-State: AOAM530G2x0DSbba+DKKR/HMD1DqDkqZCiKh9xYBC5xoW9oT7V/eeLhN 6SvCfCPAYIPA/4wJS9HR6nDNJwCKpoiXSocluYVV5MeDu6oBBshjhmhyje3BE4q4umFXg80Vg6f ux1HCUY2wK+M7XkYQ/wQ= X-Received: by 2002:a2e:88d0:: with SMTP id a16mr14619015ljk.81.1631613642526; Tue, 14 Sep 2021 03:00:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJykT7x7J5F195+MeWIEtMKTcMUw1tXu2ZmkC0cLEtdPNrN9PIcKDIJtGTxdXCXZfyDGEq0uCGlLd/NWhMLwu/8= X-Received: by 2002:a2e:88d0:: with SMTP id a16mr14618995ljk.81.1631613642314; Tue, 14 Sep 2021 03:00:42 -0700 (PDT) MIME-Version: 1.0 References: <20210909134511.18871-1-david.hunt@intel.com> <5148108.61zlV0aQVf@thomas> In-Reply-To: From: David Marchand Date: Tue, 14 Sep 2021 12:00:31 +0200 Message-ID: To: David Hunt Cc: Thomas Monjalon , Bruce Richardson , dev 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" Content-Transfer-Encoding: quoted-printable 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 Tue, Sep 14, 2021 at 11:34 AM David Hunt wrote: > > > On 10/9/2021 9:24 AM, Thomas Monjalon wrote: > > 10/09/2021 10:06, David Marchand: > >> 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 cor= es, > >>>>>> and 128 does not seem like a sensible max limit any more, especial= ly > >>>>>> when you consider multi-socket systems with Hyper-Threading enable= d. > >>>>>> > >>>>>> 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 n= umbers > >>> 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 numbe= rs 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 cor= es. > >>> > >>> 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. > > Why would we change existing options while we already have an option > > (--lcores) which solves the issue above? > > I think the only issue is to educate users. > > Is there something to improve in the documentation? > > > > Hi all, > I agree that it=E2=80=99s a good idea to switch to using the =E2=80=9C--l= crores=E2=80=9D option Let's avoid typo in the error message you'll add :-). > for cores above the default, that=E2=80=99s already future proofed. > However, I=E2=80=99m still a little concerned about usability, if our use= rs are > accustomed to the =E2=80=9C-c=E2=80=9D and =E2=80=9C-l=E2=80=9D options, = I suggest that we add a warning > to suggest using the =E2=80=9C--lcores=E2=80=9D option if any of the core= s provided on > the command line are above RTE_MAX_LCORE. That would help them with the > solution to using physical cores above 128 (or whatever the compiled > default is). > > Example: > > =E2=80=9CERROR: logical core 212 is above the maximum lcore number permit= ted. > Please use the --lcores option to map lcores onto physical cores, e.g. > --lcores=3D"(0-3)@(212-215).=E2=80=9D If you could directly provide the right --lcores syntax based on what user provided with -c or -l, it would be even better. This should be not that difficult. > > I=E2=80=99ll replace the first patch in the set with a patch that adds th= e > additional information in the error message. --=20 David Marchand