[dpdk-ci] Minutes of DPDK Lab Meeting, February 26th

[Thomas Monjalon]

08/03/2019 22:24, Aaron Conole:
> Thomas Monjalon <thomas at 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.