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 F0930459B0; Tue, 17 Sep 2024 05:37:12 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E83BF40653; Tue, 17 Sep 2024 05:37:12 +0200 (CEST) Received: from mail-oa1-f44.google.com (mail-oa1-f44.google.com [209.85.160.44]) by mails.dpdk.org (Postfix) with ESMTP id B09B6402C4 for ; Tue, 17 Sep 2024 05:37:11 +0200 (CEST) Received: by mail-oa1-f44.google.com with SMTP id 586e51a60fabf-27b55c4b35eso1332649fac.3 for ; Mon, 16 Sep 2024 20:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1726544231; x=1727149031; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rlJat3sUhvoiwZL728AjIBeJMdfWVPqDk6qJZsM5gJ0=; b=ePfd8fE4yNqDfzyQYcn2SvLFL6arn2mS9YGwfaJeUA6D3CDjb7ZuM14Qiew96ZJipJ /HN6Af8OyVw8cUDtV2SMsvOgfJHmqFP4IW85wq+JLe3wxQsYGTgAhvCfsIWHMupM1ypK biY6pdOmFYbYraMmhNZTwhppeCLul06AZjBok= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726544231; x=1727149031; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rlJat3sUhvoiwZL728AjIBeJMdfWVPqDk6qJZsM5gJ0=; b=kCDuuFNSgBuvGBQV5z1g2MqcueN9sHhdgy9SESLlFzozdtZodTlOFkm6Ta8Ix4WN0A EM3Gi3i/N0eAv0oITIxM/AMPDKB4UFqlMOApwQjO1LXIfpjlmFIg4k1yN5mCb9VuMNjY rD7r8rriEkkbgOSW6Lz04+5X7FHqGOz8VzBuCTnsp4vfT90WnTKhNtPrwX06Ji8BKGOv 6mXSYemNRpOgGGxNn7DDmHcom10iLKMWsnGckWA9VlxuRRcKHs9z6NpHtFIh8u77/FTi qf6eM8y/0sW1RmQriUiu7f3v33KrgDL9RAOGOXyRgMbVKrLcuh1VLvZRq6Uncsd5HALs YbEg== X-Gm-Message-State: AOJu0YzB8bUZyhCGvgvZh6g9B/m1pje/IJGZvEW8dkg1QItDU5Xffvag ApvZkroF7VxyXyu1Bl1QvjgJHMElpVYuTZ2mfKkPulv8hijxYZ/bRQG8dCiw0FRmI/8b8PwbXeE 8buuGTGuTeS6YoEinU4RcFSLOIXYHMW0rNCdf8g== X-Google-Smtp-Source: AGHT+IGNiSPoei0eHHflJ4nqqR8MCHEXsHtLezdRgbT0wpwiFD2RI+MZvpcYn43zLiml7Wd085kb9WfTMBWhF6LdRw4= X-Received: by 2002:a05:6871:e2e7:b0:261:1f7d:cf71 with SMTP id 586e51a60fabf-27c68ba0e75mr7473647fac.34.1726544230786; Mon, 16 Sep 2024 20:37:10 -0700 (PDT) MIME-Version: 1.0 References: <20240916042631.186816-1-probb@iol.unh.edu> In-Reply-To: From: Patrick Robb Date: Mon, 16 Sep 2024 23:36:14 -0400 Message-ID: Subject: Re: [PATCH] tests/TestSuite_crypto_perf_cryptodev_perf.py Improving lscpu parsing To: David Marchand Cc: dts@dpdk.org, Thomas Monjalon , Aaron Conole Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: test suite reviews and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dts-bounces@dpdk.org On Mon, Sep 16, 2024 at 3:17=E2=80=AFAM David Marchand wrote: > > On Mon, Sep 16, 2024 at 6:27=E2=80=AFAM Patrick Robb = wrote: > > > > This testsuite fails to parse lscpu output on some systems because > > it expects that there be no leading whitespace, which is not > > true on all systems. > > The leading whitespace is a generic issue, not really related to "some" s= ystems. > The issue is that keys of interest for the rest of the code ('Core(s) > per socket', 'Socket(s)', 'CPU(s)') may have leading whitespace on > some systems. ^The above is what I had in mind when writing my commit - your wording gets to the point better, thanks. I had observed this issue in trying to run the testsuite on an ARM Neoverse N-1 Ampere server at UNH, and noted that the leading whitespace on it's lscpu output was preventing the 'Core(s) per socket' key from appearing in the output dict (at least without the trimming which this commit provides). > > Could you detail which systems have such issue? > >From a quick look through of our systems I think that there appears to be a mixture of systems with lscpu output with no leading whitespace before any of the keys, and others (like the Ampere server I mentioned) which do have that leading whitespace/indentation. I'm not sure what the pattern is (I guess it probably depends on the OS on the system), and a google search didn't seem to reveal much about this question. However, from looking at the lscpu man page, I do see that there is a --json flag which you can include. So, in my opinion the ideal way to deal with these situation where you must read some information from the system, is to use the options available (like lscpu --json) which are guaranteed to return a machine readable output. Getting into the business of reading text output like this is not ideal, given that it is subject to change in the future. But, I have the same view as you that this commit is not likely to break this testsuite for any systems which are running the suite currently, it will only help for systems with the indented lscpu output.