Re: Byte Addressability And Beyond

Scott Lurndal wrote:

"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:

Scott Lurndal wrote:
 

Michael S <already5chosen@yahoo.com> writes:

On Mon, 3 Jun 2024 08:03:53 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
 

On Thu, 30 May 2024 18:31:46 +0000, MitchAlsup1 wrote:
=20

30 years ago you could say the same thing about encryption.

=20 >> > > =20

I don=E2=80=99t think newer CPUs have been optimized for

encryption. Inst=

ead,

we see newer encryption algorithms (or ways of using them) that

work >> better on current CPUs.=20

 
I think moderate efficiency on CPU, not too low, but not high
either, is a requirement for (symmetric-key) cipher. Esp. when

the >> > key is 128-bit or shorter.

 
Most modern CPUs have instruction set support for symmetric ciphers
such as AES, SM2/SM3 as well as message digest/hash (SHA1, SHA256

et >> al).

 
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.

 
There are always tradeoffs.  The issues surrounding the
control/sequencing logic outside of the instruction flow
require some level of asynchronicity, so to avoid bottlenecks
one might need to replicate the "inbuilt accelerator" if
more than one core will be using encryption (e.g. for RSS
with IPSEC flows).

Yes, but putting the instructions into the core means you are
replicating the logic for every core.  If you don't tie the amount of
encryption hardeware you need to the number of cores, you can adjust it
to meet the needs independently of the amount of computation you need
(i.e. number of cores)

 
From the operating software standpoint, it becomes most
convenient, then, to model the offload as a device which
requires OS support (and intervention for e.g. interrupt
handling).

I look at it differently (and perhaps incorrectly).  I view encryption
as one of several "transformations" that data goes through in its path
to/from some external device.  For exqmple, if the external device is a
disk, the data from memory may be gathere from multiple locations, is
serialized, perhaps encoded (i.e. 8b10b), has (perhaps several levels)
of ECC added, etc.  Viewing it like that makes encryption one of many
steps along the I/O pipeline.  Under that view, Encryption is an
option, probably controllede by some bits in the I/O mechanism, not as
a separate device requiring interrupt support etc.

For network traffic, there are often other operations
being performed on the flow (routing, encapsulation,
fragmentation/reassembly, etc) which require  the packet to be in a
memory buffer (which could be high-speed SRAM or lower-speed DRAM),
even when just routing from an ingress port to an egress port.

Yes. In my view, encryption is just another of these operations.




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