From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 27B66A0526; Mon, 20 Jan 2020 20:35:42 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1989D1C0AC; Mon, 20 Jan 2020 20:35:41 +0100 (CET) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id E55CF1C06B for ; Mon, 20 Jan 2020 20:35:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579548939; 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=tmxaM8OTLN9wouFLzTpugGhc4Sp4jR/40KmaMhqc36c=; b=NQY6GIqe5GSR8pC9xlQ3/uyoxI5j9LYf3NRANC4j6WqUpwWX/oyCqbvRmW5tw44laHzfn6 KnFpv1gMFXGGcFDD0GUDf8aAoyC+HwJvlNCLakwJlJuqvekB8rQeLgSHHJc2hThCe1RECo Vos7BFfPnUrjDawScu5J0rykJj5kvj4= Received: from mail-vs1-f69.google.com (mail-vs1-f69.google.com [209.85.217.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-342-Em9SzlfAM0CV7fr8mzvv9g-1; Mon, 20 Jan 2020 14:35:37 -0500 Received: by mail-vs1-f69.google.com with SMTP id t3so63632vsa.18 for ; Mon, 20 Jan 2020 11:35:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LPBP4BWxxUb4pE0H6PZmuYHD7akCFdrTRDsmVm6rRWo=; b=IsXbYFZdmS3wxmAEaVM5DwVlmOWavHwsDMc66DJbdmDMVS1Li0jnZwFMMy0SpjUSR9 LlL2pygsX9X0MQSog9CeHz9khhLbz481EHYF+e/KNPmaXYivWKvJ8YEsg4T21Oh4u5sc hLHHWVRM42WkO1naqGaHVWTxWm4JcWLKrKbmczWJIPza44vgZXqUYcDmxuEPqR4KOzki 6YW4FZfhlkcAwkyOGrfRl5zdm14QQn9M5guC67v8WkC36vHPxtKrIzP6fvFWfhUIFY9E UlZivs+oC6ndx1K5pi62c7bRQudW9B8cPM0vtIAQGRVqbqioLBw16eF42+X+rB/wUwES ZhDg== X-Gm-Message-State: APjAAAW+N/jg4PRg/ruT4G/n9ITag7zwdzETTjDPDOhiXuhboTeQ7JuG iJeLfknFuV9Y52SohGwuXuasiqfGvv7Oq465Wj6oVzgS3E20TZD4EQbMGx7ywSJ4qs62XaTWD88 WddN2ErFRfL7oPc2ferQ= X-Received: by 2002:a05:6102:20ca:: with SMTP id i10mr528837vsr.105.1579548937184; Mon, 20 Jan 2020 11:35:37 -0800 (PST) X-Google-Smtp-Source: APXvYqycgvMpFUWMwXvUeR7iG5nP3tvxyJcplnEGPmgnQ2c38iJ94LvPBXr93OPshDN5l75GarIM175ZOEnzBfOaHI8= X-Received: by 2002:a05:6102:20ca:: with SMTP id i10mr528813vsr.105.1579548936828; Mon, 20 Jan 2020 11:35:36 -0800 (PST) MIME-Version: 1.0 References: <20191202153559.9709-1-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Mon, 20 Jan 2020 20:35:25 +0100 Message-ID: To: "Yigit, Ferruh" Cc: dev , Aaron Conole X-MC-Unique: Em9SzlfAM0CV7fr8mzvv9g-1 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 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 Mon, Jan 20, 2020 at 7:37 PM Yigit, Ferruh wrote: > > On 12/2/2019 3:35 PM, David Marchand wrote: > > We are currently stuck with no option but recompile a DPDK if the syste= m > > has more cores than RTE_MAX_LCORE. > > A bit of a pity when you get a system with more than 200+ cores and you= r > > testpmd has been built and packaged with RTE_MAX_LCORE =3D=3D 128. > > Just for clarification, in this case the DPDK application will work but w= ill > only use RTE_MAX_LCORE cores, right? You need to compile to use all avail= able cores. EAL starts up to RTE_MAX_LCORE lcores (as in EAL threads), that's true before and after this patch. By default (using the -c or -l options), a lcore X runs on the physical cor= e X. With the --lcores option, you can select on which physical cores a lcore ru= ns. But, before this series, the code limits the physical cores to the same [0, RTE_MAX_LCORE[ range. > > Are cores more than RTE_MAX_LCORE usable after this patch? Yes, see below. > > > > > The --lcores does not need to care about the underlying cores, remove > > this limitation. > > > > +1 to remove limit in --lcores, but I didn't make it work with this patch= set, I > may be missing something, I tried by setting the "RTE_MAX_LCORE=3D32", in= this > case should '--lcores "(30-40)@(10-20)"' work? Quoting the parser code: * The format pattern: --lcores=3D'[<,lcores[@cpus]>...]' * lcores, cpus could be a single digit/range or a group. * '(' and ')' are necessary if it's a group. * If not supply '@cpus', the value of cpus uses the same as lcores. * e.g. '1,2@(5-7),(3-5)@(0,2),(0,6),7-8' means start 9 EAL thread as below * lcore 0 runs on cpuset 0x41 (cpu 0,6) * lcore 1 runs on cpuset 0x2 (cpu 1) * lcore 2 runs on cpuset 0xe0 (cpu 5,6,7) * lcore 3,4,5 runs on cpuset 0x5 (cpu 0,2) * lcore 6 runs on cpuset 0x41 (cpu 0,6) * lcore 7 runs on cpuset 0x80 (cpu 7) * lcore 8 runs on cpuset 0x100 (cpu 8) With --lcores "(30-40)@(10-20)", you asked to start lcores 30 to 40 to run on the cpuset 10 to 20. So it will be refused, since the max lcore is 32. If your intention was to start lcore 10 on physical core 30, lcore 11 on core 31 etc... then you can try --lcores 10@30,11@31,12@32... --=20 David Marchand