> Is it possible that /sys/class/infiniband directory exist and it is
> empty ? In which cases ?
Do "modprobe ib_core" on a system with no hardware drivers loaded (or no
RDMA hardware installed)
I see, thanks for the explanation!
I'm afraid you'll have no choice, though, but to relay the message via the
local daemon. I know that creates a window of vulnerability, but it cannot
be helped.
Passing full contact info for all daemons to all procs would take us back a
few steps and cause a who
Ralph,
I want to implement a receiver based message log (called RADIC
architecture) that stores the log file in another node (than no stable
storage is necessary).
I developed a wrapper to PML that manage the messages and then store it
locally (or in a stable storage), but now I need to migr
On May 29, 2008, at 3:27 AM, Pavel Shamis (Pasha) wrote:
I got some more feedback from Roland off-list explaining that if /
sys/
class/infiniband does exist and is non-empty and /sys/class/
infiniband_verbs/abi_version does not exist, then this is
definitely a
case where we want to warn beca
There is no way to send a message to a daemon located on another node
without relaying it through the local daemon. The application procs have no
knowledge of the contact info for any daemon other than their own, so even
using the direct routed module would not work.
Can you provide some reason wh
Hi All,
If, inside a PML component I need to send a message to the ORTE daemon
located in other node, how can I do it?
It´s safe to create a thread to manage this communication independently
or Open MPI have any service to do it (like RML in ORTE environment)?
I saw a socket connection betw
I got some more feedback from Roland off-list explaining that if /sys/
class/infiniband does exist and is non-empty and /sys/class/
infiniband_verbs/abi_version does not exist, then this is definitely a
case where we want to warn because it implies that config is screwed
up -- RDMA devices
Hi Roland,
Roland Dreier wrote:
Stick in a separate library then?
I don't think we want the complexity in the kernel -- I personally would
argue against merging it upstream; and given that the userspace solution
is actually faster, it becomes pretty hard to justify.
Memory registration has al
