Intel hardware accelerators sit on the PCIe bus, and burn just as much memory bandwidth as software encryption. The dataflow is basically:

  - disk DMA writes page from disk into DRAM
  - CPU (or PCIe crypto accel DMA) reads page from DRAM
  - CPU (or PCIe crypto accel DMA) writes encrypted page to DRAM
  - NIC DMA reads encrypted page from DRAM

Nothing changes from a memory bandwidth standpoint if its the CPU or a PCIE device doing those middle 2 steps. With "NIC TLS" (eg, inline hardware TLS) accelerators that sit on the NIC, those 2 middle steps can be eliminated, and condensed to the pre-crypto dataflow

   - disk DMA writes page from disk to DRAM
   - NIC DMA reads page from DRAM to NIC

That's wonderful, I and wish we had those things years ago.

Back then it was a realm of custom FPGA setups with very few niches like digital TV broadcasting, or expensive VPN appliances.

Ideally, I would've liked it a lot if the NIC could've spoken directly with the raid card or NVME using PCIE P2P... dreaming too big

How much are the accelerators? something tells me more expensive than delivering comparable throughput, highly flexible off the shelf x86 hardware.

Back in 2013, Intel 8920 did cost $750 wholesale, and similar Broadcom card a little bit cheaper.

Looks a lot now, but back then you didn't have server CPUs with gazillion cores on the cheap.

It was also about getting more bandwidth to a single server. 20Gb/s was a practical limit per mainstream server, but with accelerators you could've multiplied it many times more than the fastest CPU on the market.

> Looks a lot now, but back then you didn't have server CPUs with gazillion cores on the cheap.

You also didn't have the AES instruction set to improve the SSL performance.

You're also not tied to any particular vendor with a pure software approach.

Realistically with something well-defined like TLS you use a library that supports pure software or hardware acceleration. Then you can use acceleration without any lock-in.