> On Mar 15, 2018, at 12:29 PM, 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.
Here is the different models for pricing: https://github.com/pricing I would suggest Team account as it seems the cheapest as long as you have public repos and not a lot of private repos is how I read it. https://github.com/pricing/team > > > > Regards, > Keith > Regards, Keith
