bbdc2821db
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> |
||
|---|---|---|
| .. | ||
| alloc.c | ||
| catas.c | ||
| cmd.c | ||
| cq.c | ||
| eq.c | ||
| fw.c | ||
| fw.h | ||
| icm.c | ||
| icm.h | ||
| intf.c | ||
| main.c | ||
| Makefile | ||
| mcg.c | ||
| mlx4.h | ||
| mr.c | ||
| pd.c | ||
| profile.c | ||
| qp.c | ||
| reset.c | ||
| srq.c | ||