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 E95EF45482; Mon, 17 Jun 2024 17:07:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D9EF1402AB; Mon, 17 Jun 2024 17:07:33 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mails.dpdk.org (Postfix) with ESMTP id D496840674 for ; Mon, 17 Jun 2024 17:07:32 +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 D830CFEC; Mon, 17 Jun 2024 08:07:56 -0700 (PDT) Received: from [10.57.73.90] (unknown [10.57.73.90]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E92D33F6A8; Mon, 17 Jun 2024 08:07:30 -0700 (PDT) Message-ID: <58d846b4-981c-4d1d-82bc-563bdd7086e2@arm.com> Date: Mon, 17 Jun 2024 16:07:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2] dts: skip test cases based on capabilities Content-Language: en-GB To: =?UTF-8?Q?Juraj_Linke=C5=A1?= , thomas@monjalon.net, Honnappa.Nagarahalli@arm.com, jspewock@iol.unh.edu, probb@iol.unh.edu, paul.szczepanek@arm.com, npratte@iol.unh.edu Cc: dev@dpdk.org References: <20240301155416.96960-1-juraj.linkes@pantheon.tech> <20240411084829.64984-1-juraj.linkes@pantheon.tech> <044253c5-eeb4-47c4-ba66-36517d3b4add@pantheon.tech> <393620de-91f6-48d1-8d9d-512222c65d93@pantheon.tech> From: Luca Vizzarro In-Reply-To: <393620de-91f6-48d1-8d9d-512222c65d93@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 12/06/2024 10:15, Juraj Linkeš wrote: > On 11. 6. 2024 11:51, Luca Vizzarro wrote: >> While working on my blocklist patch, I've just realised I forgot to >> add another comment. I think it would be ideal to make capabilities a >> generic class, and NicCapability a child of this. When collecting >> capabilities we could group these by the final class, and let this >> final class create the environment to test the support. For example: >> > > I'm trying to wrap my head around this: > 1. What do you mean group these by the final class? The ultimate child of Capability, so NicCapability. > 2. What is this addressing or improving? It renders requirements more generic than just having to do with testpmd. For example for the blocklist we could have a different kind of "capability" and we could do: @requires(TestbedCapability.min_port(2)) class TestSuite_blocklist(TestSuite): Given the specific test requires a minimum of 2 ports. Albeit redundant for DTS as we are always assuming minimum 2 ports right now, but it's an example. >>    class Capability(ABC): >>      @staticmethod >>      @abstractmethod >>      def test_environment(node, capabilities): >>        """Overridable" >> >>    class NicCapability(Capability): >>      def test_environment(node, capabilities): >>        shell = TestPmdShell(node) >>        # test capabilities against shell capabilities >> > > I'm looking at this and I don't even know what to replace with this. Replace with what? The intention of the original message was just not to rely on a very concrete "NicCapability", but provide an abstract Capability instead.