[dpdk-dev] Best Practices for PMD Verification before Upstream Requests

[dpdk-dev] Best Practices for PMD Verification before Upstream Requests

[Shepard Siegel]

Hi,


Atomic Rules is new to the DPDK community. We attended the DPDK Summit last
week and received terrific advice and encouragement. We are developing a
DPDK PMD for our Arkville product which is a DPDK-aware data mover, capable
of marshaling packets between FPGA/ASIC gates with AXI interfaces on one
side, and the DPDK API/ABI on the other. Arkville plus a MAC looks like a
line-rate-agnostic bare-bones L2 NIC. We have testpmd and our first DPDK
applications running using our early-alpha Arkville PMD.


This post is to ask of the DPDK community what tests, regressions,
check-lists or similar verification assets we might work through before
starting the process to upstream our code? We know device-specific PMDs are
rather cloistered and unlikely to interfere; but still, others must have
managed to find a way to fail with even an L2 baseline NIC.  We don’t want
to needlessly repeat those mistakes. Any DPDK-specific collateral that we
can use to verify and validate our codes before attempting to upstream them
would be greatly appreciated. To the DPDK PMD developers, what can you
share so that we are more aligned with your regressions? To the DPDK
application developers, what’s your top gripe we might try to avoid in our
Arkville L2 baseline PMD?


Thanks in advance. We won’t have anyone at the Dublin DPDK Summit, but we
will be at FPL2016 in two weeks. Any constructive feedback is greatly
appreciated!


Shepard Siegel, CTO

atomicrules.com


<http://atomicrules.com>

Re: [dpdk-dev] Best Practices for PMD Verification before Upstream Requests

[Thomas Monjalon]

2016-08-17 08:34, Shepard Siegel:
> Atomic Rules is new to the DPDK community. We attended the DPDK Summit last
> week and received terrific advice and encouragement. We are developing a
> DPDK PMD for our Arkville product which is a DPDK-aware data mover, capable
> of marshaling packets between FPGA/ASIC gates with AXI interfaces on one
> side, and the DPDK API/ABI on the other. Arkville plus a MAC looks like a
> line-rate-agnostic bare-bones L2 NIC. We have testpmd and our first DPDK
> applications running using our early-alpha Arkville PMD.

Welcome :)

Any release targeted for upstream support?

> This post is to ask of the DPDK community what tests, regressions,
> check-lists or similar verification assets we might work through before
> starting the process to upstream our code? We know device-specific PMDs are
> rather cloistered and unlikely to interfere; but still, others must have
> managed to find a way to fail with even an L2 baseline NIC.  We don’t want
> to needlessly repeat those mistakes. Any DPDK-specific collateral that we
> can use to verify and validate our codes before attempting to upstream them
> would be greatly appreciated. To the DPDK PMD developers, what can you
> share so that we are more aligned with your regressions? To the DPDK
> application developers, what’s your top gripe we might try to avoid in our
> Arkville L2 baseline PMD?

Are you aware of the DPDK test suite?
	http://dpdk.org/doc/dts/gsg/
	http://dpdk.org/browse/tools/dts/

I don't know how efficient it is for PMD developers and who use it.
I guess that DTS authors would like to have more feedbacks.

Re: [dpdk-dev] Best Practices for PMD Verification before Upstream Requests

[Shepard Siegel]

Thomas and DPDK devs,

Almost a year into our DPDK development, we have shipped an alpha version
of our "Arkville" product. We've thankful for all the support from this
group. Most everyone has suggested "get your code upstream ASAP"; but our
team is cut from the "if it isn't tested, it doesn't work" cloth. We now
have some solid miles on our Arkville PMD driver "ark" with 16.07. Mostly
testpmd and a suite of user apps; dts not so much, only because our use
case is a little different. We expect almost all of our contribution would
land under $dpdk/drivers/net/ark . We are looking past 16.11 to possibly
jump on board when the 17.02 window opens in December. One question that
came up is "Should we do a thorough port and regression against 16.11 as a
precursor to up streaming at 17.02?". Constructive feedback always welcome!

-Shep

Shepard Siegel, CTO
atomicrules.com

On Mon, Aug 22, 2016 at 9:07 AM, Thomas Monjalon <thomas.monjalon@6wind.com>
wrote:

> 2016-08-17 08:34, Shepard Siegel:
> > Atomic Rules is new to the DPDK community. We attended the DPDK Summit
> last
> > week and received terrific advice and encouragement. We are developing a
> > DPDK PMD for our Arkville product which is a DPDK-aware data mover,
> capable
> > of marshaling packets between FPGA/ASIC gates with AXI interfaces on one
> > side, and the DPDK API/ABI on the other. Arkville plus a MAC looks like a
> > line-rate-agnostic bare-bones L2 NIC. We have testpmd and our first DPDK
> > applications running using our early-alpha Arkville PMD.
>
> Welcome :)
>
> Any release targeted for upstream support?
>
> <snip>
>

Re: [dpdk-dev] Best Practices for PMD Verification before Upstream Requests

[Remy Horton]

On 02/11/2016 20:21, Shepard Siegel wrote:
[..]
> Almost a year into our DPDK development, we have shipped an alpha version
> of our "Arkville" product. We've thankful for all the support from this
> Most everyone has suggested "get your code upstream ASAP"; but our
> team is cut from the "if it isn't tested, it doesn't work" cloth. We now
> have some solid miles on our Arkville PMD driver "ark" with 16.07. Mostly
> testpmd and a suite of user apps; dts not so much, only because our use
> case is a little different.

To me that sounds good enough for a v1 patch.


> One question that
> came up is "Should we do a thorough port and regression against 16.11 as a
> precursor to up streaming at 17.02?". Constructive feedback always welcome!

It is helpful, although bear in mind there is only so much you'll be 
able to test. Patches sent to the mailing list are picked up by 
patchwork for automated testing, so you'll find out quite quickly if 
you've broken something.

And avoid top-posting.. :)

..Remy