From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 32A3C374C for ; Thu, 28 Feb 2019 16:24:53 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Feb 2019 07:24:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,423,1544515200"; d="scan'208";a="148088028" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by fmsmga004.fm.intel.com with ESMTP; 28 Feb 2019 07:24:47 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.28]) by IRSMSX104.ger.corp.intel.com ([169.254.5.56]) with mapi id 14.03.0415.000; Thu, 28 Feb 2019 15:24:47 +0000 From: "O'Driscoll, Tim" To: Thomas Monjalon , "ci@dpdk.org" CC: Aaron Conole , "Stokes, Ian" Thread-Topic: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th Thread-Index: AdTPczq9ylSOJ9eQQ92wN3Zf0yZ7ZwABeH0AAAARKEA= Date: Thu, 28 Feb 2019 15:24:47 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BAB785C1CF@IRSMSX108.ger.corp.intel.com> References: <26FA93C7ED1EAA44AB77D62FBE1D27BAB785C151@IRSMSX108.ger.corp.intel.com> <1705160.KQmOS6fXmK@xps> In-Reply-To: <1705160.KQmOS6fXmK@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTAyNTg5MTktMzU1Ny00MjhhLThlMDYtNzliMTE1OWRhNmZmIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTWV6Y096NU5NTWpvWWsrSEc4bmd4TGc3czNoRzgrUWlmdUVOWkFZTEZSZzV5NVFyYjRSSUdcL2FVV0FlMmZsOTYifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 15:24:53 -0000 > -----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 > Subject: Re: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th >=20 > Hi, >=20 > 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. >=20 > 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. >=20 > 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 c= over all vendors. Aaron and Ian can provide more details.