Re: Request to create a repo under DPDK for Network Function Framework for Go

Re: Request to create a repo under DPDK for Network Function Framework for Go

[Melik-Adamyan, Areg]

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

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

[Stephen Hemminger]

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?

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

[Wiles, Keith]

> 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

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

[Wiles, Keith]

> On Mar 15, 2018, at 12:29 PM, 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.

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

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

[Stephen Hemminger]

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 ty
 pes 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.

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

[Wiles, Keith]

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

GitHub repos for DPDK projects in one place.

[Wiles, Keith]

On Mar 15, 2018, at 12:43 PM, Wiles, Keith <keith.wiles@intel.com> wrote:
> 
> 
> 
>> On Mar 15, 2018, at 12:29 PM, Wiles, Keith <keith.wiles@intel.com> wrote:
>> 
>> 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

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

[Melik-Adamyan, Areg]

>It may cost some money at some point, but I have not looked into it more than a year.
Our org can pay for the team account if needed, but free org account on Github has the same capabilities except for team permissions. 

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

[Melik-Adamyan, Areg]

-----Original Message-----
From: Stephen Hemminger [mailto:stephen@networkplumber.org] 
Sent: Thursday, March 15, 2018 12:49 PM
To: Wiles, Keith <keith.wiles@intel.com>
Cc: Melik-Adamyan, Areg <areg.melik-adamyan@intel.com>; dev@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

>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 there is a need then you can use both models: patch and PRs as several other projects do, e.g. Go itself, they use both Gerrit on googlesource.com and accept PRs on Github. 

Re: Request to create a repo under DPDK for Network Function Framework for Go

[Thomas Monjalon]

Hi,

15/03/2018 17:15, Melik-Adamyan, Areg:
> 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.

I don't see any reply to this thread, so I update:

The DPDK boards have accepted to host this project on dpdk.org.

Please send me the name of the committer, its SSH public key
and the name of the repository to create (nff-go?).

Thank you