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 6EE54454A5; Wed, 19 Jun 2024 10:16:46 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EEE7A4026C; Wed, 19 Jun 2024 10:16:45 +0200 (CEST) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by mails.dpdk.org (Postfix) with ESMTP id 1D9094021D for ; Wed, 19 Jun 2024 10:16:44 +0200 (CEST) Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2ec17eb4493so77276401fa.2 for ; Wed, 19 Jun 2024 01:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1718785003; x=1719389803; darn=dpdk.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=MH+UhV/Pl8d0tD12ItjtXlDhJKQeOm+Hj8Uz1aezv5g=; b=mfPTaB23rMnfyJ/hr4hVMUAu36FqpsC/bst1llRouJ1wvQSuUHbtgYvCKPKraYC4e2 ZVbxqOD4XBcX/jwRWb2PcOAHfWHXmxDSN1SwztfEioupmCJshA/G1CWBja67rdAzNoVv 0mam7pmg9IWDbAOAST1w5xsXvpJJQ033G7VI/+pSfcCNTIfPlULX9fkY+LfsUL+KtLx6 zqMYeT41SSBGjFegMmaIKiiF3mpJPzXxSYArhuvmdbovYCh2OvVd3b6168CyTPs1aKaJ 7qCOViYIh8XtJBOSKtPBVUvTHHYjHLGVGZHi6gJxv09NAXOPegF6dqYZk/GJmP/TRvLn kynQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718785003; x=1719389803; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MH+UhV/Pl8d0tD12ItjtXlDhJKQeOm+Hj8Uz1aezv5g=; b=kVd8sT5yJ0jIPxNVX+CGy0uG0667F7k4qlr4mVHNZmlxOK8aUwe+IYh+jXutIqN71g RQt0Au/9zkrJjL7UOeBXcegAtq/THq19xokZn1a7zvXFUqjpf6Jb4eLipXtmuiofqzaU diFfp0HA6dd9oNUmscOQf3WqkW6h9V5fH/DAGuZrxLqLcTjFFC4apN7m3TuSnqi3UetA yb8g5QBTA10Q/g//3+QiYt5Pgk8lzK6oHyVBxY2s9VJyfZta4BGOXX9C5d8MnJsVHXPS lV/GeH1R9wt7Tda1FkuBP3ckBGWBz2tjxboiguGH3X6l9o6/y9BPVR8kimOB1f/4DCLh vGhA== X-Gm-Message-State: AOJu0YxqYub3CU+CZ2hMxscKmH0deAplcL5QaV5FBlt9cUdq+9BFCs9M 92nWi2f3hRGfebZrGZaPDIhWD2TH6748pRiKstEIhM8xjgFW/6SdAswROseCzEc= X-Google-Smtp-Source: AGHT+IGuyfG4rZVX8qDy/j08MAhWquVvto34lhHqofKA+Hjn6a5OrEHS2y3h4roocDYTg4sDFeDHFQ== X-Received: by 2002:a05:6512:124a:b0:52c:ab21:7c05 with SMTP id 2adb3069b0e04-52ccaa599b7mr1610734e87.67.1718785003531; Wed, 19 Jun 2024 01:16:43 -0700 (PDT) Received: from [192.168.1.113] ([84.245.121.236]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6f56db5bbcsm647976066b.82.2024.06.19.01.16.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jun 2024 01:16:43 -0700 (PDT) Message-ID: Date: Wed, 19 Jun 2024 10:16:41 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/4] dts: add methods for modifying MTU to testpmd shell To: jspewock@iol.unh.edu, 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 Cc: dev@dpdk.org References: <20240514201436.2496-1-jspewock@iol.unh.edu> <20240613181510.30135-1-jspewock@iol.unh.edu> <20240613181510.30135-4-jspewock@iol.unh.edu> Content-Language: en-US From: =?UTF-8?Q?Juraj_Linke=C5=A1?= In-Reply-To: <20240613181510.30135-4-jspewock@iol.unh.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > +def stop_then_start_port_decorator( The name shouldn't contain "decorator". Just the docstring should mention it's a decorator. > + 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)? 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.". > +) -> Callable[["TestPmdShell", int, Any, bool], None]: > + """Decorator that stops a port, runs decorated function, then starts the port. > + > + The function being decorated must be a method defined in :class:`TestPmdShell` that takes a > + port ID (as an int) as its first parameter and has a "verify" parameter (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 stopped/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). > + > + Returns: > + Wrapper function that stops a port, runs the decorated function, then starts the port. This would be the function that's already been wrapped, right? > + def _start_port(self, port_id: int, verify: bool = True) -> None: > + """Start port `port_id` in testpmd. with `port_id` > + > + Because the port may need to be stopped to make some configuration changes, it naturally > + follows that it will need to be started again once those changes have been made. > + > + Args: > + port_id: ID of the port to start. > + verify: If :data:`True` the output will be scanned in an attempt 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).