What is the difference between the D-1540, D-1541, and D-1548? Let's ignore the 100 MHz the 1541 has, and the SR-IOV issues with the 1540. I've read the front page posts and see that 1541 is a storage accelerated part, and the 1548 is a network accelerated part, but I'm still fuzzy on what that means. They have support for SPDK and DPDK, respectively, but those look like software SDKs. Is there specific hardware on-chip that only those SKUs have? Do they pass through to virtualized guests? What is the software support for those SDKs in the real world? What features in what form would I have to be using to take advantage of them?
For example, the storage slide lists "data protection" with what looks like a parity calculation. What filesystem drivers would make use of this? Would it need to be an linux MD array, or could it be something like zfs/btrfs? I'm currently using the latter in RAID10 (or whatever they're calling it) until RAID6 support firms up, which could maybe use faster parity. The filesystems do checksumming, too, so does that fall under the listed "data integrity" category? Or since I'm not using SSDs for my storage array, none of those things matter, since the hardware will always be the bottleneck and I shouldn't spend any extra money on these storage accelerators?
The network accelerated parts support SSL, so faster HTTPS and OpenVPN connections through the OpenSSL library. If I wanted to use something like IPSEC instead, does that get no speedup? Does it depend on the particular library I'm using? How much hardware is needed for a full gigabit of encrypted throughput? Ten gigabits? I'm one of those lucky Chattanooga residents, so these are not theoretical someday maybe connection possibilities, they're a mere phone call away.
My concern is because I'm thinking about this in terms of devices like the Netgear R7000 router. Running stock firmware, IPv4 NAT throughput is something like 450 Mbps. Running DD-WRT, throughput drops to 360 Mbps, because the stock firmware was offloading to a NAT co-processor, but its interface isn't documented so the open source firmware can't use it. I feel like all these accelerator SDK abilities could just be lost and useless if the major software packages we all want to use don't support it for whatever reason. When CPUs get new instructions, there's a lag time before implementation, and if the CPUs with the new instructions don't sell in sufficient volume, they may never get supported. If there are specific hardware features required for SPDK/DPDK support, will they sell in enough volume for developers to bother?
For example, the storage slide lists "data protection" with what looks like a parity calculation. What filesystem drivers would make use of this? Would it need to be an linux MD array, or could it be something like zfs/btrfs? I'm currently using the latter in RAID10 (or whatever they're calling it) until RAID6 support firms up, which could maybe use faster parity. The filesystems do checksumming, too, so does that fall under the listed "data integrity" category? Or since I'm not using SSDs for my storage array, none of those things matter, since the hardware will always be the bottleneck and I shouldn't spend any extra money on these storage accelerators?
The network accelerated parts support SSL, so faster HTTPS and OpenVPN connections through the OpenSSL library. If I wanted to use something like IPSEC instead, does that get no speedup? Does it depend on the particular library I'm using? How much hardware is needed for a full gigabit of encrypted throughput? Ten gigabits? I'm one of those lucky Chattanooga residents, so these are not theoretical someday maybe connection possibilities, they're a mere phone call away.
My concern is because I'm thinking about this in terms of devices like the Netgear R7000 router. Running stock firmware, IPv4 NAT throughput is something like 450 Mbps. Running DD-WRT, throughput drops to 360 Mbps, because the stock firmware was offloading to a NAT co-processor, but its interface isn't documented so the open source firmware can't use it. I feel like all these accelerator SDK abilities could just be lost and useless if the major software packages we all want to use don't support it for whatever reason. When CPUs get new instructions, there's a lag time before implementation, and if the CPUs with the new instructions don't sell in sufficient volume, they may never get supported. If there are specific hardware features required for SPDK/DPDK support, will they sell in enough volume for developers to bother?
