Re: [dpdk-dev] [dpdk-techboard] Request to create a repo under DPDK for Network Function Framework for Go

["Wiles, Keith" <keith.wiles@intel.com>]

Sorry, did not mean to highjack this thread, I will start a new one.

> On Mar 15, 2018, at 12:48 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
> On Thu, 15 Mar 2018 17:29:44 +0000
> "Wiles, Keith" <keith.wiles@intel.com> wrote:
> 
>>> 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
>> 
> 
> 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.

Regards,
Keith