56

So currently we have something like open questions.

So does architecture make sense? Are we going in the right direction? So I believe Rust implementation is right, but who knows. So more complex questions should be finally fabric manager represented in software daemon and which fabric manager implementation makes more sense. So of course do we really need open source implementation for example fabric manager because this tool is clear but fabric manager, my expecting that for example it will be a lot of, maybe not a lot but at least several proprietary implementations. So what we can do. So this is something like, for example how probable will be the complex hierarchy of CXL switches because every additional level at something like latency. So how does it make sense at all? So this is something like questions that we have. So let's discuss.

So you mentioned like is an open source implementation required? I'm wondering like do you expect that this part will be for example bundled by some distributions to be shipped like for example RedHat operating system would be shipping it or how would one actually go ahead and obtain that? Like would it be downloaded from somewhere?

So currently it's something like we're trying to start an open-source project. For example, we could have something like a fabric manager daemon application. So you can start, you can get code from GitHub, compile, start, for example, you will have a fabric manager daemon. The same with something like a configuration tool. So what will be then? First of all, we need to have a CXL switch as real stuff that we can test, but we need to have also some infrastructure to manage, to use, and so on. So this is something like really, really the first step.

It would probably be rolled into a project like open BMC. The fabric manager, I mean it's been defined in a very general way that could mean anything to allow for use in different types of applications, right, like an automotive system that requires a fabric manager is going to want it to look very different from a data center rack level manager, right. But in a data center type environment it's probably going to be running on a BMC in a memory appliance, rack mounted memory appliance. And the thought was, yes it would expose a Redfish interface to the outside world and there would be some open source project that translates the Redfish into the CCI level commands. I wonder given the state of where the rest of the CXL management conversations are going if that winds up being just an RDE pass through basically. So the FM isn't actually doing any translation at all because that brings with it the maintenance burden of keeping on top of the Redfish mapping and the CXL spec. There's like an RDE requirement pushed down to the switch or the multi-headed device so that, I mean at that point I guess you could say that the embedded logic translating that RDE into actual device management operations within the switch or the multi-headed device, that's the fabric manager. But I don't know, but the idea is that the real intelligence of the system is in the orchestrator, it's not in the fabric manager, it's really just a translation layer. And yeah, it will need to be a distributed approach I think, definitely, if you're talking about racks of hardware.

But to the point of like getting an open source project off the ground and getting a center of gravity going, like focusing on QEMU, focusing on the aspects of it that we can do in a direct attached model first, because I think DCD is going to be direct attached first, and switches is like a, I don't know when that's going to happen. But at least, yeah, like if me as a developer wanting to test kernel drivers and Linux interactions, I'd want to use an open source tool, and then maybe that gets you your center of gravity where like, oh, if people are using this for development and somebody wants to do proprietary extension, maybe they'll use this as their baseline, or they'll say, wait, we don't even need to be proprietary here, just put it into the common FM, because, yeah, I would hope that there's nothing super value add about an FM, it's just moving the memory around the architecture. So...

Excuse me. So basically we are working on a similar thing right now. The difference is we are writing it in Go language. The question to Winston is for the Redfish implementation part, there are specifications from DMTF, but it does not clearly, like, I cannot understand if it's like when we want to use the orchestrator to talk to the Redfish. Do we expect to send a path to compose a system using resource blocks, or do we directly find those mailbox commands, map the resource?

So I don't understand Redfish either. So I completely agree. Yeah, I mean, so DMTF has published a mapping table basically translating the CXL management commands and properties into Redfish elements and attributes, and but it's -- but that's more from the context of individual end point discovery and management, which is -- first of all, I think that's the biggest first step, right? Because even without dynamic composability, even just from an inventory management, through identification perspective, you're going to want to be able to pull the serial numbers models, all of that, get a picture of what's running and health from that before you start dynamically moving things around. I will say on the question of the switch, I don't think anyone's going to get to play around with the CXL switch until 2025, 2026, but there are already demos on YouTube of multi-headed devices, and Tanzanite, they're part of Marvell now, but they actually had a -- they've had a YouTube up of dynamic capacity device on a multi-headed device for a while now, so an FPGA-type system doing pooling on a multi-headed device, I think that'll be the first place to look at this. I would also say that the OCP, Composable Memory Systems group, they're working on exactly what you're talking about, developing a POC system, a reference architecture, and an open source project to release to kind of kick start the industry on this. So I can share with you some resources there. I'd encourage you to participate there.

Just FYI, the Open Fabrics Alliance is also doing some fabric manager work. It's pretty primitive, but it's open, and it involves the Redfish discovery and representations and things like that, and it's basically warming over Gen Z stuff, Gen Z fabric management. But anybody who wants to know what all is going on in this area ought to know about that, too.

Yeah, thanks, John.

So now, in this one session, we've erupted three independent implementations. I don't know, is there any forum for these groups to work together? Or are we entering a world where everybody's going to have their own FM?

I would think that OCP would probably be the best place for an open fabric manager implementation to come out. I would expect from OFA something more orchestrator-based. Yeah, that's what I'm thinking. I mean, the CXL Consortium and DMTF are just going to push out specs and implementation notes and white papers and stuff like that. The actual work, I think, would be done by those groups.

Okay, thank you.
I think it will be great if I receive all this information.

Yeah.
Okay, so thank you for the discussion.