DPDK patches and discussions
 help / color / mirror / Atom feed
From: Vincent Li <vincent.mc.li@gmail.com>
To: "Wiles, Keith" <keith.wiles@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Network Stack discussion notes from 2015 DPDK Userspace
Date: Mon, 12 Oct 2015 21:02:15 -0700	[thread overview]
Message-ID: <CAK3+h2zSiAH27M7vFFtv81WvR3SSMuezsQacue2i8esVqWZ2gQ@mail.gmail.com> (raw)
In-Reply-To: <D23E0732.5942%keith.wiles@intel.com>

I tested mTCP and have positive result with it
https://github.com/eunyoung14/mtcp, I used the sample app epwget as a
tcp load generator, it can generate million of concurrent tcp
connection on used cheap Dell server with Intel I350 NIC or Intel
82576

On Fri, Oct 9, 2015 at 4:19 PM, Wiles, Keith <keith.wiles@intel.com> wrote:
> 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

      parent reply	other threads:[~2015-10-13  4:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-09 23:19 Wiles, Keith
2015-10-12  8:50 ` Avi Kivity
2015-10-13  4:02 ` Vincent Li [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK3+h2zSiAH27M7vFFtv81WvR3SSMuezsQacue2i8esVqWZ2gQ@mail.gmail.com \
    --to=vincent.mc.li@gmail.com \
    --cc=dev@dpdk.org \
    --cc=keith.wiles@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).