From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 922B45961 for ; Sat, 10 Oct 2015 01:19:08 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 09 Oct 2015 16:19:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,660,1437462000"; d="scan'208";a="577638238" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by FMSMGA003.fm.intel.com with ESMTP; 09 Oct 2015 16:19:07 -0700 Received: from fmsmsx118.amr.corp.intel.com (10.18.116.18) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Fri, 9 Oct 2015 16:19:07 -0700 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.155]) by fmsmsx118.amr.corp.intel.com ([169.254.1.85]) with mapi id 14.03.0248.002; Fri, 9 Oct 2015 16:19:07 -0700 From: "Wiles, Keith" To: "dev@dpdk.org" Thread-Topic: Network Stack discussion notes from 2015 DPDK Userspace Thread-Index: AQHRAujlp1LfzbTNW0iL3v16Yvce9Q== Date: Fri, 9 Oct 2015 23:19:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.252.8.108] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8C01690BECFF464FAEB69C2374DDE1BC@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [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: Fri, 09 Oct 2015 23:19:09 -0000 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 possib= ly lower latency * Meaning the developer is willing to re-write or write his applicat= ion to get the best performance. * A TCP/IPv4/v6 stack is the minimum stack we need to support applicati= ons 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 link= ed 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 perfo= rmance 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 usi= ng 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 t= o 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 ba= se) and its environment for best performance * Need to be able to configure the DPDK stack(s) from the Linux c= ommand line tools if possible * Need a DPDK specific application layer API for application to i= nterface with the network stack * Could have a socket layer API on top of the specific API for ap= plications needing to use sockets (not expected to be the best performance) * The second item is figuring out a new IPC for East/West traffic wi= thin the same system. * The design needs to improve performance between applications an= d 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 poin= ts * Needs to be very fast compared to current Linux IPC designs. (W= ill OVS work here?) Did I miss any details or comments, please reply and help me correct the co= mment or understanding. Thanks for everyone attending and packing into a small space. =97 Regards, ++Keith Wiles Intel Corporation