Sean,
I didn't bring it up on the call because I wanted to check on a couple of
semantics, but I think you could just use a single
"socket(AF_UNIX,SOCK_DGRAM,0)" socket per endpoint RX context. This should
scale -- it doesn't blow up as O(P^2) like RC QPs / SOCK_STREAM sockets / named
pipes would. You could expose that UNIX domain socket fd directly to the
libfabric application or you could shove it into an epoll set and then the app
would be given the epoll instance's FD.
The SOCK_DGRAM should be reliable [1], preserve message boundaries, and
maintain ordering.
There's some question about what the right naming scheme for the sun_path value
should be. Perhaps "/tmp/libfabric/${PID}/rx_ctx${N}" would be a reasonable
starting point? If on Linux we could use the abstract socket namespace through
sticking '\0' in sun_path[0], which should help with cleanup issues.
-Dave
[1] http://man7.org/linux/man-pages/man7/unix.7.html
_______________________________________________
ofiwg mailing list
[email protected]
http://lists.openfabrics.org/mailman/listinfo/ofiwg
