Utilizing Tech - Season 7: AI Data Infrastructure Presented by Solidigm - 4x07: AMD Brings CXL to Servers with Genoa Epyc

Episode Date: December 12, 2022

CXL couldn't be utilized until there was a server platform that supported it, so we're very excited to see AMD launch their next-generation Epyc server platform, code-name Genoa. In this episode of Utilizing CXL, Stephen Foskett and Craig Rodgers talk with Mahesh Wagh of AMD and the CXL Consortium about this important release. The first step to bring CXL to market is to prove it is functional and performs well with a mainstream platform like AMD 4th-generation Epyc. AMD is bringing CXL to market as a tiered memory solution that performs similar to as memory on a remote NUMA socket without any special configuration or software. But AMD also supports other memory technologies, including hierarchical memory with software, security, pooling, and even memory sharing with specialized software. Although Epyc is said to only support CXL 1.1, later spec devices will be backwards-compatible and the platform also supports some CXL 2.0 features including global flush for persistent memory, firmware-first error handling, and device-specific capabilities. Hosts:   Stephen Foskett: https://www.twitter.com/SFoskett Craig Rodgers: https://www.twitter.com/CraigRodgersms Guest Host:   Mahesh Wagh, Senior Fellow at AMD, Server Systems Architect, Co-chair CXL Consortium Board Technical Task Force https://www.linkedin.com/in/maheshwagh/ Follow Gestalt IT and Utilizing Tech Website: https://www.UtilizingTech.com/ Website: https://www.GestaltIT.com/ Twitter: https://www.twitter.com/GestaltIT LinkedIn: https://www.linkedin.com/company/1789 Tags: #UtilizingCXL #Genoa #Epyc #AMD #CXL 

Welcome to Utilizing Tech, the podcast about emerging technology from Gestalt IT. This season of Utilizing Tech focuses on CXL, a new technology that promises to revolutionize enterprise computing. I'm your host, Stephen Foskett, organizer of Tech Field Day and publisher of Gestalt IT. Joining me today as my co-host is Craig Rogers. Hi, I'm Craig Rogers. You can find me on Twitter at CraigRogersMS. So Craig, you and I are really focused on the practical applications of technology, although it's fun to dream about what might happen in the future and what might come and how things might be revolutionized. It's much more interesting, I think, to stick to the nuts

and bolts of how things really do work. And with CXL, that's been a little bit of a challenge since we didn't really have a platform that supported it until now. AMD recently announced their next generation Epic server CPU line, codenamed Genoa, and it supports CXL. It includes CXL. Can I get a yay from you, Craig? Absolutely. Yay. It's a mammoth release.

You know, server, you know, up to 96 cores. It's just unbelievable. You know, going back to my VDI, there's just, you could have dreamed of those number of cores and the CPU is exciting. Yeah, it's exciting. Yep. Yeah, and not only that, of course,

but we've got, if I recall correctly, I think 12 channels of DDR5 memory. We've got PCI Express 5. And yes, yes, we've got CXL. So this is exciting. We're excited. We're so excited that we decided to invite on as our guest this week Mahesh Wagh from AMD, who knows a thing or two about this platform and also about CXL generally. Mahesh, welcome to the show.

Hey, guys. Nice to be here. So give us a little background. Who are you? What's your position relative to CXL? Yep. My name is Mahesh Vagh. I'm a senior fellow at AMD, and I'm responsible for the server system architecture. Within that, I am specifically focusing on enabling on our execution plans for CXL, and we are very happy to bring a breakthrough memory expansion with CXL.

And in addition to my role at AMD, I'm also within the CXL Consortium co-chair of the board's technical task force. So that looks at the definition of the future generation for CXL. It must be great being on the board there as well, getting to work on the actual specifications. Obviously in your role in AMD,

Genoa has come out, but you obviously have more advanced products that you're working on, and they need to marry up in terms of CXL specification to that which has been released by the consortium. So it must be great to be able to see both sides of that table. Yeah, and just a little bit of background there. I was co-chairing the protocol work group through the first two generations of CXL. So, you know, this has been, you know, I'm familiar with this for many, many years. And it's great to see the products out.

So I'd be really happy to talk about all the features that we have, the capabilities, and, you know, what are the solutions we can bring to market. I guess the key takeaway I want the listeners to take out of that is you don't have to wait for anything. CXL is here. CXL 1.1, you can enable a lot of memory expansion solutions with that, and we can talk all about it. Kudos to AMD on being first to market with a viable platform for CXL devices. You know, we now will actually be able to do memory pooling, which sounds as though has been a requirement

that a lot of the industry has wanted for a long time. Yep. And I think, you know, pooling is great, but even if you get before pooling, I think we should talk about all the things that we need to do that's in front of us to bring CXL to the market. And I do the first thing, and I keep telling my team and our customers, our partners is we got to prove CXL

is functional and performant. And for that, you need a good set of features that we need to go enable with the ecosystem in the market, right? And that's what we're focusing on. So if you think about pooling and memory expansion in general, from a systems perspective, there are many, many things that you need to really consider.

And we can talk about what those areas are, what those features are, right? What we are bringing with our fourth generation AMD EPYC product is this breakthrough memory expansion, right? And when I think about breakthrough memory expansion, a few things come to mind. One is you've got to provide the system flexibility, right? In terms of, you know, what are the solutions that are going to be out there? Is it capacity?

Is it bandwidth? Is it both, right? What is it that you're targeting? There's the expansion part of it, which is you got to make sure that it's performant. So there's a lot of work that really happens both on the CPU side, as well as with the memory controller vendors on improving that performance. You need to address security. And the other key thing that we're bringing along within this first generation is really this notion of a tiered memory system, right? With CXL, as you know,

we introduce it as a headless NUMA node and, you know, memory appears as a tiered memory solution. And we are really focusing on making sure that we bring a very performant tiered memory solution to the market. And then once you establish that, what that leads to is, you know, more disaggregated memory with pooling. And then one of the additional things, there's this one more thing. We can also enable persistent memory with CXL. Indeed, it would be nice to get up to level functionality there through the CXL bus. It'd be very good. It filled a great sweet spot in terms of performance

and latency. It's very good. The memory expansion cards, we've spoke to manufacturers of these cards and some of them have some really interesting benchmarks in terms of throughput and the level of performance that they're able to attain through CXL. Some are even quoting numbers in the mid-90s in terms of percentage throughput. What have your observations been?

You guys have obviously had to have done a lot of interoperability testing and product design work there. Yeah, so one of the things that I mean, we spend more than about, you know, 30, 40 hours a week with the controller vendors and optimizing for the memory performance, right? Now, always when you talk about this benchmark, it starts with, what are you benchmarking against and what's a good metric for CXL-attached memory? And in the first generation, we were just saying,

you got to be better than equal to what you can achieve with the remote socket latency. So for example, if I consider it to be the same memory channel, I'm expecting the performance for a CXL attached device for that same media. So if you keep the media, let's say DDR5, a single channel, we expect the performance to achieve similar to what we would if that channel was on a remote socket. So that sort of gives a guideline for what we could do with our memory controllers and we're expecting the same when

we're working with the ASIC vendors that are bringing the solutions to the market. So that gives a guideline for, we want that performance to be as good or equal to what we see with remote socket memory. And the results are looking pretty good, right? We're working with some of the very first engineering samples. We work very closely on, you know, tuning, you know, their microarchitecture, their knobs for performance. And we're starting to get pretty good latency bandwidth curves.

So we're focusing on that latency bandwidth curve and making it look and behave as good as what we would see with a remote circuit latency. Yeah. One of the things you mentioned there, I wanted to help our listeners to follow along. So for a long time, we've had this concept of NUMA, non-uniform memory in multi-processor servers. And the idea there is that each processor has its own resources, including memory, and that the processors are able to communicate with each other and with each other's resources in a way that is not necessarily uniform.

In other words, my memory is different from your memory, but I can still access yours, and the system, including the software on top of that, is able to adapt when I do those things, when I access resources that are non-uniform. What you're describing is that CXL-based memory will also be part of this legacy of non-uniform memory access in that I can access memory that's not just your memory, but that's memory that's the CXL memory. It's headless. It's not another processor.

It just is on a different channel. And what I'm hearing you say is that your goal would be that CXL-based memory would be roughly similar in terms of latency and performance to memory that would be owned by another socket. Is that right? Yeah, it'll be, you know, the goal is to get it to one NUMA hop of it, right? That's the way to look at it, right? And then the other thing that I was talking about it is once we understand that, and we can do the latency bandwidth plot, right, for that NUMA hop latency, you can figure out where your tail latencies are,

where your, what your latency bandwidth profile is. And once you understand that, then you can decide when and how to map your applications onto which NUMA node. And then there are many different policies in which case, how we're seeing our customers deploy their applications, right? There are many different ways people are approaching for how they're going to solve their problems. And that is going to require software, right? Scheduling software. That's not something that's going to happen within the CPU complex. Right. That's right. And there's a lot of

developments that are happening, you know, so now we're getting into this concept of, you know, tiered memory and how do you manage this tiered memory, right? And you touched on one aspect of it, which is really important that, you know, NUMA-ness or, you know, the concept of NUMA isn't new, right? It's been there. It's been within the industry for quite some time. People really understand that very well. What has been there is, you know, you got a NUMA node with processors and memory in a NUMA domain, and then you understand what your access is going to be as you reach across the NUMA domains. With CXL, we're bringing this concept of headless NUMA node, which is now you have a NUMA domain,

but you don't have cores associated with it, And it's available. The definition through, you know, the CXL specification now provides you a way to describe the NUMA properties. So you can say what your distance is, your proximity is, right? So based on that, now you know what it means for access latencies to this particular NUMA node. So that's first. Then in terms of the software, you know, tiering software, there are many different ways you can look at it. Some applications would look at, if you don't do anything, the typical policies are you allocate out of your direct attach memory, and then when you run out of it,

you start allocating out of CXL attach memory or this NUMA node. So that's one way of deploying it. There are other ways which are more dynamically looking at what your access patterns are and then determining how you're going to allocate out of your DRAM or CXL attached memory. And there are, one good example of that would be the work that Meta has done with transparent page promotion, which is basically you can manage the hot and cold tiers, look at where the applications are and targeting, and then based on that, demote or promote memory from your hot tier to your warm tier.

And that part of code is already upstreamed. So there's a lot of development that is happening in the ecosystem to bring tiered memory to the market. And somebody who goes out there and buys themselves a fourth generation Epic server and one of the, actually quite a few memory expansion, CXL memory expansion devices that are coming to market, will they need to buy a piece of software or will they be able to maybe use a driver or even something built into the Linux kernel and just sort of use it? Yeah, I think that's the great thing about CXL is a couple of things, right, what you talked about, you know, even if we just stretch it a little bit, right, you know, if somebody brings a system, can they just plug in a card and expect it to work and the answer is yes right our bias support is in there to bring that device all the way up to

NUMA node and if you didn't do anything the way we enable it is that we just show up as a NUMA node in and we map it as you know general purpose memory in which case that memory is available to os to users as is right off the bat, you know, off the package, right? Now the additional hardware capabilities that CXL brings in is you don't have to a priori configure the port to be either PCI Express or CXL, right? You can plug in a card and we detect, you know,

right around the bring up whether it's PCI Express or CXL. If it's PCI Express, we'll function in a PCI Express mode. If it's CXL, we'll discover the card capabilities, map it as system memory, and then hand it over to the OS. If we map it as our default mapping is general purpose memory, so OS can start making use of it. Now for certain special applications, we provide the ability to map it as reserved

memory, in which case, you know, it will show up as memory mapped, but as reserved memory. And then it depends on the kernel memory manager how to make use of that particular memory. Interesting. And of course, the CXL spec includes more than that, as you mentioned, different memory technologies, hierarchical memory, but also shared and pooled memory. Is that supported by the fourth generation Epic platform? So a couple of things there. I think part of it is, you know, maybe I would touch on just the media part of it. By definition, CXL is media agnostic.

So you can start with any particular media that you want behind it. It could be DDR4, DDR5, LPDDR, and any new storage class memory. So the first thing CXL does is it's abstract setup. What we are going to see is the very first few generations of the early adopters are going to be DDR4, DDR5. There is, you know, if you were at Flash Memory Summit, you saw the excitement around using NVMe. So we're seeing a lot of traction in that space. Now coming to what can you do in terms of pooling and sharing, right? There are two ways, you know, there are two ways you can enable pooling and sharing. One is using, you know, switches and then enabling a pooled solution. The other one is really this direct

attached multi-headed controllers. For example, if you think about, let's take an example, the DDR5 memory controller that has more than one CXL port coming out of it. There are some vendors out there who have these solutions today. You can enable a pool solution with the 4th Gen AMD Epic, where from one socket, you have a link going to that controller, from another socket or from another host,

you have a link going to that same controller. And then the resources that you have on the controller, you can pool them across the two nodes. Now, when it comes to, you know, the definition of pooling is really, you carve out a certain partition and you assign it to a given host. That partition is not available to the other host. The definition of sharing is you're accessing the same physical address. Certainly sharing can be enabled even with 4th gen AMD EPYC, but the sharing part would require some amount of software because we don't provide hardware

consistency in that case and you require software-based consistency rules for managing that particular memory. But as long as you could do it through software, then yes, certainly those sharing models for that type of device are possible. And we're seeing a lot of interest in proof of concepts and work being done with several vendors with our 4th Gen and AMD Epic on both pooling as well as sharing. And also just to kind of get this out of the way as well,

in terms of numbers, which version of CXL and PCI Express is included in the platform? So we support PCI Express Gen 5 right so we can run at you know the Gen 5 data rate providing the massive bandwidth and we support CXL 1.1 plus some additional features that are there and CXL 1.1 and basically we've looked at it you know the way to think about it is if there is a CXL 2.0 device, right, you should be able to plug that device in an AMD EPYC platform. And the device, you know, by definition is required to be 1.1 compatible. So you can have the link operate at 1.1, but we can take advantage of some of the CXL 2.0 features that are defined.

That way we can take advantage of some of the CXL2.0 features that are defined. That way we can enable. So for example, the driver that would run in the kernel or the OS would be a CXL2.0 ready driver that can work with these devices. So we're sort of forward looking from that perspective as we pulled in some key features that were defined in the CXL2.0 spec and enable them on the 1.1. Can you elaborate on which of those specific features you mean? Yeah, a couple of features. For example, one good example of that would be global persistence flush. This is required if you're supporting persistent memory. Then we provide the ability to do on a power fill notifications and that notification event to the

device. If it's a device that implements persistent memory, it can flush the contents to its persistence. And it requires some coordination on the CPU side for flushing all the caches because it's a global event. So we already have that support built into the 4th Gen AMD. So we can support persistent memory right off the bat. And so that's one example. Another good example is the definition of firmware first. So firmware first error handling was defined in CXL 2.0. We pulled in that ability to do the firmware first error handling in, you know, in our

4Gen AMD EPYC. So we pulled in those capabilities. And finally, the one that we talked about, you know, the device could be CXL 2.0. It advertises all the capabilities. So from a software perspective, the discovery mechanism is that it can discover all the CXL 2.0 capabilities that are device specific, and then we can support them on our platform because they don't have host implications. It's going to be exciting to see how software companies leverage these new capabilities, new features that they haven't had access to before and I think it's really going to help with adoption of CXL you know the

some think hypervisors you know hypervisors taking advantage of CXL and Linux you know opens up huge stores you know there's a lot of native support backed into the kernel already so there's going to be new workloads we've never even thought of here or how they're going to be computed or arriving on the scene. The software vendors, I'm sure you've been working with a lot of them already, providing engineering samples to let them get a bit of a head start. Because I'm sure you want workloads taking advantage of these new features as well. That's right. And I think it sort of goes into a couple of things right there. We're working with several different software vendors who are looking at bringing very effective tiered

memory solutions. This is where you're looking at how do you manage tiered memory. We have some hardware hooks. We didn't talk about that, but when we think about bringing tiered memory solution, there's sort of two aspects of it if you're managing this tiered memory. One is you need to have a profiling driver that says where is your residency of pages that you're accessing? Is it in warm tier or hot tier? So we provide certain capabilities from our CPU. It's called instruction-based sampling. Based on that, you can figure out and very quickly determine

the residency of those pages. A good example for that would be some of the work that a company called MemWorge has done. You can look at some of their presentations at Flash Memory Summit, OCP Summit. They've shown an advantage of using odd instruction-based sampling and get significant performance improvements for their profiling driver. Now, in addition to that, so the profiling driver will tell you, okay, where the hot cold pages are. Then you have a policy engine that determines when it is appropriate to move the pages, right?

And that's a kernel level policy decision. And when you actually have to do the data move, we provide hardware data mover engines that, you know, that page moving piece of software can make use of direct hardware capabilities. So you're not making use of cores to move the data. So we provide all of these sort of hooks, the hardware hooks for some of the software vendors that are looking at, you know, taking advantage of the hardware capabilities

for bringing in a tiered memory solution. I think that's going to be very powerful. Very much so. We've spoke with members who are familiar with the product and the capabilities. You know, they're a great example. You know, being able to snapshot a whole machine, memory and all,

create a copy of it in another machine, if that spot instance goes down, there's new functionality we never had before coming off the back of CXL and epic processors are going to deliver. And there are a lot of software, you know, development kits also available, right? So for example, you have Samsung with the SMDK. I think that's, as you're looking at your application performance tuning and you want to run some experiments, I think SMDK is a very good tool because it allows you to manage

your memory and, you know, figure out the impact of different memory organizations, either you're sort of interleaving or you have different tiering schemes on your application. So you can make use of that as MDK if you're doing some exploration. So we're seeing a lot of software development in this, in this space, significant amount of code is already available or already upstreamed in Linux, and we're seeing several of these companies take advantage of these capabilities, provide the tool set, and it's all in the general goodness of the ecosystem, right? Because you're enabling,

as you're delivering these tools, you're enabling the ecosystem to sort of take advantage of the hardware, put certain systems together and start exploring what the impact of it is on their applications. So as a company that works with basically every other company in the space, I think that it is important that you're working with multiple different software providers

to make sure that the software and of course the hardware is all compatible. But I know that you're also working with the consortium itself to push this technology forward. I don't know if you want to take a moment and talk to us a little bit more about how the CXL consortium is working with AMD and with other hardware and software vendors to push the technology forward. Yeah, I mean, on the consortium side, I think what typically consortiums, either it's PCI-SA or other consortiums, don't go a whole lot into product level stuff. But they're more of the enabling sort of organizations that enable products and things to do that. Now, I believe what the consortium is looking at is, you know, sometime early next year,

start putting together, you know, something along the lines of a developers conference where you can have people come in and share, you know, what their, you know, what their learnings have been so far and start working towards that. But up until now, the consortium has done a great job for the ecosystem enabling on providing training sessions, webinars, and things like that, where people can come in and talk about some of the challenges that they're seeing, what is being addressed to meet those challenges, right?

So just to give an example, you know, I did a presentation with Meta on some of the memory challenges in one of the CXL webinars, where we came in and talked about when you look at from a memory expansion perspective, what are the challenges? What is the consortium doing in terms of the specification to address those challenges? What's happening in the ecosystem around those challenges?

So there's a lot of work and a thought that gets put behind. Every time there is a webinar, there's a discussion in the technical task force around what are the issues, problems people are saying, what is the material, what's the training that we need to put forward to enable that? So a lot of enabling happens from that perspective. And pretty much at each of the forums, if it's, you know, just to give some examples, FMS, OCP Summit, Supercomputing 22, there have been sessions, you know, both from the consortium marketing work group,

as well as the technical experts to answer any questions on those topics, right? So that's what the consortium supports from bringing the ecosystem together. And then there's, of course, the compliance program that the consortium will be driving, which is to make sure you have a compliance test suite that's developed so that, you know,

designs can bring in and run them through the compliance suite. Where the consortium is really delivered very well is simply the sheer size and scale that they've been able to grow to in terms of members. You know, even competitors are on board and have all agreed to do it this way. That alone, outside of even creating the specifications, that alone on getting that many people around the same table was an achievement. Yeah, no, I completely agree with that. I think if you look into just the size

and pretty much you got all of the compute vendors as part of the consortium. Pretty much everybody from the memory side, part of the consortium, as well as the controller device vendors. So if you look into where the consortium is going, it's really a significant achievement in terms of pulling

that bigger ecosystem together and then just bringing everybody together to address the questions, where does the technology need to go, what's the future and things like that. So Mahesh, obviously in the enterprise space, security is always a huge thing. Can you tell me what you've done to enable us to use CXL securely? Yeah. From an AMD perspective, we have our technology called Infinity Guard that provides security features for DRAM. You might also know it as ICV, secure encrypted virtualization.

Basically, it's providing the capabilities for confidential compute. One of the things that we're really proud about, the way we enable that is the same capabilities and features that you have for protecting your content that's going to DDR,

direct attached DDR, that seamlessly carries forward over CXL because we do support all of that encryption on the host side. So whether if it's those accesses are going to DDR or if those accesses are going to CXL, we provide the same level of capability that you have on DDR.

We extend it to CXL. And the good thing about that is that we don't need any specific device side support. So this mechanism just works seamlessly across all device vendors because the bulk of that is, I mean, not bulk, all of it is done on the host side for providing that capability. Nice to see that being achieved at a hardware layer rather than software. You know, the fact that it's backed in is great.

I'm also excited around persistent memory storage coming in via the CXL bus. Have you done anything to enable, facilitate, speed up, secure? Have you done anything around that? Yeah, our 4GEN AMD EPYC processors are capable of understanding and managing persistent memory from just the persistent memory domains perspective. So what we did in that was,

as I was talking about before, we intercepted some of the features for persistent memory that were defined in CXL 2.0. We pulled that in CXL 1.1. And we're now seeing interest with persistent memory. Think about an NVMe device with DRAM on the front end and then NVMe on the back. And then that particular device can operate as a persistent memory device. And we're working on enabling that solution with a couple of vendors.

If you were at Supercomputing 22, you would see some demos where we already shown that functioning on a 4th gen AMD EPYC with a Samsung NVMe drive that does persistency. So, you know, we're starting to see that, you know, pick up. There's a lot of interest in CXL plus NVMe. So, you know, stay tuned for more news on that and more excitement in 23. Yeah, I'm glad you brought that up because, of course, NVMe is also leveraging PCIe technology, as are lots and lots of other things. And there certainly is overlap between lots of the

advancements that are happening for storage and I.O. and networking and graphics and everything, not just for memory expansion. So we'll be very excited to see where this goes in the future. One final question I have for you is, I guess sort of think visionary here for a moment. How might CXL change the way servers look in the future and maybe even change the priorities of a company like AMD when designing future server processors? Yeah, so we're looking at it, right?

I think if you think about, there we're looking at it, right? I think if you think about, you know, there are two aspects of it, right? One is, you know, we talked heavily today on just, you know, what does, you know, memory expansion perspective, right? But we need to look into that from a server perspective. What does the roadmap start to look like for accelerators? And we're starting to see a significant amount of interest in the future right around CXL 3.0 with accelerators. So we are expecting some accelerator uptake in that particular timeframe with CXL 3.0, right? And that would change if you think about how PCI devices are getting built. As you have these capabilities, we'll see a shift in more towards taking advantage of what the coherency can bring to certain devices.

So that'll be an area to watch and see where that is heading. In terms of memory expansion, we're looking at it as we're adding more cores and the memory bandwidth has to keep up to provide both the capacity and bandwidth. And it continues to be an expensive sort of resource if you think about it from a server perspective so we are going to see significant amount of you know memory hierarchy optimizations as we go through and look into the future now what does that mean uh you know one of their answers could be that you know we would start looking at you know what are the things we need to do

on the CPU side to improve the efficiency or performance for that. So that's about I can say here, but we do expect to see both CXL continue to play as a tiered memory solution for a significant amount of the future. Can that be enhanced further? I think that's where all the explorations are. Yeah, it is really going to be interesting to see where this goes, because I do suspect that if this technology really takes off the way many of us think it will, it will change the priorities of system designers, especially of CPU designers. And we'll see what that means for the future of the processor market, the accelerator market, the, you know, XPU world. And frankly, a lot of the decisions that are being made around system design, many of those may be challenged by CXL. So we'll see where this goes.

I'm obviously pretty excited about it, but,L. So we'll see where this goes. I'm obviously pretty excited about it, but we'll see what gets real. Yeah, and we're excited about it. And that journey has already started and it just gets enhanced even more because now with the ASICs and the platforms out there, really it's all on the ecosystem to provide, you know, a performant, you know, CXL memory expansion solution, right?

Because everything is based on how well we do in the next, you know, year in terms of proving, you know, that CXL is functional and performant. Because that's a promise. Once we deliver that, everything else is going to ride on that. So that's what we're focused on. That's what our customers and some of our ecosystem partners are focused on. Yeah.

And that's really where it all makes sense. And that's why we named this utilizing first, utilizing AI, now utilizing CXL, because as exciting as the technology is, it really matters more how it is made, how companies make use of it, how customers make use of it and what it's able to do in the real world, it really matters more how companies make use of it, how customers make use of it, and what it's able to do in the real world, not just what it theoretically might enable in the future. So we'll be definitely keeping an eye on this. I really want to catch up with you again, maybe later in the season, maybe next season of the podcast, and see what the reality is of these chips when they're out there on the market, when servers are out there, when people are making use of this technology.

How can people continue the conversation with you in the meantime, Mahesh? Yeah, I think a good way to reach out to me, you know, would be just on LinkedIn. You should be able to find me on LinkedIn. If there's interest in the technology itself, then I would suggest, you know, going to compute express link.org and then, you know, uh, you know, get that, um, you know, connected there. If you want to get connected with the consortium. Great. Thank you. And we'll include those links in the show notes. Uh, Craig, uh, anything you want to pitch before we go?

Um, you can find me on Twitter at Craig Rogers, MS. My blog is craigrogers.co.uk, and I'm also available on LinkedIn. And as for me, you'll find me at S Foskett on most social media networks, including the new Mastodons. Thank you for listening to Utilizing CXL, part of the Utilizing Tech podcast series. If you enjoyed this discussion, please do subscribe and give us a rating and a review in your favorite podcast application. We're pretty much available everywhere now. You can also find us on YouTube.

Just go to YouTube slash Gestalt IT video. This podcast is brought to you by Gestalt IT.com, your home for IT coverage from across the enterprise. For show notes and more episodes, go to UtilizingTech.com or find us on Twitter at Utilizing Tech. Thanks for listening, and we'll see you next week.