Cloud Enabling DPDK and FD.io VPP - Ray Kinsella, Intel

I'm Rey Kinsler I've been a fighter developer for the last three or four years and then prior to that I was working on DP DK for the previous six or seven years I worked on DP DK and before it was called DP TK before it indeed had any name at all and so I'm gonna talk a little bit today about what were these we're doing to enable cloud enable VPP and DP D K now what do I mean by that because it's kind of a bit of a nebulous term what does cloud enabling mean well I guess I'm talking about making both of those VPP and EB decay more conducive to working in the kind of environment and the kind of working activities I've been happening okay oh there we go legal disclaimers and there's who I am I already talked about that okay so and before I move on I just want to comment on the last press oh and just is anybody who gets up here and can do a demo like that and not have its form that's ass I did I just think that's legend any demo I have ever done standing on stage has inevitably seg faulted caught fire exploded so way I just thought that was absolutely kick ass so I don't know I think he's left the room but anyway yep which kudos on the lot to the last presenter so um let me move on okay so I guess the network is changing when back when I start working on networking for Intel network functions where we're always kind of discreet appliances mostly with a 6 and then sometimes Software Defined and what's happened since then is that we've seen a kind of a revolution in how network functions are and I mean data playing network function a dead plant network functions are being built and that is you know things have moved from being purely expressed in Asics to being software-defined on discrete appliances and then those soft discreet appliances got turned into virtual network phone and those virtual network functions are becoming cloud native network functions and that's part of what we're here today talking about what's happening underneath is that the actual application software you know since became since being deployed and the discrete appliance really hasn't changed all that much from being this you know being on the discrete appliance to a virtual network function to a cloud native you know exactly it's a way to a cloud network function so we're having to do some work and there's many there's some good reasons why that has happened and I'm gonna talk about that in the moment but well the basically the message I wanted to give you on this slide was that even though deployment has changed application architecture hasn't necessarily changed yet so what I'm going to talk about in a moment is the kind of changes that we're bringing to DP DK and VPP to make it more conducive to working in a cloud native way oh [Applause] there we go so while your show of hands who's heard of DP DK before okay and I presume everybody's here to follow before yeah that's it so I gonna make a long to make a long story short on this slide for years we worked on DP DK and we had a ton of sample code and we always kind of looked at the Stars and said gee wouldn't it be great to have a network stack to run on DP DK wouldn't that be just fabulous because we had sample code for ipv4 we had sample code for we had sample code for l2 we had sample code for V host I ordered a bit of it myself and we had sample code for this and that well we didn't have anything we didn't have a fully featured Network we didn't have a fully featured network stack and there was a fully featured network stack available from a few different vendors so when Philo was open-sourced back in 2000 fifteen 2016 it was a gift it was what DPD hay had been missing for years it was a network stack that was built with all of the same optimizations as DP DK and was really really a lot of what we were looking for so we were delighted I didn't tell when Fido was open-sourced and that's kind of where how I would differentiate the two different use cases where we give DP DK for greenfield developments if you're looking to build your own network stack from the grounds up and you know we you know we offer DB DK and that's a great place to start if you're looking to start with an absolute ton of existing code you know that's where we offer Fido VPP and you know the great story is the two things work great together you know fighting DP DK is not aiming to integrate with kubernetes or OpenStack directly it doesn't achieve that true talking true Fido VPP so I guess the why do we engineer DP decay the way we did performance essentially you know DP became exosomes makes strong assumptions are made strong assumptions about owning all the network art it made strong assumptions about owning large tracts of memory and then made strong assumptions about using all the cpu it was given so going all the way back to those month those discrete appliances that I talked about when they became software-defined when DP DK was running on their software-defined discrete appliance it owned all the nicks on the system anyway it owned all the CPUs of the system anyway and all the memory on the system anyway so and it did this for performance reasons you know it may it made it a random hole mode in the CPU to avoid context which is caused context switches are prohibitively expensive it use huge pages to avoid TLB misses because TLB misses are prohibitively expensive and it also it owned the entire NIC because sharing and equites somebody else is on you know you can end up with things like ends up in that era in determinism in the system so deeply kaor the whole on the whole Nick so we designed EP DK to be like to support monolithic applications and to be very deterministic in how in realizing extremely fast performance but times have changed we're no longer being deployed in discrete appliances we then moved into being deployed on vnfs then we had to work very hard with virtual network functions to offer the same kind of determinism and now as we move towards cloud native cloud ready models we have to find ways to offer the same level of performance but to do a little bit better on sharing and that's talk don't talk to in the moment so inevitably things break down three ways I talked about CPU sharing i/o sharing and memory sharing so one of the things that we've done recently was we worked reworked the DP DK memory subsystem so that DP DK allocated memory on demand G there's a novel idea allocating memory on demand but that's essentially what was done so instead of our offering instead of allocating huge amounts of large tracts of huge pages as we would have done in the past now what we do is we allocate as huge pages as they're actually required so that's drastically reduces the memory footprint for the most deeply DP DK based applications and there's more like this coming and as we do further work to optimize and make more lightweight the DP DK memory subsystem we also offer an enhancement now to Intel's range of 40 gig NICs called for film what you know in an age where your network is resplendent with the overlay protocols one thing that you'll need you typically need to be able to do is balance i/o across multiple receive queues and across multiple virtual functions as you disaggregate your monolithic network appliance and that something that we enable now with for Phil we can go dive into the packet we can see overlay protocols and we can you know load balance on the other header we can old balance on the inner header required and then finally we coming into more light mate io options so previously your only way to disaggregate IO was to allocate virtual functions we're moving beyond that now when we're offering a technology called VD PA and what VD PA offers is the ability to separate a control plane and the data plane of the network card such that you essentially end up with an Rx and TX q pair virtual interface so it's a DVT PA is a for pure virtual interface that offers a that offers virtio sorry it offers virtual function speeds well it doesn't you don't end up having to allocate at virtual function granularity so typically NICs live typically Nick's live and until Nicks and limits you to 64 or 128 virtual functions but our NICs also support upwards of 1.5 K device pair queues so by no longer by moving away from virtual functions and by act creating a virtual interface that wraps the NICS device per queue you can have a very lightweight interface that you can allocate into containers as you require but gives you very very very fast performance but also doesn't have that kind of that that very you know that scaling story around virtual at the is our iove' type around virtual functions so those are just three things that we've done recently in DP DK to make it more lightweight we've given it a way to use memory more often Lee we've given it a way to and oh and ways to be more lightweight Nile so we'll move on to fight OB PP we've done similar work in Fido VPP and I have to give a lot of credit to Danny and Marian who's not in the room at the moment please damn Ian has done a lot most of this work so um you know like DP DK before you know undertaking this were Fido bpp had the same kind of characteristics in that it hold all the time it consumed all the cores it was given so what we have done is we have moved to more recent models where you can shift between pure polling mode and interrupt-driven mode based on the relative traffic at the time if you're in a and if you're in the peak scenario you may want to poll you know if it's your peak traffic time but if it's in the middle of the night and you're not seeing very much traffic you might want to shift back to interrupt mode and save power and we offer both the ability to shift from interrupt mode back to pole mode at runtime you don't need to restart it defy the VPP this is our runtime configuration shifting between the modes but then if you want VPP to be responsive to the traffic conditions you can also set hybrid mode or adaptive mode in which VPP will make a decision out runtime and in real time whether it needs to be polling or it needs to be in the or it's we can more optimally run an interrupt driven mode and the shift between the two states on demand so this gives you the but this gives you the ability to this get two response in the treta network conditions there is something else is you can also reallocate or X and T X cubes between cores so if you want to put a core into essentially into idle mode ie are not want to use that core I want to scale down the number of cores and I'm using you can reallocate your X and T excuse to a single core so move all the servicing of all the aurochs and he excused you've allocated on your Nick down to a single core or if you're in the back into a peak traffic scenario you can reallocate those or X and T excuse back to one of the worker cores at runtime now will work record that has is not servicing an RX and TX queue as essentially nothing to do so that core can be reused for something else and so you in this way you have the ability to scale out phyto VPP at runtime based on traffic conditions by shifting it shifting around the orcs and T excuse between cores and then shifting those cores between polling and adapt adaptive mode and their interrupt driven mode something else that we've added recently into Fido VPP is a symmetry you know previously filed away fight OPP was built was that it always assumed it made you ran the same graph nodes across all course and then you typically had something doing load balancing between those cores under the hood something like or SS so what's changed is that we have introduced technologies into Fido VPP to allow for the VPP to have a symmetry to run one pipeline on one core and another pipeline another core this tends to lend itself very well to kind of tunneling scenarios where you might do an in cap on one core and then grout to pack it out to the wire on the other core or you might want to do nothing on one core and then road to pack it out to another core you might want to do IPSec encapsulation on one core and then route the packet to ACLs or something out another core and that's technology is called handoff and that allows you to break the packet processing pipeline at a halfway point or the point that you deem and then to load balanced are sorry to handoff the packet between cores so it allows you to scale phyto VPP out the packet the packet packet pipeline and apply the PPP out across multiple cores something else we've also added support for is support for the DP DK or Qi flow API and what the RT flow API allows you to do is actually G to program the flow director which is a flow Direction technology and the NIC to direct one kind of flow to the bone core and then another kind of flow to another core so you might want to send all your ICMP all your air packets all your control plane packets to a single go to core zero and then you might want to send all of your data plane packets like ipv4 or ipv6 routing to one course one two three four or whatever it is and the RT flow API allows you to that allows you to program flow rules down onto the neck and again this is something that we added recently for the VPP while all these things allow you to do in concert whether it's handoff or as either RTA flow is allows you to run different pipelines on different cores and to scale out your packet pipeline we also added a high performance memory interface to support container to contain or communication you know previously in the age of virtualization we had a ton of guys myself included working on technologies like V host and vertigo and figuring out the way to squeeze the last cycle out of those two technologies both in the age of containers you know all a new virtual interface is required you know vertical no longer rules and to answer the call for the VPP created a new technology called mammoth interface which supports both V switch and point-to-point package communications so you can do a traditional V switch HP switch B router and use Fido VPP to switch between your containers because a/b switch RV router but you can also use ma'am if to create to punt packets directly between containers and I think magic was talking about this earlier where we talked we were talked about realizing virtual servers a container of cloud native service change with Fido VPP well man if is a technology that Sanchi allows you to do that so it allows you to punt from pack a day it sorry containing array to contain your beacon tell you see just using a lightweight memory interface which is live mammoth it also has been highly optimized for the platform itself making liberal views of vector and structures and vector instructions and my colleague from arm was talking about using vector instructions earlier but Lib mammoths makes liberal use of vector instructions to have a very highly optimal way to point packets between cores we have also done a lot to make V Fido VPP more lightweight itself for it infrastructure so you know if you want to have a very lightweight layer for a saree layer 2 layer 3 interface we have Lib mammoth or a layer 2 layer 3 interface and if you as just essentially it's as a lightweight library that you deploy insert it into your VM sorry insert into your container forgive me and that gives you gives you a high-performance interface back to your inference a back to your infrastructure we also have a layer layer 4 and layer 7 interface which is which is live VCL and Floren talked about that earlier again it's a lightweight way to put 2 at upon stateful communications back to your infrastructure the infrastructure itself based on file VPP you can chew into your memory requirements and in the way that I talk to you know as we talked to you before you can make it more lightweight you can make it use less memory or more memory you can make that infrastructure scale up or scale down you can get that infrastructure is more friendly around you and sharing i/o so the infrastructure itself has become more lightweight so the infrastructure is becoming more light and then the ways to talk to that infrastructure themselves are also lightweight now as someone going challenges and I guess not specifically for Fito PPP but um we're is one of the things that we're still missing is improved ways to share CPU times between processes you know one thing that we haven't cracked yet is a way for to continue to get high-performing interfaces in a way that's more you more friendly to share CPU time certainly the ability to scale up and down a cork and you know is definitely part of the answer to that but we haven't quite cracked away to mitigate the cost of a context switch so that is something that's still being worked on we and another challenge is you know user space networking and how user space networking is evolved so back when I started working on user space networking everybody wanted us to make user space networking looked like analytics this thing this thing called DP DK is fantastic it gives you great performance we want to use DB DK you know you what you need to do is make it look like Linux and then we'll go use it you know going to react tech DVD K to look like Linux I know that wasn't you know I wasn't parity wasn't possible at that time now another DP DK and Fido VPP have become solid parts of the networking ecosystem we look to other communities such as F for routing or to bird or to khawaja or to you know insert the name of your favorite network as your favorite networking software here to become friendlier to user space networking user space hat networking is here to stay and interoperability with adjacent communities it you know is starting to happen and it's a welcome trend and we need more of it so finally I'd say that Fido VPP R and D PDK are complementary technologies they're sadly becoming cloud native it's re starting to come in more cloud friendly and cloud ready the reason they were designed for a very very specific reason and that is to enable performance enabled you get you know kick-ass performance what we are finding ways and we're continuing to evolve ways to make those to make those applications perform and be more friendly to a cloud a cloud environments or cloud the cloud deployments ok and thank you for finishing with plenty of time left because we have time for a couple questions so all right I will hit the three people who have raced their hand so go first hi you talked about VTB interface in the DVD Kay like VDP a so the VTB interface video I talked about the mem interface in VPP yes can we not just pick one and use them for both very much targeted for scenarios in which you want to do something let me explain this so a lot of kubernetes deployments that we see are actually deployed inside virtual machines so your land opera the relatively large virtual machines with kubernetes deployed inside it and lots of containers in it and this is what this is a way in which some comes is some which cut some comm service by there's some cloud service providers separate you know separate or kubernetes employment from their infrastructure so in those scenarios VDP a that's where VAP a really shines which is in which one to point a lightweight interface interface into your virtual machine for use by your containers if you're in a more bare-metal deployment scenario Maggie you might find them if use so I have a sort of comment to what you said at the very beginning that you're sending all the kudos to the demonstration team doing the stuff before Frederick any teams I just wanted to as Frederick's now in the in the room I think a big kudos goes to the previous speakers who did the demo because yesterday was a very special day yesterday was the 50th anniversary of the demo of all demos by the dock Engelbart who presented web and mouse and few other things so 55 niversary yesterday and today seeing this demo it was a beautiful way to celebrate the fiftieth anniversary so really big kudos to the to the team on the on the dip it again denotes you know I've been I had heard heard about the PDK before I started to work on FD IO and MVP and I have to say that thanks to the PDK and and you guys my faith got restored into fast that working come on computers and I you know really enjoying the the collaboration and I absolutely love your visuals which were much better than mine so you clearly know your stuff in terms of the hardware yes so about a year about a year so that was the warmup about a year ago we started to project this very catchy name technical marketing you know running terabits performance on the computer that's what we did last year and we did it for Nick tonic okay and we know how much we can drive from the socket we just multiple sockets we get the turbot sure cool what do you think in your view will take for the industry to get a terabit services out of the computer so no Nick - Nick anymore but actually those network functions that I talked about and you talked about how far you away you think we are one terabits per second from a single computer lots of network functions typical watch things evolve now to the point where typical systems 20 generally have 20 posts in the aggregate on that system between a TP system you're talking about 40 cores and you're talking about speeds from the 40 to 100 Gig range I'm typically forced now so I see there's an inevitable aggression where we get to those kind of speeds it's a matter of a core and that's a matter of not as a matter of course a matter of Iola so when so I understand that you also believe in the Moore's Law rambling on from the IO networking guy all perspectives because if we just keep extending this curve I think it's not that far away at all actually also improve my PC you know we had to contribute from our main area are talking about you know the you know use of vector instructions in the iron on the iron microprocessor and we see the same behaviors in the Intel microprocessors wherever generation on generation equal IPC gets faster the number a PC improves the number of cores counts expands an amount of available I own the system also improves and also the amount of the scalability of the IO fabric also improves over time so yeah and that's why I made the comment just a moment ago that I think it's an arat it's just inevitable we heard ask me for a specific

Channel: FD.io

Views: 667

Rating: 5 out of 5

Keywords:

Id: 22nwTBtL5fM

Length: 26min 22sec (1582 seconds)

Published: Fri Jan 11 2019