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/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
************************************