>
> > diff --git a/dts/framework/testbed_model/linux_session.py
> b/dts/framework/testbed_model/linux_session.py
> > index 8cc0d09d01..b5cc0a78a9 100644
> > --- a/dts/framework/testbed_model/linux_session.py
> > +++ b/dts/framework/testbed_model/linux_session.py
> > @@ -460,3 +460,7 @@ def configure_ipv4_forwarding(self, enable: bool) ->
> None:
> >           """Overrides
> :meth:`~.os_session.OSSession.configure_ipv4_forwarding`."""
> >           state = 1 if enable else 0
> >           self.send_command(f"sysctl -w net.ipv4.ip_forward={state}",
> privileged=True)
> > +
> > +    def clean_up_vhost(self) -> None:
> > +        """Overrides :meth:`~.os_session.OSSession.clean_up_vhost`."""
> > +        self.send_command("rm -rf /tmp/vhost-net*", privileged=True)
>
> I am not particularly pleased with the idea of deleting every
> vhost-net*, just thinking in case this would disrupt any other
> application. Would there be any better way of doing this?
>
>
The command should not interfere with other vhost-net files, as I point
specifically at the /tmp/vhost-net directory when creating the socket files
for the virtual devices in this specific testsuite. This was also the
command specified in the pvp_multi_paths_vhost_single_core_perf test plan,
so I believe it wouldn't affect other virtual devices.


> > +    def _create_and_transmit(
> > +        self,
> > +        ring_format: int,
> > +        in_order: int,
> > +        buffers: int,
> > +        vectorized: int,
> > +        extra_args: TestPmdParamsDict,
> > +    ) -> None:
> > +        """Create testpmd instances with specified params and send
> traffic.
> > +
> > +        Args:
> > +            ring_format: selects the virtio queue descriptor layout.
> > +            in_order: toggles in-order packet processing.
> > +            buffers: enables mergeable rx buffers.
> > +            vectorized: enables SIMD vectorized rx/tx data paths.
> > +            extra_args: extra/generic TestPmd arguments.
> > +        """
> > +        sut_dpdk_driver =
> self._ctx.sut_node.config.ports[0].os_driver_for_dpdk
> > +        vhost_user_vdev =
> VirtualDevice("net_vhost0,iface=/tmp/vhost-net,queues=1")
> > +        virtio_user_vdev = VirtualDevice(
> > +            "net_virtio_user0,"
> > +            "mac=00:11:22:33:44:10,"
> > +            "path=/tmp/vhost-net,"
> > +            "queues=1,"
> > +            f"packed_vq={ring_format},"
> > +            f"mrg_rxbuf={buffers},"
> > +            f"in_order={in_order},"
> > +            f"vectorized={vectorized}"
> > +        )
> > +
> > +        for params in self.test_parameters:
> > +            frame_size = params["frame_size"]
> > +            num_descriptors = params["num_descriptors"]
> > +
> > +            default_args: TestPmdParamsDict = {
> > +                "tx_ring":
> TXRingParams(descriptors=int(num_descriptors)),
> > +                "rx_ring":
> RXRingParams(descriptors=int(num_descriptors)),
> > +            }
> > +
> > +            if sut_dpdk_driver == "mlx5_core":
> > +                default_args["burst"] = 64
> > +                default_args["mbcache"] = 512
> > +            elif sut_dpdk_driver == "i40e":
> > +                default_args["rx_queues"] = 1
> > +                default_args["tx_queues"] = 1
>
> This could be a problematic bit as we tried our best in the past to make
> test suites as driver-agnostic as possible. Would these undermine that
> ability? Perhaps a comment is needed here.
>

I copied this over from the single_core_forward_perf testsuite, as it was
necessary to meet the performance baseline across different drivers. The
default burst size for testpmd is 32, but Mellanox NICs typically require
burst sizes of 64 and an optimized mbuf cache of 512 as the Mellanox
NIC capabilities are higher than the other NICs. Additionally, Intel NICs
require rx_queues and tx_queues to be manually set to 1 to ensure hardware
does not distribute traffic over multiple queues, which would cause
degraded performance.

As for the other changes mentioned, I will have those in my next version as
well. Thanks!

Reply via email to