3 ms·

How do you thinking they should appear? It's interesting to compare to embedded processors without a memory management unit, like this STM32 reference manual,

How do you thinking they should appear? It's interesting to compare to embedded processors without a memory management unit, like this STM32 reference manual, see p.68 and following: https://www.st.com/resource/en/reference_manual/dm00124865-stm32f75xxx-and-stm32f74xxx-advanced-armbased-32bit-mcus-stmicroelectronics.pdf https://www.st.com/resource/en/reference_manual/dm00124865-s... Everything looks like a memory address. Note that it's not actually memory, the processor just diverts requests for that address to the peripheral instead of memory. But on that little ARM processor, if you want to write to actual RAM, that's memory addresses 0x2001 0000 to 0x2001 BFFF. Data in the onboard Flash memory is at 0x0020 0000 - 0x002F FFFF. If you want to talk to something on a serial port, write to registers from 0x4001 1000 - 0x4001 13FF. If you want to show something on an attached LCD, or pull a buffer from the USB or Ethernet peripherals, or work with GPIO, or do anything at all, really, it's at some memory offset. This chip has some DMA, you can set it up to automatically push from one peripheral memory space to actual RAM or vice versa. But everything happens at a region of memory.

superjan 5y ago
I imagine that you have regions of normal RAM reserved for Peripheral IO, and that the peripheral directly copies it’s data to or from that region using DMA. For the CPU and the driver developer, this means there is no special handling required of these ranges of memory. If the PCIe bus is slow, the CPU is not slowed down because the transfer can be async. This is perhaps the DMA scenario you describe in the last two lines, my thinking is that it would make sense to do this all the time, at least when transfers are large.
- toast0 5y ago
  You need more than just a shared area to put the data, which main memory, with DMA for devices to access works great for, you also need a way to coordinate on what data is ready to send or ready to receive. That could be in main memory and polled, but it usually makes sense to signal the device directly that something is ready to be sent so the device isn't constantly issuing reads to the memory to poll. For the device to signal the host, you'd generally raise an interrupt somehow, and then the host would ask the device what was ready. Usually you want that host to device communication to be direct, and memory mapping the i/o is a straightforward way to do that. (Using DMA to store/retreive the data also means the device doesn't need a whole lot of buffer space: enough to store a packet to be sent and maybe two packets to receive assuming you'll have time to DMA the first before the second is done, if the bus may be more congested, you'll need more a bigger receive buffer.

superjan 5y ago

I imagine that you have regions of normal RAM reserved for Peripheral IO, and that the peripheral directly copies it’s data to or from that region using DMA. For the CPU and the driver developer, this means there is no special handling required of these ranges of memory. If the PCIe bus is slow, the CPU is not slowed down because the transfer can be async. This is perhaps the DMA scenario you describe in the last two lines, my thinking is that it would make sense to do this all the time, at least when transfers are large.

toast0 5y ago
You need more than just a shared area to put the data, which main memory, with DMA for devices to access works great for, you also need a way to coordinate on what data is ready to send or ready to receive. That could be in main memory and polled, but it usually makes sense to signal the device directly that something is ready to be sent so the device isn't constantly issuing reads to the memory to poll. For the device to signal the host, you'd generally raise an interrupt somehow, and then the host would ask the device what was ready. Usually you want that host to device communication to be direct, and memory mapping the i/o is a straightforward way to do that. (Using DMA to store/retreive the data also means the device doesn't need a whole lot of buffer space: enough to store a packet to be sent and maybe two packets to receive assuming you'll have time to DMA the first before the second is done, if the bus may be more congested, you'll need more a bigger receive buffer.