From: Owen Hilyard <ohilyard@iol.unh.edu>
To: dts@dpdk.org
Cc: Lincoln Lavoie <lylavoie@iol.unh.edu>,
David Liu <dliu@iol.unh.edu>,
Daniel Kirichok <dkirichok@iol.unh.edu>,
david.marchand@redhat.com
Subject: [dts] Question about the skip setup flag and a possible addition to bug 515
Date: Wed, 29 Jul 2020 07:30:44 -0400 [thread overview]
Message-ID: <CAHx6DYDvosky14FOD8agaf-ySbU3q+e2dW7TrO_9yzr6i8S6XQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]
Hello all,
During a recent internal meeting, we (the IOL team) were discussing
bringing new test cases into the CI environment. We found that many of the
test cases which recompile DPDK seem to break testpmd for all of the tests
after them. As far as we can tell, this is because some of these tests
leave testpmd in a location different than the default once they are
compiled, resulting in the executable not being able to be found. We wanted
to reach out and ask if the skip setup flag ('-s', '--skip-setup') was
intended to stop recompilation of dpdk during the time that test cases are
running. If it is, then it seems many of the tests which recompile dpdk do
not follow this convention, and if it is not then those test cases might
need to be fixed. It is also possible that there is a misconfiguration or
misunderstanding of the root cause on our side. If it is not one of those
cases and this is both behavior that is expected given proper configuration
but not behavior which is desired, then I think I have a relatively
painless solution. This solution would be to add a check for the flag in
the build_install_dpdk function and, if it is present, assumes that
everything is compiled correctly and exits the function early. This would
only involve adding a few lines for the check and then whatever is required
to access the flags deeper into dts.
Where this becomes a possible addition to bug 515
<https://bugs.dpdk.org/show_bug.cgi?id=515>, is that doing this could break
many of the tests which edit dpdk source directly, since the compilation
they expect would not occur. As such, this would either need to be its own
bug to be fixed after 515, or tacked on to 515.
[-- Attachment #2: Type: text/html, Size: 1768 bytes --]
reply other threads:[~2020-07-29 11:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHx6DYDvosky14FOD8agaf-ySbU3q+e2dW7TrO_9yzr6i8S6XQ@mail.gmail.com \
--to=ohilyard@iol.unh.edu \
--cc=david.marchand@redhat.com \
--cc=dkirichok@iol.unh.edu \
--cc=dliu@iol.unh.edu \
--cc=dts@dpdk.org \
--cc=lylavoie@iol.unh.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).