 So good morning, or I guess good afternoon or good evening to everybody. I'd like to start off by thanking Cassandra and the Linux Foundation for hosting this webinar. I am of course Scott Stetser I work for Kyoxia. One of the largest flash vendors and foundries out there and the inventor of flash memory. So our talk today is about multi protocol capabilities. And how do we bring flash into the world of being able to support multiple protocols using a software defined flash API. And of course, open source is important software is important. So this whole approach to a software defined flash API is relatively new that we'd like to introduce. We've done a couple of presentations in the past. This is not particularly new, but the idea of showing you how multi protocol is going to work using this flash API is a new aspect of the presentation. We know today hyperscale and cloud is all built on being software defined software is actually out there eating the world. And that's actually a good thing for all of the software developers out there. Now, there's been a number of very successful software defined approaches to redefining how hardware works. I think the most notable one has been software defined networking. That's been a big success out there there's also software defined computation, emulation for different types of CPUs and processors software defined hardware and software defined storage as well. Although that last step that last mile of connection to being fully software defined is missing that lowest level component the storage component. And in our case that flash SSD. So we believe it's time to bring that flash SSD into the software defined realm and enable that capability for you the developer to define how your storage can work. Why doesn't it work that way today. If we look back in our history, all the way back to the ancient times the 1980s computer storage was based on a hard drive. And this legacy drive is still valid today. It's still important today. The challenge though was that legacy drive was a very mechanical thing that was a rotating magnetic storage in a somewhat linear fashion, which I think there really wasn't a lot of ability to adapt that storage mechanism using software. It was a black box. It's fairly inflexible in terms of being able to adapt or change how it behaves in the compute environment, which means it's somewhat limited especially an aspect to doing things in a software defined way. Traditionally, that backwards compatibility was incredibly important as flash was introduced, maybe 15 to 20 years ago as a storage medium. It was very important for flash to come in and be plug and play very easy to plug in and use just like the existing paradigm for storage the hard drive. We're not going to change the way that you approach storage for standard devices like your laptop or your data center server. At all they still need that level of interoperability and backwards compatibility. But for developing applications, especially cloud and hyperscale and self builders, trying to adapt storage to their environments and their applications. This new approach adds an extra quiver in the quill or that extra capability, in addition to the traditional storage interfaces. Now we have the legacy protocols and legacy is not a bad thing. There are connections being sass and sat at an NVMe of course protocols being block storage protocols, and the new ones, the NS, I do bring in the NS. I consider it legacy, mostly because while it's new it's based on an old hard drive paradigm of she magnetic recording. And again, these fixed protocols cannot adapt or change depending on the application requirements. So we need to think about and bring in a whole new approach to doing storage in this new software defined world. If we look at the folks that are innovating this is the cloud industry and the hyperscalers. They look at these fixed devices as being limited by that device protocol. They're, they have an inability they can't adapt to the change in workloads easily and simply, which means there's a complex supply chain issue dealing with how to populate storage in the data centers. So let's take a closer look at the complexity of the supply chain. If we look at the supply chain. Different applications require different types of devices which requires the data center source multiple drive types and keep that inventory of different drive types available, depending on when and how they need to deploy their applications. And then a particular application may want to use that block protocol, or a CNS protocol. Those protocols and those devices can't switch between applications very conveniently they're very focused on achieving the results and the goals of that particular application. This means it's fixed and it's not very flexible in the data center. So, for the, as we've brought up this topic, what if we could make flash that digital storage mechanism software defined and allow it to be a multiple protocol type of device. We can look at what or how that might look and how that would change that sourcing protocol. So now we use a simplified supply chain we simplify the supply chain. We can source a single based flash device a software enabled flash device in that inventory. We can then go and deploy that device anywhere in the data center for any application and bring in that software enabled flash API. If we have that API we can go in and define how that storage is going to work using different software drivers to define the protocol that is going to be used per application. Now the power for doing this is tremendous. A single flash device can be used anywhere in the data center and deployed depending on the requirements of a particular application it can even be a custom driver specific to a specific type of application. And what's even more amazing from this approach is as your applications change, simply redefine the storage functionality of the already deployed software enabled flash devices by changing the software driver. One of the things that I would use in this case is every year we get to the holidays of course, and we got cyber Monday and we got Black Friday and the shopping online goes crazy. So that web application that web front end store for doing all of the shopping goes crazy. So you may need to spin up that web application increase the size of it to handle that additional workload for the holidays. In this case you can go grab two or three locations of unused or unallocated space from some other applications, increase and expand that web presence and spin that up to handle that additional workload for the holidays. And of course when the holidays are done and you no longer need that additional bandwidth for that web application, you can pull that down and put the storage back to the original applications. Another approach is of course new applications come in all the time, and you can use the same approach go grab some of that unallocated space from all of the storage that's already in place bring in that new application. Bring in the new driver, even if it's a new completely custom written driver to run that new application without having to go out and source new types of drives. So this means there's a really significant TCO benefit to the data center being able to use and reuse and adapt that storage using that single storage module and adapting that capability through the use of software and software drivers, all of fully customizable to the specific needs of the application or your data center. So with that in mind, let me reintroduce the software defined flash API, we call it software enabled flash and talk to you about how that works. And the really interesting thing is I get to work with a lot of really smart and creative engineers throughout the kiosk you cooperation. So there's a whole team that's been pulled together to bring this solution to to you the developer. And of course, the multi protocol capabilities what we're going to be talking about here. The protocol capability brings that flexibility, the ability to adapt and reconfigure your storage in the fly with those TCO benefits of using that single flash module and saving costs in your data center. So how does this work. Well, the innovation is here. So you get that legacy HDD paradigm from the interface and define the protocols through that software API, which means you can bring any software driver and run any protocol that you need across that hardware. That hardware allows you to adapt and customize to the storage requirements of your data center your tenant or your application. It's incredibly easy to go in and change those protocols, simply by making a driver change reallocate your storage deal with the flash as it ages and adapted to new workloads and new purposes. And your developers can completely customize their implementations internally by taking and adjusting or adapting or rewriting the drivers themselves. I believe this statement at the bottom that this is a powerful way forward for flash. And this powerful way forward for flash enables you the software developer to scale your data center requirements of your applications your tenants and your customers. So what does this look like how is this designed well, we of course are a flash vendor, which means we still have the flash that we need to deliver. It really becomes that hardware and that software aspect working together very closely, and this is done again through that software defined flash API. The hardware side of the thing on the left. This involves a small controller with the capabilities of managing the flash itself there's a program specific or generation specific logic that allows us to abstract different types of flash, even different vendors of flash through the API so you don't have to worry about all the low level programming aspects for the flash itself, you can easily switch different types of flash without changing your upper level code. This allows for those accounts that need that flexibility you can have DRAM in the device you can have more DRAM in the device or less DRAM in the device, or completely eliminate DRAM altogether and go with the host side buffer. There's a number of functions built into the hardware that include the ability to host offload the host CPU. For example, for garbage collection activities you can completely remove host interaction for moving data around. Again, that flash generation or flash type extraction abstraction. As we move from gen two to gen three to gen five to gen 10, you won't have to change your upper level programming in order to adapt that next generation of flash. That's a real time to market advantage. Also built into the hardware is the ability to do some very advanced die time scheduling this gives you complete control over the latency outcomes of the device itself, and allows you to deliver really good parallelism across multiple channels of flash. Now, the right side of the chart here shows the software application side of this. And of course we have device drivers that are there to talk to the flash itself, all defined through that software API and software libraries. And there are several aspects or several ways to approach delivering that flash to your users or your applications. You can go through the traditional file system with standard block drivers and reference FTLs. If you're running your own software defined storage stack, we can easily adapt to that software design storage stack, or more appropriately you can define and adapt it yourself using the API library calls. The opportunity also exists for an application to talk directly to the flash through the library without going through the file system or the stack as well. The software gives complete and full control over data placement, which gives you the ability to isolate workloads and tenants from each other all the way down to the flash dial level in hardware. You've got control over your latency outcomes again with that die time scheduling and buffer management can be shared between the device and the host through software. It's a very flexible very powerful software API designed to manage both the hardware and your programming. So let's talk a moment about the abstraction capabilities. Of course, all of the low level flash management this is the programming the flash cells the voltages the timings, all managed within the hardware through the API. All management means of course flash type whether it's MLC or TLC or QLC is managed through the API and abstracted different generations generation three four and five are all covered and managed through that abstraction as well as the possibility of different vendors, which means a complete ability to use any type of flash using the API. The API also handles that traditional noisy neighbor problem. If you've got one neighbor or one application that's doing a lot of IO, you don't want that IO interfering with your particular application. You can isolate all the way down to the hardware to individual flash die and set up so that one noisy neighbor does not impact another. I'll show you how that works as part of the demo that we're going to show you a little later in this presentation. In addition to that isolation. You can manage control your latency outcomes using parallelism using that die time queuing read write is managed by the API, giving you that ability to again manage your time at die time management, and of course offloading host resources with the introduction of software enabled flash. A little later this year, the API is out today but we're also going to introduce a software development kid and SDK. And what are the benefits that are going to come from bringing out that SDK in addition to the API. Just to let you know the API is already out in open source it's available under a BSD three license, and it's up on GitHub right now, I'll give you links to that a little later towards the end of the presentation. The SDK is going to bring a lot of benefits as well, specifically it's going to bring in the ability to do accelerated development. The SDK is going to give you a complete set of code that shows you exactly how to implement all the functions of the API library. This means your applications your programming can get to market very rapidly tremendous time to market advantage as well as that TCO advantage. It gives you a completely new base for development activities for any new projects coming up. There's a number of options built in for virtualized and containerized applications. This is the ability to boy to deploy, which we haven't seen today through the SSD realm but the ability to get the full power and capability out of the flash itself. And that SDK will have a number of tools built into it that will allow the developer to evaluate that software enabled flash API code and technology, without actually having to write any code to start with. So we're going to be bringing to you functional example drivers source code as well as the drivers that implement both ZNS and block mode capabilities like a traditional or a standard SSD. This will include a functional and working FTL and open source FTL. It includes a CLI command line interface tool that allows you to configure and talk to the devices. Even a modified version of the FIO test and performance software that will be included that allows you to start talking to the devices immediately and test the capabilities as well as speed of the devices. That SDK is going to be a very powerful tool to show you how to move forward with the API and start developing that base for your new development activities. Now functions, there's quite a few functions built into the API. Again, we're here primarily to talk about this multi protocol capability. We've mentioned flash generation abstraction, the ability to isolate workloads and manage latency and queuing as well as host offload. The software enabled flash.com website has materials and training and webinars that we've given already that talk about each of these different capabilities in greater detail. And I'd invite everybody to go visit the site and take a look at some of those videos that will show you how these capabilities are implemented how they can be used. Now in terms of protocol. We know in the average data center, especially cloud data center. We're going to be spanning across hundreds if not thousands of individual software enabled flash devices individual drives. And the ability to isolate those drives for the workloads so we'll talk a little bit about workload isolation is very important, you need to be able to manage all the way down to that flash die level. In order to run different applications that might need that different protocol that we're talking about today. So let's take a look at what this looks like but instead of doing this across hundreds or 1000 devices let's show you the power not by spanning hundreds of devices but let's zero in on a single flash device. We'll bring up a single flash device this is a traditional a channel for die arrangement. And we're going to break that down into three separate hardware isolated zones. And then in these zones we're going to run different applications and different protocols. Yes, this is different applications and different protocols on a single device. So let's start with the first zone, we're going to run a traditional web application as we highlighted before. We'll run this with a block protocol. And in order to show that the device is clearly isolated will run that in a specific IO pattern of mixed reads and writes for the next zone will implement a streaming application. In this case we'll use a custom written FTL protocol. This is a protocol written based on the definition for a hyper scale account. And again, we're going to run a unique IO pattern we're going to do 100% read IO and only 100% read IO in this zone. And in the last zone will run a database app. We'll use the CNS protocol, we do have implemented as a subset of the software name will flash API, a complete CNS wrapper. So we, we like CNS, even though it's a legacy protocol. Again, in order to show the isolation capabilities will do this with strictly 100% right IO. Now remember we can move this applications and we can move the zones around we can redefine them and we can change the protocols simply by going in and change a software driver as necessary. But I would like to highlight. Notice, I haven't used all the flash time this device. There are flash die unused flash die between each of these particular applications that can exhibit that we have physically isolated each workload from each other. Now let's go take a look at the demo itself. This is a video that we've taken of a running demo. This is a heat map. So the IOs are going to be in blue. Reads are in blue and rights are in red. Let me get this started up. And you can see we have the three separate isolated zones the block mode doing a mixed read write the custom FTL doing 100% reads and the CNS mode doing 100% rights. And again, we're confirming the complete isolation based on the unused flash died between each of these zones. Again, this is a single flash device running different workloads completely isolated from each other down to the hardware flash die level. This is the tremendous power and flexibility and the fine ability that software enabled flash can bring to your development environments and your cloud data centers. So what are the benefits that this approach can bring to you. We have talked a bit about that single adaptable flash device, instead of having to source multiple different types of drives with different capabilities. You can now bring in one single flash device one single flash drive and adapt its use case or change its use case that need through the use of software and software drivers. The API itself is focused on solving all of those common low level problems through software can easily be adapted to the new high level requirements as the workloads or the tenants change in the use cases. This approach also allows a large amount of code you reuse in deploying your flash storage applications without having to worry about the changes in flash from generation to generation. And this also means that you get increased or faster internal development with simplified maintenance. Now instead of having to pull drives out of the way and put new drives in, you can simply let things stay in place and change the use case through software and continue to use that flash as it cycles. For the API, there's a whole lot of additional capabilities and very functional and very powerful low level capabilities built into the software enabled flash API. There's a lot to explore. Again, there's some tremendous information in white papers and videos up on our website software enabled flash.com. Some of the capabilities include the ability to define and use a nameless rate. This nameless rate capability allows the flash to pick the best location to write your data. And once that nameless right has placed the data will return to you that physical address. So, as in item number five you always get a direct access physical read. The ability to manage buffers using on device DRAM or or no device DRAM and unify those buffers with the host CPU and host memory. There's a whole range of asynchronous as well as synchronous event handlers. The ability for the flash vendor to deliver you a software enabled flash device means that the flash vendor can program into that hardware device. All of the capabilities to manage the health and the lifetime of the flash itself in that device and extend its life to the best possible approach. And again, I want to reiterate abstraction is an important aspect of delivering software enabled flash technology as well. This abstraction allows you to keep your application layer code consistent. And then you can deploy underneath that API different types of flash depending on your needs, whether that's MLC or TLC or QLC media without having to rewrite the code that you're using a tremendously powerful feature flash So what does this do for us in terms of value to you, especially if you're a program manager or a project manager. Well, first and foremost for the data center it means there's a tremendous time to market advantage. Imagine as you've deployed your software as you deployed your hardware in your data center. And you see that there's a new generation of flash that's coming out that time to market advantage to be able to transition to that newest generation of flash can happen rapidly. Since it's plug and play, you don't have to rewrite any software to use that newest next generation of flash you can bring in that newest generation of flash immediately and deploy it under and with your applications in your data center. Your application is another value proposition resource allocation in this case is your programming resources your human resources. Your human resources can now be focused on development where it actually matters that is delivering your applications to the benefit of your customer base. Without having to worry about how to do the programming of the low level flash itself in order to deploy the storage. This, this actually means you get to use the resources where the most value for you as a data center can be applied. And finally, of course, you get to maximize the use of your flash you we've dropped all of the legacy HDD paradigms. We're using flash to its fullest extent and its fullest potential. You can change the workloads and a change and adapt through software how you use the flash as your workloads and your environments change. We believe and understand that this new approach the software defined API approach to flash fundamentally will redefine that relationship between the host and the solid state storage that you are buying. And of course the TCO model that we've talked about earlier. Also a tremendous advantage we've simplified or have the opportunity to simplify your supply chain using the software enabled flash technology. You can now buy a single flash device and adapt its use cases through software to any environment or any application that you have makes your purchasing process much simpler. We of course are here in the Linux foundations webinar series, and it would be important for us to identify that the best way to get to you the developer is through an open source strategy. And that of course is the approach that we're taking to delivering software enabled flash technology and the software defined flash API. We know not only is it for you the developer, but also vendors and industry co travelers need this open source neutral vendor neutral location in which to collaborate and bring you the best solutions possible. So we're partnering up with the Linux foundation and working towards establishing an actual open source project to support and deliver the software enabled flash API, as well as the software development kit to you the users so that you can easily and freely pick it up and adapt it to your own requirements. So why are we doing open source. This again is something that appeals to the developer community you the developers out there. As we know, I'm an open source developer myself so I appreciate open source because it means I can do things very quickly and adapt on on need for my applications. This is broad adoption when it's open and available and accessible that means a wide range of customers and vendors and co travelers can support and deliver solutions using the technology. So this open source approach and the project will be pulled together and driven by a technical steering committee that's going to be focused on bringing you the developer community the best capabilities out of that flash API. So where do we sit today in terms of delivery. Well phase one is already out there. The API has been published. It's available on GitHub. Today it's on the key oxy GitHub slash key oxy America site. We will be transferring that to the project when the project opens will be a little later this year. In progress today is the work that is being put in place to actually create the project that's working with the Linux foundation, getting the legal aspects taken care of, and setting up and preparing the project as well as doing the development of the device drivers and the SDK itself. This is all set up once we get through phase two and phase three, we will release the project, make that SDK as well as the API that's already out available to the public on that vendor unique site. And then sometime off in the future, we can take a look at standards committees and see if they're applicable to the direction that software enabled flash is going. We key oxy believe this software enabled flash technology becomes that force multiplier in your data center economics. And I believe I mentioned I was going to share with you how to get additional information. We do have a website established today at software enabled flash calm. There are white papers. There's a link to the API that can be downloaded. There's a number of videos as well as other recorded webinars, talking about the technology. There's some very technical deep dives into the technology through some of those webinars. The API of course is out on GitHub.com, GitHub slash key oxy America. Please feel free to go visit that site and download the API. There's always available for questions you can write to me. There's a contact on here, Earl Philhauer would be happy to get your questions by email. If you have any, please reach out to us we'd very much like to hear from you. This is the end of my presentation portion of this. I'd like to thank everybody that has stayed with us throughout the entire presentation. I would like to open this up to Q&A. And for the Q&A. I'd like to bring in our chief architect to the core designer of the software enabled flash API and technology. Mr Rory Bolt. Rory if you're there. Go ahead and come on board and say hello. And we'll go ahead and open this up for Q&A. Cassandra can you help with that. If anybody has any questions for Scott or Rory, feel free to drop them in the Q&A box at the bottom of your screen, and they'll go ahead and read them and answer. So, anybody is welcome to ask a question. So we'll give it a few minutes. Rory while we're waiting for a few questions. Is there anything you'd like to say to the Linux developer community out there. Yes, first and foremost, one of the things that we're really striving for in the SDK that's currently the main focus of my efforts is ensuring that it meets all the use cases that we've been exposed to through all of our contacts with all our customers in the virtual community, as well as, you know, just trying to emphasize the fact that Kyoksia actually invented flash media. And we've been in the SSD business for, you know, quite a long time now. And so I really just want to set the expectation that the reference FTL is going to be a very high quality FTL that incorporates literally decades of experience in controlling flash devices. And as Scott already mentioned, you know, one of the things that makes flash based storage devices so powerful. It's a very inherent parallelism, the fact that, that, you know, there are multiple dies that can all be operating independently. And that allows us to control both bandwidth, as well as interaction between applications. So I think it looks now that we have some questions. We got a couple questions. Let me read off the, the first one here that I think is very germane. This from Yash Bramani, as a developer, can software enabled flash be implemented locally using flash software enabled flash? All right. And once again, feel free to follow up if this doesn't directly answer your question. Software enabled flash really is a pairing of the software APIs and the SDK with an actual hardware device and so there are some unique aspects to the software controller that are necessary to interact with with the API itself. But there's no need to, although we're compatible with things like NVMe OF, there's no need to have distributed storage with software enabled flash and so it's entirely possible to have a single software enabled flash device in a stand alone and have software interacting with it locally. So hopefully that is directed at the intent of the question. And if not, please follow up. Thank you, Rory. We don't have any additional Q&A yet. If I could just to keep us going just a little longer in case there's more questions that pop up. In terms of the API and the SDK, I talked quite a bit about the multi protocol capabilities. Do you have a different capability or a different functionality built in that you think is the key or an important facet for people to consider? Well, once again, there are the additional resources that are available on the software enabled flash website. One of the things that was introduced in this webinar but I think is really fairly unique is both the hardware isolation as well as the software isolation, which really wasn't talked about in here with the QoS domains. And some of the technical deep dives we can get into more of the features and functionalities of the isolation capabilities as well as the scheduler. And it's really the combination of the isolation capabilities which define which die are involved with interactions, which therefore determines the amount of parallelism and the bandwidth available to the applications, as well as the scheduler which really controls the latency. And so to me, probably the biggest potential game changer, if you will, for individual applications is to be able to have control over your bandwidth and your latency outcomes, which typically has not been available to applications in the past. Right, you're sharing these devices. And you really don't have a lot of control over what's going on within the devices and what the competing workloads are and how you prioritize against even internal housekeeping activities of the device. There's a question here in regards to QS domains are QS domains limited to a single device. So, this is an area where we would love more community feedback to be honest with you. In the version one of the API QS domains are in fact a divine on a per device basis, although, of course, you can group QS domains across devices by using things like the MD filter drivers, if you want. So that's one mechanism to do it. The control over QS domains across devices is actually something that is on the backlog list for a future version of the API, but we're really waiting for customer feedback. In particular, you know, one of the things that we have heard from many hyperscalers is that they view a lot of things that traditional drives and arrays do, for that matter, as overheads and not necessarily advantages to them. So, you know, a typical hyperscale data center is already mirroring data, you know, across, in some cases they're doing triple mirroring to in the same rack and one at some geographic distance. In all types of environments, they actually like to control the grouping across devices and they view subsystems doing that it's sort of a tax or a black box that that sort of interferes with their intent. But once again, you know, we've gotten a little bit of feedback on cross device QS domains. But we're certainly, as with any open source project, we're out to meet the needs of the community and so we would like to understand the needs more thoroughly and please feel free to follow up with us regarding your individual use cases and needs. Great. Now we have one more question I think we can take this one. We're getting close to our time limit, but there's a question in regards to security. Please give your experience on firmware level cybersecurity with regards to protecting data centers. To extend that one slightly Rory, the ability to define security by QoS domain was something that you and I talked about last week as well. So let's let's add that to the question here on firmware level cyber cybersecurity in the data center. Right. And so I'll actually take that one first and then I'll start going up to the to the higher level questions. So within software enabled flash API we have the notion of physical dye isolation. And so you can group physical dye into a virtual device. And that virtual device can then have one or more QoS domains mapped on to it. And the QoS domains are what present themselves as device nodes to the system. You can have individual access rights to the various QoS domains. But one thing that certainly wasn't covered in this presentation is that we actually have the ability to have separate encryption keys for each QoS domain. So, you know, here's once again in the realm of providing isolation in multi tenant environments. You can isolate against the noisy neighbor problem but you can also isolate against any sort of data leakage by in fact having separate encryption keys for each and every one of those QoS domains. So I'll stop leveling a little bit to the device itself. You know, in modern times. Frankly, I don't know of anyone's of the major SSD providers that isn't already digitally signing their, their firmware to try and prevent against attacks, depending upon the hyperscale vendor. But there are actually even protections outside of the device. It's, it's, you know, sort of interesting to note that the hyperscale layer, many of these people actually don't trust devices plugged into their PCA buses, they're they're encrypting over the PCA bus, and they're actually putting security chips as sort of proxies between the root nodes and the devices on the PCA buses. So, we work very, very closely with our hyperscale customers to meet their security requirements. And, you know, frankly, the hyperscale data centers, I am truly impressed with with the lengths that they're taking to try and maintain the integrity of their systems. So once again, if we didn't address your question thoroughly and trying to do it at a fairly high level, please follow up with us. Yeah, with that said, Rory, once again, thank you for joining and helping with the Q&A section here or actually doing all the Q&A session. Really appreciate it. We're going to turn this back over to Cassandra and the Linux Foundation as we've reached our time limit. I'd like to thank everybody that has stuck with us through the entire session. And again, if you have any questions, please reach out to us by email. Thank you very much. Cassandra, back to you. Thank you so much, Scott and Rory, for your time today and thank you to everybody who participated. As a reminder, this recording will be on the Linux Foundation's YouTube page by tomorrow, and we hope you join us for future webinars. Have a wonderful day. Thank you.