Sorry, did not mean to highjack this thread, I will start a new one. > On Mar 15, 2018, at 12:48 PM, Stephen Hemminger <step...@networkplumber.org> > wrote: > > On Thu, 15 Mar 2018 17:29:44 +0000 > "Wiles, Keith" <keith.wi...@intel.com> wrote: > >>> On Mar 15, 2018, at 11:19 AM, Stephen Hemminger >>> <step...@networkplumber.org> wrote: >>> >>> On Thu, 15 Mar 2018 16:15:21 +0000 >>> "Melik-Adamyan, Areg" <areg.melik-adam...@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
