Re: [PATCH v2 5/7] dts: add support for externally compiled DPDK

[Patrick Robb <probb@iol.unh.edu>]

[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]

On Tue, Oct 29, 2024 at 7:48 AM Luca Vizzarro <Luca.Vizzarro@arm.com> wrote:

> Hi Patrick,
>
> On 29/10/2024 01:19, Patrick Robb wrote:
> >     diff --git a/dts/conf.yaml b/dts/conf.yaml
> >     index 814744a1fc..8a65a481d6 100644
> >     --- a/dts/conf.yaml
> >     +++ b/dts/conf.yaml
> >     @@ -5,12 +5,24 @@
> >       test_runs:
> >         # define one test run environment
> >         - dpdk_build:
> >     -      arch: x86_64
> >     -      os: linux
> >     -      cpu: native
> >     -      # the combination of the following two makes CC="ccache gcc"
> >     -      compiler: gcc
> >     -      compiler_wrapper: ccache
> >     +      # dpdk_tree: Commented out because `tarball` is defined.
> >
> >
> > Should this key name be extended to clarify the desired value is a path,
> > and whether it is absolute or relative?
>
> We could amend the key name to something more suitable if we wished. The
> path could be either absolute or relative, so it doesn't matter. I
> assume you are referring to change `dpdk_tree` to `dpdk_tree_path` and
> `tarball` to `tarball_path` or something similar?
>

Yes, that was my thinking. Up to you on whether it's better or just overly
wordy.


>
> > +1 to Dean's concerns about using the tarball without --tarball flag if
> > dpdk_tree is commented out and tarball is defined.
>
> As replied to Dean, this scenario currently works, and I have also just
> re-tested it for completeness. I need some more details to figure out
> what's happening.
>

Okay, so I guess this is fine. I chatted with Dean about this today and it
sounds like the workflows he was worried about do actually work (namely,
copying a tarball from DTS engine to SUT) but that there is an added
requirement that a flag be added (i.e. you can't just run main.py alone
anymore) and it's unclear to him (and me) why this might be the case. I can
try and take another look tonight, but I'm basically happy now that I know
the workflows Dean was concerned about are tested and work.


> Best,
> Luca
>

[-- Attachment #2: Type: text/html, Size: 2957 bytes --]