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 B0B48431BB; Fri, 20 Oct 2023 17:02:20 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A0AF440A7F; Fri, 20 Oct 2023 17:02:20 +0200 (CEST) Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) by mails.dpdk.org (Postfix) with ESMTP id 7038440A6C for ; Fri, 20 Oct 2023 17:02:19 +0200 (CEST) Received: by mail-oo1-f49.google.com with SMTP id 006d021491bc7-581f78a0206so478997eaf.2 for ; Fri, 20 Oct 2023 08:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1697814138; x=1698418938; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QjVopCHo6ogALpoFQrl8U/rmYbapH8JZUhd7LNKJ6ZM=; b=bm2onMUMYy6tgQQjyyrF8IDRKsvOmwT0ZhKkse0N26JP0nL/rQ/f36zAYQCTu3O7+y 2aSHIrgdRDnl5SsASmev2M4C3WNAlMtif59f3i/scCL1tpLN3MrgLNJsQibRzZxYC/KV ce4nsngLTNMorQm/n1lGA8hWF1C+iUgDLs6eA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697814138; x=1698418938; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QjVopCHo6ogALpoFQrl8U/rmYbapH8JZUhd7LNKJ6ZM=; b=GG3h+kplvTQ/wLT2dTX6QnxsaM9htgdVulixxdZlnc+dA0gMdWFlVF9eJNY98GY4Ne sAR+O/+yPWd+v03C2p3J4oabDmXcJEDptd72hBa9hgl06ZF6Jp5fQpLTkUATr9PRXWpP Qtopxq7PismGcSaJkBZNCiiO2L4lrPIcLeRhk2bSEq0e5eZTsJWbwGXJVIqpaaSLnXO9 622Gx2FughR/NjeyH2BrtnA3lUYJ3vm1+1Gib/66E8QbAI7Y8l/wwS941QbsZuADSMe7 cJwKs9CWxCy/2/wNKKAz0mmyqvCOSGPN3vgqXOPMPvNE+l6kwt5+rroP4V6tEmfg2gtM qe8w== X-Gm-Message-State: AOJu0YzHYbtEYQkv/xsG3S7c3BL/0CRBGlRyw222daWoGIFtRoO/Qj3b q1XOU9hQf2wXozNNqDKWIH7FafennqyIVBmTPu8G9w== X-Google-Smtp-Source: AGHT+IEOjStzt49464inwd9n7PY890+lZdkfgybB91lHgcnXMArzhK0qMF/Ng8+ZMUg+8SpDuQLq9T3buFPLt4FXuzY= X-Received: by 2002:a4a:b789:0:b0:581:df34:15c with SMTP id a9-20020a4ab789000000b00581df34015cmr2222334oop.5.1697814138596; Fri, 20 Oct 2023 08:02:18 -0700 (PDT) MIME-Version: 1.0 References: <20230817105851.501947-1-bruce.richardson@intel.com> <20230914151636.278641-1-bruce.richardson@intel.com> In-Reply-To: From: Patrick Robb Date: Fri, 20 Oct 2023 11:02:07 -0400 Message-ID: Subject: Re: [PATCH v4] app/test: add support for skipping tests To: Aaron Conole Cc: David Marchand , Bruce Richardson , dev@dpdk.org, Thomas Monjalon , Kevin Traynor , Lincoln Lavoie Content-Type: multipart/alternative; boundary="000000000000a04ca9060827281e" 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 --000000000000a04ca9060827281e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 9, 2023 at 4:03=E2=80=AFPM Patrick Robb wro= te: > >> Hello, > > Yes, backporting would be ideal from a CI perspective because without it > we can't run arm64 testing on LTS tests. But I know there are other > considerations which also have to be weighed. > > David also has a patch[1] which should resolve the underlying issue which > introduces the failures on the unit test we want to skip. If that patch i= s > accepted, and backported, fixing our original problem with unit testing o= n > our arm testbeds, that's another solution, at least for this specific uni= t > test issue. > > It would still be nice to have this feature in case we need it otherwise. > > [1] > https://patches.dpdk.org/project/dpdk/patch/20230821085806.3062613-4-davi= d.marchand@redhat.com/ > > Hi. just to close the loops on this, yes David's aforementioned patch did resolve the unit test failure which was preventing us from running fast-tests on our arm64 test beds. But, it is not (yet, at least) backported for LTS releases. Even if it were, having Bruce's patch here backported would mean the CI testing approach could be common across releases in situations where testcases have to be skipped. Anyways, whether it's possible or "worth it" is ultimately down to the community's bandwidth, but I didn't want to let the conversation lapse without an update, and raising what the benefits would be. In any case, thanks again Bruce for the rework, it's a great addition. --000000000000a04ca9060827281e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Oct 9, 2023 at 4:03=E2=80=AFPM Pa= trick Robb <probb@iol.unh.edu&g= t; wrote:

Hello,

Yes, backporting would be idea= l from=C2=A0a CI=C2=A0perspective because without it we can't run arm64= testing on LTS tests. But I know there are other considerations which also= have to be weighed.=C2=A0

David also has a patch[= 1] which should resolve the underlying issue which introduces the failures = on the unit test we want to skip. If that patch is accepted, and backported= , fixing our original problem with unit testing on our arm testbeds, that&#= 39;s another solution, at least for this specific unit test issue.

It would still be nice to have this feature in case we nee= d it otherwise.=C2=A0=C2=A0

Hi. just to close the loops on this, ye= s David's aforementioned patch did resolve the unit test failure which = was preventing us from running fast-tests on our arm64 test beds. But, it i= s not (yet, at least) backported for LTS releases.=C2=A0

Even if it were, having Bruce's patch here backporte= d would mean the CI testing approach could be common across releases in sit= uations where testcases=C2=A0have to be skipped.=C2=A0

=
Anyways, whether it's possible or "worth it" is ultimate= ly down to the community's bandwidth, but I didn't want to let the = conversation lapse without an update, and raising what the benefits would b= e.=C2=A0

In any case, thanks again Bruce for the r= ework, it's a great addition.=C2=A0

--000000000000a04ca9060827281e--