From: "O'Driscoll, Tim" <tim.odriscoll@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>, "ci@dpdk.org" <ci@dpdk.org>
Cc: Aaron Conole <aconole@redhat.com>, "Stokes, Ian" <ian.stokes@intel.com>
Subject: Re: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th
Date: Thu, 28 Feb 2019 15:24:47 +0000 [thread overview]
Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BAB785C1CF@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <1705160.KQmOS6fXmK@xps>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Thursday, February 28, 2019 3:20 PM
> To: ci@dpdk.org
> Cc: O'Driscoll, Tim <tim.odriscoll@intel.com>
> Subject: Re: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th
>
> Hi,
>
> 28/02/2019 15:49, O'Driscoll, Tim:
> > OVS Tests:
> > - Jeremy and Aaron are working on setup of the temporary hardware.
> > - There are two options for hardware to run this on when the setup is
> complete: 1) use existing vendor hardware; 2) obtain standalone servers
> for OVS testing. The OVS team's preference is option 2. It's not
> realistic to expect a vendor to provide hardware to run a competitor's
> products so we'd need to find a different way to procure this. Aaron
> will check with Rashid to see if budget is available from Red Hat. I'll
> check with Trishan to see if the DPDK project budget could cover this.
> > - The OVS focus is on functional tests, not performance tests. The
> DPDK lab is currently set up so that each vendor has complete control
> over performance tests & results on their hardware. If we use separate
> hardware for the OVS tests, we need to ensure that we restrict scope to
> functional tests so that it does not conflict with this principle in
> future.
>
> I am not sure to understand.
> In my opinion, the purpose of this lab is to have properly tuned
> hardware
> for running a large set of tests. We should be able to run various
> tests
> on the same machine. So the OVS tests, like any new test scenario,
> should be run on the same machine as the performance tests.
> I think we just need to have a job queue to run tests one by one,
> avoiding a test to disturb results of another one.
>
> Why are we looking for additional machines?
That was my assumption too. I believe the reason is that the OVS team want to validate with multiple vendor NICs to be sure that nothing is broken. We only have Intel and Mellanox hardware in our lab at present, so we don't cover all vendors.
Aaron and Ian can provide more details.
next prev parent reply other threads:[~2019-02-28 15:24 UTC|newest]
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 [this message]
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
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=26FA93C7ED1EAA44AB77D62FBE1D27BAB785C1CF@IRSMSX108.ger.corp.intel.com \
--to=tim.odriscoll@intel.com \
--cc=aconole@redhat.com \
--cc=ci@dpdk.org \
--cc=ian.stokes@intel.com \
--cc=thomas@monjalon.net \
/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).