infiniband: ?

[Peter Somogyi]

Tridge,

On Saturday 18 November 2006 22:46, tridge at samba.org wrote:
> our epoll/select we would need a small hack to verbs to expose the
> channel->fd file descriptor so we can add it to the list of fd's that
> we watch.
>
That was my 1st proposal (not published), and then after Alexander B. exposed 
me the need of _real_ a socket-like interface (2nd) - at the cost of extra 
overhead to emulate it fully or almost fully - I accepted the 2nd approach.

1st) : having channel->fd (which is a read-fd, and it yet has to be filtered 
for the correct read event) public to your common event-handler 
(select/poll), + having a filter-function (e.g. "ibw_can_recv")

Pros: fast & direct + easier to implement (this layer)
Cons: hard to use + high risk of not handling _each_ event _in time_.
(You can see this if you rollback the wiki link below...)

2nd) : current http://wiki.samba.org/index.php/CTDB_Project_ibwrapper.
(I'm going to modify this to datagram-like right now rather than streams, 
sorry...)
It would have a need of a dedicated process for ib-specific event handling, 
communicating to other user processes via e.g. unix domain sockets (or 
better).

Pros: safer to handle ib-specific events
Cons: more time to implement:) + emulation overhead

Based on your responses I assume I shall rollback to my 1nd approach.

Q1: how do you imagine [TCP/IP-] connection buildup? AFAIK the common design 
is to dedicate 1 (forked) process for each connection (as samba works now).
I'd need a scenario for adding a node runtime as well.

Q2: can you provide guarantee that the main event loop won't be blocked or 
time consuming at all? (I can imagine this only by performing operations - 
with various exec time - in a different thread/process than the multiplex 
event loop).

That's why I've been curious where (and how) this layer is applied 
(dispatcher? smbd?).

Peter