[PATCH V2] examples/pipeline: fix include path for rte_log.h

[Patrick Robb]

Hi Aaron/Cristian,

On Wed, Feb 14, 2024 at 11:25 AM Aaron Conole <aconole at redhat.com> wrote:

> Ferruh Yigit <ferruh.yigit at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/stable/attachments/20240214/6e48de32/attachment.htm>