Installing new Insider’s build Windows Server vnext NVMeoF, host initiator

Installing new Insider’s build Windows Server vnext NVMeoF, host initiator

A few weeks ago, Microsoft released a new Insider’s build of Windows Server vnext with NVMeoF host initiator. This post looks at installing and setting up the new initiator for testing. Granted, this is for testing and evaluating the NVMe over Fabric (NVMeoF) that supports TCP and RDMA for networked block storage with a Windows Server vnext host, and a Linux test target. Given that this is for a simple test and trying things out, you will want to adjust some of the security and access control settings on both the initiator and target sides.

Whats Needed

For the host NVMeoF initiator, you will need a current version of the insider build release of Windows Server vnext available here. You will also need some type of NVMeoF target, such as a storage system or platform that supports NVMeoF via TCP or RDMA, or a test initiator, for example, on a Linux system. For my test target, I set up an Ubuntu 25 Linux server with a small 50GB device to export as an NVMeoF device.

On the Ubuntu Linux server (e.g NVMeoF target)

sudo apt install nvme-cli -y
sudo modprobe nvmet
sudo modprobe nvmet-tcp
lsmod | grep nvmet

You should then see something like the following:

nvmet_tcp 45056 1
nvmet 249856 7 nvmet_tcp
nvme_core 241664 4 nvmet,nvme_tcp,nvme,nvme_fabrics
nvme_keyring 20480 5 nvmet,nvme_tcp,nvmet_tcp,nvme_core,nvme_fabrics
nvme_auth 28672 2 nvmet,nvme_core

Continue with the NVMeoF target setup:

sudo mount -t configfs none /sys/kernel/config
cd /sys/kernel/config/nvmet

# define your nqn which can be what ever you like, or have

sudo mkdir subsystems/nqn-2026-03.com:nvme.storageio01

# since this is for testing, this is being loose with access control

echo 1 | sudo tee subsystems/nqn-2026-03.com:nvme.storageio01/attr_allow_any_host
sudo mkdir subsystems/nqn-2026-03.com:nvme.storageio01/namespaces/1

# specify device to use as target, the device could be a partition, volume, file, etc

echo /dev/sdb | sudo tee subsystems/nqn-2026-03.com:nvme.storageio01/namespaces/1/device_path
echo 1 | sudo tee subsystems/nqn-2026-03.com:nvme.storageio01/namespaces/1/enable

# You can select what port you want to use. For testing, used 4420

sudo mkdir ports/4420
echo tcp | sudo tee ports/4420/addr_trtype
echo 192.168.1.205 | sudo tee ports/4420/addr_traddr
echo 4420 | sudo tee ports/4420/addr_trsvcid
echo ipv4 | sudo tee ports/4420/addr_adrfam

# For non-testing, you can adjust access to suit your needs

sudo ufw allow 4420/tcp

# now make the target accessible

sudo ln -s /sys/kernel/config/nvmet/subsystems/nqn-2026-03.com:nvme.storageio01 /sys/kernel/config/nvmet/ports/4420/subsystems/nqn-2026-03.com:nvme.storageio01

# now lets see if there is a listener

sudo ss -ltnp | grep 4420

# Should see something like this:

LISTEN 0 128 192.168.1.205:4420 0.0.0.0:*

# now lets discover whats out there based on what we have setup

sudo nvme discover -t tcp -a 192.168.1.205 -s 4420

# should see something like this:

Discovery Log Number of Records 2, Generation counter 2
=====Discovery Log Entry 0======
trtype: tcp
adrfam: ipv4
subtype: current discovery subsystem
treq: not specified, sq flow control disable supported
portid: 4420
trsvcid: 4420
subnqn: nqn.2014-08.org.nvmexpress.discovery
traddr: 192.168.1.205
eflags: none
sectype: none
=====Discovery Log Entry 1======
trtype: tcp
adrfam: ipv4
subtype: nvme subsystem
treq: not specified, sq flow control disable supported
portid: 4420
trsvcid: 4420
subnqn: nqn-2026-03.com:nvme.storageio01
traddr: 192.168.1.205
eflags: none
sectype: none

# if you want to connect from the Linux server

sudo nvme connect -t tcp -a 192.168.1.205 -s 4420 -n nqn-2026-03.com:nvme.storageio01

# and then list the targets

nvme list

# you should see something like this:

Node Generic SN Model Namespace Usage Format FW Rev
——————— ——————— ——————– —————————————- ———- ————————– —————- ——–
/dev/nvme0n1 /dev/ng0n1 eab7bd175e01b9dbbba5 Linux 0x1 53.69 GB / 53.69 GB 512 B + 0 B 6.17.0-1

setting up linux nvmeof target

On Windows Server vnext (NVMeoF Initiator)

Now, on your Windows Server vnext, open a command window with elevated access (e.g., Run as Administrator) and use the following, making note of the parameters from the target (e.g., IP address, port 4420, nqn).

Here is a screen shot of the host initiator before the NVMeoF target appears.

windows server vnext nvmeof host initiator setup

Now display available NVMeoF initiators using this command:

nvmeofutil.exe list -t ia

windows server vnext nvmeof host initiator setup

Note the host adapter number (e.g., 1) which will be used in the next step to get host gateway information.

nvmeofutil.exe list -t sp -ia 1
windows server vnext nvmeof host initiator setup display host gateway

Note the host gateway, target IP address, target port, and target nqn. Also note that there is an IPV6 and IPV4, in this example there is no IPV6 being used, so we are using the 2nd item (e.g. IPV4).

nvmeofutil.exe add -t sp -ia 1 -hg -dy true -pi 1 -nq nqn-2026-03.com:nvme.storageio01 -ta 192.168.1.205 -ts 4420

windows server vnext nvmeof host initiator setup showing host gateway and other information

Now, let’s identify the target subsystem ID.

nvmeofutil.exe list -t sp -ia 1

windows server vnext nvmeof host initiator setup showing subsystem information of available targets

Now, let’s use the subsystem port from above to connect to the target. Note that in some of the instructions I have seen, there is a reference to sp without an sp shown; thus, the previous steps help identify the sp to use.

nvmeofutil.exe connect -ia 1 -sp 000000003C7E88F0

windows server vnext nvmeof host initiator setup

Congratulations, at this point, you should see a new disk or volume appear on your Windows Server vnext host system.

windows server vnext nvmeof host initiator setup

The above image shows what appears when using diskpart, as well as the disk format utility, or use your preferred command, PowerShell script, or tool. If the disk or volume has not yet been used, it must be initialized and formatted. Otoh, as in this example, the disk volume had previously been initialized and formatted as a simple NTFS volume.

Again, reiterating, the above is for simple testing and evaluation, with loose security and persistence that you will want to tighten up as needed. The whole process is pretty easy as long as you don’t make any typos, for example, with nqn or other items.

Additional Resources Where to learn more

Microsoft Windows Server Insider Build NVMeoF Initiator (Blog post)
NVMe Linux Driver and related info
Announcing Native NVMe in Windows Server 2025 (Microsoft Post)
Introducing the Windows NVMe-oF Initiator Preview in Windows Server Insiders Builds (Microsoft Post)
Windows Server Insider Builds (Microsoft Downloads)
ToE NVMeoF TCP Performance Boost Performance Reduce Costs (blog post)
TheNVMeplace.com (Various NVMe resources)
Azure Cloud Storage here (Microsoft Post)
Microsoft Azure Data Box (Blog Post)
Azure Elastic SAN from Cloud to On-Prem here (Blog Post)
Cloud and Software Defined Data Infrastructure topics here

Additional learning experiences along with common questions (and answers) pertaining to SCSI, Fibre Channel, NVMe, Cloud, Hardware, Software, Services, techniques, server, storage, I/O networking, data protection among other topics are found in my Software Defined Data Infrastructure Essentials book.

Software Defined Data Infrastructure Essentials (CRC Press) by Greg Schulz

What this all means

With the insiders preview of Windows Server vnext you have the opportunity to try out the new NVMeoF initiator using TCP and RDMA including on Ethernet based fabric networks. The current insiders build utilizes the nvmeofutility.exe for initial testing, evaluations and experiments while future releases should see other management tools and interfaces such as Powershell cmdlets among others.

Ok, nuff said.

Cheers Gs

Greg Schulz – Ten time Microsoft MVP Cloud and Data Center Management and Azure Storage, along with previous ten-time VMware vExpert. Author of Software Defined Data Infrastructure Essentials (CRC Press), as well as Cloud and Virtual Data Storage Networking (CRC Press), The Green and Virtual Data Center (CRC Press), Resilient Storage Networks (Elsevier) and twitter @storageio. Courteous comments are welcome for consideration. First published on https://storageioblog.com any reproduction in whole, in part, with changes to content, without source attribution under title or without permission is forbidden.

All Comments, (C) and (TM) belong to their owners/posters, Other content (C) Copyright 2006-2026 Server StorageIO and UnlimitedIO. All Rights Reserved. StorageIO is a registered Trade Mark (TM) of UnlimitedIO LLC.

Its Time for NVMeoF to let iSCSI begin its slow retirement journey

Why Its Time for NVMeoF

Its Time for NVMeoF to let iSCSI begin its slow retirement journey for networked shared block storage. Dating back to the late 1990s and early 2000s, iSCSI encapsulates the SCSI command set over a TCP/IP (IP)- based fabric network, or as an alternative to SCSI on Fibre Channel (SCSI_FCP aka FCP aka FC). The SCSI command set dates back to the 1980s, having been deployed on physical parallel cabling and later on other transports, including Fibre Channel, Serial Attached SCSI (SAS), and iSCSI.

The reason it’s time for NVMe over Fabric (NVMeoF), and specifically NVMeoF using TCP and RDMA, to let iSCSI begin its slow retirement journey, is the evolution of the NVMe protocol command set and the expansion of its ecosystem as a modern, ground-up, streamlined server storage I/O protocol command set.

Keep in mind that there are two aspects in play with NVMeoF, which are similar to iSCSI and Fibre Channel-based FCP: the upper layer or protocol command set (e.g., NVMe and SCSI), and media through which these command sets are implemented via various interfaces such as TCP or RDMA on Ethernet, via InfiniBand, Fibre Channel, or physical PCIe, among others.

Ethernet has established itself as the dominant network interface, supporting various upper layers, such as TCP, and increasing its speed. Likewise, InfiniBand and Fibre Channel continue to increase their speeds and maintain their deployment roles in some environments.

Besides supporting faster networks, the NVMe command set was architected and has been deployed to support the current and evolving generations of processors with multiple cores, enabling more concurrent I/O operations and compute threads with less CPU overhead due to a modern, streamlined I/O stack and associated native drivers.

Why NVMeoF (over TCP or RDMA)

Leverage the combined improved benefits of NVMe as a server storage I/O communications protocol, along with TCP networking and industry-standard Ethernet as a communications fabric. With the NVMe command protocol server storage, I/O processing is streamlined and optimized for modern high-speed, low-latency network fabrics, such as Ethernet, as the transport.

The NVMe command set, compared to the SCSI command set, enables faster I/O processing with lower latency, higher IOPs, greater bandwidth, and more transactions, while increasing concurrency and the number of threads and reducing CPU usage per I/O operation. Similar to the SCSI command set, which has been deployed on various industry-standard transport interfaces, the NVMe command set is also deployed across various transports. For example, SCSI has been supported on IP (iSCSI), Fibre Channel (SCSI_FCP, e.g., FCP), Serial Attached SCSI (SAS), and Parallel SCSI, among others.

Likewise, the NVMe command set has been implemented via PCIe, including U.2, as well as over fabrics (e.g., NVMe over Fabric, aka NVMeoF), most notably with TCP and RDMA, along with some NVMe over Fibre Channel. In addition to being a modern, streamlined command set, NVMe also supports more devices, queues, and sessions, and is optimized with host-server initiator and target-side stacks.
An example of how NVMe is being embraced from a software support standpoint is Microsoft’s production release of a new, re-architected, optimized I/O stack as part of Windows Server 2025 in December 2025. Recently, Microsoft released, as part of the latest vnext insiders preview build, an all-new NVMeoF (TCP & RDMA) initiator for testing and evaluation.

NVMe has proven itself as a command set using various transports for use as a target for various SSD and flash storage devices (e.g., back-end) in servers, clients, and storage systems, as well as a front-end alternative to SCSI_FCP (e.g., FCP or FC) and iSCSI among others on storage systems, and software-defined storage solutions. Also, keep in mind that while the SCSI command set dates back to at least the early 1990s for general-purpose access of Magnetic Tape, CD/DVD, HDD, and later SSD, NVMe developed in the last decade was created from the ground up for solid-state devices (SSDs), including flash, among other persistent storage mediums.

Why NVMeoF (TCP) vs iSCSI

It would be, and is, too easy to say the 2000s called and want iSCSI back; however, tongue-in-cheek, there is some reality to that. However, looking closer, iSCSI evolved in the early 2000s as a low-cost SCSI command set alternative to Fibre Channel (SCSI_FCP, e.g., FCP or FC), as well as the survivor of the block IP storage wars (e.g., iFCP, FCIP, iSCSI, etc.) for general-purpose IP-based SCSI storage access.

Fibre Channel-based SCSI (FCP) went on to dominate higher-performance fabric- or networked-storage, aka storage area networks (SANs), with iSCSI having some success in other areas alongside file-based IP storage access via NFS & SMB, among others.

Now that we are in the mid-2020s, the ecosystem around NVMe has matured and continues to do so, with full-stack NVMe solutions, hardware- and software-based initiators, native NVMe drivers, target-based storage systems, and storage devices using various transports. NVMe has evolved from direct-attached PCIe card slots to PCIe U.2 & U.3, M.2 and EDSFF slots, as well as NVMe over Fabrics including TCP and RDMA, among others.

The benefit of using NVMeoF vs iSCSI is lower latency, due to native NVMe commands over TCP being streamlined, vs older SCSI encapsulation and associated cumbersome driver stacks. Besides the streamlined drivers and transports, NVMeoF also provides massive parallelism and multi-threading to boost server storage I/O while leveraging today’s multi-core processors and offload capabilities.

The net result is more I/O operations supporting higher IOPs, bandwidth, and transactions per second, with lower latency and lower CPU usage, resulting in greater productivity and better economics for databases, virtualization, AI/ML, and other block-based workloads.

Who supports NVMe and NVMeoF?

Most host and client operating systems support NVMe or NVMeoF initiators (e.g., Linux, VMware, Microsoft Windows [in the current Insider build], among others). There are also hardware adapter-based NVMe initiators, such as those from Broadcom, Chelsio, and NVIDIA. There are software NVMe and NVMe target packages for many platforms, such as Linux-based NVMe, nvme-tcp, nvme-rdma, nvme-fc, nvmet, nvmet-tcp, and SPDK (Storage Performance Development Kit), among others.

Besides server- or client-side support, there are storage and server hardware chassis building blocks that support NVMe, as well as storage system solutions from Dell, HPE, Hitachi, NetApp, Pure, among others. Within large cloud service providers such as AWS, Microsoft Azure, and Google Cloud Platform (GCP), NVMe is also widely used across their platform ecosystems.

Why it’s time for NVMeoF to let iSCSI begin its slow retirement journey
This is not to say that iSCSI is dead or that it has no future; rather, NVMeoF and its ecosystem have evolved and are ready to do more. Likewise, the SCSI command set is not dead; it’s still used with SAS, Fibre Channel (FCP), iSCSI, etc. However, NVMe has evolved and is seeing broad adoption from server and client attachment to storage devices and storage systems over various transport interfaces and media (PCIe, U.2/U.3, M.2, EDSFF, Ethernet, and fabrics).

Storage systems have also evolved, adding front-end support for NVMeoF and back-end attachment of NVMe flash and SSDs. With the combination of server, client and other software platforms having or in public release review, new streamlined native NVMe drivers and I/O stacks along with NVMeoF initiators (or targets), now is the time to look at NVMeoF as a replacement or alternative to iSCSI, and perhaps even Fibre Channel in the future to support existing and legacy workloads as well as new and emerging application landscapes and their demanding server storage I/O and compute needs (e.g. AI among others).

Additional Resources Where to learn more

Microsoft Windows Server Insider Build NVMeoF Initiator (Blog post)
Installing new Insider’s build Windows Server vnext NVMeoF, host initiator (blog post)
NVMe Linux Driver and related info
Announcing Native NVMe in Windows Server 2025 (Microsoft Post)
Introducing the Windows NVMe-oF Initiator Preview in Windows Server Insiders Builds (Microsoft Post)
Windows Server Insider Builds (Microsoft Downloads)
ToE NVMeoF TCP Performance Line Boost Performance Reduce Costs (blog post)
TheNVMeplace.com (Various NVMe resources)
Azure Cloud Storage here (Microsoft Post)
Microsoft Azure Data Box (Blog Post)
Azure Elastic SAN from Cloud to On-Prem here (Blog Post)
Cloud and Software Defined Data Infrastructure topics here

Additional learning experiences along with common questions (and answers) pertaining to SCSI, Fibre Channel, NVMe, Cloud, Hardware, Software, Services, techniques, server, storage, I/O networking, data protection among other topics are found in my Software Defined Data Infrastructure Essentials book.

Software Defined Data Infrastructure Essentials (CRC Press) by Greg Schulz

What this all means

Now is a good time to look into NVMe and, specifically, NVMe over Fabric (NVMeoF) if you have not recently done so, to refresh or learn what it can do. Likewise, if you are using iSCSI or Fibre Channel-based SCSI_FCP (e.g., not FICON), now is a good time to review or refresh your understanding of NVMeoF and where it fits into future plans for block storage. For those who say block storage is dead and everything is object storage, file storage, or even table storage, that’s fine, as those are all companions to block storage in a balanced ecosystem, each with its own uses, roles, and fits.

Ok, nuff said.

Cheers Gs

Greg Schulz – Ten time Microsoft MVP Cloud and Data Center Management and Azure Storage, along with previous ten-time VMware vExpert. Author of Software Defined Data Infrastructure Essentials (CRC Press), as well as Cloud and Virtual Data Storage Networking (CRC Press), The Green and Virtual Data Center (CRC Press), Resilient Storage Networks (Elsevier) and twitter @storageio. Courteous comments are welcome for consideration. First published on https://storageioblog.com any reproduction in whole, in part, with changes to content, without source attribution under title or without permission is forbidden.

All Comments, (C) and (TM) belong to their owners/posters, Other content (C) Copyright 2006-2026 Server StorageIO and UnlimitedIO. All Rights Reserved. StorageIO is a registered Trade Mark (TM) of UnlimitedIO LLC.

ToE NVMeoF TCP Performance Line Boost Performance Reduce Costs

The ToE NVMeoF TCP Performance Line Boost Performance Reduce Costs

ToE NVMeoF TCP Performance Line Boost Performance Reduce Costs.

Yes, you read that correct; leverage TCP offload Engines (TOE) to boost the performance of TCP-based NVMeoF (e.g., NVMe over Fabrics) while reducing costs. Keep in mind that there is a difference between cutting costs (something that causes or moves problems and complexities elsewhere) and reducing and removing costs (e.g., finding, fixing, removing complexities).

Reducing or cutting costs can be easy by simply removing items for lower-priced items and introducing performance bottlenecks or some other compromise. Likewise, boosting performance can be addressed by throwing (deploying) more hardware (and or software) at the problem resulting in higher costs or some other compromise.

On the other hand, as mentioned above, finding, fixing, removing the complexity and overhead results in cost savings while doing the same work or enabling more work done via the same costs, maximizing hardware, software, and network costs. In other words, a better return on investment (ROI) and a lower total cost of ownership (TCO).

Software Defined Storage and Networks Need Hardware

With the continued shift towards software-defined data centers, software-defined data infrastructures, software-defined storage, software-defined networking, and software-defined everything, those all need something in common, and that is hardware-based compute processing.

In the case of software-defined storage, including standalone, shared fabric or networked-based, converged infrastructure (CI) or hyper-converged infrastructure (HCI) deployment models, there is the need for CPU compute, memory, and I/O, in addition to storage devices. This means that the software to create, manage, and perform storage tasks needs to run on a server’s CPU, along with I/O networking software stacks.

However, it should be evident that sometimes the obvious needs to be restarted, which is that software-defined anything requires hardware somewhere in the solution stack. Likewise, depending on how the software is implemented, it may require more hardware resources, including server compute, memory, I/O, and network and storage capabilities.

Keep in mind that networking stacks, including upper and lower-level protocols and interfaces, leverage software to implement their functionality. Therefore, the value proposition of using standard networks such as Ethernet and TCP is the ability to leverage lower-cost network interface cards (or chips), also known as NICs combined with server-based software stacks.

On the one hand, costs can be reduced by using less expensive NICs and using the generally available server CPU compute capabilities to run the TCP and other networking stack software. On systems with a lower application or other software performance demands, this can work out ok. However, for workloads and systems using software-defined storage and other applications that compete for server resources (CPU, memory, I/O), this can result in performance bottlenecks and problems.

Many Server Storage I/O Networking Bottlenecks Are CPU Problems

There is a classic saying that the best I/O is the one that you do not have to do. Likewise, the second-best I/O is the one with the most negligible overhead (and cost) as well as best performance. Another saying is that many application, database, server, and storage I/O problems are actually due to CPU bottlenecks. Fast storage devices need fast applications on fast servers with fast networks. This means finding and removing blockages, including offloading server CPU from performing network I/O processing using TOEs.

Wait a minute, isn’t the value proposition of using software-defined storage or networking to use low-cost general-purpose servers instead of more expensive hardware devices? With some caveats, Yup understands how much server CPU us being used to run the software-defined storage and software stacks and handle upper-level functionality. To support higher performance or larger workloads can be putting in more extensive (scale-up) and more (scale-out) servers and their increased connectivity and management overhead.

This is where the TOEs come into play by leveraging the best of both worlds to run software-defined storage (and networking) stacks, and other software and applications on general-purpose compute servers. The benefit is the TCP network I/O processing gets offloaded from the server CPU to the TOE, thereby freeing up the server CPU to do more work or enabling a smaller, lower-cost CPU to be used.

After all, many servers, storage, and I/O networking problems are often server CPU problems. An example of this is running the TCP networking software stack using CPU cycles on a host server that competes with the other software and applications. In addition, as an application does more I/O, for example, issuing reads and write requests to network and fabric-based storage, the server’s CPUs are also becoming busier with more overhead of running the lower-layer TCP and networking stack.

The result is server resources (CPU, memory) are running at higher utilization; however, there is more overhead. Higher resource utilization with low or no overhead, low latency, and high productivity are good things resulting in lower cost per work done. On the other hand, high CPU utilization, server operating system or kernel mode overhead, poor latency, and low productivity are not good things resulting in host per work done.

This means there is a loss of productivity as more time is spent waiting, and the cost to do a unit of work, for example, an I/O or transaction, increases (there is more overhead). Thus, offload engines (chips, cards, adapters) come into play to shift some software processing from the server CPU to a specialized processor. The result is lower server CPU overhead leaving more server resources for the main application or software-defined storage (and networking) while boosting performance and lowering overall costs.

Graphics, Compute, Network, TCP Offload Engines

Offload engines are not new, they have been around for a while, and in some cases, more common than some realize going by different names. For example, graphical Processing Units (GPUs) are used for offloading graphic and compute-intensive tasks to special chips and adapter cards. Other examples of offload processors include networks such as TCP Offload Engine (TOE), compression, and storage processing, among others.

The basic premise of offload engines is to move or shift processing of specific functions from having their software running on a general-purpose server CPU to a specialized processor (ASIC, FPGA, adapter, or mezzanine card). By moving the processing of functions to the offload or unique processing device, performance can be boosted while freeing up a server’s primary processor (CPU) to do other useful (and productive) work.

There is a cost associated with leveraging offloads and specialized processors; however, the business benefit should be offset by reducing primary server compute expenses or doing more work with available resources and driving network bandwidth line rates performance. The above should result in a net TCO reduction and boost your ROI for a given system or bill of material, including hardware, software, networking, and management.

Cloud File Data Storage Consolidation and Economic Comparison Model

Fast Storage Needs Fast Servers and I/O Networks

Ethernet network TOEs became popular in the industry back in the early 2000s, focusing on networked storage and storage networks that relied on TCP (e.g., iSCSI).

Fast forward to today, and there is continued use of networked (ok, fabric) storage over various interfaces, including Ethernet supporting different protocols. One of those protocols is NVMe in NVMe over Fabrics (NVMeoF) using TCP and underlying Ethernet-based networks for accessing fast Solid State Devices (SSDs).

Chelsio Communications T6 TOE for NVMeoF

An example of server storage I/O network TOEs, including those to support NVMeoF, are those from Chelsio Communications, such as the T6 25/100Gb devices. Chelsio announced today server storage I/O benchmark proof points for TCP based NVMe over Fabric (NVMeoF) TOE accelerated performance. StorageIO had the opportunity to look at the performance-boosting ability and CPU savings benefit of the Chelsio T6 prior to todays announcement.

After reviewing and validating the Chelsio proof points, test methodology, and results, it is clear that the T6 TOE enabled solution boosts server storage I/O performance while reducing host server CPU usage. The Chelsio T6 solution combined with Storage Performance Development Kit (SPDK) software, provides local-like performance of network fabric distributed NVMe (using TCP based NVMeoF) attached SSD storage while reducing host server CPU consumption.

“Boosting application performance, efficiency, and effectiveness of server CPUs are key priorities for legacy and software defined datacenter environments,” said Greg Schulz, Sr. Analyst Server Storage. “The Chelsio NVMe over Fabrics 100GbE NVMe/TCP (TOE) demonstration provides solid proof of how high-performance NVMe SSDs can help datacenters boost performance and productivity, while getting the best return on investment of datacenter infrastructure assets, not to mention optimize cost-of-ownership at the same time. It’s like getting a three for one bonus value from your server CPUs, your network, and your application perform better, now that’s a trifecta!”

You can read more about the technical and business benefits of the Chelsio T6 TOE enabled solution along with associated proof points (benchmarks) in the PDF white paper found here and their Press Release here. Note that the best measure, benchmark, proof point, or test is your application and workload, so contact Chelsio to arrange an evaluation of the T6 using your workload, software, and platform.

Where to learn more

Learn more about TOE, server, compute, GPU, ASIC, FPGA, storage, I/O networking, TCP, data infrastructure and software defined and related topics, trends, techniques, tools via the following links:

Chelsio Communications T6 Performance Press Release (PDF)
Chelsio Communications T6 TOE White Paper (PDF)
NVMe Linux Driver and related info
Announcing Native NVMe in Windows Server 2025 (Microsoft Post)
Introducing the Windows NVMe-oF Initiator Preview in Windows Server Insiders Builds (Microsoft Post)
Its Time for NVMeoF to let iSCSI begin its slow retirement journey (blog post)
Application Data Value Characteristics Everything Is Not the Same
PACE your Infrastructure decision-making, it’s about application requirements
Data Infrastructure Server Storage I/O Tradecraft Trends
Data Infrastructure Overview, Its What’s Inside of Data Centers
Data Infrastructure Management (Insight and Strategies)
Hyper-V and Windows Server 2025 Enhancements

Additional learning experiences along with common questions (and answers), as well as tips can be found in Software Defined Data Infrastructure Essentials book.

Software Defined Data Infrastructure Essentials Book SDDC

What this all means

The large superscalar web services and other large environments leverage offload engines and specialized processing technologies (chips, ASICs, FPGAs, GPUs, adapters) to boost performance while reducing server compute costs or getting more value out of a given server platform. If it works for the large superscalars, it can also work for your environment or your software-defined platform.

The benefits are reducing the number and cost of your software-defined platform bill of materials (BoM). Another benefit is to free up server CPU cycles to run your storage or network or other software to get more performance and work done. Yet another benefit is the ability to further stretch your software license investments, getting more work done per software license unit.

Have a look at the Chelsio Communications T6 line of TOE for NVMeoF and other workloads to boost performance, reduce CPU usage and lower costs. See for yourself The TOE NVMeoF TCP Performance Line Boost Performance Reduce Costs benefit.

Ok, nuff said, for now.

Cheers GS

Greg Schulz – Microsoft MVP Cloud and Data Center Management, previous 10 time VMware vExpert. Author of Software Defined Data Infrastructure Essentials (CRC Press), Data Infrastructure Management (CRC Press), as well as Cloud and Virtual Data Storage Networking (CRC Press), The Green and Virtual Data Center (CRC Press), Resilient Storage Networks (Elsevier) and twitter @storageio. Courteous comments are welcome for consideration. First published on https://storageioblog.com any reproduction in whole, in part, with changes to content, without source attribution under title or without permission is forbidden.

All Comments, (C) and (TM) belong to their owners/posters, Other content (C) Copyright 2006-2026 Server StorageIO and UnlimitedIO. All Rights Reserved. StorageIO is a registered Trade Mark (TM) of Server StorageIO.

Kevin Closson discusses SLOB Server CPU I/O Database Performance benchmarks

Slilly Little Oracle Benchmark (SLOB) Database Server I/O Podcast

server storage I/O trends

In this Server StorageIO podcast episode, I am joined by @Kevinclosson who is an Oracle (along with other Databases) performance expert and creator of the Silly Little Oracle Benchmark (SLOB) tool. Not surprising our data infrastructure discussion involves server CPU, software, I/O, storage, performance, software, tools, best practices, fundamental tradecraft skills among other items.

server storage I/O performance

Kevin has been involved in database performance (and porting) optimization for decades which means CPU server, memory, I/O and storage issues, resources and tuning. Part of server, storage I/O a tuning is understanding the workloads, also the demands of software such as databases along with how they use CPU and its impact on resources. This means that somewhere in the technology stack, server CPUs are still needed, even in serverless environments.

We also discuss metrics, gaining insight to resources uses, what they mean including how CPU wait may be costing your lost productivity with overhead, as well as benchmarks, simulations, and related themes. Check out Kevins website www.kevinclosson.net to learn more about Oracle, Databases, SLOB, tools and other content. Listen to the podcast discussion here (42 minutes) as well as on iTunes.

Where to learn more

Learn more about Oracle, Database Performance, Benchmarking along with other tools via the following links:

What this all means and wrap-up

Check out my discussion here with Kevin Closson where you may have some Dejavu, or learn something new on server, storage I/O, database performance, software, benchmark workloads as well as much more. Also available on 

Ok, nuff said for now…

Cheers
Gs

Greg Schulz – Microsoft MVP Cloud and Data Center Management, VMware vExpert (and vSAN). Author of Software Defined Data Infrastructure Essentials (CRC Press), as well as Cloud and Virtual Data Storage Networking (CRC Press), The Green and Virtual Data Center (CRC Press), Resilient Storage Networks (Elsevier) and twitter @storageio.

All Comments, (C) and (TM) belong to their owners/posters, Other content (C) Copyright 2006-2023 Server StorageIO(R) and UnlimitedIO All Rights Reserved