2006-03-26 12:30:50 +04:00
|
|
|
/*
|
2007-09-24 14:11:52 +04:00
|
|
|
* Copyright (c) 2006-2007 Voltaire All rights reserved.
|
2006-03-26 12:30:50 +04:00
|
|
|
* $COPYRIGHT$
|
|
|
|
|
*
|
|
|
|
|
* Additional copyrights may follow
|
|
|
|
|
*
|
|
|
|
|
* $HEADER$
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef MCA_BTL_OPENIB_EAGER_RDMA_BUF_H
|
|
|
|
|
#define MCA_BTL_OPENIB_EAGER_RDMA_BUF_H
|
|
|
|
|
|
|
|
|
|
#include "ompi_config.h"
|
|
|
|
|
#include "btl_openib.h"
|
|
|
|
|
|
2009-08-20 15:42:18 +04:00
|
|
|
BEGIN_C_DECLS
|
2006-03-26 12:30:50 +04:00
|
|
|
|
|
|
|
|
struct mca_btl_openib_eager_rdma_local_t {
|
This commit brings in two major things:
1. Galen's fine-grain control of queue pair resources in the openib
BTL.
1. Pasha's new implementation of asychronous HCA event handling.
Pasha's new implementation doesn't take much explanation, but the new
"multifrag" stuff does.
Note that "svn merge" was not used to bring this new code from the
/tmp/ib_multifrag branch -- something Bad happened in the periodic
trunk pulls on that branch making an actual merge back to the trunk
effectively impossible (i.e., lots and lots of arbitrary conflicts and
artifical changes). :-(
== Fine-grain control of queue pair resources ==
Galen's fine-grain control of queue pair resources to the OpenIB BTL
(thanks to Gleb for fixing broken code and providing additional
functionality, Pasha for finding broken code, and Jeff for doing all
the svn work and regression testing).
Prior to this commit, the OpenIB BTL created two queue pairs: one for
eager size fragments and one for max send size fragments. When the
use of the shared receive queue (SRQ) was specified (via "-mca
btl_openib_use_srq 1"), these QPs would use a shared receive queue for
receive buffers instead of the default per-peer (PP) receive queues
and buffers. One consequence of this design is that receive buffer
utilization (the size of the data received as a percentage of the
receive buffer used for the data) was quite poor for a number of
applications.
The new design allows multiple QPs to be specified at runtime. Each
QP can be setup to use PP or SRQ receive buffers as well as giving
fine-grained control over receive buffer size, number of receive
buffers to post, when to replenish the receive queue (low water mark)
and for SRQ QPs, the number of outstanding sends can also be
specified. The following is an example of the syntax to describe QPs
to the OpenIB BTL using the new MCA parameter btl_openib_receive_queues:
{{{
-mca btl_openib_receive_queues \
"P,128,16,4;S,1024,256,128,32;S,4096,256,128,32;S,65536,256,128,32"
}}}
Each QP description is delimited by ";" (semicolon) with individual
fields of the QP description delimited by "," (comma). The above
example therefore describes 4 QPs.
The first QP is:
P,128,16,4
Meaning: per-peer receive buffer QPs are indicated by a starting field
of "P"; the first QP (shown above) is therefore a per-peer based QP.
The second field indicates the size of the receive buffer in bytes
(128 bytes). The third field indicates the number of receive buffers
to allocate to the QP (16). The fourth field indicates the low
watermark for receive buffers at which time the BTL will repost
receive buffers to the QP (4).
The second QP is:
S,1024,256,128,32
Shared receive queue based QPs are indicated by a starting field of
"S"; the second QP (shown above) is therefore a shared receive queue
based QP. The second, third and fourth fields are the same as in the
per-peer based QP. The fifth field is the number of outstanding sends
that are allowed at a given time on the QP (32). This provides a
"good enough" mechanism of flow control for some regular communication
patterns.
QPs MUST be specified in ascending receive buffer size order. This
requirement may be removed prior to 1.3 release.
This commit was SVN r15474.
2007-07-18 05:15:59 +04:00
|
|
|
ompi_ptr_t base; /**< buffer for RDMAing eager messages */
|
|
|
|
|
mca_btl_openib_recv_frag_t *frags;
|
|
|
|
|
mca_btl_openib_reg_t *reg;
|
|
|
|
|
uint16_t head; /**< RDMA buffer to poll */
|
2006-03-26 12:30:50 +04:00
|
|
|
uint16_t tail; /**< Needed for credit managment */
|
This commit brings in two major things:
1. Galen's fine-grain control of queue pair resources in the openib
BTL.
1. Pasha's new implementation of asychronous HCA event handling.
Pasha's new implementation doesn't take much explanation, but the new
"multifrag" stuff does.
Note that "svn merge" was not used to bring this new code from the
/tmp/ib_multifrag branch -- something Bad happened in the periodic
trunk pulls on that branch making an actual merge back to the trunk
effectively impossible (i.e., lots and lots of arbitrary conflicts and
artifical changes). :-(
== Fine-grain control of queue pair resources ==
Galen's fine-grain control of queue pair resources to the OpenIB BTL
(thanks to Gleb for fixing broken code and providing additional
functionality, Pasha for finding broken code, and Jeff for doing all
the svn work and regression testing).
Prior to this commit, the OpenIB BTL created two queue pairs: one for
eager size fragments and one for max send size fragments. When the
use of the shared receive queue (SRQ) was specified (via "-mca
btl_openib_use_srq 1"), these QPs would use a shared receive queue for
receive buffers instead of the default per-peer (PP) receive queues
and buffers. One consequence of this design is that receive buffer
utilization (the size of the data received as a percentage of the
receive buffer used for the data) was quite poor for a number of
applications.
The new design allows multiple QPs to be specified at runtime. Each
QP can be setup to use PP or SRQ receive buffers as well as giving
fine-grained control over receive buffer size, number of receive
buffers to post, when to replenish the receive queue (low water mark)
and for SRQ QPs, the number of outstanding sends can also be
specified. The following is an example of the syntax to describe QPs
to the OpenIB BTL using the new MCA parameter btl_openib_receive_queues:
{{{
-mca btl_openib_receive_queues \
"P,128,16,4;S,1024,256,128,32;S,4096,256,128,32;S,65536,256,128,32"
}}}
Each QP description is delimited by ";" (semicolon) with individual
fields of the QP description delimited by "," (comma). The above
example therefore describes 4 QPs.
The first QP is:
P,128,16,4
Meaning: per-peer receive buffer QPs are indicated by a starting field
of "P"; the first QP (shown above) is therefore a per-peer based QP.
The second field indicates the size of the receive buffer in bytes
(128 bytes). The third field indicates the number of receive buffers
to allocate to the QP (16). The fourth field indicates the low
watermark for receive buffers at which time the BTL will repost
receive buffers to the QP (4).
The second QP is:
S,1024,256,128,32
Shared receive queue based QPs are indicated by a starting field of
"S"; the second QP (shown above) is therefore a shared receive queue
based QP. The second, third and fourth fields are the same as in the
per-peer based QP. The fifth field is the number of outstanding sends
that are allowed at a given time on the QP (32). This provides a
"good enough" mechanism of flow control for some regular communication
patterns.
QPs MUST be specified in ascending receive buffer size order. This
requirement may be removed prior to 1.3 release.
This commit was SVN r15474.
2007-07-18 05:15:59 +04:00
|
|
|
int32_t credits; /**< number of RDMA credits */
|
|
|
|
|
int32_t rd_win;
|
2009-05-07 00:11:28 +04:00
|
|
|
#if OPAL_ENABLE_DEBUG
|
2006-03-26 12:30:50 +04:00
|
|
|
uint32_t seq;
|
|
|
|
|
#endif
|
This commit brings in two major things:
1. Galen's fine-grain control of queue pair resources in the openib
BTL.
1. Pasha's new implementation of asychronous HCA event handling.
Pasha's new implementation doesn't take much explanation, but the new
"multifrag" stuff does.
Note that "svn merge" was not used to bring this new code from the
/tmp/ib_multifrag branch -- something Bad happened in the periodic
trunk pulls on that branch making an actual merge back to the trunk
effectively impossible (i.e., lots and lots of arbitrary conflicts and
artifical changes). :-(
== Fine-grain control of queue pair resources ==
Galen's fine-grain control of queue pair resources to the OpenIB BTL
(thanks to Gleb for fixing broken code and providing additional
functionality, Pasha for finding broken code, and Jeff for doing all
the svn work and regression testing).
Prior to this commit, the OpenIB BTL created two queue pairs: one for
eager size fragments and one for max send size fragments. When the
use of the shared receive queue (SRQ) was specified (via "-mca
btl_openib_use_srq 1"), these QPs would use a shared receive queue for
receive buffers instead of the default per-peer (PP) receive queues
and buffers. One consequence of this design is that receive buffer
utilization (the size of the data received as a percentage of the
receive buffer used for the data) was quite poor for a number of
applications.
The new design allows multiple QPs to be specified at runtime. Each
QP can be setup to use PP or SRQ receive buffers as well as giving
fine-grained control over receive buffer size, number of receive
buffers to post, when to replenish the receive queue (low water mark)
and for SRQ QPs, the number of outstanding sends can also be
specified. The following is an example of the syntax to describe QPs
to the OpenIB BTL using the new MCA parameter btl_openib_receive_queues:
{{{
-mca btl_openib_receive_queues \
"P,128,16,4;S,1024,256,128,32;S,4096,256,128,32;S,65536,256,128,32"
}}}
Each QP description is delimited by ";" (semicolon) with individual
fields of the QP description delimited by "," (comma). The above
example therefore describes 4 QPs.
The first QP is:
P,128,16,4
Meaning: per-peer receive buffer QPs are indicated by a starting field
of "P"; the first QP (shown above) is therefore a per-peer based QP.
The second field indicates the size of the receive buffer in bytes
(128 bytes). The third field indicates the number of receive buffers
to allocate to the QP (16). The fourth field indicates the low
watermark for receive buffers at which time the BTL will repost
receive buffers to the QP (4).
The second QP is:
S,1024,256,128,32
Shared receive queue based QPs are indicated by a starting field of
"S"; the second QP (shown above) is therefore a shared receive queue
based QP. The second, third and fourth fields are the same as in the
per-peer based QP. The fifth field is the number of outstanding sends
that are allowed at a given time on the QP (32). This provides a
"good enough" mechanism of flow control for some regular communication
patterns.
QPs MUST be specified in ascending receive buffer size order. This
requirement may be removed prior to 1.3 release.
This commit was SVN r15474.
2007-07-18 05:15:59 +04:00
|
|
|
opal_mutex_t lock; /**< guard access to RDMA buffer */
|
|
|
|
|
int32_t rd_low;
|
2006-03-26 12:30:50 +04:00
|
|
|
};
|
|
|
|
|
typedef struct mca_btl_openib_eager_rdma_local_t mca_btl_openib_eager_rdma_local_t;
|
|
|
|
|
|
|
|
|
|
struct mca_btl_openib_eager_rdma_remote_t {
|
|
|
|
|
ompi_ptr_t base; /**< address of remote buffer */
|
2006-05-25 15:05:12 +04:00
|
|
|
uint32_t rkey; /**< RKey for accessing remote buffer */
|
2007-08-27 15:37:01 +04:00
|
|
|
int32_t head; /**< RDMA buffer to post to */
|
2006-03-26 12:30:50 +04:00
|
|
|
int32_t tokens; /**< number of rdam tokens */
|
2009-05-07 00:11:28 +04:00
|
|
|
#if OPAL_ENABLE_DEBUG
|
2006-03-26 12:30:50 +04:00
|
|
|
uint32_t seq;
|
|
|
|
|
#endif
|
|
|
|
|
};
|
|
|
|
|
typedef struct mca_btl_openib_eager_rdma_remote_t mca_btl_openib_eager_rdma_remote_t;
|
|
|
|
|
|
2006-03-30 19:26:21 +04:00
|
|
|
#define MCA_BTL_OPENIB_RDMA_FRAG(F) \
|
2007-11-28 10:11:14 +03:00
|
|
|
(openib_frag_type(F) == MCA_BTL_OPENIB_FRAG_EAGER_RDMA)
|
2006-03-26 12:30:50 +04:00
|
|
|
|
|
|
|
|
#define EAGER_RDMA_BUFFER_REMOTE (0)
|
|
|
|
|
#define EAGER_RDMA_BUFFER_LOCAL (0xff)
|
|
|
|
|
|
|
|
|
|
#ifdef WORDS_BIGENDIAN
|
|
|
|
|
#define MCA_BTL_OPENIB_RDMA_FRAG_GET_SIZE(F) ((F)->u.size >> 8)
|
|
|
|
|
#define MCA_BTL_OPENIB_RDMA_FRAG_SET_SIZE(F, S) \
|
|
|
|
|
((F)->u.size = (S) << 8)
|
|
|
|
|
#else
|
|
|
|
|
#define MCA_BTL_OPENIB_RDMA_FRAG_GET_SIZE(F) ((F)->u.size & 0x00ffffff)
|
|
|
|
|
#define MCA_BTL_OPENIB_RDMA_FRAG_SET_SIZE(F, S) \
|
|
|
|
|
((F)->u.size = (S) & 0x00ffffff)
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#define MCA_BTL_OPENIB_RDMA_FRAG_LOCAL(F) \
|
|
|
|
|
(((volatile uint8_t*)(F)->ftr->u.buf)[3] != EAGER_RDMA_BUFFER_REMOTE)
|
|
|
|
|
|
|
|
|
|
#define MCA_BTL_OPENIB_RDMA_FRAG_REMOTE(F) \
|
|
|
|
|
(!MCA_BTL_OPENIB_RDMA_FRAG_LOCAL(F))
|
|
|
|
|
|
|
|
|
|
#define MCA_BTL_OPENIB_RDMA_MAKE_REMOTE(F) do { \
|
|
|
|
|
((volatile uint8_t*)(F)->u.buf)[3] = EAGER_RDMA_BUFFER_REMOTE; \
|
|
|
|
|
}while (0)
|
2008-01-21 15:11:18 +03:00
|
|
|
|
2006-03-26 12:30:50 +04:00
|
|
|
#define MCA_BTL_OPENIB_RDMA_MAKE_LOCAL(F) do { \
|
|
|
|
|
((volatile uint8_t*)(F)->u.buf)[3] = EAGER_RDMA_BUFFER_LOCAL; \
|
|
|
|
|
}while (0)
|
|
|
|
|
|
2007-03-05 17:17:50 +03:00
|
|
|
#define MCA_BTL_OPENIB_GET_LOCAL_RDMA_FRAG(E, I) \
|
|
|
|
|
(&(E)->eager_rdma_local.frags[(I)])
|
2006-03-26 12:30:50 +04:00
|
|
|
|
2006-06-28 16:00:47 +04:00
|
|
|
#define MCA_BTL_OPENIB_RDMA_NEXT_INDEX(I) do { \
|
|
|
|
|
(I) = ((I) + 1); \
|
|
|
|
|
if((I) == \
|
|
|
|
|
mca_btl_openib_component.eager_rdma_num) \
|
|
|
|
|
(I) = 0; \
|
2006-03-26 12:30:50 +04:00
|
|
|
} while (0)
|
2007-08-27 15:37:01 +04:00
|
|
|
#define MCA_BTL_OPENIB_RDMA_MOVE_INDEX(HEAD, OLD_HEAD) \
|
|
|
|
|
do { \
|
|
|
|
|
int32_t new_head; \
|
|
|
|
|
do { \
|
|
|
|
|
OLD_HEAD = HEAD; \
|
|
|
|
|
new_head = OLD_HEAD + 1; \
|
|
|
|
|
if(new_head == mca_btl_openib_component.eager_rdma_num) \
|
|
|
|
|
new_head = 0; \
|
|
|
|
|
} while(!OPAL_ATOMIC_CMPSET_32(&HEAD, OLD_HEAD, new_head)); \
|
|
|
|
|
} while(0)
|
|
|
|
|
|
|
|
|
|
|
2009-08-20 15:42:18 +04:00
|
|
|
END_C_DECLS
|
2006-03-26 12:30:50 +04:00
|
|
|
#endif
|
|
|
|
|
|