 I'm ready, yeah. OK. Hi, welcome. This is a four o'clock presentation called Accelerating the Cloud, Maximizing Network Performance for OpenStack. I'm Richie Aikawa with Solar Flare. So welcome, everybody. What I'm going to cover today, I know mostly you may not know about Solar Flare, so I'll talk a little bit about our company, our product portfolio. And I'll talk about what we're delivering today in terms of being able to make VMs more scalable and how we can improve bare metal performance. So we get bare metal performance within virtualization and in containers. And then what we're doing to connect all that up to OpenStacks. So the primary thing I want to let you know is that we've been working a lot on the network infrastructure so that we can have that be optimum for network performance. And then we're going to do all the add-ins up into OpenStacks so that you can use horizon and heat to be able to take advantage of it through our connections to Neutron and Nova. But a little background on Solar Flare. So what Solar Flare does today is that we develop network solutions to help you to accelerate, to monitor, and to secure your network data. And we do that through a variety of products. And I'll show you where we've laid our stake in terms of where we're a market share leaders, and this is going to be on the financial services sector. So let's see. So our company, just the main thing to let you know, we have over 1,300 customers worldwide. We partner with companies like Red Hat, with VMware, Citrix, and a lot of Switch companies, Arista and Cisco and others. Our products are delivered into the marketplace by our reseller channel, as well as through HP and IBM, who privately label our products into the marketplace. Our headquarters are down in Southern California, in Irvine, and we have development centers over in Cambridge, UK, which is actually part of the merger between a level 5 networks in Cambridge, who developed a lot of our technology and with Solar Flare in Irvine. And we've opened up an R&D facility over in New Delhi, India. So this is a list of our customers. So you'll notice that a lot of the premier companies. So what we like to say is, like 9 out of 10 equity trades happening in the marketplace today will be happening on Solar Flare equipment. So the New York Stock Exchange, NASDAQ, CME, SIBO, the Tokyo Stock Exchange, all these stock exchanges are using our products. So they're very reliable, very high-performance products in terms of low latency and high message rates. OK. So we develop our own network controllers. We develop our own adapters. And we even have an FPGA-based product. So you can do inline processing for both pre and post processing of network data on the fly, on the wire. This is good for things like normalization of information coming from the ticker information coming from the exchanges, for encryption, for decryption on the fly, for decoding on the fly in terms of already having it done before you have to use the actual application servers. We support all the variety of OSs and hypervisors. And then we have a variety of software applications upon which you can lay your services on top of our network adapters. So we'll talk a little bit about things like network functions virtualization and being able to use the adapter to be able to, as a platform, for you to be able to run services. So what are we delivering in terms of our adapters? So we're delivering high-performance, low-latency, 10- and 40-gig network adapters. Our adapters are very cut-through architecture. We support the various stateless hardware to offloads for TCP segmentation offload, the large receive offload, the generic segmentation offload, IPv4, v6, and TCP-UDP check sums. We have 2,048 virtual interfaces on our adapter. And you'll see how that becomes relevant when we start to talk about scalable VMs and about scalable performance. 16 physical functions on our adapter. So we have a two-port adapter. We'll come with 16 physical functions, as well as 16 MAC addresses. So you'll be able to have a single adapter that can be partitioned up into 16 different segments. So it'll be an asymmetrical partition. You can have one MAC address on one port, 15 on another, or 8 and 8, depending on how you split it up. And it'll appear to the operating system as if you have 16 ports, devices, attached to the operating system that will go out through two physical interfaces. This could be used for things like storage segmentation, network management traffic. And we're adding the ability for you can have cause features in terms of priority settings, in terms of bandwidth control, rate limiting on these. So the adapters become very flexible on how they can be deployed in the various servers. And we offer 240 virtual functions. And you'll see how that has become relevant in terms of the virtualization performance capabilities. And then we have Afflex licenses. So we have a technology that's called Afflex. So application flexibility to be able to deploy on terms of an adapter. You have a physical adapter that's now providing you your basic network connectivity at 10 and 40 gig, high performance. And now you want to be able to do things like packet capture on that. You want it to be able to do things like a filter engine packet filter. So you can do DDoS mitigation. And I'll show you how that is actually relevant for the virtualization space. If you wanted to do precision hardware-based time stamping of Ethernet and PTP packets and time synchronization across your network, that service can now be added to your adapter, and as well as performance monitoring for both Ingress and Egress time stamps. And we also have our flagship product is something that's called Open Onload. It's an open source project that we're the maintainers of that allows you to do kernel bypass middleware. And I have a slide to talk about how this is all Ethernet sockets compliant. So it's not using InfiniVan verbs or anything for already made technology. It's actually no application changes necessary runtime calls to be able to use a kernel bypass technology. So this is Onload. On your left is your typical TCP stack that goes to the kernel. And on the right is using Onload, where we run in user space. We have a TCP IP stack that runs in user space that has a front end that attaches to applications to provide a sockets interface. So it's pure BSD sockets, POSIX compliant. You run your, it co-exists with the TCP stack. So at runtime, you could decide if you're going to use a kernel or if you're going to actually use this kernel bypass technology. And through it, you get reduced latency by bypassing the kernel stack. But equally important, you have higher message rates that are capable through it, as well as being able to run very deterministic. So low jitter in terms of getting the data tuned from the off the network. And this is a graph showing in terms of kernel performance. So if you look at the red slide, this is using just a Linux kernel stack with one core. If you're using two cores with the Linux kernel stack, you can see on the left axis, on the y axis here, you have latency in terms of microseconds. So you're running at about five microseconds. If you're actually using like the Linux kernel 3.10 version and you use busy pulls, very CPU intensive, but you can get that down to sub four microseconds of performance. But if you're using on load and you're only using one core, you're down into the, with on load about 1.7 microseconds. This is a half round trip UDP. So we're doing a ping pong from one server to another server, half round trip, one way across on UDP. And we're down to about 1.67 microseconds of latency. And you can see also on the X axis, this is message rates. So not only do we have much lower latency, the message rates get much higher in terms of performance on this product. And this is used quite a bit in terms of the financial services, but it's also used in HPC marketplace. And on load is also valuable where we're seeing in terms of like web server application usage. So the web server in terms of latency does become important because one of the most important aspects of the web, this is actually interesting. One of our customers is Cloudflare and they're talking about bandwidth is not an issue. It's about latency for anybody who's doing a web server application because once you start clicking that web and you don't get a response, you're off to another site to try to figure out why something's not being responsive. So that initial latency is very important for even a web server application. Okay, so let's talk about cloud networking. So that's all the solar flare products in our portfolio. So cloud networking, I'm preaching to the choir, I know. So you got a new level service of flexibility, IT automation and scale out of compute storage and networking products. And with server virtualization also. So this is all server virtualization, as you know about commoditization of hardware. You can run all these different industry standard servers and be able to load your server, your server OS images and run it into VMs and all. But the problem with running server virtualization typically is that you run into a performance set that the hypervisor does get involved. And so you end up having VM scalability limitations as well as application latency issues in terms of how fast you can go through the stack. And I'll have a slide later to show you. This is like an order of magnitude of latency performance where you go from server to server, if you go from VM to VM, you're looking at about a 30 microseconds versus what I was just telling you about with onload of being able to get down to 1.7 microseconds latency. And how can we get that level of performance even in a virtualized environment? That's what I'm about to talk about here. So how can we help you in terms of all these in an open stack environment and virtualization and all? So we can provide you with more scalable clouds. You get more VMs per network adapter to maintain performance. We can allow you to get bare metal performance even in a virtualized environment. And we'll talk about also in containers. And we can also allow you to virtualize some network services and run those instead of having it all run in terms of appliances. You can start to flexibly deploy virtualized network services like packet capture, filtering firewall capabilities, and even precision time synchronization within VMs. So this is a use case. So we have a private cloud provider today that has a private cloud environment where they're trying to deploy up to 450 VMs. So it's all about breaking down and tearing up, creating and breaking down virtual machines so that developers can use the site. And they're wanting to be able to get scalable performance, not have to continue to add more network adapters as they add more VMs. And so this is a comparison of us. This is the Intel X520. But the idea here is that because of our architecture, we're able to continue to add VMs and maintain a high level of performance. So the counter is, of course, that you continue to add more and more cards so you can have more and more bandwidth as you add more VMs. So scalable VMs to the customer, what that meant to them was that as they deployed all these servers at 23% increase in performance, allow them to save in terms of how many physical servers they had to deploy, as well as how many adapters they had to deploy with it. So I'm gonna switch gears a little and talk about how do I get... This is all about SRV. So everybody who's doing anything today with Kilo knows about what OpenSack is doing is try to make the SRV capabilities available so that you can have low latency applications be able to be used in a complete private cloud environment. So customers today are saying, I've got my low latency applications running here. I cannot yet bring them into my cloud or my server virtualization farms because that doesn't allow me to support those low latency requirements that I have. So how do I get to that point? And so I'm gonna walk through the storyline on this. If you're not familiar with SRV, it stands for single root IO virtualization. It's a PCI-SIG standard that's been around for over 10 years. And single root means a single complex. So this is on a single server, being able to virtualize the IO channels for both storage and networking. So in the past and what people did before was of course you had emulation when you first started off. Everybody emulated like an Intel E1000 adapter, very slow performance. Then the hypervisor vendors ended up having a pair of virtualized. So it was no longer peer virtualization where the OS didn't know that it was running in a guest operating system. It now knows that it is. In fact, it has a pair of virtualized driver. So in the case of like with KVM they have a vert IO dash net driver and then VMX net three driver in ESXI. So when you load ESXI and it tells you asks you what network interface you wanna use, you would typically select the VMX net three interface as the interface. So this is what typically you run and this is still running even with pair of virtualized. That's that, I'll show you later, but that's that 30, 20, 30 microseconds of performance you get with that interface. So SRV of course is hypervisor bypass and in the KVM world it's PCI pass through and in the VMWare world they call it direct path IO. So it's the ability to bypass the hypervisor and be able to let the VM load your driver up into VM and let it talk directly to your hardware and be able to get access to the hardware resources to be able to get the performance that you need on that adapter. So we provide 240 virtual interfaces and 16 physical interfaces. So 256 interfaces available from a single adapter within a hypervisor environment so that you can load, if you had 450 guests like that one customer had then you can actually from a single adapter be able to, you can put in like two interfaces into the hypervisor itself to let it run non-latency intensive applications and then our VMs and then you can use the 254 other interfaces and let it talk directly to our hardware and get access to the hardware resources. What we've been working on in addition to that is to be able to do both simultaneous kernel bypass or open on load I was talking about as well as hypervisor bypass inside of a VM. So now you can run your low latency applications down to that two microsecond applications within a VM and now you have the ability to be able to migrate your low latency applications to within your private cloud environment as well as into server virtualization farms. So this is, we're working with a large financial services company in exchange who is building an open stack private cloud and they wanna do exactly that. They wanna have one contiguous private cloud an open stack instance and be able to have all of their applications brought into that open stack instead of having it run off as a separate entity. And they wanna use KVM as the base and it's actually with Red Hat and KVM as their base virtualization platform to do so. And so we're running this scenario here on the bottom left in terms of taking from a standard virtualization now we're gonna both be running hypervisor and kernel bypass technology. So this is what kind of performance we're able to get on the graph right there that orange is actually running PCI pasture with Linux and an open on load guest. And so that's right about at two microseconds of latency and I was seeing in bare metal we're running about 1.7. There's some things that we're still working out relative to getting that down to the same exact bare metal performance. And I'll talk about in containers we actually do identically get in bare metals and containers the same level of performance. But if you're running in a VM guest and you're running with the pair of virtualized driver this is actually on ESXi with VMX net three then you're running at about 28 microseconds of latency. So we've been able to bring down that latency performance that they were getting why they weren't bringing in those high performance applications into the cloud. They were running at 28 microseconds now they're able to get it down to the two microseconds and that meets the requirements for them to be able to now port and have a single open stack environment where they can run all their applications and be able to have it move around in their cloud environment. So what about Linux containers? If you know about Linux containers and the Red Hat folks down there will tell you more about it relative to Docker based formatted containers that they have. So it's essentially running with shared libraries so you're running the same operating system and it's really about isolating applications from one another. So you're actually running virtualization is like isolating server OSes this is about isolating applications so there's a shared library that is used with Linux containers. But so we have a paper at our booth over there as well as with Red Hat you can from their site you can download this paper that Jeremy Eater you know their network guru over at Red Hat actually wrote up in terms of being able to get the same bare metal performance in Linux as they call it a Docker formatted Linux container on a REL7 or REL7 with RELatomic that you can get in bare metal REL. So the final thing so this is all the infrastructure the things that we've been doing to try to make private clouds be able to harness all the abilities of network accelerated performance. The final thing is on I want to talk about is on DDoS mitigation. So one of the services that we're delivering that you can have in bare metal is to be able to protect servers at the endpoint from a DDoS attack. And so we have a hospitality company so one of the big large hotel chains tells us that when they get DDoS attacks and they're always under DDoS attack and but a DDoS attack can also be when they run a sale or promotion and all of a sudden their website gets hit as if it's a DDoS attack or somebody makes a miscue when they're loading up a new web page or something and so all of a sudden they've got something that's looking like a DDoS attack and what they want to do is they want to have some headroom so that they can handle the barrage of all the incoming requests without the server coming down completely. So today if you're using IP tables or if you like and this is what the example here is like if you're using EngineX as your web server then when it gets hit what happens is that as an immediate cliff all of a sudden it'll come down and the performance that come down and your server is out and you're gonna get the no access from the server. So what we have with our filter engine is the ability to do rate limiting. So we'll note that we're under attack and be able to start rate limiting. So at least your server will stay up and running and won't go down and then we'll start to ability to do filtering and blocking so we can update, we do hardware filtering and we augment that with software filtering so that your web server can have a eight to 10 increase in terms of the life of the connection so that somebody can come and actually help fix the problem and you can update your filter tables so you know like if you know where those attacks are coming from so we have an interface to something like a Norse blacklist if you're familiar with these blacklists to show you where all these incoming attacks are coming from you can augment the list for the IP tables and say okay now we're now gonna block off all those IP attacks that we know that have been documented is coming across and you know where they're typically coming across from the two major countries over there that start with China and Ukraine that are attacking the US all the time so this is where we can actually integrate in with various blacklists and that's a service that we're delivering so this requires very high performance underneath it as well from our adapters so our adapters provide this network platform and we're providing this capability for all the low level acceleration but we're also delivering network services that can be used in a private cloud and implementation so finally the conclusion so I've talked all about this network function capability that we're adding with SRV with containers with these network services and so we've been spending all so this is a part of a rollout we have this today shipping on KVM we have this as technology preview on ESX and we're gonna be rolling out on Hyper-V as well supporting the three major hypervisors out in the marketplace so our focus is now shifting to be able to integrate that in and provide the interfaces up through Neutron and Nova so that when you are deploying a through horizon or heat you're deploying you and now are aware of what the SRV capabilities are of the underlying network adapters in the marketplace and be able to get this level of performance. And with that, are there any questions?