Hefty, Sean wrote:
CM mads aren't reliable, however they are retried. If a CM REQ does not
receive a response after so many retries (usually 15), the REQ fails (status is
timeout). The mad layer reports the timeout to the cm module. With snooping
in place, a user will be notified that a
so the usage of mad snooping would be for cache invalidations, I wonder
if registering on GID/MGID IN/OUT traps be sufficient for the same purpose?
That requires registration with the SA. The intent is to avoid using a
centralized service when possible. Otherwise, we end up with all nodes
Hefty, Sean wrote:
That requires registration with the SA. The intent is to avoid using a
centralized service when possible.
yep, makes sense, look like this design finally went the decentralized way...
cool
Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the
Hefty, Sean wrote:
[...] an alternative goal f these patches is to allow ibacm and similar
applications to detect and react to SA and CM timeouts.
Hi Sean,
As far as I understand CM timeout is an event not a mad... when
referring to detecting/reacting on CM timeouts, did you mean detecting
As far as I understand CM timeout is an event not a mad... when
referring to detecting/reacting on CM timeouts, did you mean detecting
mads like CM retries and reacting on them?
CM timeout 'events' would be detected and reported as sent MADs that complete
in error. For ibacm, the only CM
This series ports the kernel madeye debug utility to
userspace. It depends on the kernel MAD snooping functionality
patches recently submitted to this list. The series
adds the following to the ib-mgmt tree:
* Adds the ability to snoop MADs to libibumad.
* Adds new header files to libibumad
