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 0C185454AE; Thu, 20 Jun 2024 21:24:09 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C70F040612; Thu, 20 Jun 2024 21:24:08 +0200 (CEST) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by mails.dpdk.org (Postfix) with ESMTP id 790A8402E2 for ; Thu, 20 Jun 2024 21:24:07 +0200 (CEST) Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-2c70c372755so1085816a91.1 for ; Thu, 20 Jun 2024 12:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1718911446; x=1719516246; 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=Ru1IB0s2v2JuvrdcmSbdu9VGWEMX1ziA//1+B+cxdo0=; b=P+feiKAfr0wskWRj/+oYMa1iQr3nIV2rlH0aTiaB78/QKWK3hrS73D6HZsMRLTxASA 6ibuXYxfvZRt4c0phzN6Y6GJ1FeXuBdeD58rgEelmcgTP4alykyNcuHq81lXpgOgOTSu gxh+F3JXRu1hoHdFvWy9CKsUHC6A0O40SVxgw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718911446; x=1719516246; 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=Ru1IB0s2v2JuvrdcmSbdu9VGWEMX1ziA//1+B+cxdo0=; b=c7zq4s5QdZeM0+qx8MpRWdAp/IxTi1Pz3BpGgucJpZweyArmOyiew0fjxUMg+h5hG+ +zSIy+/AD8tLqZd9TsgWJ7JPp6ci3OUiU8XsROa6IjSM/Hz63TDlnrJWeTxG71P+zCJ/ TmjFv1hm0SzMQn3uvWQzy349v9VTtKg7xCMIY3Rbv9qOA1KzY5df4ReS8dwCIWQFZKOv TBGfdcKdhhvguVDvIae/Dlw6vhZHhFV2nLV1NuUv7NcOZAxr4eYo1gkiozO+7pU3MugB SFsFJhMcfTxiRZQ3yAwh8KBAXeqVFON4Q03QLwF90iwUZ35jV9RkmbxCtNnn/82L6Wjy I3Mg== X-Forwarded-Encrypted: i=1; AJvYcCUoSbGUWVPS3VHWufra7JkuNMFo4JMk2GuZMeheZkOC7y/QnkBAR9Q39gfdZzmM3P42wXef1EOAYj4rIWI= X-Gm-Message-State: AOJu0YwnflrX6jSoVmS+kSWgl22wjl7fhscC7cbRx+MVVzzy4ZBoOCxq AyEFnj6fBGSS/q3GCYoZzcAmPE9Tkh9zKB8kWoJqij/dfyKrU4bAi82GyHUaHnbjajJjADbBo21 Zel9pqsHhM0RrYbxZ6wwZs69fOpGXuYh3naXdXA== X-Google-Smtp-Source: AGHT+IG1r9fm3dSwpygrKIUwspOALrEp/j0CiNvyyEYkVWXcc3CxjlQPfUVplle/AkJqwBv0vDWy9OdlQNWUgnOHrgc= X-Received: by 2002:a17:90a:e001:b0:2c4:a9b8:2f2e with SMTP id 98e67ed59e1d1-2c7b5aff049mr6712637a91.20.1718911446370; Thu, 20 Jun 2024 12:24:06 -0700 (PDT) MIME-Version: 1.0 References: <20240514201436.2496-1-jspewock@iol.unh.edu> <20240613181510.30135-1-jspewock@iol.unh.edu> <20240613181510.30135-4-jspewock@iol.unh.edu> In-Reply-To: From: Jeremy Spewock Date: Thu, 20 Jun 2024 15:23:54 -0400 Message-ID: Subject: Re: [PATCH v4 3/4] dts: add methods for modifying MTU to testpmd shell To: =?UTF-8?Q?Juraj_Linke=C5=A1?= Cc: probb@iol.unh.edu, yoan.picchi@foss.arm.com, npratte@iol.unh.edu, Honnappa.Nagarahalli@arm.com, wathsala.vithanage@arm.com, paul.szczepanek@arm.com, Luca.Vizzarro@arm.com, 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 Wed, Jun 19, 2024 at 4:16=E2=80=AFAM Juraj Linke=C5=A1 wrote: > > > > +def stop_then_start_port_decorator( > > The name shouldn't contain "decorator". Just the docstring should > mention it's a decorator. Ack. > > > + func: Callable[["TestPmdShell", int, Any, bool], None] > > I'm thinking about this type. Sounds like there are too many conditions > that need to be satisfied. The problem is with the verify parameter. Do > we actually need it? If we're decorating a function, that may imply we > always want to verify the port stop/start. In which circumstance we > wouldn't want to verify that (the decorated function would need to not > verify what it's doing, but what function would that be and would we > actually want to not verify the port stop/start even then)? I agree the parameter requirements are a little clunky and I played with them for a while, but this one seemed the most "correct" to me. We could create a policy that any method that is decorated with this function must verify the port stopping and starting worked, but if we did that I think you would have to also add to the policy that the method being decorated must also always verify it was successful. I don't think it makes sense to call a function and specify that you don't want to verify success, and then still verify some component of what the function is doing (starting and stopping ports in this case). I think it would be fine to have this as a policy, but it's slightly more limiting for users than other methods that testpmd shell offers. I don't really know of an example when you wouldn't want to verify any of the methods in TestpmdShell other than in case the developer is expecting it to fail or it might not matter to the test if it was successful or not for some reason. Considering we are already following the path of optionally verifying all methods that can be verified in the testpmd shell anyway, I didn't see the verify boolean as anything extra for the methods to really have. We could instead change to always verifying everything, but a change like that probably doesn't fit the scope of this patch. > > The requirement of port_id is fine, as this only work with ports (so > port_id must be somewhere among the parameters) and it being the first > is also fine, but we should document it. A good place seems to be the > class docstring, somewhere around "If there isn't one that satisfies a > need, it should be added.". That's a good point, I'll add some more notes about it. > > > +) -> Callable[["TestPmdShell", int, Any, bool], None]: > > + """Decorator that stops a port, runs decorated function, then star= ts the port. > > + > > + The function being decorated must be a method defined in :class:`T= estPmdShell` that takes a > > + port ID (as an int) as its first parameter and has a "verify" para= meter (as a bool) as its last > > + parameter. The port ID and verify parameters will be passed into > > + :meth:`TestPmdShell._stop_port` so that the correct port is stoppe= d/started and verification > > + takes place if desired. > > + > > + Args: > > + func: The function to run while the port is stopped. > > The description of required argument should probably be here (maybe just > here, but could also be above). Ack. > > > + > > + Returns: > > + Wrapper function that stops a port, runs the decorated functio= n, then starts the port. > > This would be the function that's already been wrapped, right? I was trying to convey that this returns the function that wraps the decorated function so I called it the "wrapper function", but maybe my wording was a little confusing. > > > > + def _start_port(self, port_id: int, verify: bool =3D True) -> None= : > > + """Start port `port_id` in testpmd. > > with `port_id` Ack. > > > + > > + Because the port may need to be stopped to make some configura= tion changes, it naturally > > + follows that it will need to be started again once those chang= es have been made. > > + > > + Args: > > + port_id: ID of the port to start. > > + verify: If :data:`True` the output will be scanned in an a= ttempt to verify that the > > + port came back up without error. Defaults to True. > > The second True is not marked as :data: (also in the other method). > A note on docstrings of private members: we don't need to be as detailed > as these are not rendered. We should still provide some docs if those > would be helpful for developers (but don't need to document everything > for people using the API). Right, I noticed that in some places they were less formal than others and figured it was because they were private. I was sticking with the general API layout regardless just as I felt it would be better to have more information than necessary rather than less, but I'll keep this in mind and not include some of the more redundant things like the args in this case. >