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 4C2E543B0E for ; Wed, 14 Feb 2024 20:32:34 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 460234325E; Wed, 14 Feb 2024 20:32:34 +0100 (CET) Received: from mail-oo1-f43.google.com (mail-oo1-f43.google.com [209.85.161.43]) by mails.dpdk.org (Postfix) with ESMTP id 4E42B42EA4 for ; Wed, 14 Feb 2024 20:32:32 +0100 (CET) Received: by mail-oo1-f43.google.com with SMTP id 006d021491bc7-59505514213so80578eaf.0 for ; Wed, 14 Feb 2024 11:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1707939151; x=1708543951; 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=PoReGRoqsZy+W33z4pGO7h5Ms3vQ+zRiEznP5/pQm1I=; b=Flmn9sCs+mDGdLq/3egAYIvefRpA3zKoRwMTj7l0htZ7Z7/45M864BZsMGLJSderkm pZefzb+oUGHbtXppl4rtWQQsqtEz0sEgXDeR/mS4fRBKcR5Bk7mAmVBV6a62XJOi9EN5 jbqhyyETfmQade3LFAVOMwZaSi5Zo/YC5bR2c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707939151; x=1708543951; 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=PoReGRoqsZy+W33z4pGO7h5Ms3vQ+zRiEznP5/pQm1I=; b=V5VivD6c7vVzKvJ6tQbcbZ56sVoFXS7imm3AIyAFqj2t/0gb7bHEYkYaq3h4x6kIUw ZOOfusnOgiv8dMDkaM64W+0UdXgkP0EvMAJfFmrYZU7ri47ZPcJNN6NnG0dfn8P+KzW9 1QIDhfahNhFyL0+LVK/Hh7HZATpWPKOI6ioA+zMuQ16+8E2RQmxugThhXWza6wxb05pi ZXie5l6PS3cOT1ur5cxtAIxXOZATrbytTrSpLNM+Sss9LwAESRT224iHmZzBELidXtvq NZeznDQvUSzULpFsVedBjDwZME0xmWLuJdAAvLtbcp5zAgLeDoYk6nHcHQnkGZ9MqpAL 4YDQ== X-Forwarded-Encrypted: i=1; AJvYcCXR+fS58QpISU8GMnIHLUN/rpMGUKWtTxy1deuN2s2SqnRnTorPVtSR4F6uJ9/k+ttHvNP/tNoP9QZ4bjtH2YM= X-Gm-Message-State: AOJu0Yx2uN4mruiqZaUHN6pVIkQNM/yN3DdpNoSo93mFQyZw+dJz1D71 roHE54UUq3jykoDQoUyWlXlWIiWKXdM1aO3xhjv5nAK/JFF3jTRNOmRfALOlQ/JJO1j5fntqcjM CCS8GSUoAOlIHb4HDjOaLomlYu34XHmqg8EjaWA== X-Google-Smtp-Source: AGHT+IEm0BiM6sGK7i/1eSPXd/QdlT3rhqkHmBrWpvT6W14rqdAV5Sm0/nEgesIsKytdNZ/fEdfsbqo+0128MoLHP6I= X-Received: by 2002:a05:6820:2801:b0:59d:4035:31f9 with SMTP id dm1-20020a056820280100b0059d403531f9mr1206150oob.1.1707939151710; Wed, 14 Feb 2024 11:32:31 -0800 (PST) MIME-Version: 1.0 References: <20240213145218.1532323-1-cristian.dumitrescu@intel.com> <20240213173809.1536955-1-cristian.dumitrescu@intel.com> In-Reply-To: From: Patrick Robb Date: Wed, 14 Feb 2024 14:32:20 -0500 Message-ID: Subject: Re: [PATCH V2] examples/pipeline: fix include path for rte_log.h To: Aaron Conole Cc: Ferruh Yigit , Cristian Dumitrescu , dev@dpdk.org, stable@dpdk.org, David Marchand , Bruce Richardson Content-Type: multipart/alternative; boundary="0000000000006fa04e06115c926b" X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org --0000000000006fa04e06115c926b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Aaron/Cristian, On Wed, Feb 14, 2024 at 11:25=E2=80=AFAM Aaron Conole = wrote: > Ferruh Yigit writes: > > > On 2/13/2024 5:38 PM, Cristian Dumitrescu wrote: > >> When rte_log.h was moved to a new directory, the include path was not > >> updated for the generated C code produced by the pipeline library, > >> which results in build failure for this code. > >> > >> Fixes: 09ce41310930 ("log: separate logging functions out of EAL") > >> Cc: stable@dpdk.org > >> > > > > Hi Cristian, > > > > How can I verify the fix? Can you please list the required steps? > > I guess maybe (?) with the pipeline DTS case, but I'm not sure that > would be sufficient. > > > And I wonder how this skipped the testing, I guess v23.11 released with > > this defect. Is there a gap in the CI or internal build/test scripts? > > I don't know that softnic driver is used in the lab. Actually, would > DTS suite even have triggered this issue? I'm not sure if there is a > set of tests which covers the case. Maybe Patrick can confirm about the > pipeline test? > So, based on what Cristian stated (passing in any of the .cli files when starting the pipeline example app would show it is fixed), yes I assume the DTS testsuite would have caught this, as I can see the testsuite does do that. But, yes it's also true that the pipeline testsuites are not run at UNH or the Intel Lab (the two labs which publicly report DTS results), so that's how this gets through CI Testing. It is not possible (testing capacity wise) to run every testsuite, and I don't think there has been conversation between the lab and our vendor contacts about this specific coverage (at least not while I've been working here). However, based on the physical testplan requirements (4 10G tester ports to 4 10G DUT ports), we could bring the testsuite online if there is interest(and the testsuite hasn't broken since it dropped in 2020). One of our Intel testbeds which we run currently has exactly that NIC topology, and it also doesn't have bad testing capacity concerns as compared to some other testbeds. Let me know if there is an interest in this coverage and I'll make a ticket for the team to take a look. At a minimum we could dry run the framework on the testbed I'm thinking of and provide feedback, which I suppose would take only a couple minutes/hours. Christian let me know if that's a value - it's a low barrier of entry to dry run. https://git.dpdk.org/tools/dts/tree/test_plans/pipeline_test_plan.rst --0000000000006fa04e06115c926b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Aaron/Cristian,

On Wed, Feb 14, 2024 at = 11:25=E2=80=AFAM Aaron Conole <aco= nole@redhat.com> wrote:
Ferruh Yigit <ferruh.yigit@amd.com> writes:

> On 2/13/2024 5:38 PM, Cristian Dumitrescu wrote:
>> When rte_log.h was moved to a new directory, the include path was = not
>> updated for the generated C code produced by the pipeline library,=
>> which results in build failure for this code.
>>
>> Fixes: 09ce41310930 ("log: separate logging functions out of = EAL")
>> Cc: stable@dp= dk.org
>>
>
> Hi Cristian,
>
> How can I verify the fix? Can you please list the required steps?

I guess maybe (?) with the pipeline DTS case, but I'm not sure that
would be sufficient.

> And I wonder how this skipped the testing, I guess v23.11 released wit= h
> this defect. Is there a gap in the CI or internal build/test scripts?<= br>
I don't know that softnic driver is used in the lab.=C2=A0 Actually, wo= uld
DTS suite even have triggered this issue?=C2=A0 I'm not sure if there i= s a
set of tests which covers the case.=C2=A0 Maybe Patrick can confirm about t= he
pipeline test?

So, based on what = Cristian stated (passing in any of the .cli files when starting the pipelin= e example app would show it is fixed), yes I assume the DTS testsuite would= have caught this,=C2=A0as I can see the testsuite does do that. But, yes i= t's also true that the pipeline testsuites are not run at UNH or the In= tel Lab (the two labs which publicly report DTS results), so that's how= this gets through CI Testing. It is not possible (testing capacity wise) t= o run every testsuite, and I don't think there has been conversation be= tween the lab and our vendor contacts about this specific coverage (at leas= t not while I've been working here).

However, = based on the physical testplan=C2=A0requirements (4 10G tester ports to 4 1= 0G DUT ports), we could bring the testsuite online if there is interest(and= the testsuite hasn't broken since it dropped in 2020). One of our Inte= l testbeds which we run currently has exactly that NIC topology, and it als= o doesn't have bad testing capacity concerns as compared to some other = testbeds. Let me know if there is an interest in this coverage and I'll= make a ticket for the team to take a look. At a minimum we could dry run t= he framework on the testbed I'm thinking of and provide feedback, which= I suppose would take only a couple minutes/hours. Christian let me know if= that's a value - it's a low barrier of entry to dry run.



--0000000000006fa04e06115c926b--