Re: [dpdk-dev] Beyond DPDK 2.0

["Wiles, Keith" <keith.wiles@intel.com>]

Hi Luke

On 5/7/15, 8:34 AM, "Luke Gorrie" <luke@snabb.co> wrote:

>On 7 May 2015 at 16:02, Avi Kivity <avi@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.

Would the shared library support in DPDK be useful here? I know it still
links in a dynamic way.

I believe DPDK is much like your snabbswitch as it provides a basic system
to run networking applications, in your case a vSwitch like design. The
design has some parts that are standalone, but to be effective they
require other parts of DPDK to work correctly. If you have some suggestion
as to how DPDK could be split up and maintain its features and performance
I would like to understand how.

Regards,
++Keith

>
>[1] https://github.com/lukego/snabbswitch/blob/README/README.md