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 59F23454B7; Fri, 21 Jun 2024 10:08:22 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 332C4402F1; Fri, 21 Jun 2024 10:08:22 +0200 (CEST) Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) by mails.dpdk.org (Postfix) with ESMTP id 5E6E54026A for ; Fri, 21 Jun 2024 10:08:20 +0200 (CEST) Received: by mail-lj1-f171.google.com with SMTP id 38308e7fff4ca-2eaea28868dso22460941fa.3 for ; Fri, 21 Jun 2024 01:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1718957300; x=1719562100; 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=VQe/ppU+h/m0n/Cnt/0VKKOXypE3oMjNb29JavA54xU=; b=F1NqjE+ezgwFfMfZyCnIuFdiMU2LqaBNXc1SCnpJ7M8Q6o7NzAOOKYYqIklv9B1wmb tBMAkVfRgSrpD65dBa/U6aoVAV3A8u3w9KXOMo7nLTeeopLnD1hCpkMBzkKYOHlgwWFI t8LCC0W6vhfXiGxMSJPYQeEFxclXHUr45iPo0jN2rwLV5t57gMiPm43KEstaTaSLojKI qxKK0EOWG7vBJ9/0vKLo3J41JOs0R3LyNzYVvwHELuaJNGpwM9zh2sF2Mu4N9dCLKD7Z O/rNkuplvPU2gKzW2AT9TJnrEA1B8N9+Gxbr71mN5zn0MhUt6pLd7QMq7jqc8a5vR5F5 wn6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718957300; x=1719562100; 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=VQe/ppU+h/m0n/Cnt/0VKKOXypE3oMjNb29JavA54xU=; b=IW6LwD2svO/M3LCIc7Ej8TkJ2CMsrKI5FYm3ogbdF3MnBvBk9D5dJGSlavKQEjSxu8 Z0x24ZygLSmLAG8ZzX13sgj7YbLQZgtEGlY+ebKqecdaRyFSQrPE7Jw8ADD5TTS0CVm1 WoyKeCsn9XbsZkrjmP5ZKrmwSmg3ZU2NBYFibpShEmsTmYtejdQbAYO2JjPmYKF2w3PX 5WOSe5X0tyeUkQa+LeJ+upd7V9m/mxORdGc9b6HYHKIgorJ5Em/zchfp+AoqmduJtCD+ lW9yVIh6DFxO1RUKtdGdkgOAcFvADLPvzSFZk4FQ2pISJwwhgPpCW6N36RWlX3lWdunW MXTg== X-Forwarded-Encrypted: i=1; AJvYcCWDa2hcTUlCSmWv4dAAux2us3y8Ntvr87D23oxMpIieIL+xTNnR1vM9kLF5m32bNIQDZ6zs/UVRjYg4tOc= X-Gm-Message-State: AOJu0Yyeaej1G+yn/gSGBZf+IyD7rD4yikCDm8UM0771JhOhUKPIETym EV+RVCreObaf+XBH0QZuLnSR82lc0irHqFzxCD2soqM8ci1nzre1YNZSvPq8Nic= X-Google-Smtp-Source: AGHT+IHiAT4ZNPG9lx/UnO1VFp7YahxMyKdGRgkTeZcxVqFztGKyIZHOjPkukAi2sWPpwkPn6mNrvg== X-Received: by 2002:a2e:9eda:0:b0:2ec:2038:925d with SMTP id 38308e7fff4ca-2ec3cea4887mr54877811fa.1.1718957299676; Fri, 21 Jun 2024 01:08:19 -0700 (PDT) Received: from [192.168.1.113] ([84.245.121.236]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6fcf56c554sm55039566b.194.2024.06.21.01.08.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Jun 2024 01:08:19 -0700 (PDT) Message-ID: <8601d9a1-3ba8-4b7c-ac38-d8e5019d2847@pantheon.tech> Date: Fri, 21 Jun 2024 10:08:17 +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: Jeremy Spewock 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 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: 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 >>> + 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. > One more thing I've thought of which could be the best of both world is to add the optional verify parameter to the decorator itself. That way we could disable verification independently of whether the decorated function does verification if need be. And the decorator would be less coupled with the functions.