 So, today's our break count session is focused on the topic of soft pass-through and user space switching, which is offered as an other improved alternative solutions for DPDK, especially for the NFV performance sensitive workload that is running on top of OpenStack. So, during my presentation, maybe if you have any questions, can interrupt me at free, so we can have further discussion. So, our slides will be firstly discussing some of the basic challenges that is faced for the NFV workload over the OpenStack Cloud Platform. And also, we will offer two alternative improved solutions, stemming from the V-switch kernel space V-switches, as well as the PCI pass-through, which we consider is still not the perfect or satisfying solutions up to now. So, we've proposed other possible solutions to further balance or make the trade-off between the performances and network automations that is required for the NFV evolution. And finally, we will give some summary. First of all, let's look at the overall architectures of the IDEA, overlay VXLAN, overlay networking solutions of OpenStack that is proposing from the latest version of OpenStack, especially with the key benefits of doing the decouplings from the logical networking layers from the physical layer. That is to more specifically enable the VM mobilities across the multiple physical servers within the resource poolings, especially without changing the layer 2 and above network configurations. This is the one crucial benefit. Secondly, is the networking topology and ACR security rules will be provisioned without dependencies on the multi-vendor physical networking components. That is to finally making the network automations for the cloud tenants fully independent of underlying switching hardware, switching and routing hardware. And finally, it's making it possible for flat networking with dramatically enlarged cloud tenants and numbers of hots within the same resource pooling. So everything here is built upon the VV switches as the cornerstone of the whole IDEA architectures. But the real situation is that the currently the default OpenV switches supported within the kernel space of Linux and KVM is not capable of satisfying the NFV data plane elements, especially for data-intensive workloads like the EPC, GGSN, Brass, which is the most commonly considered data-intensive workload that is to be transported from the legacy of a telecom platform to the cloud. So here is a taken example here is for the EPC, the latest cutting edge technology vendors for EPC like Huawei, like Cisco, Starrant, they are capable for providing the data plane throughput to approximately 20 to 25 giga BPS throughput per slot. So that first slot processing board will be migrated to the virtual machines with the anticipation of providing equivalent performances for single virtual machine. While at the same time it can be translated to the average service layer processing requirements of 3 giga BPS per physical core. So while at the same time the available capabilities that is supported by the OVS is far from these equivalent cost efficiency requirement. Especially when we take an example with a service processing board of EPC made up of eight cores to support 25 giga BPS throughput. So this will generally translated that the hypervisor layer need to capable of supporting 20 21 GBPS per core cost efficiency. So that capabilities is obviously far from what can be provided by OVS and also as can be seen from the shown linear relationship between the number of provided cores and the performances provided by the OVS. It is far from the linear relationship and also we cannot improving the OVS performances under the NFV workload just by providing more physical cores to support the data pass forwarding. So current available performances you know presenting only a zero point mega packet per second PPS and three giga BPS per core only reaches nearly one seventh of the anticipated performances. So although the OVS is capable for supporting all the varieties of VXLand features like security mirror QS but is lacking the performances basically. So obviously current offered solution from the open stack community here is the offer the PCI Direct Harbor based the pass through solutions where all the virtual functions within the new cars are being apparently visible to all the virtual machine or guest OS. While it is definitely capable of providing enough performances by based on the key technologies that is adopted by the PCI pass through like the large memory page size the Pumo drivers and you know lively real-time running environment for the V-switches by bypassing the hypervisor processing but here's the problem still exists. The problem one is that it is making the VNF or the telco workload running on top of the open stack platform still coupled with underlying hardware. That is to say whenever you are upgrading your NIC hardware to a newer version or you are introducing a new NIC vendors to your hardware platforms of the open stack supporting the NFV you will need a new brand new efforts for the interoperability tests and integrations. This whole process of interoperability test efforts will be definitely and also you need to repackage and recompile the whole VNF workloads during the whole procedure. Another problems and challenges here is the no more capabilities of supporting network automations and elasticities over the overlaying layers. This is another major disadvantages because of the introduction of the PCI pass through. Of course maybe in some cases we think that the VNF workload could be simplified and we just relying on the manual configurations to do the necessary network topology or security rules configurations accordingly but nevertheless it is still conflicting with the basic principles of tenant or overlaying, networking, virtualization and automations. So especially when under the scenario of a GI line, EPC or GGSN running environment where both the value added services together with the GGSN or EPC is running as a virtual machines within the same physical host then there might be a strong requirements of so called service training or GI line traffic stirrings that is supported by the building V-switches, high performance V-switches rather than just doing the roundabout external switch traffic routings and what is more is that the live migration features will be also completely lost during this direct pass through solution offerings. So is there any better solution to solve these problems and challenges as we mentioned above? So there's two viable potential approaches which have been identified. One is based on the soft pass through with the enhanced solutions over the PCI pass through and the other is of course the user space V-switches which have Intel and other major vendor companies also working very hard on the series for enhanced solutions that is moving the V-switches from the kernel spaces to user spaces while at the same time improving the interaction technologies between the switches and the guest OS workloads as well as the underlying NIC hardware. So this is the two possible we identified viable solutions such as the soft pass through and user space. Let's put more focus firstly on the soft pass through solutions. Here's the solutions majorly featured by the improved solution over DBDK of the soft pass through especially the rough idea is trying to insert a NIC abstraction layers between the hardware physical layer NIC and the VM guest OS layer so that the whole solutions generally will be both compatible with the SRLV specific NIC cards as well as the more generalized multi-Q NIC cards so it will be more you know have less intense requirements on the specific vendor that is providing the NIC card support and also here's the the ring buffer here is the allocated in comparison to the net map solutions as another options of software soft pass through the ring buffer here can be allocated and maintained by the virtual machine themselves rather than by the hypervisor layer so that that will provide the better security isolations and also the the host hypervisor drivers can be flexibly set to the soft pass through mode or the normal walking mode and a pair of shadow ring ring here's for each physical functions and virtual function BD range we also enable that the zero copies for for the for the point of transmissions rather than the actual content transmissions between the two layers so another major benefits we've identified here's the the with the solution is that the greatly reduced integration cost as can be generalized in this comparison pictures left to to the right so the left side is the legacy approaches of a PCI pass through where the N numbers of different types of V and F were closed and the M stands for the different types of vendors that is possible in providing the support for the whole platform there could be N times M you know different combinations of integration efforts were required for for the whole ecosystem and with with each you know integrations where we involved with more than 10,000 10,000 lines of coal for for the driver development of the PCI pass through well with with the soft pass through solutions the integration because of the screening key features that is offered by the SPT drivers soft pass through transparent drivers so the the the correlations between the V and F software packages and underlying you know different versions and vendors of neat cars there will be only M plus M you know different constellations or combinations for the for the integration costs so there will be tremendous you know reductions for the integration efforts and requirements and also the regarding the SPD for performances we have already you know got the profound test of performance comparisons between the PCI pass through and the software pass through solutions and we achieved the you know equivalent nearly equivalent performances with that of the hardware based PCI pass through with just the no more than one physical core to reach the the same level of a 10 mega PPS at the 512 by sizes packet sizes with the with the within the 2.5 giga GPU environment CPU environment and the same performances here will be also kept linearly scalable according to our anticipations so in order to support these in end-to-end solutions of software pass through solutions within the open-stack and KVM context the the open-stack management of the controller node as well as the compute and networking though just need to introduce a brand new ML to SPT mechanism driver and agent within the new chump hot and also within the guest operating system we just need an integration of SPD interface poor mode drivers with the DVD key library and also a full set of for hostile Linux and KVMs being firstly introduced into the new to the Q mil and lip word with the SPD device type added and further on contributing these SPD rim buff and driver mechanisms to Linux community we we are suggest suggesting that these type of SPD rim buff and drivers to be accepted by the Linux communities to offer a new alternative choices by fully decoupling the the VNF software from the underlying Nick hardware and the other viable solutions here is of course the improved upon the kernel space based OBS where the the virtual IO context switching and memory copy we will contribute as the major bottleneck performance you know factors and the other is the heavy IP stacks based Linux kernel that that is driving very limited performances so in order to solve all of these key challenges on the performance of the user plane the key idea is trying to firstly moving the key logics of virtual switches and the link layer and physical layer processing to the user spaces while at the other hand greatly improving the communication efficiencies between the guest OS and the the the virtual host layer processing logics of the V switches so here's the for for more efficient guest OS to V switch communications the poor mode were virtio's will be replaced the poor mode virtio or V host user mechanisms will be used to replace the legacy virtio between the the kernel V switches and the the VNF VMs and also the the lightweight IP stacks in the user spaces will be rewritten also to completely improving the the overall performances that is required for the for the user plane sensitive traffic and also for for the performance per cost there we will also anticipating a maximum of 3 mega pps per core or 10 giga bps per core throughput with the line alay scalability and also the the user space here it is actually breaking through a series of you know keyboard bottlenecks that is encountered in the default OBS solutions and in order to make it fully implementable and commercially deployable in the end-to-end open-stack context the solutions we will first also need the new charm to introduce a new user space which mechanism drivers and agent together with adding a vi for plug-in drivers in the normal in the normal modules and definitely a integrations of the virtio poor more drivers with the dbdk libraries in the guest OS and further on in the host OS and the KVM hypervisor layers we've already observed the efforts relevant efforts that is trying to contribute the V host users merge it into the leapward as well as the Qmo open source modules and also you know doing some draft specifications on the normal and in the very early stages of the discussions and Huawei and we also welcome relevant you know active participators to involved in this discussions of course we've also envisioned a series of key challenges for these user space which approaches especially in terms of how to build up and enrich ecosystems especially in the north in the southbound dbdk ecosystem as well as the linux spt ecosystem that this will involve all mainstream nick vendors active passive participations in these movements and also the how another bigger challenges stands for the the areas of advanced IP stack feature enrichment such as the IP tables traffic controls LDPs and etc to be further on conducted in the communities especially to rebuild which is such kind of enriched features that is already supported by the kernel space you know open v switches to be reviewed in the in the user space that's another big challenges so so final final summaries for for for all these you know viable solutions comparison analysis we we can reach to the conclusions is that these spt or software software pass through solutions will enable the fully decouplings between the nick hardware's and the virtual network functions that will greatly saving the multivendor hardware integration cost with no more than one physical court you know extra cost with with equivalent performances to the hardware based pass through PCI you know approaches and the others as the user space v switches improving the performances at least by five to seven times against the kernel space v switches with no more than two cores per server and especially translated to the the very beginning cases of the EPC the virtual EPC scenarios the when we are adopting the OES you know together with the service processing work clothes together you know we we can maximally achieving you know only 12 giga bps per cpu per physical cpu the for for the whole throughput including the vcpu workload together with the hypervisor consumptions and with the PCI pass through with only 20 24 giga bps per cpu with the software pass through 20 21 gbps per cpu and you the space v switches 18 gbps per cpu this is the general comparisons and relevant you know cpu utilization or consumption cost in general well at the same time it can be apparently seen that the different approaches achieve the different levels of networking automations in the overlaying layer especially here's the user space base the switches approaches is taking the advantages against the PCI pass through and also the software pass through solutions will also offer us the possibilities to support because of the insertion of intermediary layers of processing the direct pass through processing it will also offer us the the capability of supporting live migrations while achieving the PCI through parts equivalent performances yeah and finally as a new as these two new alternative solutions spt and user base switches for the for the NFV user spleen approaches we hope that these two solutions proposals will be accepted by the community and supported by the mainstream nick van doors okay so that's the general shareings of my viewpoints is any is there any questions or discussions yes as I mentioned during the presentations the shadow rings that is allocated for each of the guest OS will be managed here's in the soft past software pass through solutions you know by the guest OS rather than by the hypervisor as a as a shit one as a shit is the guest the communication between the guests can only do the you know do the communications by means of the you know inter intervf communications in the in the cars which is which is which is not you know offering any possibilities of doing the direct shit memory communications between the two guests sorry we will not propose that yeah yeah yeah we will not you know propose for that because of the secure as you mentioned the security concerns spd buffer yeah it is currently not yet you know as a as a public open source we're trying to consider to contributing this to the to the Linux community yeah so we think that that will possibly bring the more openness and the decoupling benefits compared to the legacy you know current approaches especially the PCI pass through with the more tight couplings well the the last of series of advanced it sd and automation network automation features you mean the combination of spd and definitely you can support at the very same time because you know that the at the new charm and novel layers there will be corresponding independent drivers and plug-in mechanisms for for the different and you can for the different scenarios and optional choices for the for the VM or networking deployment you can you can indicate the differences in the in the API as specifications I mean that for the same virtual machines there might be different configurations of course that that will require the the specifications and new cars multi-venic you know configurations to be supported in parallel for for different options of indications that that will definitely involve in some enhancement as required in the in the novel and newtron as well as the user plane KBM spaces you know to to enable the coexistence sub feature support within the same virtual machine yeah so it means that the how to to orchestrate the the different traffic layers you know traffic patterns or is the quality of services you know can be enforced yeah yeah yeah yeah yeah that from from my understanding that you you actually mentioning that the questions of delicate quality of service assurance and the data plane layers that possibly addressing another major topic which is overlap which is not not contradicting with these approaches which is applicable to both the you know pass-through mode or the we switch we switch user or kernel space options okay so any thank you