DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wiles, Keith" <keith.wiles@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "Melik-Adamyan, Areg" <areg.melik-adamyan@intel.com>,
	"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 17:29:44 +0000	[thread overview]
Message-ID: <689D174B-0AF6-4661-920E-7356F18F2005@intel.com> (raw)
In-Reply-To: <20180315091930.12b2a094@xeon-e3>



> On Mar 15, 2018, at 11:19 AM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
> 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?

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

  reply	other threads:[~2018-03-15 17:29 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 ` [dpdk-dev] [dpdk-techboard] " Stephen Hemminger
2018-03-15 17:29   ` Wiles, Keith [this message]
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=689D174B-0AF6-4661-920E-7356F18F2005@intel.com \
    --to=keith.wiles@intel.com \
    --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=stephen@networkplumber.org \
    --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).