Re: Byte Addressability And Beyond

MitchAlsup1 wrote:

Stephen Fuld wrote:
 

Scott Lurndal wrote:

 

Michael S <already5chosen@yahoo.com> writes:

On Mon, 3 Jun 2024 08:03:53 -0000 (UTC)

 
 
High throughput encryption has been done by hardware accelerators
for decades now (e.g. bbn or ncypher HSM boxes sitting on a SCSI
bus; now such HSM are an integral part of many SoC).

 
 

Queston.  For a modern general purpose CPU, if you are including all
the logic to implement encryption instructions, is it much more to
include the control/sequencing logic to do it and not tie up the
rest of the CPU logic to do the encryption?  Furthermore, an
"inbuilt" accelerator could interface directly with the I/O
hardware of the CPU (e.g. PCI), saving the "intermediate" step of
writing the encrypted data to memory.

 
 
It is more of a systems issue than an ISA issue:: Consider a chip
with 100 cores, do you want all 100 cores to be doing encryption at
the same
 
time, or do you only need a certain BW of encryption rather equal to
the internet BW at hand. For the first instructions are a reasonable
starting point, for the second an I/O (or attached) processor is in
order.

I agree completely.  If all of the data to be en/decrypted is comming
from/going to an external device (network, storage device), then there
is no benefit to being able to encrypt at a faster rate than the total
I/O bandwidth.  I don't know what percentage of the data is destined
for external use, but my gut feel is that it is a lot, probably most,
possibly almost all.

If that is the case, then I think a good case can be made for putting
encryption somewhere within the I/O hardware, in order to avoid the
extra memory bandwidth and latency requirements of either instructions
or a "typical" attached processor.

--
 - Stephen Fuld
(e-mail address disguised to prevent spam)