* Argy：Is it possible to share accelerator with VM3?
* Argy: You'are not proposing that transport layer be SR-IOV only, right? I assume it could be anything, even the shared memory, right?
* Saikirshana: Is there assumption on supporting metadata of acceleration on this interface?
* Saikirshana: The metadata could be anything. It could be the packet data or metadat without packet data. (not fully comprehended???)
* Srini: How could VM#3 have its packet not going through vSwitch?
* Srini: I am wondering if you can find some usecases that packets don't go to vSwitch and goes directly to the HW?
* Srini: I assume your slides are about networking?
* Argy: Why do you think it does not scale well?
Keith: One can always bypass the vSwitch in the host, and rely on the local/external device to do the VM2VM swtiching. But since not all the local device support vSwitching offload, that could add extra work load to the external world, e.g. a ToR.
* Argy: Is it possible for the SAL in the VM to allow dynamic path change for different packets? For instance, take IPsec for example, key mgmt may not need to go through vSwitch like bulk data for encryption/decryption does.
Keith: summarizes the proposals into:
* Argy: Virtio has performance issues.
* Lingli: What about the mgmt flows contained in HW's AAL framework, setting up and local mgmt of the data paths? Are they contained within your proposal? How would you realize the mgmt flows in your architecture?
Pending email confirmation from HW to settle the virtio interface and extension proposal. Once agreement reached, then move on more details regarding the packet flow, and mgmt flows.
* Srini: We have actually implement IPsec acceleration based on virtio, and would like to share it later.
2 modifications made to the slides before the discussion:
(Note: the actual definition is out of our scope, but the alignment is key.)
Argy: With the top level project, do you still need enhancement in Nova?
Srini: Looks good. Maybe need more clarifications on the interaction between different components with the work flows.
Keith: We need to define what information we would need to give to and get from Nova to be able to set up and configure the acceleration in the node itself. The API design would be very much dependent on the information type it needs to transfer.
Fahd: (comments not comprehended due to poor connection)
Next step suggestions:
Classification on accelerators: VNF accelerator and NFVI accelerator. NFVi accelerator is actually implemented by the vRouter in the host doing L2-L4 switching instead of vSwitch, which is configured through NSD/VNFD/VNFFGD.
Using small cell GW as an example, Francois shows that the IPsec tunneling funcationality between small cells and the sigGW, which is originally handled by a dedicated VNF SeGW, can be described as an IPSec connection point and realized by a vRouter sitting on SAL (e.g. using openflow-based work flows prposed by Srini to configure the underlying accelerators).
Srini: Which is the corresponding Openstack entity/item to the VNFD? Is that the VNF metadata?
When doing NS initiation, for step 7, VIM instantiates the connectivity network needed for the Network Service, where the vRouter could be called to to the proper configuration for the IPsec accelerators (look-aside or fully-offload).
Keith: vRouter and vSwitch are similar in the general framework.
FF points out Linux stack does not support full IPsec offloading, therefore vRouter-based solution is more simple than to modify the stack to utilize that. It is being considered at ETSI NFV to have the vRouter to be configured through Yang or Netconf models, and translated to Nutreon. But the descriptors are not fully standardized yet.
Lingli: There is but one piece of information contained in the current descriptor for an IPSec link. How could VIM infer from that information to comprehend the acceleration resources that might need to be allocated to vRouter to enable such link?
Howard: For implementation, we could implement those descriptors as HEAT templates.
Lingli: Do the descriptors as defined in ETSI NFV phase 1 enough for VNF accelerators?
Ferran: Question for Keith. It is proposed to add crypto API to virtio, right?
Keith: Yes, I want to extend virtio.
Ferren: I agree that virtio needs to be extended. But adding each type of accelerator's API would make it too complext.
Keith: I don't see that. Currently virio only does networking. For crypto or compression, they will have different sets of APIs, in addition to current APIs.
Ferran: I suggest another higher layer can be added on top of virtio to better address the issue.
Keith: Yes, we can. But extending virtio with more functionality could be an easier option to push it out. If we create a new piece, we still have to integrated it with virtio. Or we will have to create a new path out of VM to the host, similar to virtio is already doing. So why not extending virtio to do that as well? Maybe vritio already has a higher layer entity that can be extended. We need to have people further look into it.