[openib-general] ofa_1_2_kernel 20070223-0200 daily build status
This email was generated automatically, please do not reply Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod --with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-core-mod --with-addr_trans-mod --with-cxgb3-mod Passed: Passed on i686 with 2.6.15-23-server Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.16 Passed on i686 with linux-2.6.12 Passed on i686 with linux-2.6.17 Passed on i686 with linux-2.6.15 Passed on i686 with linux-2.6.13 Passed on i686 with linux-2.6.14 Passed on i686 with linux-2.6.19 Passed on powerpc with linux-2.6.19 Passed on x86_64 with linux-2.6.20 Passed on x86_64 with linux-2.6.19 Passed on powerpc with linux-2.6.18 Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.16 Passed on x86_64 with linux-2.6.17 Passed on x86_64 with linux-2.6.15 Passed on ppc64 with linux-2.6.19 Passed on x86_64 with linux-2.6.12 Passed on x86_64 with linux-2.6.13 Passed on powerpc with linux-2.6.17 Passed on ppc64 with linux-2.6.16 Passed on ia64 with linux-2.6.19 Passed on ppc64 with linux-2.6.18 Passed on x86_64 with linux-2.6.14 Passed on ia64 with linux-2.6.12 Passed on ia64 with linux-2.6.13 Passed on powerpc with linux-2.6.15 Passed on ppc64 with linux-2.6.15 Passed on powerpc with linux-2.6.14 Passed on ppc64 with linux-2.6.12 Passed on ppc64 with linux-2.6.17 Passed on powerpc with linux-2.6.12 Passed on x86_64 with linux-2.6.5-7.244-smp Passed on powerpc with linux-2.6.16 Passed on ia64 with linux-2.6.16 Passed on ppc64 with linux-2.6.13 Passed on powerpc with linux-2.6.13 Passed on ia64 with linux-2.6.18 Passed on x86_64 with linux-2.6.16.21-0.8-smp Passed on ppc64 with linux-2.6.14 Passed on ia64 with linux-2.6.15 Passed on x86_64 with linux-2.6.9-42.ELsmp Passed on ia64 with linux-2.6.17 Passed on ia64 with linux-2.6.14 Passed on x86_64 with linux-2.6.18-1.2798.fc6 Failed: Build failed on ia64 with linux-2.6.16.21-0.8-default Log: /home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.16.21-0.8-default_ia64_check/include/rdma/ib_verbs.h:1590: error: implicit declaration of function âsg_dma_lenâ /home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.16.21-0.8-default_ia64_check/drivers/infiniband/core/addr.c: At top level: /home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.16.21-0.8-default_ia64_check/drivers/infiniband/core/addr.c:61: warning: initialization from incompatible pointer type make[4]: *** [/home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.16.21-0.8-default_ia64_check/drivers/infiniband/core/addr.o] Error 1 make[3]: *** [/home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.16.21-0.8-default_ia64_check/drivers/infiniband/core] Error 2 make[2]: *** [/home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.16.21-0.8-default_ia64_check/drivers/infiniband] Error 2 make[1]: *** [_module_/home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.16.21-0.8-default_ia64_check] Error 2 make[1]: Leaving directory `/home/vlad/kernel.org/ia64/linux-2.6.16.21-0.8-default' make: *** [kernel] Error 2 -- Build failed on x86_64 with linux-2.6.9-22.ELsmp Log: /home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.9-22.ELsmp_x86_64_check/drivers/net/cxgb3/vsc8211.c:167: error: âADVERTISE_PAUSE_CAPâ undeclared (first use in this function) /home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.9-22.ELsmp_x86_64_check/drivers/net/cxgb3/vsc8211.c:167: error: (Each undeclared identifier is reported only once /home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.9-22.ELsmp_x86_64_check/drivers/net/cxgb3/vsc8211.c:167: error: for each function it appears in.) /home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.9-22.ELsmp_x86_64_check/drivers/net/cxgb3/vsc8211.c:170: error: âADVERTISE_PAUSE_ASYMâ undeclared (first use in this function) make[3]: *** [/home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.9-22.ELsmp_x86_64_check/drivers/net/cxgb3/vsc8211.o] Error 1 make[2]: *** [/home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.9-22.ELsmp_x86_64_check/drivers/net/cxgb3] Error 2 make[1]: *** [_module_/home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.9-22.ELsmp_x86_64_check] Error 2 make[1]: Leaving directory `/home/vlad/kernel.org/x86_64/linux-2.6.9-22.ELsmp' make: *** [kernel] Error 2 -- Build failed on x86_64 with linux-2.6.9-34.ELsmp Log: /home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.9-34.ELsmp_x86_64_check/drivers/net/cxgb3/cxgb3_offload.c: In function âadd_adapterâ: /home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.9-34.ELsmp_x86_64_check/drivers/net/cxgb3/cxgb3_offload.c:1061: error: âadapter_list_lockâ undeclared (first use in this function) /home/vlad/tmp/ofa_1_2_kernel-20070223-0200_linux-2.6.9-34.ELsmp_x86_64_check/drivers/net/cxgb3/cxgb3_offload.c: In function âremove_adapterâ: /home/vlad/tmp/ofa_1_2_kernel
Re: [openib-general] [PATCH] libmthca: optimize calls to htonl with constant parameter
So what is different in your setup that causes this patch to make a
difference for you?
Hmm. I agree it is somewhat strange.
Below is a simple test that attempts to compare htonl, CONSTANT_HTONL,
and an array-driven implementation. The code line is taken directly from htonl.
Could you compile and run it please?
I see:
$ gcc -O2 1.c
$ ./a.out
test1
122396.00 usec
test2
10517799.00 usec
test3
104099.00 usec
which seems to imply CONSTANT_HTONL is much faster.
Ideas?
---
#include stdio.h
#include sys/time.h
#include time.h
#include endian.h
#define SIZE 255
enum ibv_send_flags {
IBV_SEND_FENCE = 1 0,
IBV_SEND_SIGNALED = 1 1,
IBV_SEND_SOLICITED = 1 2,
IBV_SEND_INLINE = 1 3
};
enum {
MTHCA_NEXT_DBD = 1 7,
MTHCA_NEXT_FENCE = 1 6,
MTHCA_NEXT_CQ_UPDATE = 1 3,
MTHCA_NEXT_EVENT_GEN = 1 2,
MTHCA_NEXT_SOLICIT = 1 1,
};
int ar[SIZE];
void init_ar()
{
ar[0]=htonl(1);
ar[IBV_SEND_SIGNALED]=htonl(MTHCA_NEXT_CQ_UPDATE|1);;
ar[IBV_SEND_SOLICITED]=htonl(MTHCA_NEXT_SOLICIT|1);;
ar[IBV_SEND_SIGNALED|IBV_SEND_SOLICITED]=htonl(MTHCA_NEXT_CQ_UPDATE|MTHCA_NEXT_SOLICIT|1);;
}
int test1(int x)
{
return ar[x (IBV_SEND_SIGNALED | IBV_SEND_SOLICITED)];
}
int test2(int x)
{
return
((x IBV_SEND_SIGNALED) ? htonl(MTHCA_NEXT_CQ_UPDATE) : 0) |
((x IBV_SEND_SOLICITED) ? htonl(MTHCA_NEXT_SOLICIT) : 0) |
htonl(1);
}
#if __BYTE_ORDER == __LITTLE_ENDIAN
#define CONSTANT_HTONL(x) \
((x 24) | ((x 8) 0xff00) | ((x 8) 0xff) | (x 24))
#elif __BYTE_ORDER == __BIG_ENDIAN
#define CONSTANT_HTONL(x) (x)
#else
#define CONSTANT_HTONL(x) htonl(x)
#endif
int test3(int x)
{
return
((x IBV_SEND_SIGNALED) ?
CONSTANT_HTONL(MTHCA_NEXT_CQ_UPDATE) : 0) |
((x IBV_SEND_SOLICITED) ? CONSTANT_HTONL(MTHCA_NEXT_SOLICIT)
: 0) |
CONSTANT_HTONL(1);
}
struct timeval start, end;
void timestart(void)
{
if (gettimeofday(start, NULL)) {
perror(gettimeofday);
return;
}
}
void timeend(void)
{
if (gettimeofday(end, NULL)) {
perror(gettimeofday);
return;
}
{
float usec = (end.tv_sec - start.tv_sec) * 100 +
(end.tv_usec - start.tv_usec);
printf(%.2f usec\n, usec);
}
}
main()
{
int i;
init_ar();
printf(test1\n);
timestart();
for (i=0; i1; ++i) {
(void) test1(IBV_SEND_SIGNALED);
(void) test1(0);
(void) test1(IBV_SEND_SIGNALED | IBV_SEND_SOLICITED);
(void) test1(IBV_SEND_SOLICITED);
}
timeend();
printf(test2\n);
timestart();
for (i=0; i1; ++i) {
(void) test2(IBV_SEND_SIGNALED);
(void) test2(0);
(void) test2(IBV_SEND_SIGNALED | IBV_SEND_SOLICITED);
(void) test2(IBV_SEND_SOLICITED);
}
timeend();
printf(test3\n);
timestart();
for (i=0; i1; ++i) {
(void) test3(IBV_SEND_SIGNALED);
(void) test3(0);
(void) test3(IBV_SEND_SIGNALED | IBV_SEND_SOLICITED);
(void) test3(IBV_SEND_SOLICITED);
}
timeend();
}
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] libmthca: optimize calls to htonl with constant parameter
Quoting Michael S. Tsirkin [EMAIL PROTECTED]: Subject: Re: [PATCH] libmthca: optimize calls to htonl with constant parameter So what is different in your setup that causes this patch to make a difference for you? Hmm. I agree it is somewhat strange. Below is a simple test that attempts to compare htonl, CONSTANT_HTONL, and an array-driven implementation. The code line is taken directly from htonl. Could you compile and run it please? OK, this was stupid, the test was missing #include netinet/in.h so htonl was expanded by a gcc intrinsic which seems to work worse than the macro tricks present in netinet/in.h. I guess this include got killed on the test system somehow, and this explains why I saw a difference in libmthca. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] ipoib the partial pkey, was: librdmacm: fix bug causing failure to work with partial membership pkey
On Thu, 2007-02-22 at 18:35, Sean Hefty wrote: Doesn't this allow ipoib to join a multicast group for which it may not be able to communicate with all members? For the broadcast group, this seems like an error to me. Can ipoib work in such a configuration? If all nodes were assigned a partial membership PKey, none of them could communicate, but no errors would be generated anywhere. I looked into this more... RFC 4391 states (middle of page 5): For a node to join a partition, one of its ports must be assigned the relevant P_Key by the SM [RFC4392]. Jumping to RFC 4392 (top of page 4): at the time of creating an IB multicast group, multiple values such as the P_Key, Q_Key, Service Level, Hop Limit, Flow ID, TClass, MTU, etc. have to be specified. These values should be such that all potential members of the IB multicast group are able to communicate with one another when using them. Seems to me that for P_Key this would mean full membership. and page 14: Note that this IB_join to the broadcast group is a FullMember join. FullMember here is referring to MCMemberRecord:JoinState rather than partition membership. -- Hal If any of the ports or the switches linking the port to the rest of the IPoIB subnet cannot support the parameters (e.g., path MTU or P_Key) associated with the broadcast group, then the IB_join request will fail and the requesting port will not become part of the IPoIB subnet My initial interpretation of these statements lead me to believe that pkey check in ib_find_cached_pkey should not mask out the upper bit, which would prevent ipoib from joining a multicast group until it has been configured with the full membership pkey for the broadcast group. Does this seem reasonable? - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] librdmacm: fix bug causing failure to work with partial membership pkey
On Thu, 2007-02-22 at 17:18, Sean Hefty wrote: Can someone help my understanding here? Is ipoib joining a multicast group using the full membership PKey, even if the node that it joins from only has the limited membership PKey configured? And the code in ib_find_cached_pkey helps enable this? Yep. The ipoib create_child function Or-s 0x8000 to the device pkey which was provided by the user. Now, IPoIB uses the device pkey when forming MGIDs and when doing modify qp to init. Indeed the way ib_find_cached_pkey() is implemented, make the latter use trivial. Doesn't this allow ipoib to join a multicast group for which it may not be able to communicate with all members? Yes, if the join were to succeed which appears to me to be to be noncompliant behavior. For the broadcast group, this seems like an error to me. Why for just the broadcast group ? Isn't it any IPoIB MC group for which this would be done ? (See below as to what the IBA spec says). Can ipoib work in such a configuration? If all nodes were assigned a partial membership PKey, none of them could communicate, but no errors would be generated anywhere. Joining a multicast group requires specifying the full membership PKey. I don't see anything in the spec that explicitly prohibits joining the group from a node with only a partial membership PKey, What about the description og P_Key in MCMemberRecord (table 210 on p. 908 which is compliance) which states: All members of the multicast group shall have full membership in the partition indicated by the partition key. -- Hal but at first glance, this seems like a subnet configuration issue. Is there some use of this I'm overlooking? - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] librdmacm: fix bug causing failure to work with partial membership pkey
On Thu, 2007-02-22 at 17:18, Sean Hefty wrote: Can someone help my understanding here? Is ipoib joining a multicast group using the full membership PKey, even if the node that it joins from only has the limited membership PKey configured? And the code in ib_find_cached_pkey helps enable this? Yep. The ipoib create_child function Or-s 0x8000 to the device pkey which was provided by the user. Now, IPoIB uses the device pkey when forming MGIDs and when doing modify qp to init. Indeed the way ib_find_cached_pkey() is implemented, make the latter use trivial. Doesn't this allow ipoib to join a multicast group for which it may not be able to communicate with all members? Yes, if the join were to succeed which appears to be to be noncompliant behavior. For the broadcast group, this seems like an error to me. Why for just the broadcast group ? Isn't it any IPoIB MC group for which this would be done ? (See below as to what the IBA spec says). Can ipoib work in such a configuration? If all nodes were assigned a partial membership PKey, none of them could communicate, but no errors would be generated anywhere. Joining a multicast group requires specifying the full membership PKey. I don't see anything in the spec that explicitly prohibits joining the group from a node with only a partial membership PKey, What about the description og P_Key in MCMemberRecord (table 210 on p. 908 which is compliance) which states: All members of the multicast group shall have full membership in the partition indicated by the partition key. -- Hal but at first glance, this seems like a subnet configuration issue. Is there some use of this I'm overlooking? - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] libmthca: optimize calls to htonl with constant parameter
Newer gccs have the -fwhole-program --combine options that address this and more. One of the things that happens is that all internal functions are made 'static' and all compilation units are optimized in one go. Good point... but is there any sane way to use that feature with automake and libtool? I know that the autotools are a pain but I really don't want to reimplement the useful stuff they give us, and I don't know of any really practical replacement... - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] for OFED 1.2
I would like these fixes in OFED 1.2 as well. What git tree / branch do I
generate a patch against?
- Sean
---
rdma_cm: remove unused node_guid from cma_device structure.
ib_cm: remove ca_guid from cm_device structure.
rdma_cm: request reversible paths only.
ib_core: Set hop limit in ib_init_ah_from_wc correctly.
The patches are in:
git://git.openfabrics.org/~shefty/rdma-dev.git for-roland
(sign-off line was added to the actual commit messages)
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
---
commit 28e218621d36cf9da42f07af08775769eb289fc0
Author: Sean Hefty [EMAIL PROTECTED]
Date: Thu Feb 22 11:37:44 2007 -0800
rdma_cm: remove unused node_guid from cma_device structure.
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index bb27ce9..d441815 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -77,7 +77,6 @@ static int next_port;
struct cma_device {
struct list_headlist;
struct ib_device*device;
- __be64 node_guid;
struct completion comp;
atomic_trefcount;
struct list_headid_list;
@@ -2674,7 +2673,6 @@ static void cma_add_one(struct ib_device *device)
return;
cma_dev-device = device;
- cma_dev-node_guid = device-node_guid;
init_completion(cma_dev-comp);
atomic_set(cma_dev-refcount, 1);
commit 6de97f2a3373357d720b1653dfc0aac6d40b7506
Author: Sean Hefty [EMAIL PROTECTED]
Date: Thu Feb 22 11:37:38 2007 -0800
ib_cm: remove ca_guid from cm_device structure.
The cm_device references an ib_device, which contains the node_guid.
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index d446998..842cd0b 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -88,7 +88,6 @@ struct cm_port {
struct cm_device {
struct list_head list;
struct ib_device *device;
- __be64 ca_guid;
struct cm_port port[0];
};
@@ -739,8 +738,8 @@ retest:
ib_cancel_mad(cm_id_priv-av.port-mad_agent, cm_id_priv-msg);
spin_unlock_irqrestore(cm_id_priv-lock, flags);
ib_send_cm_rej(cm_id, IB_CM_REJ_TIMEOUT,
- cm_id_priv-av.port-cm_dev-ca_guid,
- sizeof cm_id_priv-av.port-cm_dev-ca_guid,
+ cm_id_priv-id.device-node_guid,
+ sizeof cm_id_priv-id.device-node_guid,
NULL, 0);
break;
case IB_CM_REQ_RCVD:
@@ -883,7 +882,7 @@ static void cm_format_req(struct cm_req_msg *req_msg,
req_msg-local_comm_id = cm_id_priv-id.local_id;
req_msg-service_id = param-service_id;
- req_msg-local_ca_guid = cm_id_priv-av.port-cm_dev-ca_guid;
+ req_msg-local_ca_guid = cm_id_priv-id.device-node_guid;
cm_req_set_local_qpn(req_msg, cpu_to_be32(param-qp_num));
cm_req_set_resp_res(req_msg, param-responder_resources);
cm_req_set_init_depth(req_msg, param-initiator_depth);
@@ -1442,7 +1441,7 @@ static void cm_format_rep(struct cm_rep_msg *rep_msg,
cm_rep_set_flow_ctrl(rep_msg, param-flow_control);
cm_rep_set_rnr_retry_count(rep_msg, param-rnr_retry_count);
cm_rep_set_srq(rep_msg, param-srq);
- rep_msg-local_ca_guid = cm_id_priv-av.port-cm_dev-ca_guid;
+ rep_msg-local_ca_guid = cm_id_priv-id.device-node_guid;
if (param-private_data param-private_data_len)
memcpy(rep_msg-private_data, param-private_data,
@@ -3385,7 +3384,6 @@ static void cm_add_one(struct ib_device *device)
return;
cm_dev-device = device;
- cm_dev-ca_guid = device-node_guid;
set_bit(IB_MGMT_METHOD_SEND, reg_req.method_mask);
for (i = 1; i = device-phys_port_cnt; i++) {
commit 87680047dd09ca4a4e8ec575dad215c92cf45ed3
Author: Sean Hefty [EMAIL PROTECTED]
Date: Wed Feb 21 16:40:44 2007 -0800
rdma_cm: request reversible paths only
The rdma_cm requires that path records be reversible. Set the reversible
bit when issuing an path record query.
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index f8d69b3..bb27ce9 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -1492,11 +1492,13 @@ static int cma_query_ib_route(struct rdma_id_private
*id_priv, int timeout_ms,
ib_addr_get_dgid(addr, path_rec.dgid);
path_rec.pkey = cpu_to_be16(ib_addr_get_pkey(addr));
path_rec.numb_path = 1;
+ path_rec.reversible = 1;
id_priv-query_id = ib_sa_path_rec_get(sa_client, id_priv-id.device,
id_priv-id.port_num, path_rec,
IB_SA_PATH_REC_DGID | IB_SA_PATH_REC_SGID |
- IB_SA_PATH_REC_PKEY | IB_SA_PATH_REC_NUMB_PATH,
+
[openib-general] [PATCH] uDAPL - include dapltest and dtest in build
This uDAPL patch adds both dapltest and dtest utilities, including manual pages, to the DAPL project build. The dapltest required some modifications to build on x86_64. James, please review. Signed-off by: Arlin Davis [EMAIL PROTECTED] diff --git a/Makefile.am b/Makefile.am index 1190f20..e2bf4dc 100644 --- a/Makefile.am +++ b/Makefile.am @@ -179,7 +179,9 @@ libdatinclude_HEADERS = dat/include/dat/dat.h \ dat/include/dat/udat.h \ dat/include/dat/udat_redirection.h \ dat/include/dat/udat_vendor_specific.h - + +man_MANS = man/dtest.1 man/dapltest.1 + EXTRA_DIST = dat/common/dat_dictionary.h \ dat/common/dat_dr.h \ dat/common/dat_init.h \ @@ -228,8 +230,10 @@ EXTRA_DIST = dat/common/dat_dictionary.h \ dat/udat/libdat.map \ doc/dat.conf \ dapl/udapl/libdaplcma.map \ -dapl/udapl/libdaplscm.map \ -libdat.spec.in +libdat.spec.in \ +$(man_MANS) dist-hook: libdat.spec cp libdat.spec $(distdir) + +SUBDIRS = . test/dtest test/dapltest diff --git a/configure.in b/configure.in index bf5ec09..324bfa1 100644 --- a/configure.in +++ b/configure.in @@ -1,11 +1,11 @@ dnl Process this file with autoconf to produce a configure script. AC_PREREQ(2.57) -AC_INIT(dapl, 1.2.0, [EMAIL PROTECTED]) +AC_INIT(dapl, 1.2.1, openib-general@openib.org) AC_CONFIG_SRCDIR([dat/udat/udat.c]) AC_CONFIG_AUX_DIR(config) AM_CONFIG_HEADER(config.h) -AM_INIT_AUTOMAKE(dapl, 1.2.0) +AM_INIT_AUTOMAKE(dapl, 1.2.1) AM_PROG_LIBTOOL @@ -60,5 +60,6 @@ AC_CACHE_CHECK(whether this is an RHEL system, ac_cv_rhel, fi) AM_CONDITIONAL(OS_RHEL, test $ac_cv_rhel = yes) -AC_CONFIG_FILES([Makefile libdat.spec]) +AC_CONFIG_FILES([Makefile test/dtest/Makefile test/dapltest/Makefile libdat.spec]) + AC_OUTPUT diff --git a/man/dapltest.1 b/man/dapltest.1 new file mode 100644 index 000..8ff4493 --- /dev/null +++ b/man/dapltest.1 @@ -0,0 +1,390 @@ +. Text automatically generated by txt2man +.TH dapltest 1 February 23, 2007 uDAPL 1.2 USER COMMANDS + +.SH NAME +\fB +\fBdapltest \fP- test for the Direct Access Programming Library (DAPL) +\fB +.SH DESCRIPTION + +Dapltest is a set of tests developed to exercise, characterize, +and verify the DAPL interfaces during development and porting. +At least two instantiations of the test must be run. One acts +as the server, fielding requests and spawning server-side test +threads as needed. Other client invocations connect to the server +and issue test requests. The server side of the test, once invoked, +listens continuously for client connection requests, until quit or +killed. Upon receipt of a connection request, the connection is +established, the server and client sides swap version numbers to +verify that they are able to communicate, and the client sends +the test request to the server. If the version numbers match, +and the test request is well-formed, the server spawns the threads +needed to run the test before awaiting further connections. +.SH USAGE + +dapltest [ -f script_file_name ] +[ -T S|Q|T|P|L ] [ -D device_name ] [ -d ] [ -R HT|LL|EC|PM|BE ] +.PP +With no arguments, dapltest runs as a server using default values, +and loops accepting requests from clients. + +The -f option allows all arguments to be placed in a file, to ease +test automation. + +The following arguments are common to all tests: +.TP +.B +[ -T S|Q|T|P|L ] +Test function to be performed: +.RS +.TP +.B +S +- server loop +.TP +.B +Q +- quit, client requests that server +wait for any outstanding tests to +complete, then clean up and exit +.TP +.B +T +- transaction test, transfers data between +client and server +.TP +.B +P +- performance test, times DTO operations +.TP +.B +L +- limit test, exhausts various resources, +runs in client w/o server interaction +Default: S +.RE +.TP +.B +[ -D device_name ] +Specifies the interface adapter name as documented in +the /etc/dat.conf static configuration file. This name +corresponds to the provider library to open. +Default: none +.TP +.B +[ -d ] +Enables extra debug verbosity, primarily tracing +of the various DAPL operations as they progress. +Repeating this parameter increases debug spew. +Errors encountered result in the test spewing some +explanatory text and stopping; this flag provides +more detail about what lead up to the error. +Default: zero +.TP +.B +[ -R BE ] +Indicate the quality of service (QoS) desired. +Choices are: +.RS +.TP +.B +HT +- high throughput +.TP +.B +LL +- low latency +.TP +.B +EC +- economy (neither HT nor LL) +.TP +.B +PM +- premium +.TP +.B +BE +- best effort +Default: BE +.RE +.RE +.PP +.B +Usage - Quit test client +.PP +.nf +.fam C +dapltest [Common_Args] [ -s server_name ] + +Quit testing (-T Q) connects to the server to ask it to clean up and +exit (after it waits for any
Re: [openib-general] [2.6 patch] drivers/infiniband/hw/cxgb3/: cleanups
thanks, queued for 2.6.21 ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 2.6.21] iw_cxgb3: Stop the EP Timer on BAD CLOSE.
thanks, queued for 2.6.21 ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
