Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
   * January 22, 2015
     * Minutes
       * Friday 3:00-4:00 UTC https://global.gotomeeting.com/join/230251565
         * {{:dpacc:dpacc-openstack-arch-discussion.pptx|host AML discussion}}
         * In previous figure EPD is not existent in DPACC arch, it is referring to as sio? YES.
         * AML is using s-API and making use of g-drivers within AC instead of acc drivers in host kenerl for device access. And current DPACC Arch does not include any components from host kernel. 
         * Add another arrow between Compute Management Function and other functions (for network and storage managements) and Acceleration Management Function, for VNF deployment events as described later in Section 5. 
         * Although there are such interactions in the previous figure between guest and host, it is not suggested to extend sio-backend to expose the host AML to guest, so that VNF is agnostic to VIM orchestration and management. It shall be noted that there are clear difference between orchestration and configuration, the former is done by AML as part of VIM, and the latter is done by VNF as part of data path setting up/association.
         *  {{:dpacc:dpacc-openstack-arch-discussion-v2.pptx|Updated Discussion slides}}  
         * [[https://docs.google.com/document/d/1O4rtCh1vbTOO5cMwmRwfv3UJb_bVWZrqXQS_-QJAk10/edit#heading=h.qgcc257859c0 | Updated host AML description@dpacc-arch ]]
         * [[https://docs.google.com/document/d/1_fOinIQNcPwNODZPzGK5vRMPJQLwL7iLds4NFnjXSms/edit#heading=h.bgmu8xoyn00w| Updated host AML description@gap-openstack ]]
       * Friday 9:30-10:30 UTC https://global.gotomeeting.com/join/623117821
         * follow-up discussion on virtio-pdcp
           * {{:dpacc:nxp-pdcp-virtual-accelerator-gapi-v1.0.docx|renewed doc for g-api}}
           * Rajesh goes over the g-api proposal for virtual dpcp lookaside accelerator
           * Lingli: reagarding management API, is it interacting with the orechestration of VIM. For instance, after close or before open, can the underlying accelerator be assigned to another VNF, or even getting preexempted after open or before close. 
             * Rajesh: No. The VNF assumes the virtual accelerator be always available. But it needs to first get a handle for using it. That's what open and close for.
           * Lingli: for control and setup API. Are these aligned with virtio-ipsec-la?
             * Rajesh: The management APIs are common. But not the control and setup APIs. Although they look alike, but some of the specific arguments are different. One reason is ipsec case uses kernel protocol implementation but dpcp does not. And ipsec shares same instance with multiple application, but PDCP is not.
             * Rajesh: Let us have further discussion offline to see if we can merge APIs for kernel and userland implementations.
             * Lingli: let me mark an AR to connect to Denis for this too.
           * Rajesh: We are using different set of errcode definitions from ipsec. Do you suggest to have -ve value for failure error code?
             * Lingli: Yes. If there is no technical issue, common design is good and easy to follow.
           * follow-up actions
             * Lingli will work with Duanran to produce additional input for usecase documentation for pdcp accleration on vRAN scenario.
             * Rajesh will do minor update to the g-api for pdcp, and forward it for group review.
             * Start discussion among different groups and document common design considerations for virtio-xxx proposals for DPACC usecases.
Wiki

User Tools

Site Tools

Page Tools
