3 ms·
No, you can simply have memory mapped ring buffers between processes and all of the stuff not required for the specific application cut away. You don't need to
by vardump 7y ago
No, you can simply have memory mapped ring buffers between processes and all of the stuff not required for the specific application cut away. You don't need to have any more context switches that way.
No need to have a traditional socket API while still being able to do access it from multiple applications.
I have no interest to create such beast, but I'd be truly shocked if it couldn't at least beat a generic kernel based stack.
It'll lose some performance compared to the single application approach, but there might still be a niche for this kind of way.
Sure, you'll need to copy memory, but the data should be almost always in L3 cache anyways.
- monocasa 7y agoOnce you're doing copies (in your example two copies!) it's game over.
- vardump 7y agoMy intention was however to only have one copy (other than initial DMA to (hopefully) directly L3 cache). Yeah, it hurts if it's 400 Gbps ethernet. L3 bandwidth is like 50-90 GB/s. X86 just doesn't have enough bandwidth even to the caches! Better have pretty high CPU frequency, as I think L3 gets faster in proportion (but not completely sure). 200 Gbps should be somewhat fine. Also pretty bad if the data travels over a QPI link... better have both processes in same NUMA region. And that ethernet PCI-e adapter... :-) Regardless, I do think it'd still work way faster than anything a reasonably general kernel stack could do. Might be a reasonable compromise when process & permission isolation is required.