From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) by dpdk.org (Postfix) with ESMTP id 9795F5B30 for ; Tue, 29 Jan 2019 22:07:32 +0100 (CET) Received: by mail-ot1-f54.google.com with SMTP id 32so19173874ota.12 for ; Tue, 29 Jan 2019 13:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=pJfWSLJiY1BdMw6ROdO+Ic1itoKrrYC/EATUQcvlRDQ=; b=XtSammE16MrWLojpKmuhLWTEJI/6tZHqdcDC7XvBUj6kWhZn2cduXftwZW/XtzcD7P 3FCkyDBlrtsftAEvcuZAn/OtAX+CPFElM2srXSYxEJJNEUUzwlYAE0Bh6MPtpuTtxDy2 4EX65ztdUpQhUo4qmusjf7R+s56hwAbupf644= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=pJfWSLJiY1BdMw6ROdO+Ic1itoKrrYC/EATUQcvlRDQ=; b=Nd47xkSq+Orq4e8ndwD1UwplqXVtbHBh2N1e9ex/hVQ2iSrMYq3ZmBxB1z+zc+PYxE DNYVcGhTeotzueZJFCK/W8dPrWxuDMPNVhvP4+JZPEG8QisFm+7kt/9gWSmGVDOLOKdt xUbnWtQFB6aylILCl//HoYJ6lHCxFlyd5DR1tDzzUAce3tKvC4VVkZo79PN29/s5dVc6 GTjE4nqY52Ebp/LNLpfsQMhpdcIRrpM5HXMbcdHCwnV760WuEoW+MBoEvBfqoK7FoVWm aR6RAZ2FjBldq+80wwORXDjgAfmfLMglin7ZXGeub1CRo0eINhjm2NLM0hCKZ+cCcHzf KDvA== X-Gm-Message-State: AJcUukdR5qD2Q6jUy6kvALpk42OTwoVA6O06jw3TA/oR1F2aAlXSBT+l ya6POIQfEaWvw1XgeYerIhPxnkjnn9ulq4KyZstL8R8V X-Google-Smtp-Source: ALg8bN4omcZPYqNSTVDgyR+bgHIFwKCdrGAV5l6QQvMolW+cdbpUfR3CyCI8m3tBC5GDwYMPgoOAwnRlabvWp5VYkSg= X-Received: by 2002:a9d:430:: with SMTP id 45mr21656458otc.75.1548796051688; Tue, 29 Jan 2019 13:07:31 -0800 (PST) MIME-Version: 1.0 References: <26FA93C7ED1EAA44AB77D62FBE1D27BAB78388ED@IRSMSX108.ger.corp.intel.com> In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BAB78388ED@IRSMSX108.ger.corp.intel.com> From: Jeremy Plsek Date: Tue, 29 Jan 2019 16:06:55 -0500 Message-ID: To: "ci@dpdk.org" Content-Type: multipart/alternative; boundary="0000000000007dafdf05809f2ef6" Subject: Re: [dpdk-ci] Minutes of DPDK Lab Meeting, January 29th 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: Tue, 29 Jan 2019 21:07:32 -0000 --0000000000007dafdf05809f2ef6 Content-Type: text/plain; charset="UTF-8" It was also discussed in this meeting, after Tim had to leave for another meeting, that we should be saving absolute results instead of delta results. In past discussions, it was agreed to only save the delta result to the UNH-IOL database that drives the dashboard, with the baseline (absolute result) kept on the respective system (without keeping old absolute baselines). Additionally, keeping absolute data in the database could be used to produce accurate charts of performance over time and better show trends. However, that will require some agreements to be reached for what data could be made public, compared to what is available to logged in users (i.e. seeing their own absolute performance numbers). At this time, the only change would be first storing the numbers into the database, with only UNH-IOL having access to the data. Nothing else with the systems would change with this first step. The public view will still remain showing a delta for patches, until we decide later on, on whether to show these absolute numbers in private or also in public views. If there is any issues with going forward with this decision, I'd like this thread to be a public discussion for said issues. Ideally, we would like to reach a definite go / no-go on this change for the next team meeting on February 12. No reply or participation in this thread will be considered as accepting the proposal to store the absolute numbers in the database. Thanks. On Tue, Jan 29, 2019 at 1:58 PM O'Driscoll, Tim wrote: > Red Hat Test Cases: > - We had a separate meeting with Red Hat after our lab meeting today. > Aaron and Rashid explained that they have a suite of DPDK tests, some of > which use OVS and some of which test DPDK is isolation. These can be easily > set up in the DPDK lab. > - We agreed to proceed with this. It's a great way to get additional test > coverage which we've been struggling with for a while. Aaron will work with > Jeremy on the implementation. > - The initial goal is to get tests running and results into the database. > After that, we can decide how to represent the results in the dashboard and > patchwork. > - We will need to make sure that running these tests has not impact on the > current test cases. The assumption is that current utilization is low > enough that this should not be a problem. > > DTS Improvements: > - Thomas will solicit community feedback on this. Community help will also > be required to implement any changes. > > Applying Patches to Sub-Trees: > - Plan is to apply patch sets to master first. If that fails, then we'll > use a script to determine which sub-tree to apply the patch set to. Thomas > and Ali hope to provide a script this week. > - If a patch set is applied to a sub-tree, then we need to agree whether > the baseline for performance comparison should be the master or the > sub-tree. Agreed that we should compare to master. > -- Jeremy Plsek UNH InterOperability Laboratory --0000000000007dafdf05809f2ef6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It was also discussed in this meeting, af= ter Tim had to leave for another meeting, that we should be saving absolute= results instead of delta results.

In past discussions, it was agree= d to only save the delta result to the UNH-IOL database that drives the das= hboard, with the baseline (absolute result) kept on the respective system (= without keeping old absolute baselines).

Addition= ally, keeping absolute data in the database could be used to produce accura= te charts of performance over time and better show trends. However, that wi= ll require some agreements to be reached for what data could be made public= , compared to what is available to logged in users (i.e. seeing their own a= bsolute performance numbers).=C2=A0 At this time, the only change would be = first storing the numbers into the database, with only UNH-IOL having acces= s to the data. Nothing else with the systems would change with this first s= tep.

The public view will still remain showing a delta for patches, = until we decide later on, on whether to show these absolute numbers in priv= ate or also in public views.

If there is any issues with going forwa= rd with this decision, I'd like this thread to be a public discussion f= or said issues. Ideally, we would like to reach a definite go / no-go on th= is change for the next team meeting on February 12. No reply or participati= on in this thread will be considered as accepting the proposal to store the= absolute numbers in the database.

Thanks.

On Tue, Jan 29, 2019 at 1:58 PM O'Driscoll, Tim <tim.odriscoll@intel.c= om> wrote:

--
=
Jeremy Plsek
UNH InterOperability Laboratory
--0000000000007dafdf05809f2ef6--