5 ms·

Does anybody know what kind of performance a modern Nvidia card like this can provide for offloading SSL ciphers (aes gcm 128 or aes gcm 256)?

robert_foss 11y ago
There are data-dependencies in most AES modes (except ecb) which prevent parallelization. If you however run 2k separate AES encryption streams you could expect a nice performance increase. But for a single stream there is little performance to be had.
- drewg123 11y ago
  We run tens of thousands of streams in parallel.. So that's not a problem. :) I'm just realizing that GPUs could be a viable alternative to specialized (eg, expensive) encryption offload engines or very high end (eg, expensive) v4 Xeons with many, many cores. However, it is rather hard to find data on the bandwidth at which GPUs can process a given cipher. I'm just now starting to look into this, so I could very well be mis-understanding something,
  - paulmd 11y ago
    Throughput 100% depends on how hard they need to hit memory. GPUs love stuff that they can do entirely within registers. Having to hit (the limited quantity of) shared memory slows things down much more. Inefficient/non-coaslesced use of shared memory or global memory too often can trash performance. Hitting host/CPU memory in any non-trivial amount usually dooms a program. With each step you not just cut down your bandwidth but also you increase your latency and that has a huge impact.
    - serialx 11y ago
      Guys have a look at SSLShader[1] [1]: http://shader.kaist.edu/sslshader/ http://shader.kaist.edu/sslshader/
      - nwrk 11y ago
        Thanks!
- ryuuchin 11y ago
  What about a stream cipher like ChaCha20? Also would data-dependencies be different on a GPU than with parallelization on a CPU? Because modes like GCM (i.e. CTR) both the encryption and decryption are parallelizable (with CBC it's just decryption). I wonder if AMD GPU's would be better suited to the task than Nvidia's (at least their existing GPU's) provided you could actually saturate the GPU with enough work to make it worth it.
jhj 11y ago
Bit math (bfe.*, logical bit ops, ...) are nowhere near as fast as float32 ops on their GPUs by a factor of 2-4x; there are many fewer functional units for them. Maxwell doesn't have support for many 64-bit word bit ops as well (they get emulated in SASS using the operations that they do have; e.g. bfe bitfield extract), so you'd have to do it in uint32. Issue rate is in the CUDA documentation for Maxwell (cc 5.2) at least, presumably they'll update with Pascal soon: http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#arithmetic-instructions http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.h... Where they would win is in memory bandwidth for intermediate results (e.g., in/out of registers or smem or even global memory), assuming that you aren't ultimately bound by I/O over the bus from the CPU.

robert_foss 11y ago

There are data-dependencies in most AES modes (except ecb) which prevent parallelization. If you however run 2k separate AES encryption streams you could expect a nice performance increase. But for a single stream there is little performance to be had.

drewg123 11y ago
We run tens of thousands of streams in parallel.. So that's not a problem. :) I'm just realizing that GPUs could be a viable alternative to specialized (eg, expensive) encryption offload engines or very high end (eg, expensive) v4 Xeons with many, many cores. However, it is rather hard to find data on the bandwidth at which GPUs can process a given cipher. I'm just now starting to look into this, so I could very well be mis-understanding something,
- paulmd 11y ago
  Throughput 100% depends on how hard they need to hit memory. GPUs love stuff that they can do entirely within registers. Having to hit (the limited quantity of) shared memory slows things down much more. Inefficient/non-coaslesced use of shared memory or global memory too often can trash performance. Hitting host/CPU memory in any non-trivial amount usually dooms a program. With each step you not just cut down your bandwidth but also you increase your latency and that has a huge impact.
  - serialx 11y ago
    Guys have a look at SSLShader[1] [1]: http://shader.kaist.edu/sslshader/ http://shader.kaist.edu/sslshader/
    - nwrk 11y ago
      Thanks!
ryuuchin 11y ago
What about a stream cipher like ChaCha20? Also would data-dependencies be different on a GPU than with parallelization on a CPU? Because modes like GCM (i.e. CTR) both the encryption and decryption are parallelizable (with CBC it's just decryption). I wonder if AMD GPU's would be better suited to the task than Nvidia's (at least their existing GPU's) provided you could actually saturate the GPU with enough work to make it worth it.

jhj 11y ago

Bit math (bfe.*, logical bit ops, ...) are nowhere near as fast as float32 ops on their GPUs by a factor of 2-4x; there are many fewer functional units for them. Maxwell doesn't have support for many 64-bit word bit ops as well (they get emulated in SASS using the operations that they do have; e.g. bfe bitfield extract), so you'd have to do it in uint32. Issue rate is in the CUDA documentation for Maxwell (cc 5.2) at least, presumably they'll update with Pascal soon: http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#arithmetic-instructions http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.h... Where they would win is in memory bandwidth for intermediate results (e.g., in/out of registers or smem or even global memory), assuming that you aren't ultimately bound by I/O over the bus from the CPU.