To provide a little additional context, specifically what was happening was
we paired up an Intel E810 (traffic generator) against a broadcom p2100G
(SUT) using a generic DAC cable, and then like I said in the original
commit, packets would not transmit even after the regular readiness checks
in DTS had passed (ports are reporting they are started and we have run
testpmd start and the testpmd prompt "testpmd>" had entered the output).
So, this outcome was a little confusing. I tried to throw in some
additional steps (like throw in a bring link down and up via kernel on TG
side and via testpmd on SUT side) but that didn't make a difference. I also
looked through the DTS verbose logs after having done that and saw that
testpmd was reporting link was up on the Broadcom NIC. I briefly thought
about swapping out the E810 for a second P2100G so it would be a broadcom
to broadcom connection, but I didn't have an extra on hand and if we are
going to spend money getting new hardware it should be on the newer devices
Broadcom has put out vs this model which has been out for a few years.

Anyhow, without getting into why exactly this is happening with this
specific mix of hardware, I think the important thing from my perspective
is that DTS should not be fragile to device specific behavior like this
since correctness is more important than speed. And, I don't know when this
will happen in the future with a different device. A (sort of) arbitrary
sleep isn't an ideal addition to DTS in my mind, but given that our
existing readiness checks seem correct (but may not be sufficient) this
seems like the correct action to me.

On Sun, Sep 7, 2025 at 9:48 PM Patrick Robb <probb@iol.unh.edu> wrote:

> When running our existing DTS testsuites on a new
> NIC we observed packets would not transmit from
> the traffic generator to the system under test
> even after DPDK testpmd and the NIC under test
> had indicated readiness through the existing
> readiness checks in DTS. After adding in a warm up
> sleep to DPDK shells, this issue was resolved.
> Correctness is more important than execution
> speed in DTS, so it seems justified to slow down
> the execution a little in order to make the
> testing framework less fragile to such device
> specific bringup behaviors.
>
> Signed-off-by: Patrick Robb <probb@iol.unh.edu>
> ---
>  dts/framework/remote_session/dpdk_shell.py | 9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/dts/framework/remote_session/dpdk_shell.py
> b/dts/framework/remote_session/dpdk_shell.py
> index d4aa02f39b..b0868d32fb 100644
> --- a/dts/framework/remote_session/dpdk_shell.py
> +++ b/dts/framework/remote_session/dpdk_shell.py
> @@ -6,9 +6,12 @@
>  Provides a base class to create interactive shells based on DPDK.
>  """
>
> +import time
>  from abc import ABC, abstractmethod
>  from pathlib import PurePath
>
> +from typing_extensions import Self
> +
>  from framework.context import get_ctx
>  from framework.params.eal import EalParams
>  from framework.remote_session.interactive_shell import (
> @@ -84,3 +87,9 @@ def _make_real_path(self):
>          Adds the remote DPDK build directory to the path.
>          """
>          return
> get_ctx().dpdk_build.remote_dpdk_build_dir.joinpath(self.path)
> +
> +    def __enter__(self) -> Self:
> +        """Overrides
> :meth:`~.interactive_shell.InteractiveShell.__enter__`."""
> +        super().__enter__()
> +        time.sleep(5)
> +        return self
> --
> 2.49.0
>
>