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 346DB4571D; Fri, 2 Aug 2024 19:39:00 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2150640E22; Fri, 2 Aug 2024 19:39:00 +0200 (CEST) Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com [209.85.215.179]) by mails.dpdk.org (Postfix) with ESMTP id 5427340E0A for ; Fri, 2 Aug 2024 19:38:59 +0200 (CEST) Received: by mail-pg1-f179.google.com with SMTP id 41be03b00d2f7-7a1d48e0a5fso4998143a12.3 for ; Fri, 02 Aug 2024 10:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1722620338; x=1723225138; 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=QVg0uwUR6/R8ud0bDYRPKX/iYNS9XeBPWjdN3KwWwOk=; b=MHoE+6Rb7jkN+sEsRWJfh6HvKGa3Y4pgf0SdhA6rx2K5ZIiIVLw9cZoMzpzPL01PAM wQkvIaruFg+nPp0U5B3o+YS6Rd6dNruba76MT5qRTeK8zSIKzhCqNLK5XuiYEK5UI7j4 A1DWr2bAqIZ1zj+Rr1hEe43Gq1hI6wlg2x+M0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722620338; x=1723225138; 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=QVg0uwUR6/R8ud0bDYRPKX/iYNS9XeBPWjdN3KwWwOk=; b=v6XKdWTJKIRw1XZ7151MiGLzc+yjcHmStP6qqMtZILdzen2KFvQyuXkZFfVQUejpC9 nnzlnNZNwOrJP5lMDcQd60EJ26h765pxTtxXn3qC3w3d7FwLYp+CaHpM3RKmyNbU4bMU +16RwU/MoMTiDgxElE77djUUquGHZ1IJmawyRY3uxFT9ozqvngdr1PFe6qAQh/SP+Mi2 MEysZlyhXJtEZbbV7Vjfpsxoyb40xgvXlJCdi+Ov+kX9eFF/n4M0LCRJomJg315NSMhk hsVSeRDSdweSB2wjBXfugyYFUGVJtZRL88H5J/yzxQiuhiXOJvW0r5nXAXmfBHxWLhga Y6rw== X-Forwarded-Encrypted: i=1; AJvYcCWMoYYyJaivyeABfElNhdmJokWskh60ojLJ041IG+LwEvqBOxRFaiHMI7MvdXp7UdjOsM0=@dpdk.org X-Gm-Message-State: AOJu0YwyJsCCA1sKGSwLCQ9NaeEIlOfHmjO8YCX3oguDe5uRIZVHhjPC QRPFpnfuSlMIPMgfo/aeqZUVa4JzR8DOsr1DH6ZIyj70yv0JYLkI0xUUYVoQvqX0cnbUuBLUEHR w6Svx8sunmaIfqM7xvOReSP4deAzzUQzTDaA3Pg== X-Google-Smtp-Source: AGHT+IEIXRgaVDjvUkdrypPfdXCXfjUdjSVvXFaML9Uy06hXLhyzdaOQmQ3an4YHwKobQ1DPPJexTuMhZenwN1X1KhE= X-Received: by 2002:a17:90a:5ae5:b0:2ca:7f3e:a10f with SMTP id 98e67ed59e1d1-2cff93c5a19mr5099679a91.9.1722620338134; Fri, 02 Aug 2024 10:38:58 -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: Jeremy Spewock Date: Fri, 2 Aug 2024 13:38:46 -0400 Message-ID: Subject: Re: [PATCH v2 1/1] dts: add text parser for testpmd verbose output To: Nicholas Pratte 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" Content-Transfer-Encoding: quoted-printable 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 On Fri, Aug 2, 2024 at 10:54=E2=80=AFAM Nicholas Pratte wrote: > > > > 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? I like the sound of this idea a lot actually since it would remove the chance of the output just completely being thrown away. In my own test suite I managed to dance around this by strategically placing my testpmd commands, but this could save people some headache in the future. I feel like this wouldn't be something overly complicated to implement either, all we would have to do is extend the send_command method in the TestpmdShell class and check a boolean for if verbose is on, extract this output. If/how to clear this list would be something to think about, but I would say that, in general, the idea of making sure we don't lose information is something that I'm all for.