 Good morning For me, it's not even It's really early morning because I flew from San Francisco this morning. I landed at 8 a.m. Here Just rushed to the conference. So hopefully I will be a Bit and not get you sleepy Technical content might be Well, it might be a little bit technical. So we'll see and us all the topics will continue being technical It may be good that if you have a question then you can raise the question as you have it because otherwise we will be moving to many other different topics and then It may be better to To have all the questions at once So I work for a company called Linaro Linaro is an organization That is profit neutral and it's formed by a number of members companies like Google Facebook Alibaba arm Cisco Nokia Ericsson Huawei ZTE Broadcom TI well 35 members that are collaborating to to build software to build software from the mobile handsets the tablets the Setup boxes the TV systems industrial embedded systems Servers and also networking so that I'm in charge of the networking department of Linaro and those members as I said so for the networking department you have Cisco Nokia Ericsson Huawei ZTE and So that's a pretty good set of companies to get requirements from So I'm going to talk about VPP and what ODP brings to to ODP I worked for six win before joining Linaro, so I know pretty well DP DK and I thought I knew ODP as well because I thought it was the DP DK of arm and Actually, I was completely wrong, but I did not know at what point I was wrong I'll try to explain when I came to understand as I Started to work with Linaro and the guys that imagined ODP so from a software data plane perspective There are two families of software data planes the ones that I call software Implemented which means that all the packets go through the CPU cores So you have an input port you have some handling some queues it goes to DP DK VPP and it goes to another run exit port All the flow all the packets go through a CPU core. That's the model So DP DK is one of such software implemented data plane You can consider a net map is an is another one or windows packet direct can be considered also as a software implemented data plane Open data plane is different. It says that at the bottom we have a Pipeline or if you wish a limited graph if you compare to VPP which has a very complex Full-feature graph with loops at the heart of ODP there is a Small pipeline of hardware blocks which can run entirely autonomously to switch packets from input port to output port So here you have a classifier, which is some kind of a generalization of RSS handling scheduler Layer X for warding or maybe IP sec or and then traffic manager for Shaping at the exit you have other other topics so the scheduler scheduler role is multi-fold but Out of it you can also We'll talk about a little bit of packet ordering so the ODP API actually Configures this pipeline what are each block which each block is doing and how they are chained and then When it's configured it can run as I said entirely autonomously So you could build a 100 terabit switch and control it through ODP API With a single arm core which would be just doing the programation of the hardware so you could think of ODP as a combination of DPDK and switch dev for example You know in a single in a single product Now you can also decide to extract traffic from any of those hardware blocks or functional blocks in In the pipeline and directed to an arm core So you have in that case. It's more. It's closer to a DPDK mode of behavior You can do that for all traffic You can do that for a selecting set of traffic and you can do it At different exit point of the graph so you could think of the ODP application of some kind of customized node of the ODP graph So you might say okay, that's a different but What does it buy me? so I'm I Can't be very precise on the figures because they are not public yet but to do a 20 gig IPsec Node you know for a SD1 you have let's assume that you have an SD1 box sitting at a branch office You want 10 gigabit uplink and downlink And you want the box to cause the least amount possible so We did measurements with an arm system with one core The cost of the system public price the box I mean not not the entire box, but the motherboard plus the CPU plus well Without the optics without the SFPs around $100 and you have 20 gigabit of I mix throughput That can be done in IPsec You could have so that's I mix that's not just large packets If you push the packets size to 64 bytes, then the throughput uplink downlink is 11 gigabit per second For $100 the box if you do that with another microprocessor Still so see with with with ports You have to have between the four and eight cores more probably eight or even well eight to do at least 20 gig of large packets not I mix and the cost will be between 1000 and $2000 the system so Here I would say there might be technical philosophies that are different But bottom line that's the bottom line which is important and if you take the The other microprocessor vendor with the PDK, so that's the cost I've said but if you do that with ODP and the and how we will handle the the existing acceleration you will be able to get a lower processor and You know the processor pricing is not linear. So if you go to Four cores, it's not half the price is more than half the price So here what I say is that on the same hardware on not an arm system with ODP by using this pipelining of Hardware function you can really use the hardware as much as possible So that's the fundamental difference. I Did not understood why I was doing DP DK. So I really thought ODP was a DP DK on arm and that's definitely not the case What are the other differences? Well the programming model is a little bit different It is even based well, it's not because it is even based that it cannot do run to completion But it you when you create very large applications not a layer three forwarding application, but you know as we have a large network equipment providers when they build products You have a team of 50 people that build one module you have a team of 50 people that build one module and then you have other teams that build products out of those modules and The the team that have worked on independent modules have worked really independently Ultimately when they assemble those modules and they fit together to build a product a cloud run system or a PE router or something else They Assemble modules so they need an extremely fast Even framework behind it. So that's almost the same idea of VPP with the modules but at the with the plugins but at the application module level one thing for IPsec is The fat pipe so you can reach high performance on IPsec Essentially when you have a number of tunnels usually a few hundred tunnels then the The figures you see in the benchmarks show the performance with large packets with large number of tunnels but when you have real situation you usually have only one tunnel from Let's say the SD one endpoint to the aggregation layer and You would like to have that single tunnel to reach 10 gig but to be able to do that you have to take into account packet ordering and packet ordering is also part of the ODP framework It's part of the framework in in in the sense that it's either done in hardware by One functional block part of the pipeline or we have also a software implementation for systems that do not provide a packet ordering pipeline The packet ordering pipeline is also Is one of the things that is necessary because when you have packets coming in from one tunnel if you have RSS They will all go to one queue So if you have a DPDK program in model you will have to implement an internal Queue management to actually dispatch The packets to different cores, but you will have to build that infrastructure by hand In ODP. This is part of the ODP frameworks or the application does not have to do it. So That's the essential differences But one thing which is important for me is that who would build actually an application on DPDK and ODP today I Guess the best approach to developing application is better to use VPP and create a plug-in rather than do everything alone or to use open fast path as a socket API for application servers for example but Yeah, you have to understand the low-level details of each data plane Library But you should not maybe consider developing directly on those applications rather developing on VPP or ODP I will dig a little bit more on on the differences and What happens when you reach 50 gig or even 25 and above Let's take 50 gig because 50 gig seems to be the the most liked Connectivity for network equipment vendors in the telco industry If you look at Facebook, they also use a 100 gig. So 50 gig is 74 million packets per second 74 millions packet per second that's huge but there is a catch and It was it was not mentioned earlier by the Intel people for the PCI aspect But there is a limitation on the PCI bus Which can conclude 36 million DMA transactions per second so if you have 36 million DMA transaction on one hand and 74 million packet per second on the other hand there's a problem You can dance whatever Dance you can It the packet won't go through unless you switch more than one packet per DMA transaction But if you Stitch more than one packet per DMA transaction This means that the software does not control where the hardware plays the packet The hardware decides where it puts the packet because it has a DMA engine policy and When you talk to Xilinx and other guys that that work at 400 gig you know for Design phase of 400 gig adapters the key element is the DMA engine. How do we push those packets? through whatever interconnect to the CPU cores so What what's the catch here when I say it's the hardware that decides where the packet push places the packet Where with DPDK the software decides where the packet are the software List a set of buffers and informs the hardware. Please put the packets in those places Which are typically 2k aligned So if you have 2k aligned packet buffers the hardware cannot coalesce multiple packets into one DMA transaction to fit into the model So by construction you cannot do line rates on a single 50 gig port or 100 gig port On the on the on the on the model on the data plane that don't let the hardware decide where it puts the packets So you can have you can trick the system. So there is a one Company called net cope has a 100 gig Card based on xilinx and it has a PMD for that But the PMD actually deals with the native packets Internally in internal buffers and as the buffers are received or the packets are received on those proprietary buffers in a sequential manner. They are then copied into DPDK buffers and Conversely for the exit point. So this means that You have incoming 100 gig which is roughly 15 gigabyte per second of data That goes to RAM you copy it then it's an additional Lose of layer 3 cache and then as you're using the memory resources you can't build an application So the application that is demonstrated at 100 gig to switch packets from one port to the other is Really a switching a port switching application. I get a packet from port A I send it to B and from B to A. I don't look at the header I don't do any routing table. I don't do anything else But you can't do anything else because the memory subsystem is entirely clogged by the memory copies So we hope to let's say to unleash those 50 gig and 100 gig interfaces when We'll have the drivers for ODP natively and ODP is by the way not just ARM but also x86 This is a Mandatory point from our members that ODP has to run at full speed on x86 also So if you go to the other open data plane website, you will find multiple implementations of ODP There is one which is linux generic, which is a reference implementation and You have a number of vendor specific Implementation one for KVM one for TI one for nxp etc We we are in the process of building another one which we call ODP cloud Which in in the spirit of ODP cloud is to be able to work on any Silicon Silicon specific ARM silicon specific architectures with a various set of hardware accelerations and Have a unified git repo, but for the moment it looks like there are forked projects from ODP that's not the case but from a Let's say organization perspective who would like the project to look more ODP DK where you have One binary that can handle all the hardware. So that's where we That's where we want to go with ODP cloud By the way, yeah when one thing ODP can be implemented in in strange environments. So We have one company Calray who was some sort of GPU Without a new operating system in it Which has a specific memory model for the cores where the cores have private memory and Can access some shared memory much like the GPUs can have the texture memory and then local memory local memory cannot be accessed from another core so Technically speaking, they cannot implement DPDK on their on their hardware because the memory model is not able to cope with that but with ODP you can accommodate any kind of Execution environment so that was ODP and DPDK Both are very good solutions. They may serve different needs for different markets So hopefully you haven't understood that I consider ODP as being better than the PDK. They are different They're served different needs In some cases it has some business value of choosing one versus the other not from a technical perspective Now how VPP and ODP fit together Well, quite naturally as I said that the ODP is at its very heart some kind of limited graph so In the previous presentation you had an IPsec presentation Let's say a graph of how IPsec was done in VPP by adding nodes Well those nodes could be in the ODP graph in the hardware So You have the VPP configuration for IPsec The ODP input which is the equivalent of DPDK input in the VPP graph can add or push packets in the normal ether input so the layer 2 Input or because it has done the whole IPsec thing Directly push the the packets to the IP4 input node or IP6 input node of the VPP graph So rather than going through all the different steps of IPsec you can Establish some some shortcuts in the VPP graph because they have been offloaded in The ODP pipeline so that's why there is a very natural fit between VPP and ODP VPP has an event model program programming ODP also. So this is kind of a very simple So we have created a project in FIDO called ODP for VPP where we open source all the the This input node so that you can leverage the ODP That will be available on the distribution now. Where would you put? VPP with ODP if I I Want let's say that you can place VPP ODP in the host. That's the typical Placement You can also entirely offloaded to a smart nick So there is no VPP in the host the VPP instance is in the smart nick The honeycomb agent is either in the host or on the smart nick For the Calray for example the the honeycomb agent cannot fit in the GPU so the honeycomb agent will be in the host controlling the VPP in the smart nick for KVM Oction TX smart nick which hold which can have an entire Linux inside so the The honeycomb agent will be local to the smart nick But you can also deploy on both the host and the smart nick and that's probably the best deployment option And one reason is the east-west traffic between VMs if you do traffic if you do have the traffic from one VM to the other go through the PCI bus you Basically, you cannot do a 40 gig service chain on the system Because the PCI Slot has a 50 gig uplink and downlink limit so if you go from VMA to VMB you go down so that's 40 gig I was mentioning a 40 gig so 40 gig one 40 gig upstream so that's okay Now you want to go from VMB to VMC you have to go 40 gig down again on the same PCI slot Too bad you already had consumed you're already consuming 40 gig from VMA to VMB, so you cannot do that So you cannot build a 40 gig service chain with an embedded switch on hosted on the smart nick So that's why if you deploy VPP on the host and on the smart nick they can both collaborate to make sure that for east-west traffic the host VPP can do the East-west traffic and the smart nick helps on the IP sec termination or routing if you have a Very large internet if you have the whole internet routing table on the on the To handle that's about 8 gigabyte of memory and 600 thousand routes Some network operators in the world Push that type of Routing table at the very edge of the network so that Subscribers when they reach aggregation the very first level of aggregation They know how to exit the network to the best exit point for their the destination if they go to Asia They will follow a proper route if they go to us or YouTube or Netflix They will immediately take the the best route So having the offloading that to the smart nick may be very beneficial so that's First part of my talk, which is what we are currently doing We'll have demos in September on VPP ODP demos with performance We expect to show 50 gig line rate 50 64 bytes packets With one solution and also demonstrate the very opposite, which is VPP on a on a on a Nailed size chip with a few bugs to build to build a very low cost to gateways for the home So it's not because you can do 200 gig switching that you cannot do also efficiently one gig switching We're trying to push things in the PDK so that they realize The good thing that has to be done to make sure that There is some convergence so members are pushing the event model members are pushing things Sorry, I did not hear the event was one of the key When we had this one meeting that's there are three meetings that started this convergence or this discussion One of the things that were identified was the whole event The whole event right mechanism and so my question is is now two years I think I think So how are we almost done or we're still talking about it's getting there. It's getting there, but the The biggest hurdle I see for the moment is what I just talked about the the buffer management if if The very root of DP DK it is that DP DK tells the hardware what to do and when you reach 50 gig and above Line rate you can't do that. So there is a fundamental shift to be done It's technically feasible, but it will require some work and some will to do it And so okay, so this has always been my question Is it a technical problem or is a willing problem and you're saying it's not a technical promise really a willing problem Yeah, well it becomes a technical problem because it changes a little bit the application Structure because the application today the typical DP DK application is I create a memory pool and I tell mr Driver put the packets here The model has to be changed and the application has to Say okay get me some packets and the driver will tell where it has put in which pool it has put the packets So this is not Well, can it be I mean I know I'm simple I can't it be some sort of off Off on switch that says use it or not use it You know you use the DP DK which ends up deciding where it goes or don't use it and just pass it Don't let something else do it if I I will respond to your question differently If there is a will there is a possibility of convergence That's the there is no hard technical hurdle that would prevent addressing all the issues okay, so those are the two areas basically event-driven model and then the The data packet. Yeah, the hardware driven hardware driven path not software driven You and tell guys were here you heard that We're already done ha ha was it 1040 even 40 so That's the plan what what we are going to do very briefly on the vision side What are the things brewing one is what we call direct vertigo, so I will skip those things What what's the idea the idea is to have The smart nicks talk directly to the VMs using vertigo so that there is no Driver dependency or hardware dependency, so it looks good and NXP and Xilinx have done some proof of concepts and too bad. There is something that does not work That's how you handle the available and used Descriptors So a good thing about Etsy is that they have an idea of Leveraging the vertigo but extending the vertigo with some plugins and some additional things and one idea is to actually complement the vertigo model with a specific direct vertigo Virtual function which becomes a hardware function and then you can use that control function in a VM to Make sure that the Packet management the buffer management can be fully controlled by the hardware without involvement from the host and without the tricky Cache line or the DMA problem of handling the The available and used the buffer chains There is also another way to Address the problem and it will be in the arm ecosystem Where there is a new interconnect called C6? C6 is a coherent interconnect between IO and processor So this means that they the processor and the IO can share cache lines So in that case there is no distinction if the memory is controlled by the processor or controlled by the IO So vertigo will be in this in this case fully Offloadable to the hardware so the hardware will be able to talk native vertigo at full speed So it's the benefit of sreov in terms of latency with the benefit of live migration and and and hardware independence of vertigo bottom line if I would suggest Sreov is not mandatory to be high performance and Another proof point another the same measure on an vertigo VM I generated on one queue 142 gigabit of traffic So vertigo is not the the performance. That's the back end Which is if it's ovs. It's a very slow But that the vertigo by itself is not slow. That's the back end. So ODP net is something else Again, we recognize the benefit of single driver hardware agnostic driver for VMs like vertigo So vertigo allows to be completely hardware independent. The idea is to leverage very complex offloads from VMs using a single Abstract PCI device which will be controlled by a single device driver Regardless of if the smart nick comes from KVM NXP Melanox Marvel or others last point if you go to systems that have 400 cores and You have smart nicks It starts to look like the GPU world where you have Applications that may be split between the host and and the smart Nick So you have open CL to have your part of your application run on the host part of your application run on The GPU and in a hardware independent way because that's hidden behind open CL Well, why not doing that also for networking and have ODP CL which will allow you to create application leveraging concepts of open CL and parts of the Parallel aspects will be offloaded to the smart Nick the smart Nick being either a real smart Nick or an FPGA and I've just last week started to talk to FPGA vendors if they like to collaborate on virtio FPGA and Well, it might be possible. Thank you for your Attention, if you have any question, I did not hear very well your question. So there There is a software implementation of the event that model in DPDK and KVM is just upstreaming also for the next DPDK release a hardware implementation So that's that's available. It's it's it's moving forward and Intel and KVM have collaborated to make a An event model that can fit both hardware Environments, you know, we're talking about it. So that's the status at the moment. Yeah, then the problem is the data path with the Hardware driven buffer management. Well, you have the other The packet ordering framework. I'm not sure it's there But if you want to have fat pipes for your customers, you have to have a packet ordering framework so so And if you look at for example IP sake acceleration today As we have the pipeline model, we can have inline IP sake acceleration While with DPDK for the moment, you cannot do you can do only Look aside acceleration which costs a lot because you have packet movements always From the network card to the software back to the accelerator that so all those PCI movements cost Not only latency, but if if you have two one TCP session that goes from A to B the latency result in a TCP window now do not open and Even though the DPDK IP sake acceleration could handle more traffic the endpoint because of the latency Do not open the window and have at least half of the bandwidth or half of the throughput they could handle Yeah, I had a question about the IP sake numbers. You mentioned earlier the 20 gigs Can you talk about what kind of encryption was utilized for that? Oh, it was the typical AES 256 with CBC, I don't remember. No, it's ABC. I Don't remember the but the typical one I mean, I mean a real a real encryption not new New algorithm both on the crypto and hashing algorithm I think we have time for one more question If anyone has any direct questions if you don't mind we have the break. So thank you very much. Thank you, Francois