Network Stack discussion notes from 2015 DPDK Userspace

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

Here are some notes from the DPDK Network Stack discussion, I can remember please help me fill in anything I missed.

Items I remember we talked about:

  *   The only reason for a DPDK TCP/IP stack is for performance and possibly lower latency
     *   Meaning the developer is willing to re-write or write his application to get the best performance.
  *   A TCP/IPv4/v6 stack is the minimum stack we need to support applications linked with DPDK.
     *   SCTP is also another protocol that maybe required
     *   TCP is the primary protocol, usage model for most use cases
     *   Stack must be able to terminate TCP traffic to an application linked to DPDK
  *   For DPDK the customer is looking for fast applications and is willing to write the application just for DPDK network stack
     *   Converting an existing application could  be done, but the design is for performance and may require a lot of changes to an application
     *   Using an application API that is not Socket is fine for high performance and maybe the only way we get best performance.
     *   Need to supply a Socket layer interface as a option if customer is willing to take a performance hit instead of rewriting the application
  *   Native application acceleration is desired, but not required when using DPDK network stack
  *   We have two projects related to network stack in DPDK
     *   The first one is porting some TCP/IP stack to DPDK plus it needs to give a reasonable performance increase over native Linux applications
        *   The stack code needs to be BSD/MIT like licensed (Open Sourced)
        *   The stack should be up to date with the latest RFCs or at least close
        *   A stack could be written for DPDK (not using a existing code base) and its environment for best performance
        *   Need to be able to configure the DPDK stack(s) from the Linux command line tools if possible
        *   Need a DPDK specific application layer API for application to interface with the network stack
        *   Could have a socket layer API on top of the specific API for applications needing to use sockets (not expected to be the best performance)
     *   The second item is figuring out a new IPC for East/West traffic within the same system.
        *   The design needs to improve performance between applications and be transparent to the application when the remote end is not on the same system.
        *   The new IPC path should be agnostic to local or remote end points
        *   Needs to be very fast compared to current Linux IPC designs. (Will OVS work here?)

Did I miss any details or comments, please reply and help me correct the comment or understanding.

Thanks for everyone attending and packing into a small space.

—
Regards,
++Keith Wiles
Intel Corporation