On Wed, Apr 22, 2015 at 6:11 PM, O'Driscoll, Tim <tim.o'driscoll at intel.com> wrote:
> Does anybody have any input or comments on this? > > > > -----Original Message----- > > From: O'Driscoll, Tim > > Sent: Thursday, April 16, 2015 11:39 AM > > To: dev at dpdk.org > > Subject: Beyond DPDK 2.0 > > > > Following the launch of DPDK by Intel as an internal development > > project, the launch of dpdk.org by 6WIND in 2013, and the first DPDK RPM > > packages for Fedora in 2014, 6WIND, Red Hat and Intel would like to > > prepare for future releases after DPDK 2.0 by starting a discussion on > > its evolution. Anyone is welcome to join this initiative. > > > > Since then, the project has grown significantly: > > - The number of commits and mailing list posts has increased > > steadily. > > - Support has been added for a wide range of new NICs (Mellanox > > support submitted by 6WIND, Cisco VIC, Intel i40e and fm10k etc.). > > - DPDK is now supported on multiple architectures (IBM Power support > > in DPDK 1.8, Tile support submitted by EZchip but not yet reviewed or > > applied). > > > > While this is great progress, we need to make sure that the project is > > structured in a way that enables it to continue to grow. To achieve > > this, 6WIND, Red Hat and Intel would like to start a discussion about > > the future of the project, so that we can agree and establish processes > > that satisfy the needs of the current and future DPDK community. > > > > We're very interested in hearing the views of everybody in the > > community. In addition to debate on the mailing list, we'll also > > schedule community calls to discuss this. > > > > > > Project Goals > > ------------- > > > > Some topics to be considered for the DPDK project include: > > - Project Charter: The charter of the DPDK project should be clearly > > defined, and should explain the limits of DPDK (what it does and does > > not cover). This does not mean that we would be stuck with a singular > > charter for all time, but the direction and intent of the project should > > be well understood. > One problem we've seen with dpdk is that it is a framework, not a library: it wants to create threads, manage memory, and generally take over. This is a problem for us, as we are writing a framework (seastar, [1]) and need to create threads, manage memory, and generally take over ourselves. Perhaps dpdk can be split into two layers, a library layer that only provides mechanisms, and a framework layer that glues together those mechanisms and applies a policy, trading in generality for ease of use. [1] http://seastar-project.org