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" 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: References: <2024May29.090435@mips.complang.tuwien.ac.at> <20240603132227.00004e0f@yahoo.com> 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 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)