Having the OS support sounds expensive from a Performance POV. Like network in -> network out needing to pass through an OS sounds slow... then again, the network sockets are serviced by the OS so it's probably ok (no need to fault to kernel mode).

Responding to the comment above, the solutions described in the slide don't seem to be hindered by transitions into or out of the kernel. If a userspace application wants to perform IO on a device, there will be a system call (barring some other mapping/access) anyway. The solutions involve configuring resources, in the case of marking non-cached pages, or performing some logic once already in the kernel, in the case of the flush. This example also emphasizes DMA, so the bulk of the transfer operation should not occupy the CPU or require the kernel's attention.

I think the main point, as indicated in the last bullet point, is that a hardware solution for coherence would be the most performant. However, any implementation of memory coherence adds complexity to the hardware, and given the gulf between device IO and inter-processor communication with regard to speed and frequency, achieving correct behavior by using existing hardware features is enough for software.