Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: Byte Addressability And Beyond
Date: Mon, 3 Jun 2024 17:15:34 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 90
Message-ID: <v3ktnl$3vv86$1@dont-email.me>
References: <v0s17o$2okf4$2@dont-email.me> <v32lpv$1u25$1@gal.iecc.com> <v33bqg$9cst$11@dont-email.me> <v34v62$ln01$1@dont-email.me> <v36bva$10k3v$2@dont-email.me> <2024May29.090435@mips.complang.tuwien.ac.at> <v38opv$1gsj2$3@dont-email.me> <v38rkd$1ha8a$1@dont-email.me> <jwvttifrysb.fsf-monnier+comp.arch@gnu.org> <f90b6e03c727b0f209d64484ec097298@www.novabbs.org> <v3jtd8$3qduu$2@dont-email.me> <20240603132227.00004e0f@yahoo.com> <k6k7O.8602$7jpd.5620@fx47.iad> <v3klhp$3ugeh$1@dont-email.me> <wnl7O.10195$Inzb.2858@fx13.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 03 Jun 2024 19:15:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9d4b0d0d2bbc2f77954ebbfb6ef5a061";
	logging-data="4193542"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+oBp04xnbe/T0XDQQkIPfB/hNwhnC/R8M="
User-Agent: XanaNews/1.21-f3fb89f (x86; Portable ISpell)
Cancel-Lock: sha1:v+TORHYiP/I95avl1zAIT4wgfHI=
Bytes: 5060

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)