From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com [74.125.83.41]) by dpdk.org (Postfix) with ESMTP id 29A8C7CE7 for ; Thu, 15 Mar 2018 18:49:00 +0100 (CET) Received: by mail-pg0-f41.google.com with SMTP id s13so3034055pgn.12 for ; Thu, 15 Mar 2018 10:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=QL4945FbOcySb9zIFmKoZ3GMWfB5H7UM/D/jqsSsqnI=; b=xybEUpZZ85EtPkTQKmIBM/aeObJQC9aip8VvWPc/57UOObJ4qQv8sXPwHM0/Pi0VRu y3+qd5WM9s/8kf/ciBCu97mPVzsl12ZOgZqPa4ASsEQaz4kkteA585NbvlWpqa5TV9RR o2X3WrdHp7+6774C2tL3Dy63Fbfr53UCgdljokesFSQn/bGkZ8POuYRDisyIRw5WrVR3 6gxiNonQLByGN1DcPANgq5RKIAWRE6oGi+Tv6mf0lCIL+IybMGwS+kfPWxB32jva8Tkr CEmkyZd96KIlx5xQiY0j9Uo98Knr8XHr9VYK6fIebcq8LcLj8UJyoSbjwtGDKpED6IlR QPkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=QL4945FbOcySb9zIFmKoZ3GMWfB5H7UM/D/jqsSsqnI=; b=VI5re5qMr5xFKs3wmY0yYFkKVFozjdnOlIX6OGowksNsgqX2xtIqzP2IzDs+IifFPb bSdGdXax7bWhvrNJFZa2ObFodP//C0QbJpw/tW1mBDI/nV6Xm7kzAy/xK0A2wKiGNdxM +EtEtsMRSCI3E1OowYw7mXUzSQ5KxfrtkF0sFwIEtQBLA54U2nIRtmWCeX3DMaf2631p 9Pw0QTJ6wNE570P1WXr9JMC8hX+gOckcROn3XsyEzgT3I63QtKzOhWkI8WszX2O5e5as qEQdBx2aN662Cad78o2hsgPn+PUJunjZchGzi1agROfNrPRY+yP8mykkoJVsh+gPqVNm NAYQ== X-Gm-Message-State: AElRT7GCHrmWPmhmogRW27hwPm7g+yKtbypBMoyM89kQg8LvuKEKOXz7 7j5OnCdISWNCOlyxcN6wCfJTfg== X-Google-Smtp-Source: AG47ELuvPyQQCL69BKUin11vVR88UX5gi73uzfVtXHEFUwItS6J9dNnsOyUsvNxd1KvahDWy8UlP9g== X-Received: by 10.101.100.141 with SMTP id e13mr7514777pgv.333.1521136139076; Thu, 15 Mar 2018 10:48:59 -0700 (PDT) Received: from xeon-e3 (204-195-71-95.wavecable.com. [204.195.71.95]) by smtp.gmail.com with ESMTPSA id r138sm9444101pgr.63.2018.03.15.10.48.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 15 Mar 2018 10:48:58 -0700 (PDT) Date: Thu, 15 Mar 2018 10:48:51 -0700 From: Stephen Hemminger To: "Wiles, Keith" Cc: "Melik-Adamyan, Areg" , "dev@dpdk.org" , "techboard@dpdk.org" , "Yigit, Ferruh" , "Richardson, Bruce" , "Ananyev, Konstantin" , "O'Driscoll, Tim" Message-ID: <20180315104851.444da4d1@xeon-e3> In-Reply-To: <689D174B-0AF6-4661-920E-7356F18F2005@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: 7bit 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 17:49:00 -0000 On Thu, 15 Mar 2018 17:29:44 +0000 "Wiles, Keith" wrote: > > On Mar 15, 2018, at 11:19 AM, Stephen Hemminger wrote: > > > > On Thu, 15 Mar 2018 16:15:21 +0000 > > "Melik-Adamyan, Areg" wrote: > > > >> Hello. > >> > >> Within Intel, we developed and open-sourced a DPDK based high-level library 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 with 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 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 where 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 synchronous and asynchronous programming capabilities provided by Go language. Also, auto-scaling is automatically provided by the built-in scheduler using cores as needed, and freeing them after use. NFF-Go provides an alternative development environment for creating network functions using a smaller number of lines of code compared to DPDK/C without sacrificing performance. These capabilities make it possible to implement run-till-completion packet processing model. The library includes a component called boundary node, 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 cloud 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 DPDK. 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, rather than us just providing a disjointed collection of software projects which are hosted in different places. > >> > >> We expect the initial commit to include the following: > >> > >> - Low, Asm - low-level C and ASM code for gluing DPDK > >> > >> - Packet - a library that provides an abstraction for packet and tools to manipulate > >> > >> - Flow - library to provide an abstraction for packet flows > >> > >> - Scheduler - runtime and a scheduler for auto-scaling and integration with RSS > >> > >> - Examples: > >> > >> o Forwarding - simple L3 forwarding > >> > >> o Firewall - an example of simple ACL based firewall > >> > >> o Tutorial - step based tutorial how to use NFF-Go > >> > >> o NAT - an example of production grade Network Address Translation > >> > >> o AntiDDOS - simple example of AntiDDOS on L3 > >> > >> - Automation scripts - helping to build, deploy and test applications on a single host > >> > >> Thanks, > >> Areg Melik-Adamyan > >> Engineering Manager > >> Developer Products Divison > >> Intel Corporation > > > > 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? > > There is no legal or political reason is my guess and only because it is closely connected to DPDK is the reason. > > 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. > > I would like to see us use a single GitHub account to house these different 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 account as Thomas seems to be the only person attached to the account. We could then allow people to move projects to this account with the correct permission or restrictions as we see fit and allow other (TAC member?) to help manage the account. > > It may cost some money at some point, but I have not looked into it more then a year. > > > > Regards, > Keith > I was thinking more that projects on DPDK should use similar software process. If you go to another location, you would use their Pull Request and review model. If the project is under Intel, they would have the github account; I known Microsoft has one github for all their projects.