OPNFV DPACC working group is trying to standardize the accelerator interface for vNFs to accelerate the workloads.
Accelerator standardization is required to ensure that the virtual appliances can work on different types of compute nodes - Compute nodes having no acceleration hardware, compute nodes having accelerator hardware from vendor 1, compute nodes having accelerator hardware from vendor 2 etc..
Above becomes critical in cloud environments as compute node hardware is procured independent of procurement of virtual appliances. Virtual appliance vendors like to have their virtual appliances' images work on multiple compute nodes. Operators likes to ensure that any virtual appliances they purchase continue to work with future compute node hardware.
OPNFV DPACC team goal is to identify various acceleration types. And then define software based interface for each acceleration type.
VMM which is typically bound to the compute node hardware is expected to have conversion module from the software interface to local hardware interface.
OPNFV DPACC team is choosing virtio and vring transport to implement software interface.
Accelerations normally fall into two categories - Look-aside model and Inline/fast-path model. In Look-aside model, virtual appliance software sends command to the accelerator and expect response for each command. The response can come back to virtual appliance in synchronous fashion or asynchronous fashion. Inline/fast-path model typically is for packet processing kind of vNFs. Any network function that does not need to inspect all the packets can take advantage of inline/fast-path acceleration model.
In inline/fast-path acceleration model, network function in virtual appliance establishes a session state (either pro-actively or re-actively to the packets) and then it expects the fast-path accelerator to process further packets.
Many smart-NIC vendors provide facilities to their customers to create fast-path functions in the smart-NIC. In physical appliances, typically this works best. Physical appliances are fixed functions and the entire software and hardware comes from one vendor. This vendor would ensure that both normal network function and fast-path functions work together.
In virtual world, smart-NIC comes from one vendor and virtual appliances come from separate vendors. Also, it is unknown at smart-NIC build time, the network functions that would be hosted on the compute node. It may seem that smart-NIC vendors need to have all types of fast-path functions implemented in the smart-NIC. It is obvious that it is not feasible and the smart-NIC may not have too much of code space to put all kinds of fast-path functions. Note that, smart-NIC could be based on FPGA or constrained network processor.
Another model could be that smart-NIC is populated dynamically with fast-path functions based on the type of virtual appliances are being brought up on that node. This also could be a problematic as there could be multiple smart-NIC vendors using various processors/network-processors/FPGA etc.. Hence, one may need to create similar fast path functions for many smart-NIC types. There is always security & reliability issues as these functions may not co-exist s they come from various vendors. Some function may misbehave or some functions might crash other functions. In addition, there is always a concern on amount of time it adds to bringing up and bringing down the virtual appliance.
Hence, some in OPNFV DPACC team believe that smart-NIC must implement flow processor such as openflow. Openflow has very good advantages, Some of them are :
Accelerator standardization is required to ensure that the virtual appliances can work on different types of compute nodes - Compute nodes having no acceleration hardware, compute nodes having accelerator hardware from vendor 1, compute nodes having accelerator hardware from vendor 2 etc..
Above becomes critical in cloud environments as compute node hardware is procured independent of procurement of virtual appliances. Virtual appliance vendors like to have their virtual appliances' images work on multiple compute nodes. Operators likes to ensure that any virtual appliances they purchase continue to work with future compute node hardware.
OPNFV DPACC team goal is to identify various acceleration types. And then define software based interface for each acceleration type.
VMM which is typically bound to the compute node hardware is expected to have conversion module from the software interface to local hardware interface.
OPNFV DPACC team is choosing virtio and vring transport to implement software interface.
Accelerations normally fall into two categories - Look-aside model and Inline/fast-path model. In Look-aside model, virtual appliance software sends command to the accelerator and expect response for each command. The response can come back to virtual appliance in synchronous fashion or asynchronous fashion. Inline/fast-path model typically is for packet processing kind of vNFs. Any network function that does not need to inspect all the packets can take advantage of inline/fast-path acceleration model.
In inline/fast-path acceleration model, network function in virtual appliance establishes a session state (either pro-actively or re-actively to the packets) and then it expects the fast-path accelerator to process further packets.
Many smart-NIC vendors provide facilities to their customers to create fast-path functions in the smart-NIC. In physical appliances, typically this works best. Physical appliances are fixed functions and the entire software and hardware comes from one vendor. This vendor would ensure that both normal network function and fast-path functions work together.
In virtual world, smart-NIC comes from one vendor and virtual appliances come from separate vendors. Also, it is unknown at smart-NIC build time, the network functions that would be hosted on the compute node. It may seem that smart-NIC vendors need to have all types of fast-path functions implemented in the smart-NIC. It is obvious that it is not feasible and the smart-NIC may not have too much of code space to put all kinds of fast-path functions. Note that, smart-NIC could be based on FPGA or constrained network processor.
Another model could be that smart-NIC is populated dynamically with fast-path functions based on the type of virtual appliances are being brought up on that node. This also could be a problematic as there could be multiple smart-NIC vendors using various processors/network-processors/FPGA etc.. Hence, one may need to create similar fast path functions for many smart-NIC types. There is always security & reliability issues as these functions may not co-exist s they come from various vendors. Some function may misbehave or some functions might crash other functions. In addition, there is always a concern on amount of time it adds to bringing up and bringing down the virtual appliance.
Hence, some in OPNFV DPACC team believe that smart-NIC must implement flow processor such as openflow. Openflow has very good advantages, Some of them are :
- Only one logic module.
- One could create multiple instances.
- Each instance can be controlled by separate entity.
- Multiple tables in each instance.
- Flows in the table can be pipelined.
- Flows can be programmed with pre-defined actions.
If smart-NIC implements OF, orchestration module can create an instance for each vNF and assign the instance ownership for that vNF. vNF at run time can program the flows with appropriate actions to create the fast path for those flows.
It is already proven in Industry that OF and some proprietary extensions can be used to realize IPSec, Firewall, NAT, forwarding, SLB fast paths.
Please see this link on the presentation slides made to OPNFV DPACC : https://wiki.opnfv.org/_media/opnfv-dpacc-fast-path-and-inline-acceleration-flow-processor_v1.pdf. This slide deck provides graphical picture of above description.
Comments? Please post your comments here or at https://app.pivot-it.com/public-583/Open-flow-based-distributed-data-path-for-virtualised-data-centers-openflowdatapath/enter/
No comments:
Post a Comment