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 B88794584D; Fri, 23 Aug 2024 14:16:56 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 446DB432FC; Fri, 23 Aug 2024 14:16:56 +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 1475C432F6 for ; Fri, 23 Aug 2024 14:16:55 +0200 (CEST) Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2ef2d96164aso17635081fa.3 for ; Fri, 23 Aug 2024 05:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1724415414; x=1725020214; 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=pF9sjEDlbVfSsKbzwjghyR7XdRlzFAAKwIY+V9HOs4Y=; b=O8MGnD1SB11X6WLeA3UL6B6mZcTNhfcEpmLp5y9/lpKXBpRhTshW1gO3lr6R3b7lZT Wpvpuu2w1YAVk7PlpFjiGOARqiCrRBYZsiJ6bi1QCww2NWw/0f+ZNCI46C7heuOUGTBw qUY4p46y7P6L0pyP0ofU1Zbyn1T7GVtsN1JIN+JwQMmWL6xB9xejQ8SmR5wemnCho96s FVmMs+uSnKT6K4xoeupW2d7mfGaVi2TP0w305XPhQBD2KxwI64f+hYT0qE4oTO+PzYCH PK8e1wrXjlWqlXmXx0EZhDa4g6Ba1z8AWcS4EPciWoIBrP85zPbNBuoAeA+15dJp7RWz RDSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724415414; x=1725020214; 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=pF9sjEDlbVfSsKbzwjghyR7XdRlzFAAKwIY+V9HOs4Y=; b=G8epdZzqAwYdXsr39crImDNiwlRBgXsarBqww8cUyRxmLc5T0DOnUjjFadUesbAyk2 tbZecYGIJhIzhtc5bwqCGVA4nVppW/9tTqK5YQKnP48pxZ3j52Z3MsK40nzQK2vpkjqu CaMWseDPcQOuO30Wgwm6srNDzQJebgmiuZvqk6xuFE/8JLYZTRPDq0a76vDL97TRkDiP 82+iSseDH95PoUGw3bA0H2MhFaHCUg1VgB5s9Onsf3IkWbwTbMyQDf6Ga1gv/zDWiTmL UKPxMwa5PHZBrUoDqcOrN41Kf3B+79jUBqonGqbXusF59fLj7MqZHl28K0QPVP6m+4eI ZcnA== X-Forwarded-Encrypted: i=1; AJvYcCWX4UaK2Zdt1SlWdx4KVl7jnn7s3/Y/RVjlD/NXxZ/oWMopS+XbCD0Xsspw2GmbKbJYgkU=@dpdk.org X-Gm-Message-State: AOJu0Yxr9bTZrViLgg9UxLJXq7i/lpqQTnL5uAsDRWCpDUMXYPsLbF+u qvRk+OluHjw5rLODAwGQEmO50ReNZtHjzCwGSATW0rkfUKIgO8/gJKEPvcaYT1Q= X-Google-Smtp-Source: AGHT+IGOr+3wPtgdrkQCQkzqCmGipn8QHvL9anEm/XBj8BNZTncVsospo7Ucfkp6fdCAGJWoxZs2pw== X-Received: by 2002:a05:6512:1250:b0:52c:d80e:55a5 with SMTP id 2adb3069b0e04-5343886113amr1540156e87.41.1724415414030; Fri, 23 Aug 2024 05:16:54 -0700 (PDT) Received: from [192.168.200.22] ([84.245.121.107]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a868f4f62f1sm252317766b.218.2024.08.23.05.16.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Aug 2024 05:16:53 -0700 (PDT) Message-ID: <89d39e22-ca0a-43a9-bc42-6c833a7cd8e4@pantheon.tech> Date: Fri, 23 Aug 2024 14:16:52 +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> Content-Language: en-US From: =?UTF-8?Q?Juraj_Linke=C5=A1?= In-Reply-To: <20240806124642.2580828-5-luca.vizzarro@arm.com> 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 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. 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). 2. Do we want decorators that start/stop just one port? I guess this is basically useless with the above workflow.