Skip to contentSkip to conversation

rdma_reg_read()

DISCUSSION Steve Wise 2 participants 4 messages Nov 8, 2013 3 messages not in the archive InfiniBand

lore
Share & tools
lore

Steve Wise

author
#0 lore raw

Hey Sean:

static inline struct ibv_mr *
rdma_reg_read(struct rdma_cm_id *id, void *addr, size_t length)

{
        return ibv_reg_mr(id->pd, addr, length, IBV_ACCESS_LOCAL_WRITE |

IBV_ACCESS_REMOTE_READ);
}

Should this be used for the registering sink memory of an rdma read? If so, it won't work for iWARP, which requires REMOTE_WRITE for the sink. Should this code look at the transport type and set REMOTE_WRITE for iwarp transports?

Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
In reply to a message not in the archive
Quoted 11 lines

static inline struct ibv_mr *
rdma_reg_read(struct rdma_cm_id *id, void *addr, size_t length)

{
         return ibv_reg_mr(id->pd, addr, length, IBV_ACCESS_LOCAL_WRITE |

IBV_ACCESS_REMOTE_READ);
}

Should this be used for the registering sink memory of an rdma read? If so, it won't work for iWARP, which requires REMOTE_WRITE for the sink. Should this code look at the transport type and set REMOTE_WRITE for iwarp transports?

This is to register memory as the target of an RDMA read operation. I.e. the memory being read. Is that the same as your 'sink'? --
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#4 lore raw
In reply to a message not in the archive
Quoted 7 lines · Sean
Quoted 7 lines

static inline struct ibv_mr *
rdma_reg_read(struct rdma_cm_id *id, void *addr, size_t length)

{
          return ibv_reg_mr(id->pd, addr, length, IBV_ACCESS_LOCAL_WRITE |

IBV_ACCESS_REMOTE_READ);
}

Quoted 5 lines
Quoted 4 lines

Should this be used for the registering sink memory of an rdma read? If so, it won't work for iWARP, which requires REMOTE_WRITE for the sink. Should this code look at the transport type and set REMOTE_WRITE for iwarp transports?

This is to register memory as the target of an RDMA read operation. I.e. the memory being read. Is that the same as your 'sink'?

No, I would call that the 'source' of the read. Basically the mr to-which the read data is placed needs REMOTE_WRITE for iWARP.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#6 lore raw
In reply to a message not in the archive
Quoted 13 lines · Sean
Quoted 4 lines
Quoted 4 lines

static inline struct ibv_mr *
rdma_reg_read(struct rdma_cm_id *id, void *addr, size_t length)

{
          return ibv_reg_mr(id->pd, addr, length, IBV_ACCESS_LOCAL_WRITE

|

Quoted 7 lines
Quoted 7 lines

IBV_ACCESS_REMOTE_READ);
}

Should this be used for the registering sink memory of an rdma read? If so, it won't work for iWARP, which requires REMOTE_WRITE for the sink. Should this code look at the transport type and set REMOTE_WRITE for iwarp transports?

Quoted 5 lines
Quoted 1 line

This is to register memory as the target of an RDMA read operation. I.e.

the memory being read. Is that the same as your 'sink'?

No, I would call that the 'source' of the read. Basically the mr
to-which the read data is placed needs REMOTE_WRITE for iWARP.

Then I think that maps to the rdma_reg_write() call.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html