 Hello everyone, my name is Bering Zhang and I'm a cloud computing architect working in SIPA. The other two speakers are Wen Ping Song and Shao He Feng. Wen Ping Song is a cloud computing senior research and development engineer who is also working in SIPA. And the other is Feng Shao He. Next, we'll share the topic of enhancement and optimization of new heterogeneous accelerators based on SIPA. We'll introduce the SIPA from the following four aspects, changing of heterogeneous computing, functions and optimization, managing management and planning to do, prospect for several. In recent years, heterogeneous computing has become a relative hot topic. It has gradually emerged in 5G, cloud computing, energy computing, and other fields. But heterogeneous computing faces great challenges in terms of software adaptation, savings, diversity, distributed system collaboration and data migration. For example, how to manage a large number of heterogeneous computing units with unified management? How to cross architecture, high performance, unified programming? And how to combine service to maximize hardware performance? And how to achieve finish switching hardware adaptation, finish decoupling, memory consistency, synchronization, storage compatibility and system compatibility issues in the case of a large amount of business and hardware devices dependency. Saivogar is a project management manager by hardware accelerators and it can solve the above problems effectively. Let's introduce Saivogar's contribution to heterogeneous computing. Next, we'll introduce our new features and our project management in Saivogar. Since Saivogar is still in infancy, there are some problems in it, such as poor case of failure in consistent data, single functions and failed types of accelerator support. We have made improvements to these issues and we were adding accelerator devices on an unbound spot. We have achieved data consistency and synchronization between saivogar and placement through data aggregation with the filter and the transfection processing method. We also realized the GPO virtualization management to improve GPO device utilization and introduced NVMe SSD, PURT, FPGA, DBDK and other types of drivers to improve the cloud platform spot and adaptation capabilities for accelerator hardware devices. We also support a big, great service with accelerators to make accelerator devices convenient. Saivogar is an accelerator resources management project and use macro service architecture to support distributing deployment, which contains Saivogar API, Saivogar conductor and Saivogar agent service. Firstly, we need to set a driver configure, such as the GPO driver and the FPGA driver. Secondly, Saivogar agent collects accelerator resources and information and reports it to the Saivogar conductor. Thirdly, the Saivogar conductor stores accelerator resources and information in the database and reports to the measurement resource management service. The measurement stores resources and information and provides valuable resources for NOAA scheduling when the server is created. The Saivogar API service provides interface to request accelerator resources information. Currently, we have completed NOAA and Saivogar interaction and support PGPU, WGPU and FPGA accelerator devices. And in the regulatory release, we have introduced NISBRA, FPGA and InterQAT accelerator device services. In one of the release, we plan to introduce NVME SSD driver. And in the future, we will support managing Spanlinq card. We have submitted the Spanlinq design specification to the NOAA team and going to discuss with NOAA team on this victory PDG. In user release, we have completed NOAA and Saivogar interaction features to support funding accelerator devices when creating a server. The diagram is abstract process and below is the main steps. We need to create an accelerator device profile which can be a pair of accelerator resources or combination of multiple accelerator resources such as control, GPU and FPGA. Secondly, we should select the device profile to create a server. Thirdly, getting available hosts that specify the resource reports through NOAA's conductor then to create a server with accelerators in device profile. Fourthly, NOAA scheduler get a location candidate from placement and filter and available hosts. Now computers find the server with accelerators. Finally, several API maintenance relations between server and accelerators. So about steps, we can put a server with accelerator devices profile through NOAA. If you want to test this feature that you can define your story release, I think it will be a pleasant experience. Next, Wimping Song will introduce Saivogar's implementation and optimization of acceleration devices. My name is Wimping Song and let me introduce the implementation of the optimization for Saivogar. This diagram will introduce the implementation logic of finding and unbounding acceleration devices for an active server or a stopped server. The bound and unbound are very synodical, you can see as low. Firstly, NOAA API send bound and unbounded accelerators request to NOAA computer then NOAA computer call placement to allocate accelerators resources. Next, liberal attach or detach the device and will add or remove the accelerator info from the server's XML cloud. Lastly, several API maintenance server and accelerator relations relating or adding mapping relations. VGV is necessary in current business since this diagram shows the VGV management architecture. VGV can be vitalized to many VGVs. In the future, we can use several devices table to record the VGV info. They play for the table to record the VGV info and the attributes table record the VGV trade under resources classes. Today we can only find one VGV to the server as a name that doesn't support creating multiple media devices by NOAA. With VGV management by several we need to understand the NOAA computer configure about the VGV fast on the VGV type. Several can also collect the VGV info and stored into the VGV. By GPU visualization, we can increase the GPU usage and improve its ease of use. Use find the management GPUs. We plan to introduce this feature in one by release, please pay attention. If you have better suggestions, you can contact us via IRC or email. We also support creating server with VGP like other accelerators. This diagram is the main steps. Firstly, we need to create a device profile of VGP such as NVIDA 180, NVIDA 180, and NVIDA 181. Then we use the device profile to create a server, which is same as NOAA stable interactive action. Through NOAA state schedulers like the available host that satisfies the request VGP resources. Next, NOAA computers for server with VGP and request the server to find accelerators request. Server will send accelerators bounding event to notify NOAA computer. The bounding results will NOAA computer receive the declarator bounding event. NOAA computer gets bounding info and generator configuration and write to server's external file. This diagram shows the optimization of data synchronization between stable worker and the placement. Nowadays, several collect accelerators device is info and report to placement. When placement service is gone, the report will file and data inconsistent is generated between server and placement. In largest scale scenarios, server will also report the big data to placement, even though the placement is gone, which cause a great waste of network-fund-wide resource. So, in response to the problems, we will optimize the method of accelerator resources synchronization. Further, instead of server for data to placement, we will change the way of data transformation by placement for data from server. Even though server service is gone, we needn't worry the bound-wide resource waste. Secondly, for this transform in large scenarios, we will define a future accelerator resource method, which traditionally can get the accelerator resource from server, and has data with features like NOAA. The waste metrics are device usage, device type, device aggregate, device product, device host usage, and so on. The future method will return accelerator device list with no usage rate through device type, product type, product ID, and no usage host, which has devices. Suddenly, when placement gets the future data, we will use the clean method to filter the valid data, and the correct time is earlier than after the time, and clean the device in use status. Then use transactions to save data in resource classes, resource providers, traits, inventories, tables. So, the measures above the data inconsistencies for nominence requires greatly. So, with accelerators, we will block the lots of operations such as migration, start and resume, save and un-save. To enhance the accelerator management, we have completed several events and evacuated and reviewed the blueprint. To support evacuating and rebuilding operations for server with accelerators, in the factorial release, we have submit save and un-save operations supporting patch, which is ready to go, and we will complete it in worldwide release. In addition, we will support certain resume and migration operations. This is our in-cloud, open-spread, planned form architecture. We have supported GPU virtualization, IPGA program, and NVMe SSD acceleration featured by server. We have made a lot of operations of team magicians in function and performance as follows. The physical performance of team magicians based on a signal resistance IO and multiple queen. Improved GPU performance and reduced GPU loss. Optimized resource data signal resistance machine medium. This is all my work style. Next, welcome Shao He. Introduce smart link management and planning to do a step over. Thank you. Hello, everyone. This is Shao He from Intel cloud team. Now, I will introduce SmartNIC management and planning in OpenStack. At present, we have supported SmartNIC N3000 in OpenStack. The picture shows the detailed card information. And we can see there is a 10-fg chip for OVS or other computing off-load. Yes, there is also a Mekton FPG as BMC. We have supported OVS off-load in our SmartNIC and by virtual function pass-through to VM and as network interface. This picture shows the general whole software stack for N3000. The kernel space supports FPG, PCI, physical function and virtual function by VFL. Intel supports OPS DK to manage FPG in user space. Also, there is a DPDK device driver in user space to support image function on the programmed FPG. This picture shows more details of the stack for OVS off-load. It is a similar stack as a general. We can see the software stack also from VFL OPS DPDK to application. Now, this picture shows the new feature we have supported. Now, we have supported each single program API when Edmund posted a program request to Thabaga. Thabaga will check whether the FPG is in use. If no FPG resource is consumed by any VM, then it will download an image from the ground. And the Thabaga SmartNIC driver will start program. After the program finish, the driver will rediscover and refresh the resource information in database dynamically. Also, it will refresh the resource information in placement. We also support a new API for program status and process query during the FPG program. This picture shows a new improvement in OpenStack for SmartNIC with OVS off-load. It shows the details of how we smartNIC watch function to VM as a network interface. Firstly, Edmund should create a device profile for the accelerator resource decryption. Then, the tenant can create a port with this device profile. At last, he can create a VM with this port. When NOVA receives a VM creation request, it will query the port information and get the device profile. Then, it will choose a host candidate to satisfy the device profile and post accelerator request ARQ to Thabaga. Thabaga will choose an accelerator for the VM and send it. Even to NOVA to notify that the accelerator is ready. At last, NOVA will call Libware to start a VM with this accelerator as its network interface. Of course, all these new features and improvements will be upstream and new powerful smartNIC will come out. At last, let's press back for Thabaga. We will support batch create VM with accelerator, batch bound and unbound accelerator. Of course, smartNIC's integration support level migration for SR, AOV, VM, NVME, SSD management. Optimization and more. Okay, that's all for our topic. Thank you. Thank you, everyone.