[nanomsg] Re: why memcpy data to be sent?
- From: Matthew Hall <mhall@xxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 28 Oct 2014 22:18:08 -0700
> So, for example, if the parameter was set
> to RDMA, the function could create the message in a memory pinned down
> to a physical address. RDMA-enabled NIC can then copy such message to
> a remote machine directly without copies or even bothering the CPU.
>
> Martin
The tricky part: PF_RING doesn't do TX side. Intel DPDK has RX and TX. But
Intel DPDK is user-space stack and L2-only right now. So they want to put the
frame into a special spot where they mapped the PCI BAR region of the NIC so
the NIC can pick it up, TX it, mark it empty, and continue forward through the
BAR ring. Not sure about InfiniBand, and other such ${expensive_stuff}.
So using this method we'd be stuck teaching nanomsg how to talk with every
RDMA library that somebody might use. Which I was worried would give poor
nanomsg a dependency / complexity headache, when it shouldn't have to know
about these accelerations unless they are standardized accelerated syscalls
supported by hopefully >=1 kernel, like epoll()/kqueue() (not identical but
close enough to avoid overcomplexity for nanomsg).
Matthew.
Other related posts:
