Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.arch
Subject: Re: DMA is obsolete
Date: Thu, 1 May 2025 13:07:07 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vuvrlr$att$1@reader1.panix.com>
References: <vuj131$fnu$1@gal.iecc.com> <CJ8PP.2629170$eNx6.1327988@fx14.iad> <da5b3dea460370fc1fe8ad2323da9bc4@www.novabbs.org>
Injection-Date: Thu, 1 May 2025 13:07:07 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="11197"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)

In article <da5b3dea460370fc1fe8ad2323da9bc4@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:
>On Sat, 26 Apr 2025 17:29:06 +0000, Scott Lurndal wrote:
>[snip]
>Reminds me of trying to sell a micro x86-64 to AMD as a project.
>The µ86 is a small x86-64 core made available as IP in Verilog
>where it has/runs the same ISA as main GBOoO x86, but is placed
>"out in the PCIe" interconnect--performing I/O services topo-
>logically adjacent to the device itself. This allows 1ns access
>latencies to DCRs and performing OS queueing of DPCs,... without
>bothering the GBOoO cores.
>
>AMD didn't buy the arguments.

I can see it either way; I suppose the argument as to whether I
buy it or not comes down to, "in depends".  How much control do
I, as the OS implementer, have over this core?

If it is yet another hidden core embedded somewhere deep in the
SoC complex and I can't easily interact with it from the OS,
then no thanks: we've got enough of those between MP0, MP1, MP5,
etc, etc.

On the other hand, if it's got a "normal" APIC ID, the OS has
control over it like any other LP, and its coherent with the big
cores, then yeah, sign me up: I've been wanting something like
that for a long time now.

Consider a virtualization application.  A problem with, say,
SR-IOV is that very often the hypervisor wants to interpose some
sort of administrative policy between the virtual function and
whatever it actually corresponds to, but get out of the fast
path for most IO.  This implies a kind of offload architecture
where there's some (presumably software) agent dedicated to
handling IO that can be parameterized with such a policy.  A
core very close to the device could handle that swimmingly,
though I'm not sure it would be enough to do it at (say) line
rate for a 400Gbps NIC or Gen5 NVMe device.

....but why x86_64?  It strikes me that as long as the _data_
formats vis the software-visible ABI are the same, it doesn't
need to use the same ISA.  In fact, I can see advantages to not
doing so.

	- Dan C.