From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by dpdk.org (Postfix) with ESMTP id CD44B49E1 for ; Thu, 16 Aug 2018 21:58:58 +0200 (CEST) Received: by mail-oi0-f53.google.com with SMTP id k12-v6so10194840oiw.8 for ; Thu, 16 Aug 2018 12:58:58 -0700 (PDT) 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 :cc:content-transfer-encoding; bh=QN4pYnsR3V4MOVZfu7OpW9sUQ2awCa/9D01tOMoshFM=; b=QI2dG+YEKWyztXGv4yI5nKdnSZpRjH5m0dVO+fOSYGK1RWdxqr0SaXhT0KRINiALpL V5dMrOOYVVH/aCwTp5byZqoKjIAY2F9+dz+/z66GbqGD9HVBrK4s1iy49t/4oAxK+NoJ zGLJnpPvUR50nK+u6u6wgrvHnyQrDeN6isyZA= 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:cc:content-transfer-encoding; bh=QN4pYnsR3V4MOVZfu7OpW9sUQ2awCa/9D01tOMoshFM=; b=mp4wzOBkrf6skgiR6LrKQgvRGill9oElxl8W4dmH9BXTgwb884HJ84D6w10lShRPVw 0wasFlCYx47O2OCJGMi92KCrbq8eNROZZr9nGVNLpDFy1lJ6q0cxsN8/rF5i5pZrZGlu emFit+OhEny1GWjUkLs/W0laO0Sh1hFLVec5vErKMJ2ewXeoVvy0eX5lbdj0d7C7qSGw PCo28G4gnchBjBVsERZVpsii0/4PkLescqN3xFKasvvEnF6EOHOFlOpJxaTslHzLxNGT 9ri2ucrQ696utY+SsltZajO23cTl+JeqkKLV6dvGidVqzJHzfRNJ8yLDrsJpHsI4teD6 2qYw== X-Gm-Message-State: AOUpUlFLSec38QHEB5f4ZTjQECbKJOWD3IfvgpObxhWaF1nmFhSCO9jK tSSuObc4lGVYYMXMhrlPcb0fAiiHPX6d10fcI3EBRw== X-Google-Smtp-Source: AA+uWPwiCcnqRJ38/6x9gWuNC4E2+BjNrxGPmI7Nx8tRAAeML3gbQY2pdTW4TwDhuEa2RUmDVKZEGTngfuMyEfSaFhM= X-Received: by 2002:aca:ce51:: with SMTP id e78-v6mr31493202oig.225.1534449537971; Thu, 16 Aug 2018 12:58:57 -0700 (PDT) MIME-Version: 1.0 References: <26FA93C7ED1EAA44AB77D62FBE1D27BAB7721682@IRSMSX107.ger.corp.intel.com> <9A3E4DCF947BAB4FBECB1FA88D4D67891F33B018@IRSMSX101.ger.corp.intel.com> In-Reply-To: <9A3E4DCF947BAB4FBECB1FA88D4D67891F33B018@IRSMSX101.ger.corp.intel.com> From: Jeremy Plsek Date: Thu, 16 Aug 2018 15:58:21 -0400 Message-ID: To: "Yigit, Ferruh" Cc: Bob Noseworthy , "O'Driscoll, Tim" , ci@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-ci] Minutes of DPDK Lab Meeting, July 17th 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: Thu, 16 Aug 2018 19:58:59 -0000 Hi Ferruh, With regards to "DPDK Branch(s) to test", I agree with testing the patch against the appropriate branch. For some history, we originally tried to apply patches to the appropriate branches (before Patchwork 2.0) based on the heuristics of the subject line, but we ended up having a lot of apply errors. After a meeting, the group agreed with testing against master for now. But with Patchwork 2.0, is there a way to tell what branch a patch/series is supposed to be applied against? If not, how can we figure this out in a reliable programmatic way? On Thu, Aug 16, 2018 at 5:33 AM Yigit, Ferruh wrot= e: > > Hi Bob, > > > > A few comments/questions on =E2=80=9CUNH Policies and Procedures Doc=E2= =80=9D: > > > > - Objective and Scope of Project > > - 2: =E2=80=9CDPDK-enabled applications=E2=80=9D, what ar= e these applications, are they refer to testpmd/l2fwd like test application= s, or OVS/VPP like other products using DPDK? And if these are other produc= ts, will they run for all vendors or for the vendor requested it? > > - 3: =E2=80=9CDemonstrate any new feature performance of = DPDK=E2=80=9D, is this via updating test scripts, if not how these new test= will be run and how results will be shared? > > - What is the plan to use Lab for Continuous Integration,= adding more sanity checks than performance checks by time, as far as I kno= w this was one of the initial plans for a lab. > > > > - DPDK Branch(s) to test > > - 5.1.1: =E2=80=9Cmaster=E2=80=9D, a little background, i= n dpdk development there are multiple sub-trees, some specific patches targ= ets specific trees, these sub-trees are merged into main tree before releas= e candidate, and there is a target to do regular integration from these sub= -trees. > > As a result of this process, for example a patch sent for next-net sub-tr= ee may not apply cleanly to main repo, so it won=E2=80=99t be tested. But t= hat patch will be applied to next-net tree and a week later next-net tree w= ill be merged into main tree, this patch can be something affects the perfo= rmance, but it won=E2=80=99t be detected. Later, when a patch arrives that = can be applied on main tree, it will reveal the performance issue, but susp= ect will be the wrong patch and the problematic patch will be already merge= d. We need a solution for this. There are 5 sub-trees merged into main tree= and more than half of the patches are coming to main repo through them. > > > > - Private DPDK-Member only Dashboard Specification > > - 5.6.1.2: =E2=80=9CThe delta-values of the script output, per test perfo= rmed.=E2=80=9D, in member-only dashboard, why not show base value too, sinc= e it will be updated regularly, via =E2=80=9C--update-expected argument=E2= =80=9D, it would be good to see both current baseline and the diff. > > > > - I am for defining a change management system, there are multiple vendor= and multiple requests, it would be good to trace, discuss and record the r= esult for all of them systematically. > > > > Thanks, > > ferruh > > > > From: O'Driscoll, Tim > Sent: Thursday, July 19, 2018 3:55 PM > To: 'ci@dpdk.org' > Cc: 'Bob Noseworthy' ; Mcnamara, John ; 'Shepard Siegel' ; 'Thomas Monjalo= n' ; 'Erez Scop' ; 'Shreyansh Jai= n' ; Xu, Qian Q ; 'pmacarth@io= l.unh.edu' ; 'Matt Spencer' ; '= George Zhao' ; 'Mishra, Shishir' ; 'Lixuming' ; Tkachuk, Georgii ; 'Trishan de Lanerolle' ; 'Sean Campbell' ; 'Ali Alnubani' ; 'May Chen' ; 'Lodha, Nishant' ; Zhang, Chun ; 'Malla, Malathi' ; 'khemendra kumar' ; 'gr= aeme.gregory@linaro.org' ; Yigit, Ferruh ; Tu, Lijuan > Subject: Minutes of DPDK Lab Meeting, July 17th > > > > UNH Policies and Procedures Doc: > > Document is available at: https://docs.google.com/document/d/1rtSwpNKltVN= yDKNWgeTV5gaYeDoAPlK-sfm8XE7o_5s/edit?usp=3Dsharing > > I reviewed it and it looks good to me. > > Please add any comments to the google doc, or send them directly to Bob (= ren@iol.unh.edu). > > > > Dashboard: > > Dashboard is in much better shape now and most tests are passing. > > We do need to monitor the results and determine if the tolerance is right= . If it=E2=80=99s too high then all tests will pass and we=E2=80=99ll miss = any genuine issues. If it=E2=80=99s too low then we=E2=80=99ll have too man= y tests failing when there isn=E2=80=99t really a problem. Agreed that tuni= ng the tolerance is the responsibility of each vendor. > > For Intel, we need to add the specific test config to the results page. W= e need to confirm the config details to Patrick, and he=E2=80=99ll add this= to the results pages. Other vendors may want to do something similar. > > > > Hardware: > > Shreyansh is almost ready to ship the NXP hardware. It should be in UNH i= n 2-3 weeks. > > > > > > > > -- Jeremy Plsek UNH InterOperability Laboratory