[dpdk-moving] Atomic Rules interest in DPDK Lab Participation

[dpdk-moving] Atomic Rules interest in DPDK Lab Participation

[Shepard Siegel]

[-- Attachment #1: Type: text/plain, Size: 5154 bytes --]

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, <moving-request@dpdk.org> 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" <tim.odriscoll@intel.com>
> To: "moving@dpdk.org" <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
> ************************************
>

[-- Attachment #2: Type: text/html, Size: 6910 bytes --]

Re: [dpdk-moving] Atomic Rules interest in DPDK Lab Participation

[O'Driscoll, Tim]

[-- Attachment #1: Type: text/plain, Size: 5732 bytes --]

No problem Shep. I’ll add you to the meetings on this and we can work out if and how Atomic Rules fit into this initiative.


Tim

From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of Shepard Siegel
Sent: Friday, April 7, 2017 12:07 PM
To: moving@dpdk.org
Subject: [dpdk-moving] Atomic Rules interest in DPDK Lab Participation

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<http://atomicrules.com>



On Fri, Apr 7, 2017 at 6:00 AM, <moving-request@dpdk.org<mailto:moving-request@dpdk.org>> wrote:
Send moving mailing list submissions to
        moving@dpdk.org<mailto: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<mailto:moving-request@dpdk.org>

You can reach the person managing the list at
        moving-owner@dpdk.org<mailto: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" <tim.odriscoll@intel.com<mailto:tim.odriscoll@intel.com>>
To: "moving@dpdk.org<mailto:moving@dpdk.org>" <moving@dpdk.org<mailto:moving@dpdk.org>>
Subject: [dpdk-moving] DPDK Lab
Message-ID:
        <26FA93C7ED1EAA44AB77D62FBE1D27BA75A60870@IRSMSX108.ger.corp.intel.com<mailto: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/17t8j388wAxwF7B6iuZ5gpkauLMB1ownJe3eIVl4TXUg/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
************************************


[-- Attachment #2: Type: text/html, Size: 10489 bytes --]