Hi Avi, On 05/07/2015 04:02 PM, Avi Kivity wrote: > 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 > I fully agree with this analysis/proposal. And I think that: - the associated modifications should be done ASAP, - the underlying design rules that this proposal refers to should drive the design and review of new DPDK features.
Regards, Ivan
