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 B8664A0C41; Thu, 16 Sep 2021 14:35:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4911440151; Thu, 16 Sep 2021 14:35:08 +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 130634003F for ; Thu, 16 Sep 2021 14:35:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631795706; 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=k90Lg85KuETVY7FmxW2QDC+XQNztl8s+bEh6kSY3+HE=; b=PouOzHdYhTXYJxKFCxsdljwisnl8p92+tKMyyr0OQlRpdY2ns6ixO5peSbuJrfP+napr+n fHA2b3J5z2ItkCbnwoIKd8aiZqCsU9tYz/L0/5cx3eZLMKjpDcsfxBkNVPDuwofmlLr22e 5YzyRbEJViBkuOgHTh2/tBC6q1w1HqA= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-487-o12MRu0YPlWnnkaCcDkGIQ-1; Thu, 16 Sep 2021 08:34:42 -0400 X-MC-Unique: o12MRu0YPlWnnkaCcDkGIQ-1 Received: by mail-lf1-f70.google.com with SMTP id w18-20020ac25d520000b02903c5ff81b281so3788834lfd.3 for ; Thu, 16 Sep 2021 05:34:42 -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=k90Lg85KuETVY7FmxW2QDC+XQNztl8s+bEh6kSY3+HE=; b=Ro7PVQaFnFcdXliDMylHyGAtWL+g37P2h1uGM3F+xUdZhVSGPqEkjdJMILTj/BfbpT uqrV6RS6Gh/UbOTGNG3/EEPc/A0ZNE5U9MlFpD9Luj9otFwQcB6X7zPQNHtyIL5y1szN 3OvN3y24xPWpHUdxRBC8P1BEhM1nzJ/ASy5C0mETjCtVykJC9M0DRoyOjSLiIAC2+b1e mSpEUiCaCJb/6jzHDvm0R8NGEC4PywtNTeLxW3EoKNSa64EeSWVJpULYc8uGp8YZFNNC EV2H691u9OYPQL6adPSXJSEUEXyHzZYqBirZ4C2+QBB0GGpkawcGtTPtT3Kn3HtTjvPO 03mw== X-Gm-Message-State: AOAM530aox8itcq+/cG/Z0RdvZLaa0idM89Kgx8O1UZHihft1lP1n2a1 9qO3nksb0FUT19Ll073bNPzWWYt2Ucjx3x8a/ZpmwOHPP/Z0pmrwg1vJ2erbmb2E6BsFzuezVQ+ 6xLS9yOGCThv1wohRMg8= X-Received: by 2002:a05:6512:36d9:: with SMTP id e25mr3882722lfs.553.1631795680813; Thu, 16 Sep 2021 05:34:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJylogUJmvp795y000FLzD1NuPccP5ALG8hOP/zugP9xdnKfW4Sa3wW9WqCb4JBeJJkYyiFpR3gBdFhfefnerd0= X-Received: by 2002:a05:6512:36d9:: with SMTP id e25mr3882698lfs.553.1631795680457; Thu, 16 Sep 2021 05:34:40 -0700 (PDT) MIME-Version: 1.0 References: <20210909134511.18871-2-david.hunt@intel.com> <20210915121104.30581-1-david.hunt@intel.com> In-Reply-To: <20210915121104.30581-1-david.hunt@intel.com> From: David Marchand Date: Thu, 16 Sep 2021 14:34:29 +0200 Message-ID: To: David Hunt Cc: dev , Bruce Richardson , 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" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH v2] eal: add additional info if lcore exceeds max cores 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 Wed, Sep 15, 2021 at 2:11 PM David Hunt wrote: > > If the user requests to use an lcore above 128 using -l or -c, > the eal will exit with "EAL: invalid core list syntax" and > very little other useful information. > > This patch adds some extra information suggesting to use --lcores > so that physical cores above RTE_MAX_LCORE (default 128) can be > used. This is achieved by using the --lcores option by mapping > the logical cores in the application onto to physical cores. > > There is no change in functionalty, just additional messages > suggesting how the --lcores option might be used for the supplied > list of lcores. For example, if "-l 12-14,130,132" is used, we > see the following additional output on the command line: > > EAL: Error =3D One of the 5 cores provided exceeds RTE_MAX_LCORE (128) > EAL: Please use --lcores instead, e.g. --lcores 0@12,1@13,2@14,3@130,4@13= 2 > > Signed-off-by: David Hunt > > --- > changes in v2 > * Rather than increasing the default max lcores (as in v1), > it was agreed to do this instead (switch to --lcores). > * As the other patches in the v1 of the set are no longer related > to this change, I'll submit as a separate patch set. The -c option can use the same kind of warning. > --- > lib/eal/common/eal_common_options.c | 31 +++++++++++++++++++++++++---- > 1 file changed, 27 insertions(+), 4 deletions(-) > > diff --git a/lib/eal/common/eal_common_options.c b/lib/eal/common/eal_com= mon_options.c > index ff5861b5f3..5c7a5a45a5 100644 > --- a/lib/eal/common/eal_common_options.c > +++ b/lib/eal/common/eal_common_options.c > @@ -836,6 +836,8 @@ eal_parse_service_corelist(const char *corelist) > return 0; > } > > +#define MAX_LCORES_STRING 512 > + > static int > eal_parse_corelist(const char *corelist, int *cores) > { > @@ -843,6 +845,9 @@ eal_parse_corelist(const char *corelist, int *cores) > char *end =3D NULL; > int min, max; > int idx; > + bool overflow =3D false; > + char lcores[MAX_LCORES_STRING] =3D ""; This code is not performance sensitive. In the worst case, like for RTE_MAX_LCORES lcores, it gives this: 0@0,1@1,2@2,3@3,4@4,5@5,6@6,7@7,8@8,9@9,10@10,11@11,12@12,13@13,14@14,15@15= ,16@16,17@17,18@18,19@19,20@20,21@21,22@22,23@23,24@24,25@25,26@26,27@27,28= @28,29@29,30@30,31@31,32@32,33@33,34@34,35@35,36@36,37@37,38@38,39@39,40@40= ,41@41,42@42,43@43,44@44,45@45,46@46,47@47,48@48,49@49,50@50,51@51,52@52,53= @53,54@54,55@55,56@56,57@57,58@58,59@59,60@60,61@61,62@62,63@63,64@64,65@65= ,66@66,67@67,68@68,69@69,70@70,71@71,72@72,73@73,74@74,75@75,76@76,77@77,78= @78,79@79,80@80,81@81,82@82,83@83,84@84,85@85,86@86,87@87,88@88,89@89,90@90= ,91@91,92@92,93@93,94@94,95@95,96@96,97@97,98@98,99@99,100@100,101@101,102@= 102,103@103,104@104,105@105,106@106,107@107,108@108,109@109,110@110,111@111= ,112@112,113@113,114@114,115@115,116@116,117@117,118@118,119@119,120@120,12= 1@121,122@122,123@123,124@124,125@125,126@126,127@127, Which is 800+ bytes long, let's switch do dynamic allocations. > + int len =3D 0; > > for (idx =3D 0; idx < RTE_MAX_LCORE; idx++) > cores[idx] =3D -1; > @@ -862,8 +867,10 @@ eal_parse_corelist(const char *corelist, int *cores) > idx =3D strtol(corelist, &end, 10); > if (errno || end =3D=3D NULL) > return -1; > - if (idx < 0 || idx >=3D RTE_MAX_LCORE) > + if (idx < 0) > return -1; > + if (idx >=3D RTE_MAX_LCORE) > + overflow =3D true; The code before was intermixing parsing and validation of values. This intermix was not that great. Let's separate those concerns. > while (isblank(*end)) > end++; > if (*end =3D=3D '-') { > @@ -873,10 +880,19 @@ eal_parse_corelist(const char *corelist, int *cores= ) > if (min =3D=3D RTE_MAX_LCORE) > min =3D idx; > for (idx =3D min; idx <=3D max; idx++) { > - if (cores[idx] =3D=3D -1) { > - cores[idx] =3D count; > - count++; > + if (idx < RTE_MAX_LCORE) { > + if (cores[idx] =3D=3D -1) > + cores[idx] =3D count; > } > + count++; > + if (count =3D=3D 1) > + len =3D len + snprintf(&lcores[le= n], > + MAX_LCORES_STRING= - len, > + "%d@%d", count-1,= idx); > + else > + len =3D len + snprintf(&lcores[le= n], > + MAX_LCORES_STRING= - len, > + ",%d@%d", count-1= , idx); Always appending a , is easier to read, then after the loop, you just need to trim the last ,. > } > min =3D RTE_MAX_LCORE; > } else > @@ -886,6 +902,13 @@ eal_parse_corelist(const char *corelist, int *cores) > > if (count =3D=3D 0) > return -1; > + if (overflow) { > + RTE_LOG(ERR, EAL, "Error =3D One of the %d cores provided= exceeds RTE_MAX_LCORE (%d)\n", > + count, RTE_MAX_LCORE); > + RTE_LOG(ERR, EAL, "Please use --lcores instead, e.g. --lc= ores %s\n", > + lcores); > + return -1; > + } > return 0; I'd rework both -c and -l parsing to fill a common data structure, then validate and generate the suggestion in common helpers. Something like: https://github.com/david-marchand/dpdk/commit/lcores This probably needs some time to look at to enhance style and carefully check for mem leaks. Tested with max_lcores =3D 4 (for my 8 cores laptop): $ for opt in "-c 0x" "-c 0x0" "-c 0x1" "-c 0xf" "-c 0x10" "-c 0x1f" "-c 0x11" "-c 0x30" "-l 0" "-l 0-3" "-l 0-3,2" "-l 4" "-l 0-4" "-l 0,4" "-l 4,5" do echo $opt echo quit | build/app/dpdk-testpmd $opt --log-level=3Dlib.eal:debug --no-huge -m 20 -a 0:0.0 -- --total-num-mbufs=3D2048 -ia |& grep -E '(ready|RTE_MAX_LCORE|Please use|No lcore|Too many)' echo done -c 0x EAL: No lcore in coremask: 0x -c 0x0 EAL: No lcore in coremask: 0x0 -c 0x1 EAL: Main lcore 0 is ready (tid=3D7f03956d1c00;cpuset=3D[0]) -c 0xf EAL: Main lcore 0 is ready (tid=3D7fe464461c00;cpuset=3D[0]) EAL: lcore 1 is ready (tid=3D7fe45f924700;cpuset=3D[1]) EAL: lcore 2 is ready (tid=3D7fe45f123700;cpuset=3D[2]) EAL: lcore 3 is ready (tid=3D7fe45e922700;cpuset=3D[3]) -c 0x10 EAL: lcore 4 >=3D RTE_MAX_LCORE (4) EAL: Please use --lcores 0@4 -c 0x1f EAL: Too many lcores in coremask: 0x1f -c 0x11 EAL: lcore 4 >=3D RTE_MAX_LCORE (4) EAL: Please use --lcores 0@0,1@4 -c 0x30 EAL: lcore 4 >=3D RTE_MAX_LCORE (4) EAL: lcore 5 >=3D RTE_MAX_LCORE (4) EAL: Please use --lcores 0@4,1@5 -l 0 EAL: Main lcore 0 is ready (tid=3D7f833b17ac00;cpuset=3D[0]) -l 0-3 EAL: Main lcore 0 is ready (tid=3D7f9ff5216c00;cpuset=3D[0]) EAL: lcore 2 is ready (tid=3D7f9fefed8700;cpuset=3D[2]) EAL: lcore 3 is ready (tid=3D7f9fef6d7700;cpuset=3D[3]) EAL: lcore 1 is ready (tid=3D7f9ff06d9700;cpuset=3D[1]) -l 0-3,2 EAL: Main lcore 0 is ready (tid=3D7f106b937c00;cpuset=3D[0]) EAL: lcore 1 is ready (tid=3D7f1066dfa700;cpuset=3D[1]) EAL: lcore 2 is ready (tid=3D7f10665f9700;cpuset=3D[2]) EAL: lcore 3 is ready (tid=3D7f1065df8700;cpuset=3D[3]) -l 4 EAL: lcore 4 >=3D RTE_MAX_LCORE (4) EAL: Please use --lcores 0@4 -l 0-4 EAL: Too many lcores in core list: 0-4 -l 0,4 EAL: lcore 4 >=3D RTE_MAX_LCORE (4) EAL: Please use --lcores 0@0,1@4 -l 4,5 EAL: lcore 4 >=3D RTE_MAX_LCORE (4) EAL: lcore 5 >=3D RTE_MAX_LCORE (4) EAL: Please use --lcores 0@4,1@5 --=20 David Marchand