<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> Hardware Setup:<o:p></o:p> <![if !supportLists]>· <![endif]>Intel 25G hardware has been set up, but there’s an issue using TRex with the firmware version that supports our 25G NICs. We’ll swap the 25G NICs for 40G, which allows us to avoid the issue. New hardware has been ordered and should be delivered soon. George will work with Patrick on the setup. Setup of 10G NICs is also in progress.<o:p></o:p> <![if !supportLists]>· <![endif]>This wasn’t covered during the meeting, but in a separate email discussion Cavium confirmed that they’re working on getting hardware ready and hope to be ready to ship to UNH by the end of this week.<o:p></o:p> <![if !supportLists]>· <![endif]>Mellanox hardware has been running for a few weeks now. Ali is working on some scripts.<o:p></o:p> <![if !supportLists]>· <![endif]>NXP hardware is still in progress.<o:p></o:p> <o:p> </o:p> Test Setup:<o:p></o:p> <![if !supportLists]>· <![endif]>Discussed a few corner cases for testing:<o:p></o:p> <![if !supportLists]>o <![endif]>What happens when the system detects patch sets that have already been applied? This would not normally happen, but can do if the system falls behind due to load or other issues, or if patch sets are applied very quickly which sometimes happens towards the end of a release.<o:p></o:p> <![if !supportLists]>o <![endif]>If a patch set doesn’t apply to master, should we try applying to next-net and test that? This situation may occur if next-net is ahead of master. It would mean keeping separate performance history for next-net, as this may differ from master. John will discuss with Ferruh (next-net maintainer) to see how common this situation is and if it’s worth the effort of doing this.<o:p></o:p> <![if !supportLists]>o <![endif]>For patch set dependencies, we could add a specific tag which could then be detected by Patchwork. Patchwork 2 may help with this as it has better handling for patch sets. Ali and Thomas are planning to install Patchwork 2 after 18.05 has been released.<o:p></o:p> <![if !supportLists]>· <![endif]>Patrick sent email with a mock-up of the dashboard (<a href="http://dpdk.org/ml/archives/ci/2018-May/000178.html">http://dpdk.org/ml/archives/ci/2018-May/000178.html</a>). Please review and send comments to Patrick. We also need to consider possible extension of the lab scope to cover CI (see item below) and make sure the dashboard can be easily extended if we add that in future.<o:p></o:p> <![if !supportLists]>· <![endif]>Target is still to have tests running with public results by the end of Q2, in time for the China DPDK Summit on June 28th.<o:p></o:p> <o:p> </o:p> Contract Extension<o:p></o:p> <![if !supportLists]>· <![endif]>The current contract runs until the end of June.<o:p></o:p> <![if !supportLists]>· <![endif]>Agreed that we will extend this to the end of this year initially. Lincoln will provide the necessary documentation to Trishan. After this, we’ll extend on an annual basis which aligns with the DPDK budgeting cycle.<o:p></o:p> <![if !supportLists]>· <![endif]>Discussed extending the lab scope to include additional CI capabilities, similar to the FD.io CSIT lab. The Intel team are investigating some CI improvements. We’ll discuss further internally and when we have a proposal on this we’ll review with this group.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html>