Message ID | 20240916042631.186816-1-probb@iol.unh.edu (mailing list archive) |
---|---|
State | Accepted |
Delegated to: | David Marchand |
Headers |
Return-Path: <dts-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4F0F2459A7; Mon, 16 Sep 2024 06:27:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 47E844025F; Mon, 16 Sep 2024 06:27:28 +0200 (CEST) Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by mails.dpdk.org (Postfix) with ESMTP id 9BB2A40041 for <dts@dpdk.org>; Mon, 16 Sep 2024 06:27:26 +0200 (CEST) Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-7a9a30a0490so454603985a.3 for <dts@dpdk.org>; Sun, 15 Sep 2024 21:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1726460846; x=1727065646; darn=dpdk.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=X7i3v8UGA7QFVgop203dPWrbfQmQePPokNNUU9riphA=; b=QLvNw/jcxNreSMHTxMmHyKT8IEPcY1mcd1auKbMkPhNjnnafEVWYBFet/fVCk4fx5v YXQj5lHWj9WL1BsWKbzOXh3G1KlRxcw60+3kd+MeKWlpVgsHCXq7To5gVc3Jzx51kf/9 6j24tHxySEmVq3Hm3FE1kfS+yBj5BgGMjgdB4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726460846; x=1727065646; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=X7i3v8UGA7QFVgop203dPWrbfQmQePPokNNUU9riphA=; b=lk+SjG8pISxg8smF8CG7fBphOrJnPcXi724U9rdDKdN5sYdRLfLAlvhuZnCANARsmq 40NEKBQE7WdgwYDzPs91GQlYsTn78zIW9q25BjJLEZGa9hkOr06uCp4nC/1BNHF2Sby8 7pD4zwefkvqvLpP0MfrqrXNrT3+B3vePan+iVYT7wXdeGWDnlM47+M9nCSvFZD1vH4GF AIt9djw5yp0UX3whNVE0QAaHs3QkwS0a2/08ByfB66uuXtHaBxqyLFBOf4FPR1ggSj0h CjJNUFby/2VODg441VDhVoKN89mdLku61MUTK1mGAwOBn8DV+zFCRG45BXzy+xSOHbwI Hh/Q== X-Gm-Message-State: AOJu0YzPRac6qDyXh9aQtg7g67DFynemIGt0eXBrC38z4kuc1U7Ehq/v ZSB9FgeG0wh3DH51OJP15oYoqsKFKMkwT+t/5pqcY0yyDm/iVRA0dGQOIAehFRA= X-Google-Smtp-Source: AGHT+IGP3JcFWWjp2gfigQdGzYXUgt2S2Z9CnivfacUSMLizJ1unMoPUWQCPuhOy1k+inCx18v6jnA== X-Received: by 2002:a05:620a:4481:b0:7a9:bf2a:d7d8 with SMTP id af79cd13be357-7a9e5eea6e7mr2004159085a.8.1726460845914; Sun, 15 Sep 2024 21:27:25 -0700 (PDT) Received: from localhost.unh.edu ([2606:4100:3880:1257::10e7]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7ab3e98ef84sm212299285a.40.2024.09.15.21.27.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Sep 2024 21:27:25 -0700 (PDT) From: Patrick Robb <probb@iol.unh.edu> To: david.marchand@redhat.com Cc: dts@dpdk.org, Patrick Robb <probb@iol.unh.edu> Subject: [PATCH] tests/TestSuite_crypto_perf_cryptodev_perf.py Improving lscpu parsing Date: Mon, 16 Sep 2024 00:26:31 -0400 Message-ID: <20240916042631.186816-1-probb@iol.unh.edu> X-Mailer: git-send-email 2.46.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dts@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: test suite reviews and discussions <dts.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dts>, <mailto:dts-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dts/> List-Post: <mailto:dts@dpdk.org> List-Help: <mailto:dts-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dts>, <mailto:dts-request@dpdk.org?subject=subscribe> Errors-To: dts-bounces@dpdk.org |
Series |
tests/TestSuite_crypto_perf_cryptodev_perf.py Improving lscpu parsing
|
|
Commit Message
Patrick Robb
Sept. 16, 2024, 4:26 a.m. UTC
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.
Signed-off-by: Patrick Robb <probb@iol.unh.edu>
---
tests/TestSuite_crypto_perf_cryptodev_perf.py | 1 +
1 file changed, 1 insertion(+)
Comments
On Mon, Sep 16, 2024 at 6:27 AM Patrick Robb <probb@iol.unh.edu> 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" systems. 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. Could you detail which systems have such issue? In any case, this fix makes sense to me and it seems limited and safe enough to merge the patch in the "legacy" repository for dts. > > Signed-off-by: Patrick Robb <probb@iol.unh.edu> Reviewed-by: David Marchand <david.marchand@redhat.com>
On Mon, Sep 16, 2024 at 3:17 AM David Marchand <david.marchand@redhat.com> wrote: > > On Mon, Sep 16, 2024 at 6:27 AM Patrick Robb <probb@iol.unh.edu> 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" systems. > 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.
On Tue, Sep 17, 2024 at 5:37 AM Patrick Robb <probb@iol.unh.edu> wrote: > > On Mon, Sep 16, 2024 at 3:17 AM David Marchand > <david.marchand@redhat.com> wrote: > > > > On Mon, Sep 16, 2024 at 6:27 AM Patrick Robb <probb@iol.unh.edu> 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" systems. > > 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). Thank you for confirming, I'll update the commitlog accordingly before applying. > > > > > 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 Ok, there is no point in investigating more from my pov. I'll just mention that some ARM env were affected. > 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. This would be a more robust solution, but I guess this is beyond the simple fixing that we want to do on this "legacy" repository. Hopefully, the new DTS code in the DPDK repo won't be subject to such issue. > 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. +1
On Mon, Sep 16, 2024 at 9:16 AM David Marchand <david.marchand@redhat.com> wrote: > On Mon, Sep 16, 2024 at 6:27 AM Patrick Robb <probb@iol.unh.edu> 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. > > > > Signed-off-by: Patrick Robb <probb@iol.unh.edu> > Reviewed-by: David Marchand <david.marchand@redhat.com> Applied with some update on the commitlog. Thanks Patrick.
diff --git a/tests/TestSuite_crypto_perf_cryptodev_perf.py b/tests/TestSuite_crypto_perf_cryptodev_perf.py index 0531b9c677da..a6b611d7956d 100644 --- a/tests/TestSuite_crypto_perf_cryptodev_perf.py +++ b/tests/TestSuite_crypto_perf_cryptodev_perf.py @@ -330,6 +330,7 @@ class TestCryptoPerfCryptodevPerf(TestCase): elif "Vulnerability" in each_line: continue key, value = each_line.split(":") + key = key.strip() cpu_info[key] = value.strip() core, thread = 0, 0 lcores = self.get_case_cfg()["l"].split(",")