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 53D6A43D6D; Thu, 28 Mar 2024 17:48:42 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3FDBE410DD; Thu, 28 Mar 2024 17:48:42 +0100 (CET) Received: from mail-pj1-f44.google.com (mail-pj1-f44.google.com [209.85.216.44]) by mails.dpdk.org (Postfix) with ESMTP id A2BC4402D8 for ; Thu, 28 Mar 2024 17:48:40 +0100 (CET) Received: by mail-pj1-f44.google.com with SMTP id 98e67ed59e1d1-29f6f8614c8so908700a91.0 for ; Thu, 28 Mar 2024 09:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1711644520; x=1712249320; 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=tKgPEVyUV1gZ+D5abg8v2hWMNXFhP1eUeHAL8kJL6Bw=; b=GQQNKoSYvsuqdQ7m7AnnoQ1xWSBE0XlOnTRu+GRGcyEjXVLh2bJ7C12cAncO44abpu H66CPttcVCs51wqMwv2yFa1UEocrHWDxnsNGj3usu13gvRT+bwwsLbXIxLU3oEpeC0kt MDAXpBPFIRT+AvZwsrGAz1quyf77LpGlhyRbg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711644520; x=1712249320; 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=tKgPEVyUV1gZ+D5abg8v2hWMNXFhP1eUeHAL8kJL6Bw=; b=hCoqVoFbI17rM/+RBmBqEagPLEev5UsO84xCd6grXCYNTFt9/26AsQtEYgvBpCalUi IS+nlQqcckYm9OaC/TM+mC/GNih7OhGRIFa7NoinuXhq7yB5bkhivrj/Xoww99F9nlzR RT1EEJ1rPM6pdP4A3JltZGeKLKhiGjAwwpiC9yH4uRhSKESqEPY1n1pjERn4YS2kxKC0 t9inrw9ckUAqFC70oiX2bPGFmfknFgoTsbKvsiUS2jFnUNk6DSsI2u6X2SSKnGomn/U5 ilbqutkqH7AwFDHsqzGYDELs/b605/rF4Dw6xxc0Uo4oRvhYjhdXPZOGdfUGI1fcodAd k5tw== X-Gm-Message-State: AOJu0YyJTOfTZMjmPeqqFF0IquZeLwz7xfeepc1FnAU1mf6vwnEb0w/P FTfneICyPYJOqH8kcgMOPIlX6y9+bAsz0D7qz8u4UY7sC8PoeG7QVbSVGT4+Do9GaOzZ8BR6E/4 0x2PC1rFs6NrGjuiAPrRjdLLPur819zXRmTv7TA== X-Google-Smtp-Source: AGHT+IFH4pJ+hAZVTx5Ni2KsaubWSJ908kzu3oLfFrHTgWM42PcoBD3yTRAi4rrV0nVXR0jaXzZeQic7H/zweMqxM38= X-Received: by 2002:a17:90a:4408:b0:2a1:fefd:1f09 with SMTP id s8-20020a17090a440800b002a1fefd1f09mr2483285pjg.27.1711644519806; Thu, 28 Mar 2024 09:48:39 -0700 (PDT) MIME-Version: 1.0 References: <20240326190422.577028-1-luca.vizzarro@arm.com> <20240326190422.577028-3-luca.vizzarro@arm.com> In-Reply-To: <20240326190422.577028-3-luca.vizzarro@arm.com> From: Jeremy Spewock Date: Thu, 28 Mar 2024 12:48:29 -0400 Message-ID: Subject: Re: [PATCH 2/6] dts: use Params for interactive shells To: Luca Vizzarro Cc: dev@dpdk.org, =?UTF-8?Q?Juraj_Linke=C5=A1?= , Jack Bond-Preston , Honnappa Nagarahalli 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 Tue, Mar 26, 2024 at 3:04=E2=80=AFPM Luca Vizzarro wrote: > > Make it so that interactive shells accept an implementation of `Params` > for app arguments. Convert EalParameters to use `Params` instead. > > String command line parameters can still be supplied by using the > `StrParams` implementation. > > Signed-off-by: Luca Vizzarro > Reviewed-by: Jack Bond-Preston > Reviewed-by: Honnappa Nagarahalli > --- > @@ -40,7 +42,7 @@ class InteractiveShell(ABC): > _ssh_channel: Channel > _logger: DTSLogger > _timeout: float > - _app_args: str > + _app_args: Params | None > I'm not sure if allowing None should be the solution for these shells as opposed to just supplying an empty parameter object. Maybe something that could be done is the factory method in sut_node allows it to be None, but when it comes time to make the abstract shell it creates an empty one if it doesn't exist, or the init method makes this an optional parameter but creates it if it doesn't exist. I suppose this logic would have to exist somewhere because the parameters aren't always required, it's just a question of where we should put it and if we should just assume that the interactive shell class just knows how to accept some parameters and put them into the shell. I would maybe leave this as something that cannot be None and handle it outside of the shell, but I'm not sure it's something really required and I don't have a super strong opinion on it. > #: Prompt to expect at the end of output when sending a command. > #: This is often overridden by subclasses. > @@ -118,8 +119,15 @@ def _start_application(self, get_privileged_command:= Callable[[str], str] | None > Also find the number of pci addresses which were allowed on the = command line when the app > was started. > """ > - self._app_args +=3D " -i --mask-event intr_lsc" > - self.number_of_ports =3D self._app_args.count("-a ") > + from framework.testbed_model.sut_node import EalParameters > + > + assert isinstance(self._app_args, EalParameters) > + > + if isinstance(self._app_args.app_params, StrParams): > + self._app_args.app_params.value +=3D " -i --mask-event intr_= lsc" > + > + self.number_of_ports =3D len(self._app_args.ports) if self._app_= args.ports is not None else 0 I we should override the _app_args parameter in the testpmd shell to always be EalParameters instead of doing this import and assertion. It's a DPDK app, so we will always need EalParameters anyway, so we might as well put that as our typehint to start off as what we expect instead. The checking of an instance of StrParams also feels a little strange here, it might be more ideal if we could just add the parameters without this check. Maybe something we can do, just because these parameters are meant to be CLI commands anyway and will be rendered as a string, is replace the StrParams object with a method on the base Params dataclass that allows you to just add any string as a value only field. Then, we don't have to bother validating anything about the app parameters and we don't care what they are, we can just add a string to them of new parameters. I think this is something that likely also gets solved when you replace this with testpmd parameters, but it might be a good way to make the Params object more versatile in general so that people can diverge and add their own flags to it if needed. > + > super()._start_application(get_privileged_command) > > def start(self, verify: bool =3D True) -> None: > @@ -134,7 +136,7 @@ def create_interactive_shell( > shell_cls: Type[InteractiveShellType], > timeout: float, > privileged: bool, > - app_args: str, > + app_args: Params | None, This also falls in line with what I was saying before about where this logic is handled. This was made to always be a string originally because by this point it being optional was already handled by the sut_node.create_interactive_shell() and we should have some kind of value here (even if that value is an empty parameters dataclass) to pass into the application. It sort of semantically doesn't really change much, but at this point it might as well not be None, so we can simplify this type. > ) -> InteractiveShellType: > """Factory for interactive session handlers. > > +@dataclass(kw_only=3DTrue) > +class EalParameters(Params): > """The environment abstraction layer parameters. > > The string representation can be created by converting the instance = to a string. > """ > > - def __init__( > - self, > - lcore_list: LogicalCoreList, > - memory_channels: int, > - prefix: str, > - no_pci: bool, > - vdevs: list[VirtualDevice], > - ports: list[Port], > - other_eal_param: str, > - ): > - """Initialize the parameters according to inputs. > - > - Process the parameters into the format used on the command line. > + lcore_list: LogicalCoreList =3D field(metadata=3Dparams.short("l")) > + """The list of logical cores to use.""" > > - Args: > - lcore_list: The list of logical cores to use. > - memory_channels: The number of memory channels to use. > - prefix: Set the file prefix string with which to start DPDK,= e.g.: ``prefix=3D'vf'``. > - no_pci: Switch to disable PCI bus e.g.: ``no_pci=3DTrue``. > - vdevs: Virtual devices, e.g.:: > + memory_channels: int =3D field(metadata=3Dparams.short("n")) > + """The number of memory channels to use.""" > > - vdevs=3D[ > - VirtualDevice('net_ring0'), > - VirtualDevice('net_ring1') > - ] > - ports: The list of ports to allow. > - other_eal_param: user defined DPDK EAL parameters, e.g.: > - ``other_eal_param=3D'--single-file-segments'`` > - """ > - self._lcore_list =3D f"-l {lcore_list}" > - self._memory_channels =3D f"-n {memory_channels}" > - self._prefix =3D prefix > - if prefix: > - self._prefix =3D f"--file-prefix=3D{prefix}" > - self._no_pci =3D "--no-pci" if no_pci else "" > - self._vdevs =3D " ".join(f"--vdev {vdev}" for vdev in vdevs) > - self._ports =3D " ".join(f"-a {port.pci}" for port in ports) > - self._other_eal_param =3D other_eal_param > - > - def __str__(self) -> str: > - """Create the EAL string.""" > - return ( > - f"{self._lcore_list} " > - f"{self._memory_channels} " > - f"{self._prefix} " > - f"{self._no_pci} " > - f"{self._vdevs} " > - f"{self._ports} " > - f"{self._other_eal_param}" > - ) > + prefix: str =3D field(metadata=3Dparams.long("file-prefix")) > + """Set the file prefix string with which to start DPDK, e.g.: ``pref= ix=3D"vf"``.""" Just a small note on docstrings, I believe generally in DTS we use the google docstring (https://google.github.io/styleguide/pyguide.html#38-comments-and-docstring= s) format where it applies with some small differences. Because these attributes aren't class vars however, I believe they should be in the docstring for the class in the `Attributes` section. I generally have trouble remembering exactly how it should look, but Juraj documented it in `doc/guides/tools/dts.rst` > + > + no_pci: params.Option > + """Switch to disable PCI bus e.g.: ``no_pci=3DTrue``.""" > -- > 2.34.1 >