diff options
author | Olaf Kirch <okir@lst.de> | 2008-04-29 20:46:53 (GMT) |
---|---|---|
committer | Roland Dreier <rolandd@cisco.com> | 2008-04-29 20:46:53 (GMT) |
commit | bbdc2821db041fb07ffa52e4a0e1ebb5410790e9 (patch) | |
tree | 1a0757409c89c6236d9c0ffa1eb0f5a63faa2527 /drivers/infiniband | |
parent | d227fa7288adebe5ba37fa8e4a589c977d4e4a34 (diff) | |
download | linux-fsl-qoriq-bbdc2821db041fb07ffa52e4a0e1ebb5410790e9.tar.xz |
mlx4_core: Avoid recycling old FMR R_Keys too soon
When a FMR is unmapped, mlx4 resets the map count to 0, and clears the
upper part of the R_Key which is used as the sequence counter.
This poses a problem for RDS, which uses ib_fmr_unmap as a fence
operation. RDS assumes that after issuing an unmap, the old R_Keys
will be invalid for a "reasonable" period of time. For instance,
Oracle processes uses shared memory buffers allocated from a pool of
buffers. When a process dies, we want to reclaim these buffers -- but
we must make sure there are no pending RDMA operations to/from those
buffers. The only way to achieve that is by using unmap and sync the
TPT.
However, when the sequence count is reset on unmap, there is a high
likelihood that a new mapping will be given the same R_Key that was
issued a few milliseconds ago.
To prevent this, don't reset the sequence count when unmapping a FMR.
Signed-off-by: Olaf Kirch <olaf.kirch@oracle.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Diffstat (limited to 'drivers/infiniband')
0 files changed, 0 insertions, 0 deletions