 Ready to go? OK. Thank you, everybody. My name is Nick Dossanovich, Solutions Architect at Netronome. Today I'm going to be talking about SmartNix. So SmartNix, there's been quite a bit of buzz in the industry about SmartNix. At Netronome, we also call them intelligent server adapters. But people like to call them SmartNix, I guess, because it's shorter and it sounds cool. And I have nothing against that. Before we talk specifically about what a SmartNix is, I want to introduce sort of where the SmartNix plays in a cloud stack network. So really we're going to focus in on the compute node, which is the server in the cloud infrastructure, which is working within the context of an open stack cloud. And in the compute node, obviously, you have a CPU that's running your virtual machines. And then typically there's a network interface card that's plugged in via a PCI slot that performs functions such as talking to your network switch, your top of rack switch, through ethernet ports. And then doing some basic functions to the packets, processing the packets and sending them over the PCI bus doing some DMA operations. In some cases, the basic NIC functions include things like basic offloads. RSS is an example or LSO. Check some offloads, things like that. And then there's specialized offloads that some NICs do for things like storage and so on. And then once the packet is delivered to the server, that's where the server networking data path takes over. And this is where richer features are implemented. And these richer features are critical to successful deployments of open stack clouds. So as an example, in open stack clouds, typically there is overlay network support to support things like network virtualization and multi-tenancy. And in that case, overlay tunnels such as VXLAN or other types of tunnel protocols need to be processed. And they're processed in the server networking data path. Other things that can be done are more complex traffic classification for policy-based forwarding and also security policy, both stateless and stateful, can be implemented in the server-based networking data path. And then finally, things such as customer-based or workload-based QoS, metering, statistics, and stateful operations as well. So this rich set of server-based networking data path functionality, as I said, is critical to open stack clouds. And today is commonly implemented in the server in software, either running in kernel space or in user space in some implementations. So the key attributes of the server-based networking data path in an open stack environment are the ability to handle these rich features that we just discussed and future features that may come along. And then it's very important that the server-based networking data path is very flexible and easy to use so that operators can roll out features very quickly, implement things like new tunnel types and new features in their open stack clouds. So that implies very simple and easy programming and configuration of the server-based networking data path and also, obviously, leverage of the open source ecosystem is critical here as well. What the server-based networking data path must not be is a bottleneck to performance or provide an excessive tax on the server CPU. Unfortunately, that's exactly what's occurring today. And this graph illustrates the performance of a typical server-based networking data path based on open vSwitch or OVS and the performance that we get with that data path running it in software on an x86 CPU. And you see both a kernel-based and a user-spaced implementation for Layer 2 or tunnel-based processing in the context of OVS. And normalized per core roughly hits about a million packets per second of processing. So you can see that that's not even close to 10-giggy line rate. Many cores would be needed to support a 10-giggy line rate at that performance level. And furthermore, operators are moving to 25-giggy, 40-giggy, and beyond in their network. So this is a real problem today and it's getting worse as time goes on. Just to illustrate this in a little bit more detail, let's say we take a typical implementation of a server-based networking data path in software running on four CPU cores. As we just said, you get about 4 million packets per second of data path performance. And in a 24-core, typical 24-core modern server CPU, you have 20 cores available for VMs. And if at a VM workload of 1 million packets per second, which is not unusual, those VMs would be asking for 20 million packets per second. Yet the data path can only deliver 4 million packets per second. So you have a bottleneck. And basically your applications are running in a starving state and are not able to perform. Now you can try to solve this problem by adding more cores, throwing more cores at the problem. And in this case, you can have 12 cores delivering 12 million packets per second to 12 VMs. And there's a nice balance in terms of data path performance. But look what happened. You just took up half of your server CPU and it's not running applications. So that's not a good utilization of your cloud infrastructure resources. This is why we need smartNICs. I think there's a wide recognition here that this is a problem that needs to be solved. And the way to solve it is to take the server networking data path and accelerate and offload that networking data path down into the smartNIC. In this case, we're showing the data path being implemented in a processor on the NIC card. And all of those functions, the same functionality had before, can be implemented in the processor on the NIC card. And the processor here is optimized for server-based networking processing so that it can implement those functions at a much lower cost and power per bit than they can be implemented on the server. And at the same time, you get all of your CPU, expensive server CPU resources back for applications. So with the smartNIC, you now have an even balance. The data path can support the same data rate that all of those VMs need, even to 23 million packets per second and beyond. And you have minimal impact on your CPU resources and almost all of your CPU is now available to run your applications. Now there are different models. Not all smartNICs are created equal. So we'll talk a little bit about how the smartNIC operates and different options for offload. So on the left of the screen, you see a partial offload model. In that case, you split up the functionality and you perform some of the functions on to the smartNIC. And some of the functions still occur on the server. This might be because the smartNIC may not be able to process all of the functions or something like that, or they're not implemented yet. So that's one model. It's called partial function offload. The next model is partial flow offload. And this is the case where the smartNIC can process all of the traffic. All of the functions are on the smartNIC, but it may have a limited capacity for flows. So you may cache a subset of your flows in the smartNIC and accelerate those. But if you go beyond that capacity, then you'll have to fall back to the server-based networking data path. So you get some acceleration, but it depends on how many flows are active at a given time. And then, of course, you can have a combination of those two, partial function offload and partial flow offload. So these are partial offload models. And then, of course, there can be a full offload model. And in the full offload model, all of the functionality is implemented on the smartNIC. And all of the flows that are active can be held on the smartNIC so that there is no intermediate step. All of the traffic gets accelerated and offloaded and delivered directly to the applications. Now, the next one on the right side of the screen shows a full data plane offload model. But in addition to that, you have a control plane offload as well. So in the previous models, the control agent was always running on the server. In this case, the control agent can be run on the NIC card on some type of a processor that would be present there. This use case is applicable in cloud environments where the host operating system is unknown or not trusted in some way and is also very useful in bare metal environments. So you don't have to be running VMs at all. You could have a bare metal server. And you may want to have smartNIC functionality to implement things like security policies and things like that on the NIC card. In that case, typically the control agent is accessed via the network and not via the server so that basically the server doesn't have to know that anything is running, but it's getting the ability to get security firewall policies, for instance, metering QoS and things like that. So I presented several models for smartNIC offload. And the key point here is that it's not all black and white. There is a spectrum. There are approaches that do less flows and approaches that do more flows, approaches that do less functions, approaches that do more functions. So there's a spectrum here. And really, if you're looking for a smartNIC, you want to look for one that tries to optimize that for your data center. So the more functions you offload that are applicable for your use case and the more flows you offload in your flow environment, the higher the performance is going to be, the more CPU cores you're going to save. And that translates directly into total cost of ownership in terms of capex for servers and things like that and power and overall operational cost. Now, we talked a lot about performance. We talked a lot about CPU utilization. We talked a little bit about flexibility in terms of being able to program or change the functionality and adapt the functionality of the smartNIC. But flexibility is more than just programmability. Sometimes people just think of those as being the same thing. But in a modern, open-stack cloud, flexibility means more than just being able to change the functionality of the data path. There's a lot of operational complexity in implementing a large-scale data center. And flexibility is important when you think about dynamically moving workloads around, not having to worry about the software infrastructure in terms of drivers and things like that for your workloads. So it's very important. And so not having limitations on where you can place specific workloads, not having limitations on vendor-specific drivers, is directly translates into operational efficiency for Cloud Service providers. So in addition to being programmable, the key point here is that a smartNIC should have a strategy, must have a strategy, to be as vendor-agnostic as possible in terms of its driver architecture. And then also to effectively be truly flexible. It should have something that's typically built on a VerdiO or Power Virtualized Driver infrastructure. So here's an area where Netronome has announced a architecture called XVIO. And XVIO stands for Express VerdiO. And what this does is it kind of puts together the best of all worlds. It takes driver architectures that are very efficient and high performance, that are based on things like DPDK Polmo drivers and SRIO V principles. And it integrates them together and presents them to workloads in the same common way, in a vendor-agnostic way, through VerdiO. And that's what XVIO essentially is. And what XVIO basically translates to the end user is very high performance. Basically, the performance of XVIO is on par with SRIO V implementations. But at the same time, you get rich services and you get high flexibility, as we just said, because you can move workloads around and you don't have to pin workloads to specific resources. So that's some of the key principles behind XVIO. So what does a SmartNIC look like? Here's a picture of one. Netronome provides a line of SmartNICs called Agilio, Agilio CX. And as I said earlier in the presentation, we also call them intelligent server adapters or ISAs. We have versions that are based on 10-giggy and 40-giggy standards and 25-giggy is coming as well. And the key point here is that we support all of those different offload models that I presented previously, partial and full offload, full offload because we can support millions of simultaneous flows. So in any real-world environments, we can effectively have all the flows being offloaded down on the SmartNIC card itself. And our metrics are showing a 20x performance gain core per core on the x86 over user space-based OVS implementations, so very high efficiency. And as I noted, we have the XVIO strategy to provide the workload flexibility. So here's a picture of one. You can also pick one up and touch one in our booth, which is located right over there, behind the stage, to the left, to my right. And we'd be happy to answer any further questions. Thank you. Questions right now, or do you want to? Questions? Yes? Yeah, excellent question. Question was, does it support firewall features or connection tracking? The answer is yes. We have support in our OVS offering. We support the contract functionality, which is integrated into OVS 2.5. So that's basically a stateful connection tracking feature. And you can implement things like distributed stateful firewalls for micro segmentation and things like that. And that is supported in our hardware and our software. Yeah. Yeah. And our VRouter package as well, yes. OK? Other questions? OK, well, thank you very much for your attendance.