From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by dpdk.org (Postfix) with ESMTP id CA53B728A; Thu, 15 Mar 2018 19:01:41 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2018 11:01:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,311,1517904000"; d="scan'208";a="24842270" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga008.fm.intel.com with ESMTP; 15 Mar 2018 11:01:40 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 15 Mar 2018 11:01:40 -0700 Received: from fmsmsx117.amr.corp.intel.com ([169.254.3.171]) by fmsmsx115.amr.corp.intel.com ([169.254.4.14]) with mapi id 14.03.0319.002; Thu, 15 Mar 2018 11:01:40 -0700 From: "Wiles, Keith" To: Stephen Hemminger CC: "Melik-Adamyan, Areg" , "dev@dpdk.org" , "techboard@dpdk.org" , "Yigit, Ferruh" , "Richardson, Bruce" , "Ananyev, Konstantin" , "O'Driscoll, Tim" Thread-Topic: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go Thread-Index: AdO8CNIRrZ07R+IHTYWSRS2WXmp6awAb+8+AAA7UFQAAAnPKgAAAqxCAAABycYA= Date: Thu, 15 Mar 2018 18:01:39 +0000 Message-ID: <23A20F81-3A57-4916-BC1F-6DC7ED09F73E@intel.com> References: <20180315091930.12b2a094@xeon-e3> <689D174B-0AF6-4661-920E-7356F18F2005@intel.com> <20180315104851.444da4d1@xeon-e3> In-Reply-To: <20180315104851.444da4d1@xeon-e3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.71.6] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 18:01:43 -0000 Sorry, did not mean to highjack this thread, I will start a new one. > On Mar 15, 2018, at 12:48 PM, Stephen Hemminger wrote: >=20 > On Thu, 15 Mar 2018 17:29:44 +0000 > "Wiles, Keith" wrote: >=20 >>> On Mar 15, 2018, at 11:19 AM, Stephen Hemminger wrote: >>>=20 >>> On Thu, 15 Mar 2018 16:15:21 +0000 >>> "Melik-Adamyan, Areg" wrote: >>>=20 >>>> Hello. >>>>=20 >>>> Within Intel, we developed and open-sourced a DPDK based high-level li= brary and runtime named Network Function Framework for Go (NFF-Go: https://= github.com/intel-go/nff-go) which is intended to simplify packet processing= applications, especially for cloud-native deployment. Based on DPDK NFF-Go= provides higher-level packet processing functions in native Go alongside w= ith simple, powerful runtime. >>>> NFF-Go library itself is not a set of wrappers over 'C' calls to DPDK = as that would result in poor performance due to the 300-1500 cycles that ca= n be spent by a context switch. Instead, NFF-Go uses pointers from the DPDK= initialization of the device mbuf structures. It permits copying of packet= data between Go's safe and DPDK/C unsafe memory. NFF-Go works everywhere w= here DPDK works. >>>> *Capabilities:* Library provides functions to create packet processing= graph from user-defined or predefined functions. The graph can be arbitrar= y but will need to have a single entry point. The user can freely use both = synchronous and asynchronous programming capabilities provided by Go langua= ge. Also, auto-scaling is automatically provided by the built-in scheduler = using cores as needed, and freeing them after use. NFF-Go provides an alter= native development environment for creating network functions using a small= er number of lines of code compared to DPDK/C without sacrificing performan= ce. These capabilities make it possible to implement run-till-completion pa= cket processing model. The library includes a component called boundary no= de, which allows consuming packet data from all types of sources: Ethernet,= file, memory buffer, remote procedure call and then applying the packets t= o the processing graph which will be transparently deployed through any clo= ud orchestration engine. >>>> *Benefit* NFF-Go is based on the DPDK and lowers the entry barrier for= bringing packet processing to less experienced developers and push towards= cloud-native usages. We strongly believe that NFF-Go is complementary to D= PDK. Having a closer link between them should help both projects - it will = ease pickup from one source/repo the needed set of features to be used, rat= her than us just providing a disjointed collection of software projects whi= ch are hosted in different places. >>>>=20 >>>> We expect the initial commit to include the following: >>>>=20 >>>> - Low, Asm - low-level C and ASM code for gluing DPDK >>>>=20 >>>> - Packet - a library that provides an abstraction for packet = and tools to manipulate >>>>=20 >>>> - Flow - library to provide an abstraction for packet flows >>>>=20 >>>> - Scheduler - runtime and a scheduler for auto-scaling and in= tegration with RSS >>>>=20 >>>> - Examples: >>>>=20 >>>> o Forwarding - simple L3 forwarding >>>>=20 >>>> o Firewall - an example of simple ACL based firewall >>>>=20 >>>> o Tutorial - step based tutorial how to use NFF-Go >>>>=20 >>>> o NAT - an example of production grade Network Address Translation >>>>=20 >>>> o AntiDDOS - simple example of AntiDDOS on L3 >>>>=20 >>>> - Automation scripts - helping to build, deploy and test appl= ications on a single host >>>>=20 >>>> Thanks, >>>> Areg Melik-Adamyan >>>> Engineering Manager >>>> Developer Products Divison >>>> Intel Corporation =20 >>>=20 >>> I am ok with it being on DPDK, but might it make more sense on github o= r under FD.io? >>> Or is there some legal and/or political reason not to? =20 >>=20 >> There is no legal or political reason is my guess and only because it is= closely connected to DPDK is the reason. >>=20 >> I know that DPDK TAC and others are not wanting to have a lot of repos i= n DPDK.org for maintains reason and I agree. >>=20 >> I would like to see us use a single GitHub account to house these differ= ent projects as then we would have a much cleaner one stop shopping for DPD= K related projects. We have the mirror for DPDK on GitHub https://github.co= m/DPDK and we could easily add all of these projects in this organization a= ccount as Thomas seems to be the only person attached to the account. We co= uld then allow people to move projects to this account with the correct per= mission or restrictions as we see fit and allow other (TAC member?) to help= manage the account. >>=20 >> It may cost some money at some point, but I have not looked into it more= then a year. >>=20 >>=20 >>=20 >> Regards, >> Keith >>=20 >=20 > I was thinking more that projects on DPDK should use similar software pro= cess. > If you go to another location, you would use their Pull Request and revie= w model. > If the project is under Intel, they would have the github account; I know= n Microsoft has one github for all their projects. Regards, Keith