test suite reviews and discussions
 help / color / Atom feed
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
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 --]

<div dir="ltr">Hello all,<div><br></div><div>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 (&#39;-s&#39;, &#39;--skip-setup&#39;) 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. <br><br>Where this becomes a possible addition to <a href="https://bugs.dpdk.org/show_bug.cgi?id=515">bug 515</a>, 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. </div></div>

                 reply index

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publically 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

test suite reviews and discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/dts/0 dts/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dts dts/ http://inbox.dpdk.org/dts \
		dts@dpdk.org
	public-inbox-index dts


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dts


AGPL code for this site: git clone https://public-inbox.org/ public-inbox