From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by dpdk.org (Postfix) with ESMTP id D70F38E80 for ; Tue, 13 Oct 2015 06:02:15 +0200 (CEST) Received: by lbcao8 with SMTP id ao8so5269660lbc.3 for ; Mon, 12 Oct 2015 21:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ndORr+sGtzlRQR37/HTq8kh+dei6rYbvlZSFW8FDrbQ=; b=cEUfD9fhEit5S7NFo1Jrmrq0HcVh+WUW3Lk2p2e7BHsWbi9zvYODE/L4syrkFQZma/ qpZE8zIizK2/4aFlORqiTSp2EkIA1RgldeBBpa44lHdx/EI7k2Ql/RdlJ9RfF1rMT2yr WLhYK14tVEbqIwA9dQfbDMbZwRKyar1SxWl1QeVSmyGSHuYTzKE34uFLnXWhwy1kVR7g OeuqdTHO5TY2pQXDw+rB6uxEOpZgMbqKBou13MdRXkCN1Ojirjj5y4IP12IsebZMoXBW CYKssS5mZTIcXJcEaKLF+aAqDKrgvsMloDkXWpUWwg1IDQWFkdIxokXVibcaJ7IEPv12 /TTw== MIME-Version: 1.0 X-Received: by 10.25.28.73 with SMTP id c70mr7631390lfc.76.1444708935440; Mon, 12 Oct 2015 21:02:15 -0700 (PDT) Received: by 10.25.19.37 with HTTP; Mon, 12 Oct 2015 21:02:15 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Oct 2015 21:02:15 -0700 Message-ID: From: Vincent Li To: "Wiles, Keith" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Network Stack discussion notes from 2015 DPDK Userspace X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 04:02:16 -0000 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 wrote: > Here are some notes from the DPDK Network Stack discussion, I can remembe= r 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 poss= ibly lower latency > * Meaning the developer is willing to re-write or write his applic= ation to get the best performance. > * A TCP/IPv4/v6 stack is the minimum stack we need to support applica= tions 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 li= nked to DPDK > * For DPDK the customer is looking for fast applications and is willi= ng to write the application just for DPDK network stack > * Converting an existing application could be done, but the desig= n 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 per= formance 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 u= sing 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 Source= d) > * The stack should be up to date with the latest RFCs or at lea= st 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 performanc= e) > * 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 sam= e system. > * The new IPC path should be agnostic to local or remote end po= ints > * 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. > > =E2=80=94 > Regards, > ++Keith Wiles > Intel Corporation