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 D860444120; Fri, 31 May 2024 23:08:16 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C554942DCB; Fri, 31 May 2024 23:08:16 +0200 (CEST) Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) by mails.dpdk.org (Postfix) with ESMTP id 3DDDE42D8C for ; Fri, 31 May 2024 23:08:04 +0200 (CEST) Received: by mail-pg1-f175.google.com with SMTP id 41be03b00d2f7-681953ad4f2so1789158a12.2 for ; Fri, 31 May 2024 14:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1717189683; x=1717794483; 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=gAWyaESvBB/HSMr6UbTA4/eLXjTijuvkHFYk/6lvDxY=; b=O33+dZK4jjJO0Yz5qdWpJCmQyeOdA+ohahwoHwa7TplUYtaQrLGQwGnx75l2GFozsZ qzyBYjGlyJkuNmJT0YncgMRKMw6fk9Xds3VhBF5qX678eyVVdFF+XMVHVoabaN9l65rx 3EBMSqsM7rkG8KSH0inQeZBfyKmKemMoaesAs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717189683; x=1717794483; 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=gAWyaESvBB/HSMr6UbTA4/eLXjTijuvkHFYk/6lvDxY=; b=QzWuMrJdANaSskeUrhzRdmoz8pY9i3sFbbop9tgrAy6H471PKPrbD1BmRUObIeR3WX 4bOGL3dmUXij2cBV2zTMqXv5UZFBO+Hpa1AUPpefggMxAl5CTg3rrkf0PGVayWPqRKRc 3vJx4ukBCCl2VuZyXrK61JYj5x9Ky7Y19ZCyb9MMpCQuvMmhsEjCc5jA5QhPh//i4AVQ IWXOYOSbcDU4SFU9VeCYq//ZGSMP1chK1I5UUXYK2/0idptr4+4N5Gaf20dBRe7Em/r+ pQQ+000EVJA+LUF4AfbaBP77sFvU4gNoKfxdxXO50IY/ZlbPXMod+Sy3mECNejq4T1ju Mb3g== X-Forwarded-Encrypted: i=1; AJvYcCXWtgWmh5troTUsEhx1IvwP9/lBO04NZZb7fka9rurCYJXfYb2scL0fOe4KWZ/OHkyEO+UiFITyP6assvU= X-Gm-Message-State: AOJu0YzVfxQl9jS8Acz+TWo8NzkN9MAepZQtyEJ9nTrrYHZuvjhFSXA8 AfG3mUhXyuXbQkq+kP1r5JVdHM7sVq64i2y1OxmlpB9zZtvyWzgKKZV/g20McH4w3LbFQYpfj77 H1VUrnxXyY79AXcX3l6X8gs10urE0UUG6ThKzNw== X-Google-Smtp-Source: AGHT+IHKInDHNm+RlgNdUFkqDaspy5yCjiUZ/C6QrAPKpqIEI6yfCnmByJ4p/JdCLWnW8pPiZtZol2a6/gZZMnd8xBA= X-Received: by 2002:a17:90a:bf07:b0:2bd:e639:686c with SMTP id 98e67ed59e1d1-2c1dc58fa20mr3251624a91.23.1717189683337; Fri, 31 May 2024 14:08:03 -0700 (PDT) MIME-Version: 1.0 References: <20240514201436.2496-1-jspewock@iol.unh.edu> <20240530163339.14566-1-jspewock@iol.unh.edu> <20240530163339.14566-2-jspewock@iol.unh.edu> In-Reply-To: From: Jeremy Spewock Date: Fri, 31 May 2024 17:07:52 -0400 Message-ID: Subject: Re: [PATCH v2 1/4] dts: improve starting and stopping interactive shells To: Luca Vizzarro Cc: juraj.linkes@pantheon.tech, paul.szczepanek@arm.com, wathsala.vithanage@arm.com, Honnappa.Nagarahalli@arm.com, probb@iol.unh.edu, yoan.picchi@foss.arm.com, npratte@iol.unh.edu, thomas@monjalon.net, 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, May 31, 2024 at 12:37=E2=80=AFPM Luca Vizzarro wrote: > > On 30/05/2024 17:33, jspewock@iol.unh.edu wrote: > > @@ -93,17 +102,39 @@ def __init__( > > def _start_application(self, get_privileged_command: Callable[[st= r], str] | None) -> None: > > """Starts a new interactive application based on the path to = the app. > > > > - This method is often overridden by subclasses as their process= for > > - starting may look different. > > + This method is often overridden by subclasses as their process= for starting may look > > + different. Initialization of the shell on the host can be retr= ied up to 5 times. This is > > + done because some DPDK applications need slightly more time af= ter exiting their script to > > + clean up EAL before others can start. > > + > > + When the application is started we also bind a class for final= ization to this instance of > > + the shell to ensure proper cleanup of the application. > > > > Args: > > get_privileged_command: A function (but could be any call= able) that produces > > the version of the command with elevated privileges. > > """ > > + self._finalizer =3D weakref.finalize(self, self._close) > > + max_retries =3D 5 > > + self._ssh_channel.settimeout(1) > > This timeout being too short is causing the testpmd shell (which is > still loading in my case) to be spammed with testpmd instantiation > commands. Unfortunately causing the next commands to fail too, as the > testpmd shell has received a lot of garbage. > > 5 seconds of timeout seemed to have worked just fine in my case. Ack. It's hard to gauge exactly how long this timeout should be since it will be different between every system (and between different NICs on the same system) but I think 5 seconds should be a reasonable amount of time for testpmd to start in most cases. The only blanket way I could see to fix this would be to just clean out the buffer before sending every command so that the previous command outputting harmless clutter in the buffer doesn't cause every future command sent into that shell to also break. This idea would likely slow things down however and doesn't fit the scope of this patch regardless. > > > start_command =3D f"{self.path} {self._app_args}" > > if get_privileged_command is not None: > > start_command =3D get_privileged_command(start_command) >