[dpdk-ci] Minutes of DPDK Lab Meeting, February 26th
ian.stokes at intel.com
Mon Mar 4 09:49:13 CET 2019
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> Sent: Monday, March 4, 2019 8:40 AM
> To: Stokes, Ian <ian.stokes at intel.com>
> Cc: O'Driscoll, Tim <tim.odriscoll at intel.com>; ci at dpdk.org; Aaron Conole
> <aconole at redhat.com>
> Subject: Re: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th
> 04/03/2019 09:06, Stokes, Ian:
> > > -----Original Message-----
> > > From: O'Driscoll, Tim
> > > Sent: Thursday, February 28, 2019 3:25 PM
> > > To: Thomas Monjalon <thomas at monjalon.net>; ci at dpdk.org
> > > Cc: Aaron Conole <aconole at redhat.com>; Stokes, Ian
> > > <ian.stokes at intel.com>
> > > Subject: RE: [dpdk-ci] Minutes of DPDK Lab Meeting, February 26th
> > >
> > > > -----Original Message-----
> > > > From: Thomas Monjalon [mailto:thomas at monjalon.net]
> > > > Sent: Thursday, February 28, 2019 3:20 PM
> > > > To: ci at dpdk.org
> > > > Cc: O'Driscoll, Tim <tim.odriscoll at 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.
> > 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 the
> ongoing/upcoming HWOL development work. There is a risk that the
> implementation for HWOL for vendor x may not be compatible or suitable for
> 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.
> Yes it seems to be the scope of the DPDK Community Lab.
> > 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.
> 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.
> > 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.
> Which vendor is not available in the DPDK Community Lab?
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.
> > @Aaron, have I missed anything from your side?
> > Thanks
> > Ian
More information about the ci