DPDK CI discussions
 help / color / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Aaron Conole <aconole@redhat.com>
Cc: Lincoln Lavoie <lylavoie@iol.unh.edu>,
	"O'Driscoll, Tim" <tim.odriscoll@intel.com>,
	"ci@dpdk.org" <ci@dpdk.org>, "Stokes, Ian" <ian.stokes@intel.com>,
	Rashid Khan <rkhan@redhat.com>
Subject: Re: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th
Date: Sat, 09 Mar 2019 00:22:39 +0100
Message-ID: <28236099.lslQNaqCNh@xps> (raw)
In-Reply-To: <f7th8cd6ow8.fsf@dhcp-25.97.bos.redhat.com>

08/03/2019 22:24, Aaron Conole:
> Thomas Monjalon <thomas@monjalon.net> writes:
> 
> > 04/03/2019 17:59, Lincoln Lavoie:
> >> Hi All,
> >> 
> >> The reason we selection loaner machines (UNH provided) for the development
> >> was to avoid interference with the existing setup, i.e. don't break or
> >> degrade the performance tuned systems.
> >> 
> >> For the deployed testing (i.e. once we have the OVS developed and
> >> integrated with the lab dashboard) can be done either on the existing
> >> hardware, or a stand alone setup with multiple NICs.  I think this was
> >> proposed, because function testing with multiple NICs would had more
> >> hardware coverage than the two vendor performance systems right now.  That
> >> might also be a lower bar for some hardware vendors to only provide a NIC,
> >> etc.
> >
> > Either a vendor participate fully in the lab with properly setup HW,
> > or not at all. We did not plan to have half participation.
> > Adding more tests should encourage to participate.
> >
> >> In we choose the "option A" to use the existing performance setups, we
> >> would serialize the testing, so the performance jobs run independently, but
> >> I don't think that was really the question.
> >
> > Yes, it is absolutely necessary to have a serialized job queue,
> > in order to have multiple kinds of tests on the same machine.
> > I think we need some priority levels in the queue.
> 
> One problem that we will run into is the length of time currently set
> for running the ovs pvp tests.  Each stream size will run for a length
> of time * # of stream sizes * # flows * 2 (L2 + L3 flow caching) - so it
> can take a full day for the ovs_perf tests to run.  That would be a long
> time on patch-set basis.
> 
> It might make sense to restrict it to a smaller subset of streams,
> flows, etc.  We'll need to figure out what makes sense (for example,
> maybe we only do 10 minutes of 64-byte and 1514-byte packets with 1m
> flows l2 + l3) from a testing perspective to give us a good mix of test
> coverage without spending too many cycles tying up the machines.

Right, the tests must limited to a reasonnable time.
10 minutes might be a maximum.

      reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-28 14:49 O'Driscoll, Tim
2019-02-28 15:20 ` Thomas Monjalon
2019-02-28 15:24   ` O'Driscoll, Tim
2019-03-04  8:06     ` Stokes, Ian
2019-03-04  8:40       ` Thomas Monjalon
2019-03-04  8:49         ` Stokes, Ian
2019-03-04 13:06     ` Aaron Conole
2019-03-04 16:59       ` Lincoln Lavoie
2019-03-04 17:40         ` Thomas Monjalon
2019-03-08 21:24           ` Aaron Conole
2019-03-08 23:22             ` Thomas Monjalon [this message]

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=28236099.lslQNaqCNh@xps \
    --to=thomas@monjalon.net \
    --cc=aconole@redhat.com \
    --cc=ci@dpdk.org \
    --cc=ian.stokes@intel.com \
    --cc=lylavoie@iol.unh.edu \
    --cc=rkhan@redhat.com \
    --cc=tim.odriscoll@intel.com \
    /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

DPDK CI discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/ci/0 ci/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 ci ci/ http://inbox.dpdk.org/ci \
		ci@dpdk.org
	public-inbox-index ci


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


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