[dpdk-ci] Question about performance test

[Jeremy Plsek]

Hi Rami,

I'm the current maintainer of the DPDK Performance CI. I realize that the
performance results don't point to the website, so it's not obvious on
where to find this information. You can find an overview of these tests
here: https://lab.dpdk.org

Most of this information can be either found on the detailed results of a
test (such as https://lab.dpdk.org/results/dashboard/patchsets/4157/) or on
the about page (https://lab.dpdk.org/results/dashboard/about/).

But to answer your questions:
At the moment, we only run performance tests. Specifically the
nic_single_core_perf_test from the DPDK Test Suite with the TRex traffic
generator.
The devices we are testing are currently the Intel 82599ES 10G, the Intel
XL710-QDA2 40G, the Mellanox ConnectX-5 100G, and the ConnectX-4 Lx 25G and
40G.

We don't apply the doc folder when applying the series, in case a patch
included code unrelated to documentation. If others in the group feel that
it's still unnecessary to include "doc" labeled series, I can look into
filtering them out.

Thanks.


On Fri, Jan 4, 2019 at 5:46 AM Rami Rosen <ramirose at gmail.com> wrote:

> Hi,
> I have a question about DPDK CI process and the tests done when a patch is
> submitted to dpdk-dev mailing list.
> In DPDK patch work I see these response messages from the DPDK CI for all
> patches:
>
> ...
> ci/intel-Performance-Testing success Performance Testing PASS
> ci/mellanox-Performance-Testing success Performance Testing PASS
> ...
>
> My question is (I hope and believe the info is available publicly) : which
> tests are run in the ci, generating these messages?  is it done with IXIA
> and DTS ? (DPDK test suite, https://doc.dpdk.org/dts/gsg/) ? are these
> l2fwd/l3fwd performance tests? or more than that ? and on which
> Intel/Mellanox nics ?  Are these merely performance tests, or also
> functional tests ?
>
> And BTW, I noticed that the CI runs a full performance cycle also for doc
> patches (at least these messages are generated), which is a kind of
> redundant (unless there is some filter which checks that if a patch only
> affects modules under "doc", than such a cycle is not done but the messages
> are still sent)
>
> Regards,
> Rami Rosen
>


-- 
Jeremy Plsek
UNH InterOperability Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/ci/attachments/20190104/52fe8d66/attachment.html>