RDMA offers that. The NIC can directly access user space buffers. It does require that the buffers are “registered” first but applications usually aim to do that once up front.
Maybe a dumb question but how do non x86 boards normally boot Linux images in a generic way? When I was in the embedded space, our boards all relied on very specific device tree blobs. Is the same strategy used for these or does it use ACPI or something?
My favorite is my Bosh wall oven that uses 85C rated capacitors with practically no voltage derating for the control board that sits directly at the top of the oven. After 4 years, they gave out causing the display to dim to the point of invisibility.
We’re talking about 50 cents of part savings on a $3000+ appliance here.
Replaced them myself easily, but most people will end up having to call for service and end up replacing the entire board for hundreds of dollars minimum.
It normally works in conjunction with GCC’s “-MMD -MP” arguments which provide .d files which then get included back into the Makefile with something like “-include $(OBJS:%.o=%.d)”.
It doesn’t directly interpret any source file though, if that’s what you mean.
Another annoyance for me is when trying to move the cursor to the end of a long text box like the URL bar in Safari. You basically have to keep using the “hold space bar” method and swiping one inch at a time. I’m sure there’s a better way to do this but I haven’t found it yet.
PCIe busses are like a tree with “hubs” (really switches).
Imagine you have a PC with a PCIe x16 interface which is attached to a PCIe switch that has four x16 downstream ports, each attached to a GPU. Those GPUs are capable of moving data in and out of their PCIe interfaces at full speed.
If you wanted to transfer data from GPU0 and 1 to GPU2 and 3, you have basically 2 options:
- Have GPU0 and 1 move their data to CPU DRAM, then have GPU2 and 3 fetch it
- Have GPU0 and 1 write their data directly to GPU2 and 3 through the switch they’re connected to without ever going up to the CPU at all
In this case, option 2 is better both because it avoids the extra copy to CPU DRAM and also because it avoids the bottleneck of two GPUs trying to push x16 worth of data up through the CPUs single x16 port. This is known as peer to peer.
There are some other scenarios where the data still must go up to the CPU port and back due to ACS, and this is still technically P2P, but doesn’t avoid the bottleneck like routing through the switch would.
Do you have any more info on this KVM back end for Virtualbox? I love Virtualbox (I know, I know) but the one annoying thing is the dependency on out of tree kernel modules (at least they’re open source though).