From: Stephen Hemminger <stephen@networkplumber.org>
To: "Melik-Adamyan, Areg" <areg.melik-adamyan@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"techboard@dpdk.org" <techboard@dpdk.org>,
"Yigit, Ferruh" <ferruh.yigit@intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"O'Driscoll, Tim" <tim.odriscoll@intel.com>
Subject: Re: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go
Date: Thu, 15 Mar 2018 09:19:30 -0700 [thread overview]
Message-ID: <20180315091930.12b2a094@xeon-e3> (raw)
In-Reply-To: <ABCD154DCB698E4BA9B0815185C1385FACAD353A@fmsmsx104.amr.corp.intel.com>
On Thu, 15 Mar 2018 16:15:21 +0000
"Melik-Adamyan, Areg" <areg.melik-adamyan@intel.com> 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?
next prev parent reply other threads:[~2018-03-15 16:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 16:15 [dpdk-dev] " Melik-Adamyan, Areg
2018-03-15 16:19 ` Stephen Hemminger [this message]
2018-03-15 17:29 ` [dpdk-dev] [dpdk-techboard] " Wiles, Keith
2018-03-15 17:43 ` Wiles, Keith
2018-03-15 18:04 ` [dpdk-dev] GitHub repos for DPDK projects in one place Wiles, Keith
2018-03-15 17:48 ` [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go Stephen Hemminger
2018-03-15 18:01 ` Wiles, Keith
2018-03-15 20:58 ` Melik-Adamyan, Areg
2018-03-15 20:52 ` Melik-Adamyan, Areg
2018-04-24 9:31 ` [dpdk-dev] " Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180315091930.12b2a094@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=areg.melik-adamyan@intel.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=techboard@dpdk.org \
--cc=tim.odriscoll@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).