[9.191][ANSWERED] Will 9.2 take advantage of Intel QuickAssist technology

Hardware Acceleration has it's place. That said, the amount of excess CPU and RAM capacity on modern systems often times allows the system to implement a feature in software and still be ahead of the hardware by a decent margin.

Case in point being the Linux MD RAID system. I don't have hard numbers from my own systems to back this up but where I've implemented md raid in custom built storage servers, I've been able to get better performance numbers with md raid then with purpose built raid cards. When you get down to comparing the specs, the typical H/W raid controllers I see have some sort of ARM based accelerator card and up to 1GB cache, 512MB being more common. Compare that to a quad core Xeon with 8GB RAM. There I can dedicate as much cache as I want, making the responsiveness faster, and while the disk themselves aren't any faster, the raid computations usually end up on an unused core so beat the pant's off the little 800MHz ARM. [:)]

That depends on the raid level..the card...and the workload.  For anything other than raid 5 or 6 I agree and highly utilize md(linux) or dynamic disks in windows.  For md ill use it up to raid 01 or 10.  Anything that uses raid 5 or 6 or any variant the dedicated asic on a good card(3ware or areca only) will run circles around soft raid.

Hardware Acceleration has it's place. That said, the amount of excess CPU and RAM capacity on modern systems often times allows the system to implement a feature in software and still be ahead of the hardware by a decent margin.

Case in point being the Linux MD RAID system. I don't have hard numbers from my own systems to back this up but where I've implemented md raid in custom built storage servers, I've been able to get better performance numbers with md raid then with purpose built raid cards. When you get down to comparing the specs, the typical H/W raid controllers I see have some sort of ARM based accelerator card and up to 1GB cache, 512MB being more common. Compare that to a quad core Xeon with 8GB RAM. There I can dedicate as much cache as I want, making the responsiveness faster, and while the disk themselves aren't any faster, the raid computations usually end up on an unused core so beat the pant's off the little 800MHz ARM. [:)]

That depends on the raid level..the card...and the workload.  For anything other than raid 5 or 6 I agree and highly utilize md(linux) or dynamic disks in windows.  For md ill use it up to raid 01 or 10.  Anything that uses raid 5 or 6 or any variant the dedicated asic on a good card(3ware or areca only) will run circles around soft raid.

Anything that uses raid 5 or 6 or any variant the dedicated asic on a good card(3ware or areca only) will run circles around soft raid.

Agree to disagree.[:)]

I should have been more specific as I was referring to RAID 5 & 6, and basing my opinion of more recent versions of md & the linux kernel. Any raid level that combines mirroring and/or striping (RAID 0, 1, 10) does minimal calculations for RAID. It's when you have to start figuring out parity that things begin to get interesting.

I've followed the md RAID email list over nearly the past decade and what I keep seeing in performance test's posted to the list is that with a decent CPU, decent amount of RAM available, and properly setup, the performance figures from i/o workload simulators (like iometer, bonnie, etc among others) show that md raid can outperform the hardware RAID controllers from most if not all vendors.

The conclusion consistently being drawn is that properly setup, md RAID, by virtue of access to spare CPU cycles on server class hardware, and wads of cache (typically in excess of 2GB) can keep enough data moving to compete with the likes of 3ware & Acreca. 

There is however one major benefit to hardware RAID cards which software raid can never match, and that is bootability. Doesn't matter what the raid level is on disk, if the volume is presented as a bootable volume, you can boot from it.

Intel® QuickAssist Technology to accelerate cryptographic workloads via direct access or via open source frameworks would be nice to see being utilized in the Sophos UTM products. [:)]

The integrated hardware acceleration includes support for
Ciphers: AES, DES/3DES, Kasumi, RC4, Snow3G;
Authentication: MD5, SHA1, SHA2, AES-XCBC;
Public Key: Diffie-Hellman, RSA, DSA, ECC

The integrated hardware acceleration includes support for
Ciphers: AES, DES/3DES, Kasumi, RC4, Snow3G;
Authentication: MD5, SHA1, SHA2, AES-XCBC;
Public Key: Diffie-Hellman, RSA, DSA, ECC

Hi,

If OpenSSL, OpenVPN, et al add support for QuickAssist, then it will make it's way into the UTM when Sophos updates those components.

However, the UTM already uses AES-NI for AES VPNs, so I'm not sure how much more QuickAssist is going to help.

AES-NI is in many current CPUs; QuickAssist appears to be extremely rare at the moment.

What something like QuickAssist would be most useful for is accelerating the IPS's rule trees, as the IPS is very CPU-heavy.

Googling for "Suricata quickassist" and "Snort quickassist" DOES show that both IPS's have already added support.
This is very good.

Now, we just need more CPUs with QuickAssist, and for the UTM to turn it on in Snort if it's not enabled already.

Barry