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 3785B4571C; Fri, 2 Aug 2024 16:54:40 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2942540E3F; Fri, 2 Aug 2024 16:54:40 +0200 (CEST) Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by mails.dpdk.org (Postfix) with ESMTP id 8A29A40E20 for ; Fri, 2 Aug 2024 16:54:39 +0200 (CEST) Received: by mail-lj1-f176.google.com with SMTP id 38308e7fff4ca-2ef18ca13f2so15888301fa.3 for ; Fri, 02 Aug 2024 07:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1722610479; x=1723215279; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Q46uayoEpXkspVwjN26jqw7DIqotG6QnH6BDgpxEXLM=; b=TQP/WYMIrwAALHYzTbvUnHXvcrP2JqsAR/dFSmECAXVQBrDQLc1/fe11Siv9fZlpnK 6+y+VUuxlfA3S39KEtqprCoZXiyTrqFrIFvSmZqqaksLYbgbx0zFzb5+Xo5HNZdEVw0H jHTRW4udadUEv8M3Vag1wVwPeBY9HzXDzFGhs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722610479; x=1723215279; h=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=Q46uayoEpXkspVwjN26jqw7DIqotG6QnH6BDgpxEXLM=; b=Pql0fMiqgA5IhZzUoP8+TM7pcwM4ohaUcfAZQXVu6WJ5VRV6h4uJnPTPvTK6USSwZ8 hTEljG2DPxvVEz5oAyQasCrWy4M7e10ISL5iJur7nzm5KO2psYcjMKk0+vWGXM5RjUkR lm4V8eru87w8i/9a9K4wcOxWdgcoNrEmITqs9a9VqzKVRVHPoVFjc98mpgDOjthmWUti L47hDEvRU181jrPBuWXCjMuGMsIKxmvrPEkUpEt2lZkBs8cteGrFBd4mBiprw/Bzftes EFaZ0z8Qa+8ilpkb6uf+I4V/51v+3bNwn3Gn2vIPKAjSTFkRqj/PNZYa9v5s/RClBPAs yEwg== X-Forwarded-Encrypted: i=1; AJvYcCUYs2Mw5DObaWam9U+KFo/25RMD+6uxmaJnWCcfU+WpHNVCSMNBXi26SPSsvrm56NERF50gDdWUwnTuWfU= X-Gm-Message-State: AOJu0Yxs4A87JqkFRbaxUpRGd3sdZBG3KpHjGsEAF1EKBvn175tQ6wG2 DGrWTc45XKwZ7rEBZnBu5UaYXEe33UDgiECEcVr5dM/ECfEuvcgNcSvui1soAPLTnbCEtUmmU6K UHxF8D2/+0eIGcdY7JvOpKcnySpp7i9UZy1VOuA== X-Google-Smtp-Source: AGHT+IFr7LAPJLgmI354bcsw7Up0YJyMBi+UJa36g2reKBTJ/b//Yc3lrdIq4X0Qtw1Mew/cP1XV5z2MMA3W0nkZHmQ= X-Received: by 2002:a05:651c:104a:b0:2ee:e196:1486 with SMTP id 38308e7fff4ca-2f15aafd0a1mr15388341fa.4.1722610478641; Fri, 02 Aug 2024 07:54:38 -0700 (PDT) MIME-Version: 1.0 References: <20240729203955.267942-1-jspewock@iol.unh.edu> <20240730133459.21907-1-jspewock@iol.unh.edu> <20240730133459.21907-2-jspewock@iol.unh.edu> In-Reply-To: From: Nicholas Pratte Date: Fri, 2 Aug 2024 10:54:27 -0400 Message-ID: Subject: Re: [PATCH v2 1/1] dts: add text parser for testpmd verbose output To: Jeremy Spewock Cc: yoan.picchi@foss.arm.com, probb@iol.unh.edu, paul.szczepanek@arm.com, thomas@monjalon.net, Honnappa.Nagarahalli@arm.com, Luca.Vizzarro@arm.com, juraj.linkes@pantheon.tech, wathsala.vithanage@arm.com, dev@dpdk.org Content-Type: text/plain; charset="UTF-8" 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 > You're right that in most cases it would come from the stop output, > but the output from that stop command has one other thing as well that > I would consider valuable which is statistics of packets handled by > ports specifically for the duration of the packet forwarding you are > stopping. It is also true that sending other testpmd commands while > verbose output is being sent will change what is collected, so I > didn't want to tie the method specifically to the stop command since > if you did a start command then checked port statistics for example, > it would consume all of the verbose output up until the command to > check port statistics. > > For the reason stated above I think it actually might make sense to > make it so that every testpmd method (including ones that currently > return dataclasses) return their original, unmodified collected output > from the testpmd shell as well. Things like port stats can return both > in a tuple potentially. This way if there is asynchronous output like > there is with verbose output other commands don't completely remove > it. I agree! I think giving each testpmd method its own output would add more consistency. An idea I had floating around that kind of relates to your suggestion above was introducing some instance variables that could enable the testpmd shell object to be smart enough to automatically scan, and keep a record of, any verbose output that comes out across any command run. The TestPMDShell class could track whether verbose mode is on or not, and if True, run additional logic to scan for verbose output and add it to a data structure for access every time a command is run. Then users, from the perspective of writing a test suite, could do something like 'output in testpmd.verbose_output', where verbose_output is an instance data structure of the TestPMDShell. This might be overcomplicated to implement, but it was an idea I had that might make using verbose mode more streamlined. What are your thoughts?