Decentralized storage is bridging the gap between Web 2.0 and Web 3.0, and its impact on enterprise storage is significant. The topic of decentralized storage and Web 3.0 will be the focus of an expert panel discussion the SNIA Networking Storage Forum is hosting on June 1, 2023, “Why Web 3.0 is Important to Enterprise Storage.” In this webinar, we will provide an overview of enterprise decentralized storage and explain why it is more relevant now than ever before. We will delve into the benefits and demands of decentralized storage and discuss the evolution of on-premises, to cloud, to decentralized storage (cloud 2.0). We will also explore various use cases of decentralized storage, including its role in data privacy and security and the potential for decentralized applications (dApps) and blockchain technology. As part of this webinar, we will introduce you to the Decentralized Storage Alliance, a group of like-minded individuals and organizations committed to advancing the adoption of decentralized storage. We will provide insights into the members of the Alliance and the working groups that are driving innovation and progress in this exciting field and answer questions such as:

• Why is enterprise decentralized storage important?
• What are the benefits, the demand, and why now?
• How will on-premises, to cloud, to decentralized storage evolve?
• What are the use cases for decentralized storage?
• Who are the members and working groups of the Decentralized Storage Alliance?

Join us on June 1^st to gain valuable insights into the future of decentralized storage and discover how you can be part of this game-changing technology. The post Web 3.0 – The Future of Decentralized Storage first appeared on SNIA on Network Storage.

Last month, the SNIA Networking Storage Forum made sense of the “wild west” of programming frameworks, covering xPUs, GPUs and computational storage devices at our live webcast, “You’ve Been Framed! An Overview of xPU, GPU & Computational Storage Programming Frameworks.” It was an excellent overview of what’s happening in this space.

There was a lot to digest, so our stellar panel of experts has taken the time to answer the questions from our live audience in this blog.

Q. Why is it important to have open-source programming frameworks?

A. Open-source frameworks enable community support and partnerships beyond what proprietary frameworks support. In many cases they allow ISVs and end users to write one integration that works with multiple vendors.

Q. Will different accelerators require different frameworks or can one framework eventually cover them all?

A. Different frameworks support accelerator attributes and specific applications. Trying to build a single framework that does the job of all the existing frameworks and covers all possible use case would be extremely complex and time consuming. In the end it would not produce the best results. Having separate frameworks that can co-exist is a more efficient and effective approach. That said, providing a well-defined hardware abstraction layer does complement different programming frameworks and can  allow one framework to support different types of accelerators.

Q. Is there a benefit to standardization at the edge?

A. The edge is a universal term that has many different definitions, but in this example can be referred to as a network of end points where data is generated, collected and processed. Standardization helps with developing a common foundation that can be referenced across application domains, and this can make it easier to deploy different types of accelerators at the edge. 

Q. Does adding a new programming framework in computational storage help to alleviate current infrastructure bottlenecks?

A. The SNIA Computational Storage API and TP4091 programming framework enables a standard programming approach over proprietary methods that may be vendor limited. The computational storage value proposition significantly reduces resource constraints while the programming framework supports improved resource access at the application layer. By making it easier to deploy computational storage, these frameworks may relieve some types of infrastructure bottlenecks.

Q. Do these programming frameworks typically operate at a low level or high level?

A. They operate at both. The goal of programming frameworks is to operate at the application resource management level with high level command calls that can initiate underlying hardware resources. They typically engage the underlying hardware resources using lower-level APIs or drivers.  

Q. How does one determine which framework is best for a particular task?

A. Framework selection should be addressed by which accelerator type is best suited to run the workload. Additionally, when multiple frameworks could apply, the decision on which to use would depend on the implementation details of the workload components. Multiple frameworks have been created and evolve because of this fact. There is not always a single answer to the question. The key idea motivating this webinar was to increase awareness about the frameworks available so that people can answer this question for themselves.

Q. Does using an open-source framework generally give you better or worse performance than using other programming options?

A. There is usually no significant performance difference between open source and proprietary frameworks, however the former is more relatively adaptable and scalable by the interested open-source community. A proprietary framework might offer better performance or access to a few more features, but usually works only with accelerators from one vendor.

Q. I would like to hear more on accelerators to replace vSwitches. How are these different from NPUs?   

A. Many of these accelerators include the ability to accelerate a virtual network switch (vSwitch) using purpose-built silicon as one of several tasks they can accelerate, and these accelerators are usually deployed inside a server to accelerate the networking instead of running the vSwitch on the server’s general-purpose CPU. A Network Processing Unit (NPU) is also an accelerator chip with purpose-built silicon but it typically accelerates only networking tasks and is usually deployed inside a switch, router, load balancer or other networking appliance instead of inside a server.

Q. I would have liked to have seen a slide defining GPU and DPU for those new to the technology.

A. SNIA has been working hard to help educate on this topic. A good starting point is our “What is an xPU” definition. There are additional resources on that page including the first webcast we did on this topic “SmartNICs to xPUs: Why is the Use of Accelerators Accelerating.”  We encourage you to check them out.

Q. How do computational storage devices (CSD) deal with "data visibility" issues when the drives are abstracted behind a RAID stripe (e.g. RAID0, 5, 6). Is it expected that a CSD will never live behind such an abstraction?

A. The CSD can operate as a standard drive under RAID as well as a drive with a complementary CSP (computational storage processor, re: CS Architecture Spec 1.0). If it is deployed under a RAID controller, then the RAID hardware or software would need to understand the computational capabilities of the CSD in order to take full advantage of them.

Q. Are any of the major OEM storage vendors (NetApp / Dell EMC / HPE / IBM, etc.) currently offering Computational Storage capable arrays?

A. A number of OEMs are offering arrays with compute resources that reside with data. The computational storage initiative that is promoted by SNIA provides a common reference architecture and programming model that may be referenced by developers and end customers.

Last month, the SNIA Networking Storage Forum made sense of the “wild west” of programming frameworks, covering xPUs, GPUs and computational storage devices at our live webcast, “You’ve Been Framed! An Overview of xPU, GPU & Computational Storage Programming Frameworks.” It was an excellent overview of what’s happening in this space. There was a lot to digest, so our stellar panel of experts has taken the time to answer the questions from our live audience in this blog. Q. Why is it important to have open-source programming frameworks? A. Open-source frameworks enable community support and partnerships beyond what proprietary frameworks support. In many cases they allow ISVs and end users to write one integration that works with multiple vendors. Q. Will different accelerators require different frameworks or can one framework eventually cover them all? A. Different frameworks support accelerator attributes and specific applications. Trying to build a single framework that does the job of all the existing frameworks and covers all possible use case would be extremely complex and time consuming. In the end it would not produce the best results. Having separate frameworks that can co-exist is a more efficient and effective approach. That said, providing a well-defined hardware abstraction layer does complement different programming frameworks and can  allow one framework to support different types of accelerators. Q. Is there a benefit to standardization at the edge? A. The edge is a universal term that has many different definitions, but in this example can be referred to as a network of end points where data is generated, collected and processed. Standardization helps with developing a common foundation that can be referenced across application domains, and this can make it easier to deploy different types of accelerators at the edge. Q. Does adding a new programming framework in computational storage help to alleviate current infrastructure bottlenecks? A. The SNIA Computational Storage API and TP4091 programming framework enables a standard programming approach over proprietary methods that may be vendor limited. The computational storage value proposition significantly reduces resource constraints while the programming framework supports improved resource access at the application layer. By making it easier to deploy computational storage, these frameworks may relieve some types of infrastructure bottlenecks. Q. Do these programming frameworks typically operate at a low level or high level? A. They operate at both. The goal of programming frameworks is to operate at the application resource management level with high level command calls that can initiate underlying hardware resources. They typically engage the underlying hardware resources using lower-level APIs or drivers. Q. How does one determine which framework is best for a particular task? A. Framework selection should be addressed by which accelerator type is best suited to run the workload. Additionally, when multiple frameworks could apply, the decision on which to use would depend on the implementation details of the workload components. Multiple frameworks have been created and evolve because of this fact. There is not always a single answer to the question. The key idea motivating this webinar was to increase awareness about the frameworks available so that people can answer this question for themselves. Q. Does using an open-source framework generally give you better or worse performance than using other programming options? A. There is usually no significant performance difference between open source and proprietary frameworks, however the former is more relatively adaptable and scalable by the interested open-source community. A proprietary framework might offer better performance or access to a few more features, but usually works only with accelerators from one vendor. Q. I would like to hear more on accelerators to replace vSwitches. How are these different from NPUs?    A. Many of these accelerators include the ability to accelerate a virtual network switch (vSwitch) using purpose-built silicon as one of several tasks they can accelerate, and these accelerators are usually deployed inside a server to accelerate the networking instead of running the vSwitch on the server’s general-purpose CPU. A Network Processing Unit (NPU) is also an accelerator chip with purpose-built silicon but it typically accelerates only networking tasks and is usually deployed inside a switch, router, load balancer or other networking appliance instead of inside a server. Q. I would have liked to have seen a slide defining GPU and DPU for those new to the technology. A. SNIA has been working hard to help educate on this topic. A good starting point is our “What is an xPU” definition. There are additional resources on that page including the first webcast we did on this topic “SmartNICs to xPUs: Why is the Use of Accelerators Accelerating.”  We encourage you to check them out. Q. How do computational storage devices (CSD) deal with “data visibility” issues when the drives are abstracted behind a RAID stripe (e.g. RAID0, 5, 6). Is it expected that a CSD will never live behind such an abstraction? A. The CSD can operate as a standard drive under RAID as well as a drive with a complementary CSP (computational storage processor, re: CS Architecture Spec 1.0). If it is deployed under a RAID controller, then the RAID hardware or software would need to understand the computational capabilities of the CSD in order to take full advantage of them. Q. Are any of the major OEM storage vendors (NetApp / Dell EMC / HPE / IBM, etc.) currently offering Computational Storage capable arrays? A. A number of OEMs are offering arrays with compute resources that reside with data. The computational storage initiative that is promoted by SNIA provides a common reference architecture and programming model that may be referenced by developers and end customers.

Using software to perform memory copies has been the gold standard for applications performing memory-to-memory data movement or system memory operations. With new accelerators and memory types enriching the system architecture, accelerator-assisted memory data movement and transformation need standardization.

At the forefront of this standardization movement is the SNIA Smart Data Accelerator Interface (SDXI) which is designed as an industry-open standard that is Extensible, Forward-compatible, and Independent of I/O interconnect technology.

Adjacently, Compute Express Link™ (CXL™) is an industry-supported Cache-Coherent Interconnect for Processors, Memory Expansion, and Accelerators. CXL is designed to be an industry-open standard interface for high-speed communications, as accelerators are increasingly used to complement CPUs in support of emerging applications such as Artificial Intelligence and Machine Learning.

How are these two standards related? What are the unique advantages of each? Find out on November 30, 2022 in our next SNIA Networking Storage Forum webcast “What’s in a Name? Memory Semantics and Data Movement with CXL and SDXI” where SNIA and CXL experts working to develop these standards will:

• Introduce SDXI and CXL.
• Discuss data movement needs in a CXL ecosystem
• Cover SDXI advantages in a CXL interconnect

Please join us on November 30^th to learn more about these exciting technologies.

Using software to perform memory copies has been the gold standard for applications performing memory-to-memory data movement or system memory operations. With new accelerators and memory types enriching the system architecture, accelerator-assisted memory data movement and transformation need standardization. At the forefront of this standardization movement is the SNIA Smart Data Accelerator Interface (SDXI) which is designed as an industry-open standard that is Extensible, Forward-compatible, and Independent of I/O interconnect technology. Adjacently, Compute Express Link (CXL) is an industry-supported Cache-Coherent Interconnect for Processors, Memory Expansion, and Accelerators. CXL is designed to be an industry-open standard interface for high-speed communications, as accelerators are increasingly used to complement CPUs in support of emerging applications such as Artificial Intelligence and Machine Learning. How are these two standards related? What are the unique advantages of each? Find out on November 30, 2022 in our next SNIA Networking Storage Forum webcast “What’s in a Name? Memory Semantics and Data Movement with CXL and SDXI” where SNIA and CXL experts working to develop these standards will:

• Introduce SDXI and CXL.
• Discuss data movement needs in a CXL ecosystem
• Cover SDXI advantages in a CXL interconnect

Please join us on November 30^th to learn more about these exciting technologies.

The popular xPU webcast series hosted by the SNIA Networking Storage Forum’s continued last month with an in-depth look at accelerator offload functions of the xPU. Our experts discussed the problems the xPUs solve, where in the system they live, and the functions they implement. If you missed the session, you can watch it on-demand and access the presentation slides at the SNIA Educational Library. The Q&A here offers additional insights into the role of the xPU.

Q. Since xPUs can see traffic on the host doesn't that widen the surface area for exposure if it were to be compromised?

A. There is another aspect of this question: It depends on who owns control of the device and who's allowed to run software there. If the organization that runs the infrastructure owns the xPU and controls the software that goes on there, then it can act as a security boundary to the rest of the host which might be running user software or other kinds of software. So, you can use the xPU as a security check in a security boundary and it actually could reduce the total attack surface or provide better security isolation. If you open up the xPU to be just another general-purpose micro server, then it has effectively the same attack surface as the hosting system, but you could run it in a mode or control it in a mode where it actually reduced the total attack service and make that a security boundary. That's one of the interesting notions that's come out in the industry on how xPUs can provide value.

Q. Before, the host internal-only traffic was only exposed if the host was compromised, but now if the xPU is compromised it might exfiltrate information without the host being aware. Cuts both ways - I get that it is a hardened domain.... but everything gets compromised eventually.  

A. Any programmable offload engine or hypervisor in a deployment has this same consideration. The xPU is most similar to a hypervisor that is providing common services such as storage or packet forwarding (vswitch) to its VMs. See the previous answer for additional discussion.

Q. What are the specific offloads and functions that xPUs offer that NICs and HBAs don't provide today?

A. From a storage offloads point of view, in addition to the data path offloads, the xPU has the integrated SOC CPU cores. Portions of the storage stack or the whole storage application and the control plane could be moved to the xPU.

The addition of accessible CPU cores, programmable pipelines, and directly usable offload engines, coupled to a general-purpose operating system, make the xPU fundamentally different from previous standard NIC- or HBA-based offloads. For the xPU, we're now talking about the infrastructure services offloads with storage applications as one of the key use cases. For that reason, we have this new xPU terminology which describes this new type of device that offloads infrastructure services of the hypervisor functionality. With xPUs, the host CPU cores can be completely freed up for hosting customer applications, containers, and VMs. NICs and HBAs typically offload only specific network or storage functions. xPUs can run an expanded set of agents, data services or applications.

To summarize at a high-level, you have local switching both on the PCIe side and on the network side, together with general purpose processors, plus the degree of programmability of the accelerators and the flexibility in the ways you can use an xPU.

Q. When security offload is enabled, do we still need single flow 100G rate? Can you talk about use cases and where it may be needed?

A. If the application or workload needs 100G line rate (or any other single flow specific rate) encryption and integrity, you need to find a specific xPU model that supports the desired security offload rate. xPU models will have varying capabilities. Typical workloads which might require this scale of single flow rate include storage access across a local network, AI workloads, technical computing, video processing, and large-scale streaming.

Q. When will you be hosting the next xPU webcast?

A. We’re glad you asked! The third presentation in this series will be “xPU Deployment and Solutions Deep Dive” on August 24, 2022 where we will explain key considerations on when, where and how to deploy xPUs. You can register here.

The popular xPU webcast series hosted by the SNIA Networking Storage Forum’s continued last month with an in-depth look at accelerator offload functions of the xPU. Our experts discussed the problems the xPUs solve, where in the system they live, and the functions they implement. If you missed the session, you can watch it on-demand and access the presentation slides at the SNIA Educational Library. The Q&A here offers additional insights into the role of the xPU. Q. Since xPUs can see traffic on the host doesn’t that widen the surface area for exposure if it were to be compromised? A. There is another aspect of this question: It depends on who owns control of the device and who’s allowed to run software there. If the organization that runs the infrastructure owns the xPU and controls the software that goes on there, then it can act as a security boundary to the rest of the host which might be running user software or other kinds of software. So, you can use the xPU as a security check in a security boundary and it actually could reduce the total attack surface or provide better security isolation. If you open up the xPU to be just another general-purpose micro server, then it has effectively the same attack surface as the hosting system, but you could run it in a mode or control it in a mode where it actually reduced the total attack service and make that a security boundary. That’s one of the interesting notions that’s come out in the industry on how xPUs can provide value. Q. Before, the host internal-only traffic was only exposed if the host was compromised, but now if the xPU is compromised it might exfiltrate information without the host being aware. Cuts both ways – I get that it is a hardened domain…. but everything gets compromised eventually.   A. Any programmable offload engine or hypervisor in a deployment has this same consideration. The xPU is most similar to a hypervisor that is providing common services such as storage or packet forwarding (vswitch) to its VMs. See the previous answer for additional discussion. Q. What are the specific offloads and functions that xPUs offer that NICs and HBAs don’t provide today? A. From a storage offloads point of view, in addition to the data path offloads, the xPU has the integrated SOC CPU cores. Portions of the storage stack or the whole storage application and the control plane could be moved to the xPU. The addition of accessible CPU cores, programmable pipelines, and directly usable offload engines, coupled to a general-purpose operating system, make the xPU fundamentally different from previous standard NIC- or HBA-based offloads. For the xPU, we’re now talking about the infrastructure services offloads with storage applications as one of the key use cases. For that reason, we have this new xPU terminology which describes this new type of device that offloads infrastructure services of the hypervisor functionality. With xPUs, the host CPU cores can be completely freed up for hosting customer applications, containers, and VMs. NICs and HBAs typically offload only specific network or storage functions. xPUs can run an expanded set of agents, data services or applications. To summarize at a high-level, you have local switching both on the PCIe side and on the network side, together with general purpose processors, plus the degree of programmability of the accelerators and the flexibility in the ways you can use an xPU. Q. When security offload is enabled, do we still need single flow 100G rate? Can you talk about use cases and where it may be needed? A. If the application or workload needs 100G line rate (or any other single flow specific rate) encryption and integrity, you need to find a specific xPU model that supports the desired security offload rate. xPU models will have varying capabilities. Typical workloads which might require this scale of single flow rate include storage access across a local network, AI workloads, technical computing, video processing, and large-scale streaming. Q. When will you be hosting the next xPU webcast? A. We’re glad you asked! The third presentation in this series will be “xPU Deployment and Solutions Deep Dive” on August 24, 2022 where we will explain key considerations on when, where and how to deploy xPUs. You can register here.

The SNIA Networking Storage Forum kicked off its xPU webcast series last month with “SmartNICs to xPUs – Why is the Use of Accelerators Accelerating?” where SNIA experts defined what xPUs are, explained how they can accelerate offload functions, and cleared up confusion on many other names associated with xPUs such as SmartNIC, DPU, IPU, APU, NAPU. The webcast was highly-rated by our audience and already has more than 1,300 views. If you missed it, you can watch it on-demand and download a copy of the presentation slides at the SNIA Educational Library.

The live audience asked some interesting questions and here are answers from our presenters.

Q. How can we have redundancy on an xPU?

A. xPUs are optimal for optimizing and offloading server/appliance and application redundancy schemes. Being the heart of the data movement and processing at the server, xPUs can expose parallel data-paths and be a reliable control point for server management. Also, the xPUs’ fabric connecting the hosts can provide self-redundancy and elasticity such that redundancy between xPU devices can be seamless and provide simplified redundancy and availability scheme between the different entities in the xPU fabric that is connecting between the servers over the network. The fact that xPUs don’t run the user applications, (or maybe in the worst case run some offload functions for them) makes them a true stable and reliable control point for such redundancy schemes. It’s also possible to put two (or potentially more) xPUs into each server to provide redundancy at the xPU level.

Q. More of a comment.  I'm in the SSD space, and with the ramp up in E.1L/S E.3 space is being optimized for these SmartNICs/GPUs, DPUs, etc.  Also better utilizing space inside a server/node, and allow for serial interface location on the PCB.  Great discussion today.

A. Yes, it’s great to see servers and component devices evolving towards supporting cloud-ready architectures and composable infrastructure for data centers. We anticipate that xPUs will evolve into a variety of physical form factors within the server especially with the modular server component standardization work that is going on. We’re glad you enjoyed the session.

Q. How does CXL impact xPUs and their communication with other components such as DRAM? Will this eliminate DDR and not TCP/IP?   

A. xPUs might use CXL as an enhanced interface to the host, to local devices connected to the xPU or to a CXL fabric that acts as an extension of local devices and xPUs network, for example connected to an entity like a shared memory pool. CXL can provide an enhanced, coherent memory interface and can take a role in extending access to slower tiers of memory to the host or devices through the CXL.MEM interface. It can also provide a coherent interface through the CXL.CACHE interface that can create an extended compute interface and allow close interaction between host and devices. We think CXL will provide an additional tier for memory and compute that will be living side by side with current tiers of compute and memory, each having its own merit in different compute scenarios. Will CXL eliminate DDR? Local DDR for the CPU will always have a latency advantage and will provide better compute in some use cases, so CXL memory will add additional tiers of memory/PMEM/storage in addition to that provided by DDR.  

Q. Isn't a Fibre Channel (FC) HBA very similar to a DPU, but for FC?

A. The NVMe-oF offloads make the xPU equivalent to an FC HBA, but the xPU can also host additional offloads and services at the same time. Both FC HBAs and xPUs typically accelerate and offload storage networking connections and can enable some amount of remote management. They may also offload storage encryption tasks. However, xPUs typically support general networking and might also support storage tasks, while FC HBAs always support Fibre Channel storage tasks and rarely support any non-storage functions.

Q. Were the old TCP Offload Engine (TOE) cards from Adaptec many years ago considered xPU devices, that were used for iSCSI?

A.They were not considered xPUs as—like FC HBAs—they only offloaded storage networking traffic, in this case for iSCSI traffic over TCP. In addition, the terms “xPU,” “IPU” and “DPU” were not in use at that time. However, TOE and equivalent cards laid the ground work for the evolution to the modern xPU.

Q. For xPU sales to grow dramatically won't that happen after CXL has a large footprint in data centers?

A. The CXL market is focused on a coherent device and memory extension connection to the host, while the xPU market is focused on devices that handle data movement and processing offload for the host connected over networks. As such, CXL and xPU markets are complementary. Each market has its own segment and use case and viability independent on each other. As discussed above, the technical solutions are complements so that the evolution of each market proliferates from the other. Broader adoption of CXL will enable faster and broader functionality for xPUs, but is not required for rapid growth of the xPU market.

Q. What role will CXL play in these disaggregated data centers?

A. The ultimate future of CXL is a little hard to predict. CXL has a potential role in disaggregation of coherent devices and memory pools at the chassis/rack scale level with CXL switch devices, while xPUs have the role of disaggregating at the rack/datacenter level. xPUs will start out connecting multiple servers across multiple racks then extend across the entire data center and potentially across multiple data centers (and potentially from cloud to edge). It is likely that CXL will start out connecting devices within a server then possibly extend across a rack and eventually across multiple racks. 

If you are interested in learning more about xPUs, I encourage you to register for our second webcast

“xPU Accelerator Offload Functions”to hear what problems the xPUs are coming to solve, where in the system they live, and the functions they implement.

The SNIA Networking Storage Forum kicked off its xPU webcast series last month with “SmartNICs to xPUs – Why is the Use of Accelerators Accelerating?” where SNIA experts defined what xPUs are, explained how they can accelerate offload functions, and cleared up confusion on many other names associated with xPUs such as SmartNIC, DPU, IPU, APU, NAPU. The webcast was highly-rated by our audience and already has more than 1,300 views. If you missed it, you can watch it on-demand and download a copy of the presentation slides at the SNIA Educational Library. The live audience asked some interesting questions and here are answers from our presenters. Q. How can we have redundancy on an xPU? A. xPUs are optimal for optimizing and offloading server/appliance and application redundancy schemes. Being the heart of the data movement and processing at the server, xPUs can expose parallel data-paths and be a reliable control point for server management. Also, the xPUs’ fabric connecting the hosts can provide self-redundancy and elasticity such that redundancy between xPU devices can be seamless and provide simplified redundancy and availability scheme between the different entities in the xPU fabric that is connecting between the servers over the network. The fact that xPUs don’t run the user applications, (or maybe in the worst case run some offload functions for them) makes them a true stable and reliable control point for such redundancy schemes. It’s also possible to put two (or potentially more) xPUs into each server to provide redundancy at the xPU level. Q. More of a comment. I’m in the SSD space, and with the ramp up in E.1L/S E.3 space is being optimized for these SmartNICs/GPUs, DPUs, etc. Also better utilizing space inside a server/node, and allow for serial interface location on the PCB.  Great discussion today. A. Yes, it’s great to see servers and component devices evolving towards supporting cloud-ready architectures and composable infrastructure for data centers. We anticipate that xPUs will evolve into a variety of physical form factors within the server especially with the modular server component standardization work that is going on. We’re glad you enjoyed the session. Q. How does CXL impact xPUs and their communication with other components such as DRAM? Will this eliminate DDR and not TCP/IP?    A. xPUs might use CXL as an enhanced interface to the host, to local devices connected to the xPU or to a CXL fabric that acts as an extension of local devices and xPUs network, for example connected to an entity like a shared memory pool. CXL can provide an enhanced, coherent memory interface and can take a role in extending access to slower tiers of memory to the host or devices through the CXL.MEM interface. It can also provide a coherent interface through the CXL.CACHE interface that can create an extended compute interface and allow close interaction between host and devices. We think CXL will provide an additional tier for memory and compute that will be living side by side with current tiers of compute and memory, each having its own merit in different compute scenarios. Will CXL eliminate DDR? Local DDR for the CPU will always have a latency advantage and will provide better compute in some use cases, so CXL memory will add additional tiers of memory/PMEM/storage in addition to that provided by DDR. Q. Isn’t a Fibre Channel (FC) HBA very similar to a DPU, but for FC? A. The NVMe-oF offloads make the xPU equivalent to an FC HBA, but the xPU can also host additional offloads and services at the same time. Both FC HBAs and xPUs typically accelerate and offload storage networking connections and can enable some amount of remote management. They may also offload storage encryption tasks. However, xPUs typically support general networking and might also support storage tasks, while FC HBAs always support Fibre Channel storage tasks and rarely support any non-storage functions. Q. Were the old TCP Offload Engine (TOE) cards from Adaptec many years ago considered xPU devices, that were used for iSCSI? A.They were not considered xPUs as—like FC HBAs—they only offloaded storage networking traffic, in this case for iSCSI traffic over TCP. In addition, the terms “xPU,” “IPU” and “DPU” were not in use at that time. However, TOE and equivalent cards laid the ground work for the evolution to the modern xPU. Q. For xPU sales to grow dramatically won’t that happen after CXL has a large footprint in data centers? A. The CXL market is focused on a coherent device and memory extension connection to the host, while the xPU market is focused on devices that handle data movement and processing offload for the host connected over networks. As such, CXL and xPU markets are complementary. Each market has its own segment and use case and viability independent on each other. As discussed above, the technical solutions are complements so that the evolution of each market proliferates from the other. Broader adoption of CXL will enable faster and broader functionality for xPUs, but is not required for rapid growth of the xPU market. Q. What role will CXL play in these disaggregated data centers? A. The ultimate future of CXL is a little hard to predict. CXL has a potential role in disaggregation of coherent devices and memory pools at the chassis/rack scale level with CXL switch devices, while xPUs have the role of disaggregating at the rack/datacenter level. xPUs will start out connecting multiple servers across multiple racks then extend across the entire data center and potentially across multiple data centers (and potentially from cloud to edge). It is likely that CXL will start out connecting devices within a server then possibly extend across a rack and eventually across multiple racks. If you are interested in learning more about xPUs, I encourage you to register for our second webcast “xPU Accelerator Offload Functions”to hear what problems the xPUs are coming to solve, where in the system they live, and the functions they implement.

As covered in our first xPU webcast “SmartNICs and xPUs: Why is the Use of Accelerators Accelerating,” we discussed the trend to deploy dedicated accelerator chips to assist or offload the main CPU. These new accelerators (xPUs) have multiple names such as SmartNIC, DPU, IPU, APU, NAPU. If you missed the presentation, I encourage you to check it out in the SNIA Educational Library where you can watch it on-demand and access the presentation slides. This second webcast in this SNIA Networking Storage Forum xPU webcast series is “xPU Accelerator Offload Functions” where our SNIA experts will take a deeper dive into the accelerator offload functions of the xPU. We’ll discuss what problems the xPUs are coming to solve, where in the system they live, and the functions they implement, focusing on:

• Network Offloads
  • Virtual switching and NPU
  • P4 pipelines
  • QoS and policy enforcement
  • NIC functions
  • Gateway functions (tunnel termination, load balancing, etc)
• Security Offloads
  • Encryption
  • Policy enforcement
  • Key management and crypto
  • Regular expression matching
  • Firewall
  • Deep Packet Inspection (DPI)
• Compute Offloads
  • AI calculations, model resolution
  • General purpose processing (via local cores)
  • Emerging use of P4 for general purpose
• Storage Offloads
  • Compression and data at rest encryption
  • NVMe-oF offload
  • Regular expression matching
  • Storage stack offloads

This webcast will be live on June 29, 2022 at 11:00 am PT/2:00 pm ET. I encourage you to register today and bring your questions for our experts. We look forward to seeing you.