From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wiles, Keith" Subject: Re: [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go Date: Thu, 15 Mar 2018 17:43:52 +0000 Message-ID: <9AEAD466-B9F9-4C6E-9CCF-D267CD90A53F@intel.com> References: <20180315091930.12b2a094@xeon-e3> <689D174B-0AF6-4661-920E-7356F18F2005@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "Melik-Adamyan, Areg" , "dev@dpdk.org" , "techboard@dpdk.org" , "Yigit, Ferruh" , "Richardson, Bruce" , "Ananyev, Konstantin" , "O'Driscoll, Tim" To: Stephen Hemminger Return-path: In-Reply-To: <689D174B-0AF6-4661-920E-7356F18F2005@intel.com> Content-Language: en-US Content-ID: <8F2B05D1B590EA4EBCD91813C4E6B9E1@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On Mar 15, 2018, at 12:29 PM, Wiles, Keith wrote: >=20 >=20 >=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 lib= rary and runtime named Network Function Framework for Go (NFF-Go: https://g= ithub.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 wi= th simple, powerful runtime. >>> NFF-Go library itself is not a set of wrappers over 'C' calls to DPDK a= s that would result in poor performance due to the 300-1500 cycles that can= 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 wh= ere DPDK works. >>> *Capabilities:* Library provides functions to create packet processing = graph from user-defined or predefined functions. The graph can be arbitrary= but will need to have a single entry point. The user can freely use both s= ynchronous and asynchronous programming capabilities provided by Go languag= e. Also, auto-scaling is automatically provided by the built-in scheduler u= sing cores as needed, and freeing them after use. NFF-Go provides an altern= ative development environment for creating network functions using a smalle= r number of lines of code compared to DPDK/C without sacrificing performanc= e. These capabilities make it possible to implement run-till-completion pac= ket processing model. The library includes a component called boundary nod= e, which allows consuming packet data from all types of sources: Ethernet, = file, memory buffer, remote procedure call and then applying the packets to= the processing graph which will be transparently deployed through any clou= d 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 DP= DK. Having a closer link between them should help both projects - it will e= ase pickup from one source/repo the needed set of features to be used, rath= er than us just providing a disjointed collection of software projects whic= h 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 a= nd tools to manipulate >>>=20 >>> - Flow - library to provide an abstraction for packet flows >>>=20 >>> - Scheduler - runtime and a scheduler for auto-scaling and int= egration 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 appli= cations on a single host >>>=20 >>> Thanks, >>> Areg Melik-Adamyan >>> Engineering Manager >>> Developer Products Divison >>> Intel Corporation >>=20 >> I am ok with it being on DPDK, but might it make more sense on github or= under FD.io? >> Or is there some legal and/or political reason not to? >=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 in= DPDK.org for maintains reason and I agree. >=20 > I would like to see us use a single GitHub account to house these differe= nt projects as then we would have a much cleaner one stop shopping for DPDK= related projects. We have the mirror for DPDK on GitHub https://github.com= /DPDK and we could easily add all of these projects in this organization ac= count as Thomas seems to be the only person attached to the account. We cou= ld then allow people to move projects to this account with the correct perm= ission 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. Here is the different models for pricing: https://github.com/pricing I would suggest Team account as it seems the cheapest as long as you have p= ublic repos and not a lot of private repos is how I read it. https://github.com/pricing/team >=20 >=20 >=20 > Regards, > Keith >=20 Regards, Keith