From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com [209.85.128.182]) by dpdk.org (Postfix) with ESMTP id CEEDC326C for ; Fri, 7 Apr 2017 13:07:01 +0200 (CEST) Received: by mail-wr0-f182.google.com with SMTP id c55so28802155wrc.3 for ; Fri, 07 Apr 2017 04:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atomicrules-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=MuMm5utKde/PSyVAa4faYLRRuV6TossYTPYXuzlmNXQ=; b=UPvkbHo89ax1NB53bjPkeVOcQUWP6aHHrWG2lL03/nvluLFCu3R4FvPIHGwt616d8D EcGUnpFYKZCcN4gOQ98CQlclztBgsOXLjUmvIQE+6l+HevU2Ur9D1PKFu/IyfBWvFYP2 qpIHU3XwQW+uWoyDgS176QeGDoOeXP9KfWm/6ALSM0buWExieU3cdspYYIhxqI2wDCHQ uYDS9v+nWowOaFmOHnNCn00VC9ye6917PWM5PIF+aHSLSDR4kPyBHrd9L1RxqbfpGaN9 mn0hgd6ZIDBPze4jRTj/7CaplLhfOtqR0l5KjNSEAqkoEeO4YTTa/KAn1Wnd1XI9TfP/ Mvqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MuMm5utKde/PSyVAa4faYLRRuV6TossYTPYXuzlmNXQ=; b=V7y9v3apGAtIyc/r7q7QMTFXWUjl8H5ByG8oirUEedyYJDgjzVFd0dxYythJJ1074W z/7IuY1edrXSDKO7slngwxYD2RQX08XBtvQ68wC3+XpHGZxmx7R81KnGM7vY9/5WB6Vo octsMxv8onekwoieA0H55e0vIcLhXplOKS0ZnRbQKWeo7O4byaafxpB3wXhbDP0koRJp /xWZse1abqXfATw5uXWvj5jspo9HdVsFbKZ0NGyB1M0wvO1irBu30k3x+RElGu2j338G xnREmaqx03M35CBMfS4w9JnNBCcKBJ3XW82JE0smPSS/25alc9siYFVmGzePcZhwYjQw J1mQ== X-Gm-Message-State: AFeK/H2djjL96h8mRJQqit1AeC64jd/nFOoLpvINWxmXaArG5b0vXJB6xGU8ALwVjfPRjTk4iz66geiqvVAjoA== X-Received: by 10.28.146.12 with SMTP id u12mr28952123wmd.142.1491563221032; Fri, 07 Apr 2017 04:07:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.203.196 with HTTP; Fri, 7 Apr 2017 04:07:00 -0700 (PDT) From: Shepard Siegel Date: Fri, 7 Apr 2017 07:07:00 -0400 Message-ID: To: moving@dpdk.org Content-Type: multipart/alternative; boundary=001a114434a0f33748054c919f42 Subject: [dpdk-moving] Atomic Rules interest in DPDK Lab Participation X-BeenThere: moving@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK community structure changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 11:07:02 -0000 --001a114434a0f33748054c919f42 Content-Type: text/plain; charset=UTF-8 Tim and DPDK Lab Group, Atomic Rules is a new DPDK/LF Member and is interested in participating in and contributing to the DPDK Lab effort. For over a year, about five engineers have been working to develop our Arkville product which will be announced publicly next month following 17.05. The elevator-pitch for Arkville is that it is a FPGA/GPP AXI/DPDK packet conduit. It is by design, line-rate and feature-agnostic. You can think of it as barebones FPGA-based NIC without any specific MAC. There is a blog post here: http://atomicrules.blogspot.com/2017/03/the-road-to-arkville.html Months ago we began to use DPDK/DTS as our testing regime. Then, as now, we require objective measures for correctness, throughput, and latency in our CI regression loop. We spent several frustrating months doing the following: Buy a bunch of Fortville/XL710s and servers; set up DTS and understand it; reach a baseline that shows out-of-the-box Fortville/XL710 performance. Instrument everything. Then; replace the Fortville DUT NIC with a work-alike Arkville DUT NIC and note the differences. This has not gone as smoothly as planned; as the DTS code is quite brittle to exact system configuration (e.g. numa zones and processor selection). We have learned from this and even built our own 4 x 100GbE Trex-ready packet player. (Thanks Cisco and Hanoch Haim) http://atomicrules.blogspot.com/2017/01/paced-packet-player.html This work remains incomplete and stalled on several technical fronts. Still, this is "toy" up against what this group is considering. I'm not sure that Atomic Rules has the resources to stand shoulder-to-shoulder with the giants in this group. But we are terrifically interested in finding a way to get the vital DPDK correctness, throughput, and latency measures we seek. We are located 40 minutes from the UNH IOL in Durham, NH, where we have participated in related interop events. It's a great space with sharp engineers and an army of bright interns and grad students. Please allow Atomic Rules to at least participate as an observer in the DPDK Lab project as we impedance-match to see if we can actually engage and contribute our software and hardware into this much-needed process. -Shep Shepard Siegel, CTO atomicrules.com On Fri, Apr 7, 2017 at 6:00 AM, wrote: > Send moving mailing list submissions to > moving@dpdk.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://dpdk.org/ml/listinfo/moving > or, via email, send a message with subject or body 'help' to > moving-request@dpdk.org > > You can reach the person managing the list at > moving-owner@dpdk.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of moving digest..." > > > Today's Topics: > > 1. DPDK Lab (O'Driscoll, Tim) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 7 Apr 2017 05:02:32 +0000 > From: "O'Driscoll, Tim" > To: "moving@dpdk.org" > Subject: [dpdk-moving] DPDK Lab > Message-ID: > <26FA93C7ED1EAA44AB77D62FBE1D27BA75A60870@IRSMSX108.ger. > corp.intel.com> > > Content-Type: text/plain; charset="us-ascii" > > A couple of months ago we discussed creating an open DPDK lab for > identifying performance regressions. See http://dpdk.org/ml/archives/ > moving/2017-February/000177.html for the initial proposal. We agreed to > form a small sub-team of those who were interested in participating in the > lab, and have had a few follow-up calls involving reps from Intel, > Mellanox, NXP, 6WIND and Red Hat. > > Because several companies have now joined the DPDK Linux Foundation > project who were not involved in those earlier discussions, we agreed at > our last meeting to post again on this mailing list to see if anybody else > is interested in participating. If anybody is, let me know and I'll include > you in the meetings. > > As background, the purpose of the lab is to identify any performance > regressions in patches that are submitted to DPDK. Testing when the patches > are submitted will help to identify problems early, and avoid situations > where we're trying to fix performance issues late in the release (as we > have been doing with the mbuf changes in 17.05 recently). Doing the testing > in an open lab will help to give people confidence in the numbers, and make > sure the data is accessible to the community. > > As a quick status update on this, we have an initial equipment list now > (see https://docs.google.com/spreadsheets/d/17t8j388wAxwF7B6iuZ5gpkauLMB1o > wnJe3eIVl4TXUg/edit?usp=sharing), and plan to focus on the specific tests > to be run at our next meeting. At the moment the spreadsheet specifies all > tests as being run on a daily basis, but we need to determine which can be > run per patch and/or per patch set. We're also investigating hosting costs > so that we can create a complete proposal that can then be submitted to the > governing board for review/approval. > > > Tim > > > > End of moving Digest, Vol 7, Issue 2 > ************************************ > --001a114434a0f33748054c919f42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tim and DPDK Lab Group,=

Atomic Rules is a new DPDK/LF Member and is interested in par= ticipating in and contributing to the DPDK Lab effort. For over a year, abo= ut five engineers have been working to develop our Arkville product which w= ill be announced publicly next month following 17.05. The elevator-pitch fo= r Arkville is that it is a FPGA/GPP AXI/DPDK packet conduit. It is by desig= n, line-rate and feature-agnostic. You can think of it as barebones FPGA-ba= sed NIC without any specific MAC. There is a blog post here:
http://a= tomicrules.blogspot.com/2017/03/the-road-to-arkville.html

= Months ago we began to use DPDK/DTS as our testing regime. Then, as now, we= require objective measures for correctness, throughput, and latency in our= CI regression loop. We spent several frustrating months doing the followin= g: Buy a bunch of Fortville/XL710s and servers; set up DTS and understand i= t; reach a baseline that shows out-of-the-box Fortville/XL710 performance. = Instrument everything. Then; replace the Fortville DUT NIC with a work-alik= e Arkville DUT NIC and note the differences. This has not gone as smoothly = as planned; as the DTS code is quite brittle to exact system configuration = (e.g. numa zones and processor selection). We have learned from this and ev= en built our own 4 x 100GbE Trex-ready packet player. (Thanks Cisco and Han= och Haim)
http://atomicrules.blogspot.com/2017/01/paced-packet-player.= html
This work remains incomplete and stalled on several = technical fronts.

Still, this is "toy" up= against what this group is considering. I'm not sure that Atomic Rules= has the resources to stand shoulder-to-shoulder with the giants in this gr= oup. But we are terrifically interested in finding a way to get the vital D= PDK correctness, throughput, and latency measures we seek. We are located 4= 0 minutes from the UNH IOL in Durham, NH, where we have participated in rel= ated interop events. It's a great space with sharp engineers and an arm= y of bright interns and grad students.

Please allow Atomic Rul= es to at least participate as an observer in the DPDK Lab project as we imp= edance-match to see if we can actually engage and contribute our software a= nd hardware into this much-needed process.

-Shep

= Shepard Siegel, CTO
atomicrules= .com



<= div class=3D"gmail_extra">
On Fri, Apr 7, 201= 7 at 6:00 AM, <moving-request@dpdk.org> wrote:
Send moving mailing list sub= missions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 moving@dpdk.= org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://dpdk.org/ml/listinfo/movin= g
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 movi= ng-request@dpdk.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 moving= -owner@dpdk.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of moving digest..."


Today's Topics:

=C2=A0 =C2=A01. DPDK Lab (O'Driscoll, Tim)


-----------------------------------------------------------------= -----

Message: 1
Date: Fri, 7 Apr 2017 05:02:32 +0000
From: "O'Driscoll, Tim" <tim.odriscoll@intel.com>
To: "moving@dpdk.org" <= moving@dpdk.org>
Subject: [dpdk-moving] DPDK Lab
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <26FA93C7ED1EAA44AB77D62FBE1D2= 7BA75A60870@IRSMSX108.ger.corp.intel.com>

Content-Type: text/plain; charset=3D"us-ascii"

A couple of months ago we discussed creating an open DPDK lab for identifyi= ng performance regressions. See http://d= pdk.org/ml/archives/moving/2017-February/000177.html for the = initial proposal. We agreed to form a small sub-team of those who were inte= rested in participating in the lab, and have had a few follow-up calls invo= lving reps from Intel, Mellanox, NXP, 6WIND and Red Hat.

Because several companies have now joined the DPDK Linux Foundation project= who were not involved in those earlier discussions, we agreed at our last = meeting to post again on this mailing list to see if anybody else is intere= sted in participating. If anybody is, let me know and I'll include you = in the meetings.

As background, the purpose of the lab is to identify any performance regres= sions in patches that are submitted to DPDK. Testing when the patches are s= ubmitted will help to identify problems early, and avoid situations where w= e're trying to fix performance issues late in the release (as we have b= een doing with the mbuf changes in 17.05 recently). Doing the testing in an= open lab will help to give people confidence in the numbers, and make sure= the data is accessible to the community.

As a quick status update on this, we have an initial equipment list now (se= e https://docs.google.com/spreadsheets/d/17t8j388wAxwF7B6iuZ5gp= kauLMB1ownJe3eIVl4TXUg/edit?usp=3Dsharing), and plan to focus= on the specific tests to be run at our next meeting. At the moment the spr= eadsheet specifies all tests as being run on a daily basis, but we need to = determine which can be run per patch and/or per patch set. We're also i= nvestigating hosting costs so that we can create a complete proposal that c= an then be submitted to the governing board for review/approval.


Tim



End of moving Digest, Vol 7, Issue 2
************************************

--001a114434a0f33748054c919f42--