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 2FBFD45946; Mon, 9 Sep 2024 09:32:51 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E22B9402A8; Mon, 9 Sep 2024 09:32:49 +0200 (CEST) Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by mails.dpdk.org (Postfix) with ESMTP id 9141A402A5 for ; Mon, 9 Sep 2024 09:32:47 +0200 (CEST) Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-a8d24f98215so195411266b.1 for ; Mon, 09 Sep 2024 00:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1725867167; x=1726471967; 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=xbnym7lOWdg9TMCww/dp9of/oyog3GZDxpvdxGUmk8s=; b=D/6MZksNh2ydmKc8mIPb7MseUDu17S1D58N08LgFJFo+zM51JHCanMG9LFtcXdV37W Mk2d0OI+Go7/amK5NC5tlZiYZOcLDyUvsTb+ufnMivdvxEh6n0lyhHrTFRSpl45szg4J tWIXzGdogCVMW+HPQPMmveK21rdbvi6Af0XvmULSMGGx7g1X/fi83Ce12ohO5huAyZRA xhCvqYFmNtiMwhv/39+DNWJEI7jHaRgi/sBbyKiLe6ypPSqc/x5EN1J0gsCt04BM7TtP A3p5YhNnfBiqp5dAO2si8BUTx+HEjsRaRP8PIhVtDi2csJ7s9c1DkeDAanygX1/ZISnx VVxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725867167; x=1726471967; 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=xbnym7lOWdg9TMCww/dp9of/oyog3GZDxpvdxGUmk8s=; b=SCO3Sc9FcWY1yUW6+mrCd+ud7p7kjU5RIKEBH7MBClTsIbvXr6zqtK9cLGPZ/VoU3f xcdI8S2Ec7rPZVu2EEJVnpvv1AIb5r4YwQgFSENQeeQQdkCQVLzAnGWcY9yyF8jgcHC0 ANfB6AGfhNFh+GFsm+bOt/JilyYUOMtxCji1rsikeu4DM7Zqa74LtZFOx57y76pIn+Dg tCqkDxXusfqEWEYPJp6cdzbcZ097U8iORKj9mP2dC9IAx1i4gqHMvN4e5H4xTqr831Vs Ygg2Mz4mJ0boNe0AMTJF83JYNbOxU8bWzLxamVcDxL2TBQw8Zm/Oguwd9QXH6Qfly/C9 cFOA== X-Forwarded-Encrypted: i=1; AJvYcCVsJdno5CD7ycf4agfMDx9ou151uib3g+ns90dGtsi2RMwf/9RnO077bpHdEg/INgfY12c=@dpdk.org X-Gm-Message-State: AOJu0YylVg8TDg4EJuCwca7I9VQFRr6nPLeX/Tcnd9DKJ1S0QRXuBY1l TGQqiHb0QjKB1WwovNqioQxKPGBEKmDOMSKJoI6dR8DWT9/9KONWysivpSHHVDc= X-Google-Smtp-Source: AGHT+IGBuiltioxneO6QTm0QH0fLk/sbamKbWdVcIesQ3WhH6m+00SHOtNIpoEGhyeK/5BnZ8doHFg== X-Received: by 2002:a17:906:f595:b0:a8d:1655:a42c with SMTP id a640c23a62f3a-a8d24512872mr495185966b.1.1725867166965; Mon, 09 Sep 2024 00:32:46 -0700 (PDT) Received: from [192.168.200.22] ([84.245.121.62]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a8d2598b844sm298900366b.76.2024.09.09.00.32.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 09 Sep 2024 00:32:46 -0700 (PDT) Message-ID: <18d028ac-5a60-41f2-8f4d-7c9681e6e28a@pantheon.tech> Date: Mon, 9 Sep 2024 09:32:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 4/5] dts: add ability to start/stop testpmd ports To: Luca Vizzarro , 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> <6b1e1e14-41f2-4303-99bf-24d95c1ed600@arm.com> Content-Language: en-US From: =?UTF-8?Q?Juraj_Linke=C5=A1?= In-Reply-To: <6b1e1e14-41f2-4303-99bf-24d95c1ed600@arm.com> 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 6. 9. 2024 18:46, Luca Vizzarro wrote: > 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. > I agree. I was initially thinking about this from the point of view of making sure we don't change things for other users, but that doesn't apply here, as we control the whole testpmd workflow. Your approach is actually great - simple and effective. >> 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. I think the only benefit would be that we're sending less commands so it'll be a bit faster. Maybe we just make a mental note of this for the future.