On 7 May 2015 at 16:02, Avi Kivity <avi at cloudius-systems.com> wrote:
> 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. > That is also broadly why we don't currently use DPDK in Snabb Switch [1]. There is a bunch of functionality in DPDK that would be tempting for us to use and contribute back to: device drivers, SIMD routines, data structures, and so on. I think that we would do this if they were available piecemeal as stand-alone libi40e, libsimd, liblpn, etc. The whole DPDK platform/framework is too much for us to adopt though. Some aspects of it are in conflict with our goals and it is an all-or-nothing proposition. So for now we are staying self-sufficient even when it means writing our own ixgbe replacement, etc. Having said that we are able to share code that doesn't require linking into our address space e.g. vhost-user and potentially the bifurcated drivers in the future. That seems like a nice direction for things to be going in and a way to collaborate even without our directly linking with DPDK. [1] https://github.com/lukego/snabbswitch/blob/README/README.md
