From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 26A042B9E for ; Mon, 4 Mar 2019 09:49:17 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2019 00:49:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,439,1544515200"; d="scan'208";a="156221769" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by orsmga001.jf.intel.com with ESMTP; 04 Mar 2019 00:49:15 -0800 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.185]) by irsmsx105.ger.corp.intel.com ([169.254.7.72]) with mapi id 14.03.0415.000; Mon, 4 Mar 2019 08:49:14 +0000 From: "Stokes, Ian" To: Thomas Monjalon CC: "O'Driscoll, Tim" , "ci@dpdk.org" , Aaron Conole Thread-Topic: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th Thread-Index: AdTPczq9ylSOJ9eQQ92wN3Zf0yZ7ZwABeH0AAAARKEAAuQ9PAAACD+EAAAA5JOA= Date: Mon, 4 Mar 2019 08:49:13 +0000 Message-ID: References: <26FA93C7ED1EAA44AB77D62FBE1D27BAB785C151@IRSMSX108.ger.corp.intel.com> <26FA93C7ED1EAA44AB77D62FBE1D27BAB785C1CF@IRSMSX108.ger.corp.intel.com> <3087301.JtsJcBCixJ@xps> In-Reply-To: <3087301.JtsJcBCixJ@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGFiOGRkNzctODQ5NC00NDA0LThkZTgtMjJhMzdmZjUzODU0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiOEpUVDhMVEkxZWxcL3ZQVitLT3JzbThEMlhCY3VUM3EyUGJCcmQxU3VQWmVtd1pmZlpUUW5sY3BkUk5GM2huUjAifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [163.33.239.180] 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: Mon, 04 Mar 2019 08:49:18 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Monday, March 4, 2019 8:40 AM > To: Stokes, Ian > Cc: O'Driscoll, Tim ; ci@dpdk.org; Aaron Conole > > Subject: Re: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th >=20 > 04/03/2019 09:06, Stokes, Ian: > > > -----Original Message----- > > > From: O'Driscoll, Tim > > > Sent: Thursday, February 28, 2019 3:25 PM > > > To: Thomas Monjalon ; ci@dpdk.org > > > Cc: Aaron Conole ; Stokes, Ian > > > > > > Subject: RE: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th > > > > > > > -----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 > > > > > > > > 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. > > > > Hi Thomas, > > > > So from the OVS point of view, one of challenges when consuming DPDK is > ensuring device compatibility across the community, in particular with th= e > ongoing/upcoming HWOL development work. There is a risk that the > implementation for HWOL for vendor x may not be compatible or suitable fo= r > vendor y etc. > > > > To help address this risk, it was proposed back in DPDK userspace 2018 > that if the OVS community could provide a server, it could be used to co- > locate a variety of vendor NICs. We could then leverage the OVS Zero Day > robot to apply and conduct functional testing for OVS development patches > and ensure patches do not break existing functionality. >=20 > Yes it seems to be the scope of the DPDK Community Lab. >=20 > > To date Aaron has received a number of NICs from various vendors, > however a server (possibly 2) would still be needed to deploy the NICS. > > > > It was proposed that possibly the DPDK Lab in UNL aid with this. > > > > The aim here is purely functional and the system would not be used to > benchmark the NICs in question. It would be purely to stop regressions > being introduced into OVS DPDK and also act as a feedback to the DPDK > community if changes were needed in DPDK itself. >=20 > So far I don't see the need for new servers. Maybe there isn't, I guess when this was proposed originally, knowledge WRT= what HW was available was limited. >=20 > > It might be possible to run the tests on the existing hardware in UNL > but I guess this might not cover the NIC vendors Aaron has received to > date. I wonder would it interrupt the existing DPDK workloads on those > servers also so there was an open question on whether OVS DPDK should be > deployed on a separate board. >=20 > Which vendor is not available in the DPDK Community Lab? >=20 I'm not sure which vendor Aaron has NICs for already, if this can be shared= I guess this needs to be compared to which vendors are in the lab already. Thanks Ian > > @Aaron, have I missed anything from your side? > > > > Thanks > > Ian >=20