Path: ...!weretis.net!feeder8.news.weretis.net!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:05:11 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <v3kt47$3vs3s$1@dont-email.me>
References: <v0s17o$2okf4$2@dont-email.me> <v327n3$1use$1@gal.iecc.com> <BM25O.40665$HBac.4762@fx15.iad> <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> <c7439653803f528f0f7d2b185431f373@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 03 Jun 2024 19:05:11 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="9d4b0d0d2bbc2f77954ebbfb6ef5a061";
	logging-data="4190332"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19jUA7Ha3kb08QDUpC0XVjB9U9jj78akKk="
User-Agent: XanaNews/1.21-f3fb89f (x86; Portable ISpell)
Cancel-Lock: sha1:qwIAnmLt1deqKCVcT2mW2LtanhI=
Bytes: 3495

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)