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 A138E44180; Fri, 7 Jun 2024 15:20:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5B1A340151; Fri, 7 Jun 2024 15:20:41 +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 B1E3A40150 for ; Fri, 7 Jun 2024 15:20:38 +0200 (CEST) Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2eaafda3b90so25311061fa.0 for ; Fri, 07 Jun 2024 06:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1717766438; x=1718371238; 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=AGIzCew6MJ2Qm75iSeAtguBKv/AhwSTev7ALRQADAtw=; b=S8snNOdlfHNm+eArgHPJi8NQk4pr1sLRggAAlimlqFBA8pIfqFJ5KE7DjhiDsWPmkq RrnVAgY+n87+OUtDCwU+uu1ogBc1VrNnmxq9CAnkG5vG5HOdmvKRCB6MTQnlJeeEiY8r bzJhCNB8HE55twsz4QQhS4kwoQdvGX8hC0bFBwJGfLat5+5ejNTJEljIRv1oeLotJcEN XzQ6+qRe9fJluRgyXGINaqiuqm55L4rW275neRlKICTtqvjTs/wVEk1tzQtxnTqjVwZH neZEo4IwUspefbperdMvZqs7tn4Q8TxxoaTgMAlyHC6esudvF1N7pQ4wdwN2pUPEQQJH e0rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717766438; x=1718371238; 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=AGIzCew6MJ2Qm75iSeAtguBKv/AhwSTev7ALRQADAtw=; b=fgysGVQV1rxJdHczY7jIl8YXQer6sxfs8sZaUXafU4mKD3+lJdkzUshWsmpdUO6Vu1 KkWeSv410VVuqdU3D0cOZgeSfIz/7IEa6b3BS0JUBBVcT+Fl2av0G7+WxyD86kZ93sid EF5bCPZ673mGj8WhI3vVx/e5kpyv7YIZGVb9NHSTqrDM2H3cRjlwtDOK+p485eHKbeL5 L0k/uJGfKihOFFXPc+5uYlGjQQB4pzIgRYULGs8ppp9+XwLb/OM5fb9cXVh0zXFtSSfZ AT4I7uNPZt9SeOgMlNQ4p8snvJE6CsQPjDzJcd4zyYF/lc/SjGdz9FEcGvjoDC2dFvyT KkzQ== X-Forwarded-Encrypted: i=1; AJvYcCV0GBgnA4aa1YJ9mgZj+I5CR4Lfa+SZfsrdJmI9L1P8VB73sFsAWc6JivW5k8DsxG1wD0/+Lkg1HfUye8Q= X-Gm-Message-State: AOJu0YwN26u35wu/pvQbNLo5Ba6/jNqReUgUY/3TlvgQ9pTxbxGjXwzt tOLUDAqDekA1aPxFziYRguph5lWS2edgGFc65nRgH8A3je3lVVMD3FZR0qDRg9M= X-Google-Smtp-Source: AGHT+IHzsFM3lfvNku5g/kNnzJp9xN6wYxLJZAt+2WL+WlR0OE5oBy2iRIiMRfWliZaxn+jKNl62cA== X-Received: by 2002:a05:651c:216:b0:2ea:78e2:6a5e with SMTP id 38308e7fff4ca-2eadce727dfmr16473811fa.34.1717766438188; Fri, 07 Jun 2024 06:20:38 -0700 (PDT) Received: from [192.168.1.113] ([84.245.121.236]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-57aae202341sm2739560a12.70.2024.06.07.06.20.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jun 2024 06:20:37 -0700 (PDT) Message-ID: <2657ce05-11c5-4514-b288-406e1f24ad4b@pantheon.tech> Date: Fri, 7 Jun 2024 15:20:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2] dts: skip test cases based on capabilities To: Nicholas Pratte Cc: thomas@monjalon.net, Honnappa.Nagarahalli@arm.com, jspewock@iol.unh.edu, probb@iol.unh.edu, paul.szczepanek@arm.com, Luca.Vizzarro@arm.com, dev@dpdk.org References: <20240301155416.96960-1-juraj.linkes@pantheon.tech> <20240411084829.64984-1-juraj.linkes@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: 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 On 3. 6. 2024 16:40, Nicholas Pratte wrote: > I was able to use this implementation on the in-development > jumboframes suite, setting restrictions on the required link speeds of > NICs and using this as a requirement to run all test cases. While the > framework you've developed is intuitive for true/false capabilities, > this may not be the case for other device capabilities such as link > speed, where perhaps someone might want to support a certain range of > speeds (I also acknowledge that this may be a needless feature). Would using the same decorator multiple times work? In any case, I will think about this. And also, thanks for the comments in the other thread, I'll incorporate those. > I > personally found implementing this to be a head-scratcher, and I > ultimately ended up implementing this using a lower bound link speed > instead of accepting a range of speeds. The reason for me implementing > this at all is because of some complications within old DTS's > jumboframes implementation. In old DTS, the test suite would check for > 1GB NICs within certain test cases and modify the MTU lengths because > of some inconsistent logic. You can see what I am referring to in the > link below, take a look at test_jumboframes_bigger_jumbo, if you are > interested. > > https://git.dpdk.org/tools/dts/tree/tests/TestSuite_jumboframes.py > > A solution to this problem is to set a restriction on the speed of > NICs for the test suite, but whether or not this is a viable solution > may require further discussion. This issue is its own conversation, > but I'm bringing it up in this thread since we may run into > requirements issues like this in the future, but I'm not so sure what > the rest of you guys think, or if you guys think it is a viable > concern at all. > >