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 4453E45920; Fri, 6 Sep 2024 18:46:47 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BD1DF42EB0; Fri, 6 Sep 2024 18:46:46 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mails.dpdk.org (Postfix) with ESMTP id 94E5E42E82 for ; Fri, 6 Sep 2024 18:46:45 +0200 (CEST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 42F23FEC; Fri, 6 Sep 2024 09:47:12 -0700 (PDT) Received: from [10.57.17.223] (unknown [10.57.17.223]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 342653F73B; Fri, 6 Sep 2024 09:46:44 -0700 (PDT) Message-ID: <6b1e1e14-41f2-4303-99bf-24d95c1ed600@arm.com> Date: Fri, 6 Sep 2024 17:46:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/5] dts: add ability to start/stop testpmd ports Content-Language: en-GB To: =?UTF-8?Q?Juraj_Linke=C5=A1?= , dev@dpdk.org Cc: Jeremy Spewock , Honnappa Nagarahalli , Paul Szczepanek References: <20240806121417.2567708-1-Luca.Vizzarro@arm.com> <20240806124642.2580828-1-luca.vizzarro@arm.com> <20240806124642.2580828-5-luca.vizzarro@arm.com> <89d39e22-ca0a-43a9-bc42-6c833a7cd8e4@pantheon.tech> From: Luca Vizzarro In-Reply-To: <89d39e22-ca0a-43a9-bc42-6c833a7cd8e4@pantheon.tech> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 23/08/2024 13:16, Juraj Linkeš wrote: > As Jeremy mentioned, adding the verify argument may be worthwhile, but > maybe only if we actually identify a usecase where we wouldn't want to > do the verification. Yeah, as I pointed out, it feels unlikely to pretend that they are started (or stopped). I think that could cause my unpredicted behaviour and confusion. But also as said already, it can always be added on demand. > I also have two other points: > 1. Do we want a decorator that does both - starting and stopping? Is the > idea to have all methods that require a certain state to be decorated > and in that case we don't need this? E.g. if there are multiple > configuration steps, only the first one stops the ports (if started) and > we start the ports only when a method needs that (such as starting pkt > fwd)? I think this workflow should be documented in the class docstring > (the important part being that starting and stopping of ports is done > automatically). The way I envisioned these decorators is by using a lazy approach. I don't think it may be right to eagerly restart ports after stopping them, because maybe we want to run another command after that will stop them again. So only start and stop as needed. Ideally every port that requires a specific state of the ports need to be decorated. I went through all the methods in the class to check which would and which wouldn't, and it seems alright like this. > 2. Do we want decorators that start/stop just one port? I guess this is > basically useless with the above workflow. Would it actually matter? We are not really using the other ports in parallel here I believe. May bring unnecessary complexity. I am thinking that maybe if needed it could be added later.