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 D9BF2424C3; Wed, 12 Jun 2024 11:15:37 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7495D40395; Wed, 12 Jun 2024 11:15:37 +0200 (CEST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by mails.dpdk.org (Postfix) with ESMTP id 93377402AB for ; Wed, 12 Jun 2024 11:15:36 +0200 (CEST) Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2ebdfe26226so19951191fa.1 for ; Wed, 12 Jun 2024 02:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1718183736; x=1718788536; 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=JLXq1Xl94Os7C9nEJUuzzLHRCcYSZaC3YXszAA4AVe8=; b=celvPX5H2mnd8GGza2MVrZXRNWMyHQL77BvkpGH5r9Hl1zb5T7cbomuRl2we+V/gon 5Vk7JGjn9Wd1XWUTPvRW6SYPMyfLKm6AxpL9xXSrVHY9JplGus69KFcH8f2kc46pj3Qg OJAyagLEGKhRlRfwoLpGNp4sfRWRD/5TQmqmvK7/mdnP4ekhzuxJtb7wnHK+3lJgwAZW 2MS5cO6J8VLkMeDNJZ3D7luccxECR1yW+mx3t7MUDU3sZKNsQE2uNLjsymlRNLmNakMJ bXEX/mcAeBTFkf7ajFg7gojycNWTwq4sKmj1+0ZKkBNHKG3bpYzy2KJwJU9WiLulJdQQ YZpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718183736; x=1718788536; 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=JLXq1Xl94Os7C9nEJUuzzLHRCcYSZaC3YXszAA4AVe8=; b=hwevTb/1xujr2mSoIRD7xhOkiWDyT0zEWCo6zvSEaDaQ4DXMu8Kt/O7YJr4/HRyZ0f l5ic5Skil8jrpPIXMsj5cX/5UdA9PQqN3AmraOzxsBoAWD5a6cu1lr2/SMILj+LU1YKa K9ms4nR9wA+QSKUGeRzMgWBN3QsDKDEhS6hqJhWlv68thGUq/Av31wOAAhW81F0SjB0Y V/+p8QMI9QKQHG9ax7UE0uXoQrhy1qYu7u93vwcjhoHTZ542zeS3b847IFoyxZTPGVyD BRkmq+NHHrZAgqijeXgh4gATfGs9/GYmnp8ZHN/EKqmmvOfTl6E7L98onyn+uH9ZFcCB mxhw== X-Gm-Message-State: AOJu0YzKgo+lb4cAGM4t98E1lLLTPlxo3OMVeTx29t3soz4EUqWDA780 Mm30PBYZEg67WbQUjJxy7fgBogcSdAZqkYxknJMDKQ1qt/WRaEYrEbNVehO44B8= X-Google-Smtp-Source: AGHT+IGlEk7w3p30DQnoJBYY4mEVQFL0aCTuUh77mGuDxbjEX3oHtFe3DBcSEQH37S5ZdQlJcaUxcA== X-Received: by 2002:a2e:979a:0:b0:2ea:e9f9:6ac2 with SMTP id 38308e7fff4ca-2ebfc8ab317mr9313491fa.8.1718183735781; Wed, 12 Jun 2024 02:15:35 -0700 (PDT) Received: from [192.168.1.113] ([84.245.121.236]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42286fe9230sm18096265e9.17.2024.06.12.02.15.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jun 2024 02:15:35 -0700 (PDT) Message-ID: <393620de-91f6-48d1-8d9d-512222c65d93@pantheon.tech> Date: Wed, 12 Jun 2024 11:15:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2] dts: skip test cases based on capabilities To: Luca Vizzarro , 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> 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: 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 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? 2. What is this addressing or improving? >   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. > Another thing that I don't remember if I pointed out, please let's use > complete names: required_capabilities instead of req_capas. I kept > forgetting what it meant. req commonly could mean "request". If you want > to use a widely used short version for capability, that's "cap", > although in a completely different context/meaning (hardware capabilities). > No problem. > On 07/06/2024 14:13, Juraj Linkeš wrote: > >>> -    def get_capas_rxq( >>> -        self, supported_capabilities: MutableSet, >>> unsupported_capabilities: MutableSet >>> -    ) -> None: >>> +    # the built-in `set` is a mutable set. Is there an advantage to >>> using MutableSet? >> >>  From what I can tell, it's best practice to be as broad as possible >> with input types. set is just one class, MutableSet could be any class >> that's a mutable set. > > Oh, yes! Great thinking. Didn't consider the usage of custom set > classes. Although, not sure if it'll ever be needed. > >>>           command = "show rxq info 0 0" >>>           rxq_info = self.send_command(command) >>>           for line in rxq_info.split("\n"): >>> @@ -270,4 +269,6 @@ class NicCapability(Enum): >>>       `unsupported_capabilities` based on their support. >>>       """ >>> >>> +    # partial is just a high-order function that pre-fills the >>> arguments... but we have no arguments >>> +    # here? Was this intentional? >> >> It's necessary because of the interaction between Enums and functions. >> Without partial, accessing NicCapability.scattered_rx returns the >> function instead of the enum. > > Oh interesting. Tested now and I see that it's not making it an enum > entry when done this way. I wonder why is this.