Discussion for the framework layering slides on the meeting, and welcome feedback afterwards from the list for the rest of the slides.

Bob: There is a lot of controversy over what is the actual API to the vNF. So g-API is placed as a place-holder, which is a generic API that might even be optional.

Keith: g-API may be specific to the application, or specific API like sockets or libcrypto, and has nothing to do with the acceleration core APIs or very little. The g-API is more application centric, not centric towards the SAL layer. So it is trying to take and adapt libcrypto to whatever is underlying API on the acceleration core. That does not mean they have to use it, and that's why it is optional or to be TBD.

Ola: But defining such API to be not the accleration API but get acceleration indirectly, may get people confused on how to write applications.

Argy: If it is just an adapter, I think we need to change the wording about what g-API is.

Keith: I think we can call it something like adapter. Or conversion layer or wrapper layer.

Lingli: Actually, I have a concern here. When I came up with the name g-API, generic API for applications, I meant a common set of APIs for whatever acceleration core is underneath. So I am wondering if it is possible. It there is such possibility, I prefer the generic API be mandatory layer, as applications would probably be using generic API to get access to the acceleration cores. Otherwise, we would have to suffer from different worlds for dpdk or odp or different SACs, I am afraid.

Bob: I think one of your points is ultimately we wanna preserve application portability. That is huge. We just don't know how we can get there yet. So as long as we are putting application portability as a requirement, and that could meandifferent things to different people, we can offer ranges of compatibilities well.

Kin-Yip: I think it is important make the intention clear, There are different opinions over what the g-API is. For legacy or for application portability. I think the requirement should be described here clearly. Basically, it is not something like legacy API. It is something that tries to be generic and portable across vNFs.

Keith: In my thinking, what Lingli wants for the g-API is to unify SAC APIs into one API. And that's a lofty goal. I just don't know if they all fit that way. That is why we suggest that we wait until we figure out what the vNFs really need as requirements. If they need that common application API, then we are going to have create a g-API layer that sits on top of s-API, or the acceleration core APIs have to change to a new methodology.

Venky: libcrypto is actually a very generic crypto API. applications using libcrypto does not necessarily need to go through g-API to enable portability.

Bob: Let us define clearly what we want for application poratbility via g-API. If lots of vendors conform to an s-API and make it generic across platforms, there is no need for an extra layer for g-API. If the upstream project satisfies the requirement, then it is perfect. If it is not, it has to evolve or has adapters.

Bob: Splitting slide 7 and 8 for different cases to make it more clear. Need clarification for sio-backend on the top of SAL.

Ola: From the previously slide, there is sio for para-virtualized interfaces for different devices. Since they are para-virtualized, there has to be something in the host in the hypervisor to handle that. So sio-backend could be something in the QEMU user space to handle this. For instance, it can be virtio-based, virtio vrings in the host for the hypervisor to pick up the packets and send them to the crypto accelerator.

Subha: The vHost-User I think is the one that is doing that. User space virtio interface.

Ola: The vHost-User is one way to implement it.

Subha: Question regarding no sio underneath the SAL@host.

Ola/Keith: sio is expected to be software constract between guest and host for para-virtualized hardware devices.

Subha: OK, we have in figure C, applications in the host, which need to make use of hardware accelerators, in this case, even though the HA accelerator is virtio-based, the virtio-rings are implemented in HW, we call it hio driver, but actually it is a virtio driver. It is just a technical term issue.

Keith: Let me make sure we get this clear. That little orange box "hio", I expect that to be pass-through interface, e.g. SR-IOV, directly to the HW. Is that what you mean?

Subha: Yeah.

Keith: OK, I think we are sync then.

Ola: Yes, that is my understanding as well.

Ola: In this Slide 9, example A here, it says sio in the guest, but with nothing in the host. And there is some kind of HW device. I don't understand.

Keith: That one is for the case via hyper-call, virtio calling directly to the kernel (which is not shown in the digram) and the kernel does the access to the accelerator.

more comments are welcome from the list.