[ofa-general] Re: [GIT PULL] please pull infiniband.git for-linus branch
Dotan Barak (3): IB: Include linux/list.h from rdma/ib_mad.h IB: Include linux/list.h and linux/rwsem.h from rdma/ib_verbs.h Hmm, if these things are appropriate for 2.6.23, maybe my patch adding linux/mutex.h to ehca_classes.h can go in too? -- MST ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] ofa_1_2_kernel 20070816-0100 daily build status
This email was generated automatically, please do not reply git_url: git://git.openfabrics.org/ofed_1_2/linux-2.6.git git_branch: ofed_1_2 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-rds-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.21.1 Passed on i686 with linux-2.6.17 Passed on i686 with linux-2.6.16 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.14 Passed on i686 with linux-2.6.13 Passed on i686 with linux-2.6.15 Passed on i686 with linux-2.6.12 Passed on ppc64 with linux-2.6.15 Passed on powerpc with linux-2.6.19 Passed on powerpc with linux-2.6.12 Passed on x86_64 with linux-2.6.16 Passed on powerpc with linux-2.6.18 Passed on ia64 with linux-2.6.18 Passed on powerpc with linux-2.6.13 Passed on powerpc with linux-2.6.14 Passed on x86_64 with linux-2.6.20 Passed on ppc64 with linux-2.6.18 Passed on ppc64 with linux-2.6.19 Passed on x86_64 with linux-2.6.17 Passed on powerpc with linux-2.6.15 Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.21.1 Passed on ppc64 with linux-2.6.12 Passed on ppc64 with linux-2.6.16 Passed on powerpc with linux-2.6.17 Passed on ppc64 with linux-2.6.14 Passed on x86_64 with linux-2.6.14 Passed on x86_64 with linux-2.6.13 Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.17 Passed on x86_64 with linux-2.6.12 Passed on ia64 with linux-2.6.13 Passed on x86_64 with linux-2.6.15 Passed on ia64 with linux-2.6.12 Passed on ia64 with linux-2.6.15 Passed on ppc64 with linux-2.6.17 Passed on powerpc with linux-2.6.16 Passed on ia64 with linux-2.6.14 Passed on ia64 with linux-2.6.16 Passed on ppc64 with linux-2.6.13 Passed on x86_64 with linux-2.6.16.43-0.3-smp Passed on ia64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.16.21-0.8-smp Passed on ppc64 with linux-2.6.18-8.el5 Passed on x86_64 with linux-2.6.18-8.el5 Passed on ia64 with linux-2.6.16.21-0.8-default Passed on x86_64 with linux-2.6.18-1.2798.fc6 Failed: ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] [PATCH] librdmacm 1/2: add valgrind support to auto-tools configuration file
Sean Hefty wrote: +if test x$with_valgrind = x || test x$with_valgrind = xno; then +want_valgrind=no +AC_DEFINE([NVALGRIND], 1, [Define to 1 to disable Valgrind annotations.]) +AC_CHECK_HEADER(valgrind/memcheck.h, +[AC_DEFINE(HAVE_VALGRIND_MEMCHECK_H, 1, +[Define to 1 if you have the valgrind/memcheck.h header file.])], What's the difference between including memcheck.h with NVALGRIND=1, versus not including it if valgrind support is not enabled. - Sean Here is some text from the file valgrind.h that will answer this question: /* This file is for inclusion into client (your!) code. You can use these macros to manipulate and query Valgrind's execution inside your own programs. The resulting executables will still run without Valgrind, just a little bit more slowly than they otherwise would, but otherwise unchanged. When not running on valgrind, each client request consumes very few (eg. 7) instructions, so the resulting performance loss is negligible unless you plan to execute client requests millions of times per second. Nevertheless, if that is still a problem, you can compile with the NVALGRIND symbol defined (gcc -DNVALGRIND) so that client requests are not even compiled in. */ thanks Dotan ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] ofa_1_2_c_kernel 20070816-0200 daily build status
This email was generated automatically, please do not reply git_url: git://git.openfabrics.org/ofed_1_2/linux-2.6.git git_branch: ofed_1_2_c Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod --with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-mlx4-mod --with-core-mod --with-addr_trans-mod --with-rds-mod --with-cxgb3-mod Passed: Passed on i686 with 2.6.15-23-server Passed on i686 with linux-2.6.21.1 Passed on i686 with linux-2.6.22 Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.17 Passed on i686 with linux-2.6.16 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.14 Passed on i686 with linux-2.6.13 Passed on i686 with linux-2.6.15 Passed on i686 with linux-2.6.12 Passed on x86_64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.16 Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.19 Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.12 Passed on ia64 with linux-2.6.13 Passed on powerpc with linux-2.6.13 Passed on ppc64 with linux-2.6.14 Passed on ia64 with linux-2.6.22 Passed on x86_64 with linux-2.6.20 Passed on ia64 with linux-2.6.15 Passed on ppc64 with linux-2.6.12 Passed on x86_64 with linux-2.6.12 Passed on ppc64 with linux-2.6.16 Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.14 Passed on x86_64 with linux-2.6.13 Passed on ppc64 with linux-2.6.15 Passed on powerpc with linux-2.6.12 Passed on ia64 with linux-2.6.17 Passed on ia64 with linux-2.6.16 Passed on x86_64 with linux-2.6.17 Passed on powerpc with linux-2.6.15 Passed on powerpc with linux-2.6.14 Passed on x86_64 with linux-2.6.16.43-0.3-smp Passed on ppc64 with linux-2.6.13 Passed on x86_64 with linux-2.6.22 Passed on x86_64 with linux-2.6.15 Passed on ppc64 with linux-2.6.18 Passed on ppc64 with linux-2.6.17 Passed on ppc64 with linux-2.6.19 Passed on x86_64 with linux-2.6.16.21-0.8-smp Passed on ia64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.18-8.el5 Passed on x86_64 with linux-2.6.14 Passed on x86_64 with linux-2.6.9-42.ELsmp Passed on x86_64 with linux-2.6.9-22.ELsmp Passed on x86_64 with linux-2.6.9-55.ELsmp Passed on ia64 with linux-2.6.16.21-0.8-default Passed on x86_64 with linux-2.6.18-1.2798.fc6 Passed on x86_64 with linux-2.6.9-34.ELsmp Passed on ppc64 with linux-2.6.18-8.el5 Failed: Build failed on powerpc with linux-2.6.19 Log: /home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:831: error: invalid type argument of â-â /home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:834: error: invalid type argument of â-â /home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:835: error: invalid type argument of â-â make[4]: *** [/home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.o] Error 1 make[3]: *** [/home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.19_powerpc_check/drivers/infiniband/hw/ehca] Error 2 make[2]: *** [/home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.19_powerpc_check/drivers/infiniband] Error 2 make[1]: *** [_module_/home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.19_powerpc_check] Error 2 make[1]: Leaving directory `/home/vlad/kernel.org/powerpc/linux-2.6.19' make: *** [kernel] Error 2 -- Build failed on powerpc with linux-2.6.18 Log: /home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:831: error: invalid type argument of â-â /home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:834: error: invalid type argument of â-â /home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:835: error: invalid type argument of â-â make[4]: *** [/home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.o] Error 1 make[3]: *** [/home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.18_powerpc_check/drivers/infiniband/hw/ehca] Error 2 make[2]: *** [/home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.18_powerpc_check/drivers/infiniband] Error 2 make[1]: *** [_module_/home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.18_powerpc_check] Error 2 make[1]: Leaving directory `/home/vlad/kernel.org/powerpc/linux-2.6.18' make: *** [kernel] Error 2 -- Build failed on powerpc with linux-2.6.16 Log: /home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.16_powerpc_check/drivers/infiniband/hw/ehca/ehca_main.c:831: error: invalid type argument of â-â /home/vlad/tmp/ofa_1_2_c_kernel-20070816-0200_linux-2.6.16_powerpc_check/drivers
[ofa-general] Here is nice pharmacy store
attachment: smotrisjuda.gif___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] [PATCH] ipoib/cm: use common CQ for all TX QPs
Use common CQ for all TX QPs: keep a per-device counter of outstanding TX WRs,
and stop the interface when this counter reaches the send queue size, to avoid
CQ overruns. This should help reduce the number of interrupts for
bi-directional traffic (such as TCP).
This helps fix driver is hogging interrupts errors reported for IPoIB send
side.
See e.g. https://bugs.openfabrics.org/show_bug.cgi?id=508
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
Index: linux-2.6/drivers/infiniband/ulp/ipoib/ipoib.h
===
--- linux-2.6.orig/drivers/infiniband/ulp/ipoib/ipoib.h 2007-08-16
15:23:30.0 +0300
+++ linux-2.6/drivers/infiniband/ulp/ipoib/ipoib.h 2007-08-16
15:23:56.0 +0300
@@ -97,9 +97,9 @@ enum {
#defineIPOIB_OP_RECV (1ul 31)
#ifdef CONFIG_INFINIBAND_IPOIB_CM
-#defineIPOIB_CM_OP_SRQ (1ul 30)
+#defineIPOIB_OP_CM (1ul 30)
#else
-#defineIPOIB_CM_OP_SRQ (0)
+#defineIPOIB_OP_CM (0)
#endif
/* structs */
@@ -176,7 +176,6 @@ struct ipoib_cm_rx {
struct ipoib_cm_tx {
struct ib_cm_id *id;
- struct ib_cq*cq;
struct ib_qp*qp;
struct list_head list;
struct net_device *dev;
@@ -271,6 +270,7 @@ struct ipoib_dev_priv {
unsigned tx_tail;
struct ib_sgetx_sge;
struct ib_send_wrtx_wr;
+ unsigned tx_outstanding;
struct ib_wc ibwc[IPOIB_NUM_WC];
@@ -480,6 +480,7 @@ void ipoib_cm_destroy_tx(struct ipoib_cm
void ipoib_cm_skb_too_long(struct net_device* dev, struct sk_buff *skb,
unsigned int mtu);
void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc);
+void ipoib_cm_handle_tx_wc(struct net_device *dev, struct ib_wc *wc);
#else
struct ipoib_cm_tx;
@@ -568,6 +569,9 @@ static inline void ipoib_cm_handle_rx_wc
{
}
+static inline void ipoib_cm_handle_tx_wc(struct net_device *dev, struct ib_wc
*wc)
+{
+}
#endif
#ifdef CONFIG_INFINIBAND_IPOIB_DEBUG
Index: linux-2.6/drivers/infiniband/ulp/ipoib/ipoib_cm.c
===
--- linux-2.6.orig/drivers/infiniband/ulp/ipoib/ipoib_cm.c 2007-08-16
15:23:30.0 +0300
+++ linux-2.6/drivers/infiniband/ulp/ipoib/ipoib_cm.c 2007-08-16
15:23:56.0 +0300
@@ -87,7 +87,7 @@ static int ipoib_cm_post_receive(struct
struct ib_recv_wr *bad_wr;
int i, ret;
- priv-cm.rx_wr.wr_id = id | IPOIB_CM_OP_SRQ;
+ priv-cm.rx_wr.wr_id = id | IPOIB_OP_CM | IPOIB_OP_RECV;
for (i = 0; i IPOIB_CM_RX_SG; ++i)
priv-cm.rx_sge[i].addr = priv-cm.srq_ring[id].mapping[i];
@@ -401,7 +401,7 @@ static void skb_put_frags(struct sk_buff
void ipoib_cm_handle_rx_wc(struct net_device *dev, struct ib_wc *wc)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
- unsigned int wr_id = wc-wr_id ~IPOIB_CM_OP_SRQ;
+ unsigned int wr_id = wc-wr_id ~(IPOIB_OP_CM | IPOIB_OP_RECV);
struct sk_buff *skb, *newskb;
struct ipoib_cm_rx *p;
unsigned long flags;
@@ -412,7 +412,7 @@ void ipoib_cm_handle_rx_wc(struct net_de
wr_id, wc-status);
if (unlikely(wr_id = ipoib_recvq_size)) {
- if (wr_id == (IPOIB_CM_RX_DRAIN_WRID ~IPOIB_CM_OP_SRQ)) {
+ if (wr_id == (IPOIB_CM_RX_DRAIN_WRID ~(IPOIB_OP_CM |
IPOIB_OP_RECV))) {
spin_lock_irqsave(priv-lock, flags);
list_splice_init(priv-cm.rx_drain_list,
priv-cm.rx_reap_list);
ipoib_cm_start_rx_drain(priv);
@@ -498,7 +498,7 @@ static inline int post_send(struct ipoib
priv-tx_sge.addr = addr;
priv-tx_sge.length = len;
- priv-tx_wr.wr_id = wr_id;
+ priv-tx_wr.wr_id = wr_id | IPOIB_OP_CM;
return ib_post_send(tx-qp, priv-tx_wr, bad_wr);
}
@@ -549,20 +549,19 @@ void ipoib_cm_send(struct net_device *de
dev-trans_start = jiffies;
++tx-tx_head;
- if (tx-tx_head - tx-tx_tail == ipoib_sendq_size) {
+ if (++priv-tx_outstanding == ipoib_sendq_size) {
ipoib_dbg(priv, TX ring 0x%x full, stopping kernel net
queue\n,
tx-qp-qp_num);
netif_stop_queue(dev);
- set_bit(IPOIB_FLAG_NETIF_STOPPED, tx-flags);
}
}
}
-static void ipoib_cm_handle_tx_wc(struct net_device *dev, struct ipoib_cm_tx
*tx,
- struct ib_wc *wc)
+void ipoib_cm_handle_tx_wc(struct net_device *dev, struct ib_wc *wc)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
- unsigned int wr_id = wc-wr_id;
+ struct ipoib_cm_tx *tx = wc-qp-qp_context;
+ unsigned int wr_id = wc-wr_id ~IPOIB_OP_CM;
[ofa-general] [PATCH 4/6] infiniband: mlx4_MAD_IFC copies out response unconditionally
It seems a trailing ';' has slipped into mlx4_MAD_IFC() which causes the response to be copied out unconditionally. Signed-off-by: Andy Whitcroft [EMAIL PROTECTED] Cc: Roland Dreier [EMAIL PROTECTED] Cc: Sean Hefty [EMAIL PROTECTED] Cc: Hal Rosenstock [EMAIL PROTECTED] Cc: general@lists.openfabrics.org --- drivers/infiniband/hw/mlx4/mad.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c index 3330917..0ed02b7 100644 --- a/drivers/infiniband/hw/mlx4/mad.c +++ b/drivers/infiniband/hw/mlx4/mad.c @@ -109,7 +109,7 @@ int mlx4_MAD_IFC(struct mlx4_ib_dev *dev, int ignore_mkey, int ignore_bkey, in_modifier, op_modifier, MLX4_CMD_MAD_IFC, MLX4_CMD_TIME_CLASS_C); - if (!err); + if (!err) memcpy(response_mad, outmailbox-buf, 256); mlx4_free_cmd_mailbox(dev-dev, inmailbox); ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.
On Wed, 2007-08-15 at 22:26 -0400, Jeff Garzik wrote: [...snip...] I think removing the RDMA stack is the wrong thing to do, and you shouldn't just threaten to yank entire subsystems because you don't like the technology. Lets keep this constructive, can we? RDMA should get the respect of any other technology in Linux. Maybe its a niche in your opinion, but come on, there's more RDMA users than say, the sparc64 port. Eh? It's not about being a niche. It's about creating a maintainable software net stack that has predictable behavior. Isn't RDMA _part_ of the software net stack within Linux? Why isn't making RDMA stable, supportable and maintainable equally as important as any other subsystem? Needing to reach out of the RDMA sandbox and reserve net stack resources away from itself travels a path we've consistently avoided. I will NACK any patch that opens up sockets to eat up ports or anything stupid like that. Got it. Ditto for me as well. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] [PATCH] core/verbs: Check that the LID in attach/detach multicast group is a multicast LID
Check that the LID in attach/detach multicast group is a multicast LID.
Signed-off-by: Dotan Barak [EMAIL PROTECTED]
---
diff --git a/drivers/infiniband/core/verbs.c b/drivers/infiniband/core/verbs.c
index 86ed8af..97353ff 100644
--- a/drivers/infiniband/core/verbs.c
+++ b/drivers/infiniband/core/verbs.c
@@ -832,7 +832,8 @@ int ib_attach_mcast(struct ib_qp *qp, union ib_gid *gid,
u16 lid)
{
if (!qp-device-attach_mcast)
return -ENOSYS;
- if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
+ if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD ||
+ lid 0xc000 || lid 0xfffe)
return -EINVAL;
return qp-device-attach_mcast(qp, gid, lid);
@@ -843,7 +844,8 @@ int ib_detach_mcast(struct ib_qp *qp, union ib_gid *gid,
u16 lid)
{
if (!qp-device-detach_mcast)
return -ENOSYS;
- if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD)
+ if (gid-raw[0] != 0xff || qp-qp_type != IB_QPT_UD ||
+ lid 0xc000 || lid 0xfffe)
return -EINVAL;
return qp-device-detach_mcast(qp, gid, lid);
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: [PATCH 4/6] infiniband: mlx4_MAD_IFC copies out response unconditionally
It seems a trailing ';' has slipped into mlx4_MAD_IFC() which causes the response to be copied out unconditionally. Thanks -- this is the third time someone has sent me this patch in the last day ;) - R. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] OFED 1.2.5 - GA release
I am happy to announce on OFED 1.2.5 GA release. The release can be found under: http://www.openfabrics.org/builds/ofed-1.2.5/release/ And later it will be on the OpenFabrics download page: http://www.openfabrics.org/downloads.htm This release was done in a joint effort of all companies in the EWG group. I wish to thank all who contributed to the success of this release. Tziporet === Release summary: The OpenFabrics Enterprise Distribution (OFED) version 1.2.5 software package supporting InfiniBand and iWARP fabrics. It is composed of several software modules intended for use on a computer cluster constructed as an InfiniBand subnet or an iWARP network. OFED package contains the following components: === The OFED Distribution package generates RPMs for installing the following: OFED 1.2.5 Contents --- The OFED package contains the following components: o OpenFabrics core and ULPs: - IB HCA drivers (mthca, mlx4, ipath, ehca) - iWARP RNIC driver (cxgb3) - core - Upper Layer Protocols: IPoIB, SDP, SRP Initiator, iSER Host, RDS, uDAPL and VNIC. o OpenFabrics utilities: - OpenSM (OSM): InfiniBand Subnet Manager - Diagnostic tools - Performance tests o MPI: - OSU MPI stack supporting the InfiniBand and iWARP interface - Open MPI stack supporting the InfiniBand and iWARP interface - OSU MVAPICH2 stack supporting the InfiniBand and iWARP interface - MPI benchmark tests (OSU benchmarks, Intel MPI benchmarks, Presta) o Extra packages: - open-iscsi: open-iscsi initiator with iSER support - ib-bonding: Bonding driver for IPoIB interface o Sources of all software modules (under conditions mentioned in the modules' LICENSE files) o Documentation Third Party Packages The following third party packages have been tested with OFED 1.2.5: 1. Intel MPI, Version 3.0 - Package ID: l_mpi_p_3.0.043 2. HP MPI, Version 2.2.5 Main Changes from OFED 1.2 == Changes in components: The following components are different between OFED 1.2 and OFED 1.2.5: User space: - libmlx4 (new) - mstflint (was enhanced to support ConnectX IB) - ofascripts - perftest - MVAPICH - opensm Kernel: - Code is based on kernel 2.6.22 - mthca - mlx4_core (new) - mlx4_ib(new) - core (the verbs providers) - cxgb3 - RDS See each package release notes for the specific changes from OFED 1.2 Supported Platforms and Operating Systems = o CPU architectures: - x86_64 - x86 - ia64 - ppc64 o Linux Operating Systems: - RedHat EL4 up3: 2.6.9-34.ELsmp - RedHat EL4 up4: 2.6.9-42.ELsmp - RedHat EL4 up5: 2.6.9-55.ELsmp - RedHat EL5: 2.6.18-8.el5 - SLES9 SP3: 2.6.5-7.244-smp - SLES10: 2.6.16.21-0.8-smp - SLES10 SP1: 2.6.16.46-0.12-smp (partially tested) - kernel.org: 2.6.20.x and 2.6.22.x HCAs and RNICs Supported This release supports IB HCAs by Mellanox Technologies, Qlogic and IBM as well as iWARP RNICs by Chelsio Communications. o Mellanox Technologies HCAs (SDR and DDR modes are supported): - InfiniHost (fw-23108 Rev 3.5.000) - InfiniHost III Ex (MemFree: fw-25218 Rev 5.2.000 with memory: fw-25208 Rev 4.8.200) - InfiniHost III Lx (fw-25204 Rev 1.2.000) - ConnectX IB (fw-25408 Rev 2.2.000) For official firmware versions please see: http://www.mellanox.com/support/firmware_table.php o Qlogic HCAs: - QHT6040 (PathScale InfiniPath HT-460) - QHT6140 (PathScale InfiniPath HT-465) - QLE6140 (PathScale InfiniPath PE-880) o IBM HCAs: - GX Dual-port 4x IB HCA - GX Dual-port 12x IB HCA o Chelsio RNICs: - S310/S320 10GbE Storage Accelerators - R310E 10GbE iWARP Adapters Infiniband Switches Supported - This release was tested with switches and gateways provided by the following companies: - Cisco - Voltaire - Qlogic - Flextronics ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] [PATCH 7/7] IB/ehca: Prevent overwriting QP init attributes given by caller
I don't understand this patch. rdma/ib_verbs.h says this about ib_create_qp(): * @qp_init_attr: A list of initial attributes required to create the * QP. If QP creation succeeds, then the attributes are updated to * the actual capabilities of the created QP. So it seems the current code is actually correct and your patch breaks it?? ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: [GIT PULL] please pull infiniband.git for-linus branch
Hmm, if these things are appropriate for 2.6.23, maybe my patch adding linux/mutex.h to ehca_classes.h can go in too? Actually I queued Dotan's patches quite a while ago, although Linus seems to be ignoring my pull requests. I don't see any urgency in adding more similar patches to 2.6.23, since AFAIK 2.6.23 builds fine, right? Also I would prefer to get ehca patches from the ehca people at IBM, or at least an ack from them. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] OFED 1.2 1.2.5 on SLES 10 SP1 with Xen[Scanned]
Hi all, I am currently trying to install/compile OFED on SLES 10 SP1 with the xen kernel and each time the compilation errors out at the same place. kernel: 2.6.16.46-0.12-xen OS: SLES 10 SP1 x86_64 build All applications via the build.sh script the last few lines from the OFED.log file gcc -Wp,-MD,/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/.vnic_sys.o.d -nostdinc -isystem /usr/lib64/gcc/x86_64-suse-linux/4.1.2/include -Iinclude2/asm/mach-xen -D__KERNEL__ -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/kernel_addons/backport/2.6.16_sles10_sp1/include/ -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/include -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/include -Iinclude -Iinclude2 -I/usr/src/linux-2.6.16.46-0.12/include -include include/linux/autoconf.h -include /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/include/linux/autoconf.h -D__XEN_INTERFACE_VERSION__=0x00030203 -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration -fno-strict-aliasing -fno-common -ffreestanding -Os -mtune=generic -m64 -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/include -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/include -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/ipoib -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/debug -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/hw/cxgb3/core -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/net/cxgb3 -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/net/rds -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/net/mlx4 -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/hw/mlx4 -DMODULE -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(vnic_sys) -DKBUILD_MODNAME=KBUILD_STR(ib_vnic) -c -o /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/.tmp_vnic_sys.o /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/vnic_sys.c ld -m elf_x86_64 -r -o /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/ib_vnic.o /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/vnic_main.o /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/vnic_ib.o /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/vnic_viport.o /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/vnic_control.o /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/vnic_data.o /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/vnic_netpath.o /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/vnic_config.o /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/vnic/vnic_sys.o make -f /usr/src/linux-2.6.16.46-0.12/scripts/Makefile.build obj=/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/net/cxgb3 gcc -Wp,-MD,/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/net/cxgb3/.cxgb3_main.o.d -nostdinc -isystem /usr/lib64/gcc/x86_64-suse-linux/4.1.2/include -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/kernel_addons/backport/2.6.16_sles10_sp1/include/ -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/include -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/include -Iinclude -Iinclude2 -I/usr/src/linux-2.6.16.46-0.12/include -include include/linux/autoconf.h -include /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/include/linux/autoconf.h -Iinclude2/asm/mach-xen -D__KERNEL__ -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/kernel_addons/backport/2.6.16_sles10_sp1/include/ -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/include -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/include -Iinclude -Iinclude2 -I/usr/src/linux-2.6.16.46-0.12/include -include include/linux/autoconf.h -include /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/include/linux/autoconf.h -D__XEN_INTERFACE_VERSION__=0x00030203 -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/net/cxgb3 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration -fno-strict-aliasing -fno-common -ffreestanding -Os -mtune=generic -m64 -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/include -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/include -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/ulp/ipoib -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/debug -I/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/infiniband/hw/cxgb3/core
Re: [ofa-general] OFED 1.2.5 - GA release
Hi all, Quoting Tziporet Koren [EMAIL PROTECTED]: I am happy to announce on OFED 1.2.5 GA release. Thanks for the release. I just wanted to let you know that I got a compilation error (using RHEL4) in ofa_kernel: In file included from /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/scsi/attri bute_container.c:1: /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/include/../drivers/base/attribute_contai ner.c:23:18: base.h: No such file or directory make[5]: *** [/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/scsi/attribute_con tainer.o] Error 1 make[4]: *** [/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/scsi] Error 2 make[3]: *** [_module_/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5] Error 2 make[2]: *** [modules] Error 2 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.9-55.EL_lustre-1.6.1-obj/x86_64/s mp' make: *** [kernel] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.56294 (%install) The drivers/base/attribute_container.c include a base.h which is not provided. Copying the vanilla kernel drivers/base/base.h file in the ofa_kernel drivers/base directory works, as well as the following dirty patch: --- attribute_container.c.orig 2007-08-16 10:59:08.0 -0700 +++ attribute_container.c 2007-08-16 10:57:21.0 -0700 @@ -20,7 +20,7 @@ #include linux/module.h #include linux/mutex.h -#include base.h +#include ../drivers/base/base.h /* This is a private structure used to tie the classdev and the * container .. it should never be visible outside this file */ Cheers -- Kilian ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: OFED 1.2.5 - GA release
Quoting Kilian Cavalotti [EMAIL PROTECTED]: Subject: Re: OFED 1.2.5 - GA release Hi all, Quoting Tziporet Koren [EMAIL PROTECTED]: I am happy to announce on OFED 1.2.5 GA release. Thanks for the release. I just wanted to let you know that I got a compilation error (using RHEL4) in ofa_kernel: In file included from /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/scsi/attri bute_container.c:1: /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/include/../drivers/base/attribute_contai ner.c:23:18: base.h: No such file or directory make[5]: *** [/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/scsi/attribute_con tainer.o] Error 1 make[4]: *** [/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/scsi] Error 2 make[3]: *** [_module_/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5] Error 2 make[2]: *** [modules] Error 2 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.9-55.EL_lustre-1.6.1-obj/x86_64/s mp' make: *** [kernel] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.56294 (%install) The drivers/base/attribute_container.c include a base.h which is not provided. Copying the vanilla kernel drivers/base/base.h file in the ofa_kernel drivers/base directory works, as well as the following dirty patch: --- attribute_container.c.orig 2007-08-16 10:59:08.0 -0700 +++ attribute_container.c 2007-08-16 10:57:21.0 -0700 @@ -20,7 +20,7 @@ #include linux/module.h #include linux/mutex.h -#include base.h +#include ../drivers/base/base.h /* This is a private structure used to tie the classdev and the * container .. it should never be visible outside this file */ This is iser stuff. A simple workaround is to disable iser before build. Erez, can you check this please? -- MST ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] ib_umem_get lock_limiting...
hi all, in ib_umem_get() in drivers/infiniband/core/umem.c in the kernel.org
driver at around line 115, we:
locked = npages + current-mm-locked_vm;
lock_limit = current-signal-rlim[RLIMIT_MEMLOCK].rlim_cur
PAGE_SHIFT;
if ((locked lock_limit) !capable(CAP_IPC_LOCK)) {
ret = -ENOMEM;
goto out;
}
the calculation looks ok, but it looks to me like
the should be an || in the test, esp since earlier
in the routine, we do an:
if (!can_do_mlock())
return ERR_PTR(-EPERM);
so, maybe the !capable(CAP_IPC_LOCK) should not be
there at all?
arthur
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] ib_umem_get lock_limiting...
the calculation looks ok, but it looks to me like the should be an || in the test, esp since earlier in the routine, we do an: if (!can_do_mlock()) return ERR_PTR(-EPERM); so, maybe the !capable(CAP_IPC_LOCK) should not be there at all? No, I think the code is correct. CAP_IPC_LOCK basically means we are root and should ignore resource limits. You can compare against the code in sys_mlock() to see that it has exactly the same logic. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] ib_umem_get lock_limiting...
hi roland, thanks, i get it now, it also helped when i saw this in the memlock manpage: Limits and permissions In Linux 2.6.8 and earlier, a process must be privileged (CAP_IPC_LOCK) in order to lock memory and the RLIMIT_MEMLOCK soft resource limit defines a limit on how much memory the process may lock. Since Linux 2.6.9, no limits are placed on the amount of memory that a privileged process can lock and the RLIMIT_MEMLOCK soft resource limit instead defines a limit on how much memory an unprivileged process may lock. arthur On Thu, Aug 16, 2007 at 01:33:04PM -0700, Roland Dreier wrote: the calculation looks ok, but it looks to me like the should be an || in the test, esp since earlier in the routine, we do an: if (!can_do_mlock()) return ERR_PTR(-EPERM); so, maybe the !capable(CAP_IPC_LOCK) should not be there at all? No, I think the code is correct. CAP_IPC_LOCK basically means we are root and should ignore resource limits. You can compare against the code in sys_mlock() to see that it has exactly the same logic. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.
From: Tom Tucker [EMAIL PROTECTED] Date: Thu, 16 Aug 2007 08:43:11 -0500 Isn't RDMA _part_ of the software net stack within Linux? It very much is not so. When using RDMA you lose the capability to do packet shaping, classification, and all the other wonderful networking facilities you've grown to love and use over the years. I'm glad this is a surprise to you, because it illustrates the point some of us keep trying to make about technologies like this. Imagine if you didn't know any of this, you purchase and begin to deploy a huge piece of RDMA infrastructure, you then get the mandate from IT that you need to add firewalling on the RDMA connections at the host level, and oh shit you can't? This is why none of us core networking developers like RDMA at all. It's totally not integrated with the rest of the Linux stack and on top of that it even gets in the way. It's an abberation, an eye sore, and a constant source of consternation. ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] [PATCH] opensm/osm_subnet.c: trivial naming changes
Some trivial renames + more formatting (with osm_indent).
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
opensm/opensm/osm_subnet.c | 662 +++-
1 files changed, 282 insertions(+), 380 deletions(-)
diff --git a/opensm/opensm/osm_subnet.c b/opensm/opensm/osm_subnet.c
index 5b240e1..818d73f 100644
--- a/opensm/opensm/osm_subnet.c
+++ b/opensm/opensm/osm_subnet.c
@@ -479,10 +479,9 @@ void osm_subn_set_default_opt(IN osm_subn_opt_t * const
p_opt)
/**
**/
-static inline void
-__osm_subn_opts_unpack_net64(IN char *p_req_key,
-IN char *p_key,
-IN char *p_val_str, IN uint64_t * p_val)
+static void
+opts_unpack_net64(IN char *p_req_key,
+ IN char *p_key, IN char *p_val_str, IN uint64_t * p_val)
{
uint64_t val;
@@ -506,10 +505,9 @@ __osm_subn_opts_unpack_net64(IN char *p_req_key,
/**
**/
-static inline void
-__osm_subn_opts_unpack_uint32(IN char *p_req_key,
- IN char *p_key,
- IN char *p_val_str, IN uint32_t * p_val)
+static void
+opts_unpack_uint32(IN char *p_req_key,
+ IN char *p_key, IN char *p_val_str, IN uint32_t * p_val)
{
uint32_t val;
@@ -528,10 +526,9 @@ __osm_subn_opts_unpack_uint32(IN char *p_req_key,
/**
**/
-static inline void
-__osm_subn_opts_unpack_uint16(IN char *p_req_key,
- IN char *p_key,
- IN char *p_val_str, IN uint16_t * p_val)
+static void
+opts_unpack_uint16(IN char *p_req_key,
+ IN char *p_key, IN char *p_val_str, IN uint16_t * p_val)
{
uint16_t val;
@@ -550,10 +547,9 @@ __osm_subn_opts_unpack_uint16(IN char *p_req_key,
/**
**/
-static inline void
-__osm_subn_opts_unpack_net16(IN char *p_req_key,
-IN char *p_key,
-IN char *p_val_str, IN uint16_t * p_val)
+static void
+opts_unpack_net16(IN char *p_req_key,
+ IN char *p_key, IN char *p_val_str, IN uint16_t * p_val)
{
if (!strcmp(p_req_key, p_key)) {
uint32_t val;
@@ -572,10 +568,9 @@ __osm_subn_opts_unpack_net16(IN char *p_req_key,
/**
**/
-static inline void
-__osm_subn_opts_unpack_uint8(IN char *p_req_key,
-IN char *p_key,
-IN char *p_val_str, IN uint8_t * p_val)
+static void
+opts_unpack_uint8(IN char *p_req_key,
+ IN char *p_key, IN char *p_val_str, IN uint8_t * p_val)
{
if (!strcmp(p_req_key, p_key)) {
uint32_t val;
@@ -594,10 +589,9 @@ __osm_subn_opts_unpack_uint8(IN char *p_req_key,
/**
**/
-static inline void
-__osm_subn_opts_unpack_boolean(IN char *p_req_key,
- IN char *p_key,
- IN char *p_val_str, IN boolean_t * p_val)
+static void
+opts_unpack_boolean(IN char *p_req_key,
+ IN char *p_key, IN char *p_val_str, IN boolean_t * p_val)
{
if (!strcmp(p_req_key, p_key) p_val_str) {
boolean_t val;
@@ -619,10 +613,9 @@ __osm_subn_opts_unpack_boolean(IN char *p_req_key,
/**
**/
-static inline void
-__osm_subn_opts_unpack_charp(IN char *p_req_key,
-IN char *p_key,
-IN char *p_val_str, IN char **p_val)
+static void
+opts_unpack_charp(IN char *p_req_key,
+ IN char *p_key, IN char *p_val_str, IN char **p_val)
{
if (!strcmp(p_req_key, p_key) p_val_str) {
if ((*p_val == NULL) || strcmp(p_val_str, *p_val)) {
@@ -652,15 +645,15 @@ subn_parse_qos_options(IN const char *prefix,
char name[256];
snprintf(name, sizeof(name), %s_max_vls, prefix);
- __osm_subn_opts_unpack_uint32(name, p_key, p_val_str, opt-max_vls);
+ opts_unpack_uint32(name, p_key, p_val_str, opt-max_vls);
snprintf(name, sizeof(name), %s_high_limit, prefix);
- __osm_subn_opts_unpack_uint32(name,
[ofa-general] [PATCH] osm_perfmgr.c: Fix extra port being added to num_ports
For some reason there was a +1 in here. This resulted in the dump function
printing a fictitious extra port for each node.
Ira
From 873fc9b19ddb8e4db068d0b2d9618310e57f3fd1 Mon Sep 17 00:00:00 2001
From: Ira K. Weiny [EMAIL PROTECTED]
Date: Tue, 14 Aug 2007 19:16:56 -0700
Subject: [PATCH] Fix extra port being added to num_ports
Signed-off-by: Ira K. Weiny [EMAIL PROTECTED]
---
opensm/opensm/osm_perfmgr.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/opensm/opensm/osm_perfmgr.c b/opensm/opensm/osm_perfmgr.c
index 43689fa..34c18ff 100644
--- a/opensm/opensm/osm_perfmgr.c
+++ b/opensm/opensm/osm_perfmgr.c
@@ -473,7 +473,7 @@ __osm_perfmgr_query_counters(cl_map_item_t * const
p_map_item, void *context)
node_guid = cl_ntoh64(node-node_info.node_guid);
/* make sure we have a database object ready to store this information
*/
- if (perfmgr_db_create_entry(pm-db, node_guid, num_ports + 1,
+ if (perfmgr_db_create_entry(pm-db, node_guid, num_ports,
node-print_desc) !=
PERFMGR_EVENT_DB_SUCCESS)
{
--
1.5.2
0001-Fix-extra-port-being-added-to-num_ports.patch
Description: Binary data
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] Re: [PATCH] osm_perfmgr.c: Fix extra port being added to num_ports
On 15:00 Thu 16 Aug , Ira Weiny wrote: For some reason there was a +1 in here. This resulted in the dump function printing a fictitious extra port for each node. Ira From 873fc9b19ddb8e4db068d0b2d9618310e57f3fd1 Mon Sep 17 00:00:00 2001 From: Ira K. Weiny [EMAIL PROTECTED] Date: Tue, 14 Aug 2007 19:16:56 -0700 Subject: [PATCH] Fix extra port being added to num_ports Signed-off-by: Ira K. Weiny [EMAIL PROTECTED] Applied. Thanks. Sasha ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] [PATCH] opensm/osm_sm_mad_ctrl.c: trivial changes
Some trivial flow consolidations and removing unneeded braces.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
opensm/opensm/osm_sm_mad_ctrl.c | 265 +--
1 files changed, 117 insertions(+), 148 deletions(-)
diff --git a/opensm/opensm/osm_sm_mad_ctrl.c b/opensm/opensm/osm_sm_mad_ctrl.c
index 758262b..b846b61 100644
--- a/opensm/opensm/osm_sm_mad_ctrl.c
+++ b/opensm/opensm/osm_sm_mad_ctrl.c
@@ -82,40 +82,36 @@ __osm_sm_mad_ctrl_retire_trans_mad(IN osm_sm_mad_ctrl_t *
const p_ctrl,
/*
Return the MAD wrapper to the pool.
*/
- if (osm_log_is_active(p_ctrl-p_log, OSM_LOG_DEBUG)) {
+ if (osm_log_is_active(p_ctrl-p_log, OSM_LOG_DEBUG))
osm_log(p_ctrl-p_log, OSM_LOG_DEBUG,
__osm_sm_mad_ctrl_retire_trans_mad:
Retiring MAD with TID 0x% PRIx64 \n,
cl_ntoh64(osm_madw_get_smp_ptr(p_madw)-trans_id));
- }
osm_mad_pool_put(p_ctrl-p_mad_pool, p_madw);
outstanding = cl_atomic_dec(p_ctrl-p_stats-qp0_mads_outstanding);
- if (osm_log_is_active(p_ctrl-p_log, OSM_LOG_DEBUG)) {
+ if (osm_log_is_active(p_ctrl-p_log, OSM_LOG_DEBUG))
osm_log(p_ctrl-p_log, OSM_LOG_DEBUG,
__osm_sm_mad_ctrl_retire_trans_mad:
%u QP0 MADs outstanding\n,
p_ctrl-p_stats-qp0_mads_outstanding);
- }
if (outstanding == 0) {
/*
The wire is clean.
Signal the state manager.
*/
- if (osm_log_is_active(p_ctrl-p_log, OSM_LOG_DEBUG)) {
+ if (osm_log_is_active(p_ctrl-p_log, OSM_LOG_DEBUG))
osm_log(p_ctrl-p_log, OSM_LOG_DEBUG,
__osm_sm_mad_ctrl_retire_trans_mad:
Posting Dispatcher message %s\n,
osm_get_disp_msg_str
(OSM_MSG_NO_SMPS_OUTSTANDING));
- }
status = cl_disp_post(p_ctrl-h_disp,
- OSM_MSG_NO_SMPS_OUTSTANDING,
- (void *)
+ OSM_MSG_NO_SMPS_OUTSTANDING, (void *)
OSM_SIGNAL_NO_PENDING_TRANSACTIONS, NULL,
NULL);
@@ -167,12 +163,10 @@ __osm_sm_mad_ctrl_disp_done_callback(IN void *context, IN
void *p_data)
if (ib_smp_is_response(p_smp)) {
CL_ASSERT(p_madw-resp_expected == FALSE);
__osm_sm_mad_ctrl_retire_trans_mad(p_ctrl, p_madw);
- } else {
- if (p_madw-resp_expected == TRUE)
- __osm_sm_mad_ctrl_retire_trans_mad(p_ctrl, p_madw);
- else
- osm_mad_pool_put(p_ctrl-p_mad_pool, p_madw);
- }
+ } else if (p_madw-resp_expected == TRUE)
+ __osm_sm_mad_ctrl_retire_trans_mad(p_ctrl, p_madw);
+ else
+ osm_mad_pool_put(p_ctrl-p_mad_pool, p_madw);
OSM_LOG_EXIT(p_ctrl-p_log);
}
@@ -198,12 +192,11 @@ __osm_sm_mad_ctrl_update_wire_stats(IN osm_sm_mad_ctrl_t
* const p_ctrl)
mads_on_wire =
cl_atomic_dec(p_ctrl-p_stats-qp0_mads_outstanding_on_wire);
- if (osm_log_is_active(p_ctrl-p_log, OSM_LOG_DEBUG)) {
+ if (osm_log_is_active(p_ctrl-p_log, OSM_LOG_DEBUG))
osm_log(p_ctrl-p_log, OSM_LOG_DEBUG,
__osm_sm_mad_ctrl_update_wire_stats:
%u SMPs on the wire, %u outstanding\n, mads_on_wire,
p_ctrl-p_stats-qp0_mads_outstanding);
- }
/*
We can signal the VL15 controller to send another MAD
@@ -240,13 +233,11 @@ __osm_sm_mad_ctrl_process_get_resp(IN osm_sm_mad_ctrl_t *
const p_ctrl,
p_smp = osm_madw_get_smp_ptr(p_madw);
- if (p_smp-mgmt_class == IB_MCLASS_SUBN_DIR) {
- if (!ib_smp_is_d(p_smp)) {
- osm_log(p_ctrl-p_log, OSM_LOG_ERROR,
- __osm_sm_mad_ctrl_process_get_resp: ERR 3102:
- 'D' bit not set in returned SMP\n);
- osm_dump_dr_smp(p_ctrl-p_log, p_smp, OSM_LOG_ERROR);
- }
+ if (p_smp-mgmt_class == IB_MCLASS_SUBN_DIR !ib_smp_is_d(p_smp)) {
+ osm_log(p_ctrl-p_log, OSM_LOG_ERROR,
+ __osm_sm_mad_ctrl_process_get_resp: ERR 3102:
+ 'D' bit not set in returned SMP\n);
+ osm_dump_dr_smp(p_ctrl-p_log, p_smp, OSM_LOG_ERROR);
}
p_old_madw = (osm_madw_t *) transaction_context;
@@ -312,33 +303,29 @@ __osm_sm_mad_ctrl_process_get_resp(IN osm_sm_mad_ctrl_t *
const p_ctrl,
goto Exit;
}
- if (msg_id != CL_DISP_MSGID_NONE) {
-
[ofa-general] [PATCH] opensm/osm_vl15intf.c: trivial changes
Drop unneeded braces, consolidate some flows.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
opensm/opensm/osm_vl15intf.c | 59 --
1 files changed, 11 insertions(+), 48 deletions(-)
diff --git a/opensm/opensm/osm_vl15intf.c b/opensm/opensm/osm_vl15intf.c
index 5316a12..0f240df 100644
--- a/opensm/opensm/osm_vl15intf.c
+++ b/opensm/opensm/osm_vl15intf.c
@@ -77,9 +77,7 @@ __osm_vl15_poller(
OSM_LOG_ENTER( p_vl-p_log, __osm_vl15_poller );
if ( p_vl-thread_state == OSM_THREAD_STATE_NONE)
- {
p_vl-thread_state = OSM_THREAD_STATE_RUN;
- }
while( p_vl-thread_state == OSM_THREAD_STATE_RUN )
{
@@ -105,17 +103,13 @@ __osm_vl15_poller(
if( p_madw != (osm_madw_t*)cl_qlist_end( p_fifo ) )
{
if( osm_log_is_active( p_vl-p_log, OSM_LOG_DEBUG ) )
- {
osm_log( p_vl-p_log, OSM_LOG_DEBUG,
__osm_vl15_poller:
Servicing p_madw = %p\n, p_madw );
- }
if( osm_log_is_active( p_vl-p_log, OSM_LOG_FRAMES ) )
- {
osm_dump_dr_smp( p_vl-p_log,
osm_madw_get_smp_ptr( p_madw ), OSM_LOG_FRAMES );
- }
/*
Non-response-expected mads are not throttled on the wire
@@ -131,15 +125,11 @@ __osm_vl15_poller(
To avoid this confusion, preincrement the counts on the
assumption that send() will succeed.
*/
-mads_on_wire = cl_atomic_inc(
- p_vl-p_stats-qp0_mads_outstanding_on_wire );
+mads_on_wire =
cl_atomic_inc(p_vl-p_stats-qp0_mads_outstanding_on_wire);
CL_ASSERT( mads_on_wire = p_vl-max_wire_smps );
}
else
- {
-unicasts_sent = cl_atomic_inc(
- p_vl-p_stats-qp0_unicasts_sent );
- }
+unicasts_sent = cl_atomic_inc(p_vl-p_stats-qp0_unicasts_sent);
mads_sent = cl_atomic_inc( p_vl-p_stats-qp0_mads_sent );
@@ -197,12 +187,10 @@ __osm_vl15_poller(
Signal the state manager.
*/
if( osm_log_is_active( p_vl-p_log, OSM_LOG_DEBUG ) )
-{
osm_log( p_vl-p_log, OSM_LOG_DEBUG,
__osm_vl15_poller:
Posting Dispatcher message %s\n,
osm_get_disp_msg_str( OSM_MSG_NO_SMPS_OUTSTANDING ) );
-}
cl_status = cl_disp_post( p_vl-h_disp,
OSM_MSG_NO_SMPS_OUTSTANDING,
@@ -211,54 +199,41 @@ __osm_vl15_poller(
NULL );
if( cl_status != CL_SUCCESS )
-{
osm_log( p_vl-p_log, OSM_LOG_ERROR,
__osm_vl15_poller: ERR 3E06:
Dispatcher post message failed (%s)\n,
CL_STATUS_MSG( cl_status ) );
-}
}
}
}
- else
- {
-if( osm_log_is_active( p_vl-p_log, OSM_LOG_DEBUG ) )
-{
- osm_log( p_vl-p_log, OSM_LOG_DEBUG,
- __osm_vl15_poller:
- %u QP0 MADs on wire, %u outstanding, %u unicasts sent,
- %u total sent\n,
- p_vl-p_stats-qp0_mads_outstanding_on_wire,
- p_vl-p_stats-qp0_mads_outstanding,
- p_vl-p_stats-qp0_unicasts_sent,
- p_vl-p_stats-qp0_mads_sent );
-}
- }
+ else if( osm_log_is_active( p_vl-p_log, OSM_LOG_DEBUG ) )
+osm_log( p_vl-p_log, OSM_LOG_DEBUG,
+ __osm_vl15_poller:
+ %u QP0 MADs on wire, %u outstanding, %u unicasts sent,
+ %u total sent\n,
+ p_vl-p_stats-qp0_mads_outstanding_on_wire,
+ p_vl-p_stats-qp0_mads_outstanding,
+ p_vl-p_stats-qp0_unicasts_sent,
+ p_vl-p_stats-qp0_mads_sent );
}
else
-{
/*
The VL15 FIFO is empty, so we have nothing left to do.
*/
status = cl_event_wait_on( p_vl-signal,
EVENT_NO_TIMEOUT, TRUE );
-}
while( (p_vl-p_stats-qp0_mads_outstanding_on_wire =
(int32_t)p_vl-max_wire_smps )
(p_vl-thread_state == OSM_THREAD_STATE_RUN ) )
-{
status = cl_event_wait_on( p_vl-signal,
EVENT_NO_TIMEOUT, TRUE );
-}
if( status != CL_SUCCESS )
-{
osm_log( p_vl-p_log, OSM_LOG_ERROR,
__osm_vl15_poller: ERR 3E02:
Event wait failed (%s)\n,
CL_STATUS_MSG( status ) );
-}
}
/*
@@ -425,11 +400,9 @@ osm_vl15_poll(
(int32_t)p_vl-max_wire_smps )
{
if( osm_log_is_active( p_vl-p_log, OSM_LOG_DEBUG ) )
-{
osm_log( p_vl-p_log, OSM_LOG_DEBUG,
osm_vl15_poll:
Signalling poller thread\n );
-}
cl_event_signal( p_vl-signal );
}
@@ -449,11 +422,9 @@ osm_vl15_post(
[ofa-general] [PATCH] opensm/osm_vl15intf.c: indentation changes
Formatting changes as produced by opensm/osm_indent.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
opensm/opensm/osm_vl15intf.c | 758 -
1 files changed, 370 insertions(+), 388 deletions(-)
diff --git a/opensm/opensm/osm_vl15intf.c b/opensm/opensm/osm_vl15intf.c
index 0f240df..f6050a7 100644
--- a/opensm/opensm/osm_vl15intf.c
+++ b/opensm/opensm/osm_vl15intf.c
@@ -47,7 +47,7 @@
#if HAVE_CONFIG_H
# include config.h
-#endif /* HAVE_CONFIG_H */
+#endif /* HAVE_CONFIG_H */
#include string.h
#include iba/ib_types.h
@@ -59,448 +59,430 @@
#include complib/cl_thread.h
#include signal.h
-
/**
**/
-void
-__osm_vl15_poller(
- IN void *p_ptr )
+void __osm_vl15_poller(IN void *p_ptr)
{
- ib_api_status_t status;
- osm_madw_t *p_madw;
- uint32_t mads_sent;
- uint32_t unicasts_sent;
- uint32_t mads_on_wire;
- osm_vl15_t* const p_vl = (osm_vl15_t*)p_ptr;
- cl_qlist_t* p_fifo;
-
- OSM_LOG_ENTER( p_vl-p_log, __osm_vl15_poller );
-
- if ( p_vl-thread_state == OSM_THREAD_STATE_NONE)
-p_vl-thread_state = OSM_THREAD_STATE_RUN;
-
- while( p_vl-thread_state == OSM_THREAD_STATE_RUN )
- {
-/*
- Start servicing the FIFOs by pulling off MAD wrappers
- and passing them to the transport interface.
- There are lots of corner cases here so tread carefully.
-
- The unicast FIFO has priority, since somebody is waiting
- for a timely response.
-*/
-cl_spinlock_acquire( p_vl-lock );
-
-if( cl_qlist_count( p_vl-ufifo ) != 0 )
- p_fifo = p_vl-ufifo;
-else
- p_fifo = p_vl-rfifo;
-
-p_madw = (osm_madw_t*)cl_qlist_remove_head( p_fifo );
-
-cl_spinlock_release( p_vl-lock );
-
-if( p_madw != (osm_madw_t*)cl_qlist_end( p_fifo ) )
-{
- if( osm_log_is_active( p_vl-p_log, OSM_LOG_DEBUG ) )
-osm_log( p_vl-p_log, OSM_LOG_DEBUG,
- __osm_vl15_poller:
- Servicing p_madw = %p\n, p_madw );
-
- if( osm_log_is_active( p_vl-p_log, OSM_LOG_FRAMES ) )
-osm_dump_dr_smp( p_vl-p_log,
- osm_madw_get_smp_ptr( p_madw ), OSM_LOG_FRAMES );
-
- /*
-Non-response-expected mads are not throttled on the wire
-since we can have no confirmation that they arrived
-at their destination.
- */
- if( p_madw-resp_expected == TRUE )
- {
-/*
- Note that other threads may not see the response MAD
- arrive before send() even returns.
- In that case, the wire count would temporarily go negative.
- To avoid this confusion, preincrement the counts on the
- assumption that send() will succeed.
-*/
-mads_on_wire =
cl_atomic_inc(p_vl-p_stats-qp0_mads_outstanding_on_wire);
-CL_ASSERT( mads_on_wire = p_vl-max_wire_smps );
- }
- else
-unicasts_sent = cl_atomic_inc(p_vl-p_stats-qp0_unicasts_sent);
-
- mads_sent = cl_atomic_inc( p_vl-p_stats-qp0_mads_sent );
-
- status = osm_vendor_send(
-osm_madw_get_bind_handle( p_madw ),
-p_madw, p_madw-resp_expected );
-
- if( status != IB_SUCCESS )
- {
-uint32_t outstanding;
-cl_status_t cl_status;
-
-osm_log( p_vl-p_log, OSM_LOG_ERROR,
- __osm_vl15_poller: ERR 3E03:
- MAD send failed (%s)\n,
- ib_get_err_str( status ) );
-
-/*
- The MAD was never successfully sent, so
- fix up the pre-incremented count values.
-*/
-
-/* Decrement qp0_mads_sent and qp0_mads_outstanding_on_wire
- that were incremented in the code above. */
-mads_sent = cl_atomic_dec( p_vl-p_stats-qp0_mads_sent );
-if( p_madw-resp_expected == TRUE )
- cl_atomic_dec( p_vl-p_stats-qp0_mads_outstanding_on_wire );
-
-/*
- The following code is similar to the code in
- __osm_sm_mad_ctrl_retire_trans_mad. We need to decrement the
- qp0_mads_outstanding counter, and if we reached 0 - need to call
- the cl_disp_post with OSM_SIGNAL_NO_PENDING_TRANSACTION (in order
- to wake up the state mgr).
- There is one difference from the code in
__osm_sm_mad_ctrl_retire_trans_mad.
- This code is called for all (vl15) mads, if osm_vendor_send()
failed, unlike
- __osm_sm_mad_ctrl_retire_trans_mad which is called only on mads
where
- resp_expected == TRUE. As a result, the qp0_mads_outstanding counter
- should be decremented and handled accordingly only if this is a mad
- with resp_expected == TRUE.
-*/
-if ( p_madw-resp_expected == TRUE )
-{
- outstanding = cl_atomic_dec( p_vl-p_stats-qp0_mads_outstanding );
-
- osm_log( p_vl-p_log,
[ofa-general] [PATCH] opensm/osm_vl15intf.c: trivial code reordering
Trivial code reordering to make it more readable.
Signed-off-by: Sasha Khapyorsky [EMAIL PROTECTED]
---
opensm/opensm/osm_vl15intf.c | 234 -
1 files changed, 114 insertions(+), 120 deletions(-)
diff --git a/opensm/opensm/osm_vl15intf.c b/opensm/opensm/osm_vl15intf.c
index f6050a7..bc667b6 100644
--- a/opensm/opensm/osm_vl15intf.c
+++ b/opensm/opensm/osm_vl15intf.c
@@ -61,13 +61,124 @@
/**
**/
-void __osm_vl15_poller(IN void *p_ptr)
+
+static void vl15_send_mad(osm_vl15_t * p_vl, osm_madw_t * p_madw)
{
ib_api_status_t status;
- osm_madw_t *p_madw;
+ cl_status_t cl_status;
uint32_t mads_sent;
uint32_t unicasts_sent;
uint32_t mads_on_wire;
+ uint32_t outstanding;
+
+ /*
+ Non-response-expected mads are not throttled on the wire
+ since we can have no confirmation that they arrived
+ at their destination.
+*/
+ if (p_madw-resp_expected == TRUE) {
+ /*
+ Note that other threads may not see the response MAD
+ arrive before send() even returns.
+ In that case, the wire count would temporarily go negative.
+ To avoid this confusion, preincrement the counts on the
+ assumption that send() will succeed.
+*/
+ mads_on_wire =
+ cl_atomic_inc(p_vl-p_stats-qp0_mads_outstanding_on_wire);
+ CL_ASSERT(mads_on_wire = p_vl-max_wire_smps);
+ } else
+ unicasts_sent =
+ cl_atomic_inc(p_vl-p_stats-qp0_unicasts_sent);
+
+ mads_sent = cl_atomic_inc(p_vl-p_stats-qp0_mads_sent);
+
+ status = osm_vendor_send(osm_madw_get_bind_handle(p_madw),
+p_madw, p_madw-resp_expected);
+
+ if (status == IB_SUCCESS) {
+ if (osm_log_is_active(p_vl-p_log, OSM_LOG_DEBUG))
+ osm_log(p_vl-p_log, OSM_LOG_DEBUG,
+ __osm_vl15_poller:
+ %u QP0 MADs on wire, %u outstanding,
+ %u unicasts sent, %u total sent\n,
+ p_vl-p_stats-qp0_mads_outstanding_on_wire,
+ p_vl-p_stats-qp0_mads_outstanding,
+ p_vl-p_stats-qp0_unicasts_sent,
+ p_vl-p_stats-qp0_mads_sent);
+ return;
+ }
+
+ osm_log(p_vl-p_log, OSM_LOG_ERROR,
+ __osm_vl15_poller: ERR 3E03:
+ MAD send failed (%s)\n, ib_get_err_str(status));
+
+ /*
+ The MAD was never successfully sent, so
+ fix up the pre-incremented count values.
+*/
+
+ /* Decrement qp0_mads_sent and qp0_mads_outstanding_on_wire
+ that were incremented in the code above. */
+ mads_sent = cl_atomic_dec(p_vl-p_stats-qp0_mads_sent);
+
+ if (p_madw-resp_expected == FALSE)
+ return;
+
+ cl_atomic_dec(p_vl-p_stats-qp0_mads_outstanding_on_wire);
+
+ /*
+ The following code is similar to the code in
+ __osm_sm_mad_ctrl_retire_trans_mad. We need to decrement the
+ qp0_mads_outstanding counter, and if we reached 0 - need to call
+ the cl_disp_post with OSM_SIGNAL_NO_PENDING_TRANSACTION (in order
+ to wake up the state mgr).
+ There is one difference from the code in
__osm_sm_mad_ctrl_retire_trans_mad.
+ This code is called for all (vl15) mads, if osm_vendor_send()
failed, unlike
+ __osm_sm_mad_ctrl_retire_trans_mad which is called only on mads where
+ resp_expected == TRUE. As a result, the qp0_mads_outstanding counter
+ should be decremented and handled accordingly only if this is a mad
+ with resp_expected == TRUE.
+*/
+
+ outstanding = cl_atomic_dec(p_vl-p_stats-qp0_mads_outstanding);
+
+ osm_log(p_vl-p_log, OSM_LOG_DEBUG,
+ __osm_vl15_poller:
+ %u QP0 MADs outstanding\n,
+ p_vl-p_stats-qp0_mads_outstanding);
+
+ if (outstanding)
+ return;
+
+ /*
+ The wire is clean.
+ Signal the state manager.
+*/
+ if (osm_log_is_active(p_vl-p_log, OSM_LOG_DEBUG))
+ osm_log(p_vl-p_log,
+ OSM_LOG_DEBUG,
+ __osm_vl15_poller:
+ Posting Dispatcher message %s\n,
+ osm_get_disp_msg_str(OSM_MSG_NO_SMPS_OUTSTANDING));
+
+ cl_status = cl_disp_post(p_vl-h_disp,
+OSM_MSG_NO_SMPS_OUTSTANDING, (void *)
+OSM_SIGNAL_NO_PENDING_TRANSACTIONS,
+NULL, NULL);
[ofa-general] Re: [ewg] OFED 1.2.5 - GA release
On Thu, 16 Aug 2007 18:36:56 +0300 Tziporet Koren [EMAIL PROTECTED] wrote: I am happy to announce on OFED 1.2.5 GA release. The release can be found under: http://www.openfabrics.org/builds/ofed-1.2.5/release/ Cool, could I get the git tree/tag for each of the sub projects? Especially the kernel. Thanks, IRa And later it will be on the OpenFabrics download page: http://www.openfabrics.org/downloads.htm This release was done in a joint effort of all companies in the EWG group. I wish to thank all who contributed to the success of this release. Tziporet === Release summary: The OpenFabrics Enterprise Distribution (OFED) version 1.2.5 software package supporting InfiniBand and iWARP fabrics. It is composed of several software modules intended for use on a computer cluster constructed as an InfiniBand subnet or an iWARP network. OFED package contains the following components: === The OFED Distribution package generates RPMs for installing the following: OFED 1.2.5 Contents --- The OFED package contains the following components: o OpenFabrics core and ULPs: - IB HCA drivers (mthca, mlx4, ipath, ehca) - iWARP RNIC driver (cxgb3) - core - Upper Layer Protocols: IPoIB, SDP, SRP Initiator, iSER Host, RDS, uDAPL and VNIC. o OpenFabrics utilities: - OpenSM (OSM): InfiniBand Subnet Manager - Diagnostic tools - Performance tests o MPI: - OSU MPI stack supporting the InfiniBand and iWARP interface - Open MPI stack supporting the InfiniBand and iWARP interface - OSU MVAPICH2 stack supporting the InfiniBand and iWARP interface - MPI benchmark tests (OSU benchmarks, Intel MPI benchmarks, Presta) o Extra packages: - open-iscsi: open-iscsi initiator with iSER support - ib-bonding: Bonding driver for IPoIB interface o Sources of all software modules (under conditions mentioned in the modules' LICENSE files) o Documentation Third Party Packages The following third party packages have been tested with OFED 1.2.5: 1. Intel MPI, Version 3.0 - Package ID: l_mpi_p_3.0.043 2. HP MPI, Version 2.2.5 Main Changes from OFED 1.2 == Changes in components: The following components are different between OFED 1.2 and OFED 1.2.5: User space: - libmlx4 (new) - mstflint (was enhanced to support ConnectX IB) - ofascripts - perftest - MVAPICH - opensm Kernel: - Code is based on kernel 2.6.22 - mthca - mlx4_core (new) - mlx4_ib(new) - core (the verbs providers) - cxgb3 - RDS See each package release notes for the specific changes from OFED 1.2 Supported Platforms and Operating Systems = o CPU architectures: - x86_64 - x86 - ia64 - ppc64 o Linux Operating Systems: - RedHat EL4 up3: 2.6.9-34.ELsmp - RedHat EL4 up4: 2.6.9-42.ELsmp - RedHat EL4 up5: 2.6.9-55.ELsmp - RedHat EL5: 2.6.18-8.el5 - SLES9 SP3: 2.6.5-7.244-smp - SLES10: 2.6.16.21-0.8-smp - SLES10 SP1: 2.6.16.46-0.12-smp (partially tested) - kernel.org: 2.6.20.x and 2.6.22.x HCAs and RNICs Supported This release supports IB HCAs by Mellanox Technologies, Qlogic and IBM as well as iWARP RNICs by Chelsio Communications. o Mellanox Technologies HCAs (SDR and DDR modes are supported): - InfiniHost (fw-23108 Rev 3.5.000) - InfiniHost III Ex (MemFree: fw-25218 Rev 5.2.000 with memory: fw-25208 Rev 4.8.200) - InfiniHost III Lx (fw-25204 Rev 1.2.000) - ConnectX IB (fw-25408 Rev 2.2.000) For official firmware versions please see: http://www.mellanox.com/support/firmware_table.php o Qlogic HCAs: - QHT6040 (PathScale InfiniPath HT-460) - QHT6140 (PathScale InfiniPath HT-465) - QLE6140 (PathScale InfiniPath PE-880) o IBM HCAs: - GX Dual-port 4x IB HCA - GX Dual-port 12x IB HCA o Chelsio RNICs: - S310/S320 10GbE Storage Accelerators - R310E 10GbE iWARP Adapters Infiniband Switches Supported - This release was tested with switches and gateways provided by the following companies: - Cisco - Voltaire - Qlogic - Flextronics ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
RE: [ofa-general] [PATCH] librdmacm 1/2: add valgrind support to auto-tools configuration file
The resulting executables will still run without Valgrind, just a
little bit more slowly than they otherwise would, but otherwise
unchanged. When not running on valgrind, each client request
consumes very few (eg. 7) instructions, so the resulting performance
loss is negligible unless you plan to execute client requests
millions of times per second. Nevertheless, if that is still a
problem, you can compile with the NVALGRIND symbol defined (gcc
-DNVALGRIND) so that client requests are not even compiled in. */
It just seems that we're using two checks where we really want one. We check to
see if memcheck.h exists, and if it does, we include it. But if the user
doesn't want valgrind, then we disable using it through NVALGRIND.
How about something more like:
if with-valgrind is set then {
if memcheck is found then
INCLUDE_MEMCHECK_H = 1
if with_valgrind then set CPPFLAGS
else
error
}
The error message in your second patch is a little misleading otherwise, since
it could occur even though valgrind support was not requested.
- Sean
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] [PATCH] ipoib/cm: use common CQ for all TX QPs
Michael S. Tsirkin wrote: Use common CQ for all TX QPs: keep a per-device counter of outstanding TX WRs, and stop the interface when this counter reaches the send queue size, to avoid CQ overruns. This should help reduce the number of interrupts for bi-directional traffic (such as TCP). CQ overrun generates asynchronous errors. If CQ overruns are avoided, how does that reduce interrupts? On a side note, as a further extension to this idea, would it be worth considering sendq_size and recvq_size being device specific in the future, instead of being module specific? This helps fix driver is hogging interrupts errors reported for IPoIB send side. See e.g. https://bugs.openfabrics.org/show_bug.cgi?id=508 In bug 508, timer ticks were lost because some device was hogging interrupts. What is the association between dropping packets and hogging interrupts? Can you expand on that? Pradeep ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] nightly osm_sim report 2007-08-17:normal completion
OSM Simulation Regression Summary [Generated mail - please do NOT reply] OpenSM rev = Tue_Aug_14_19:41:02_2007 [3faa14cf64da6e58900c1abbcafe0f33ae1c69e2] ibutils rev = Thu_Aug_9_15:39:12_2007 [d1681ad8afb35441ac1741392d9e2e94a9d7e22f] Total=560 Pass=560 Fail=0 Pass: 42 Stability IS1-16.topo 42 Pkey IS1-16.topo 42 OsmTest IS1-16.topo 42 OsmStress IS1-16.topo 42 Multicast IS1-16.topo 42 LidMgr IS1-16.topo 14 Stability IS3-loop.topo 14 Stability IS3-128.topo 14 Pkey IS3-128.topo 14 OsmTest IS3-loop.topo 14 OsmTest IS3-128.topo 14 OsmStress IS3-128.topo 14 Multicast IS3-loop.topo 14 Multicast IS3-128.topo 14 LidMgr IS3-128.topo 14 FatTree merge-roots-4-ary-2-tree.topo 14 FatTree merge-root-4-ary-3-tree.topo 14 FatTree gnu-stallion-64.topo 14 FatTree blend-4-ary-2-tree.topo 14 FatTree RhinoDDR.topo 14 FatTree FullGnu.topo 14 FatTree 4-ary-2-tree.topo 14 FatTree 2-ary-4-tree.topo 14 FatTree 12-node-spaced.topo 14 FTreeFail 4-ary-2-tree-missing-sw-link.topo 14 FTreeFail 4-ary-2-tree-links-at-same-rank-2.topo 14 FTreeFail 4-ary-2-tree-links-at-same-rank-1.topo 14 FTreeFail 4-ary-2-tree-diff-num-pgroups.topo Failures: ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [ofa-general] [PATCH] librdmacm 1/2: add valgrind support to auto-tools configuration file
Sean Hefty wrote:
The resulting executables will still run without Valgrind, just a
little bit more slowly than they otherwise would, but otherwise
unchanged. When not running on valgrind, each client request
consumes very few (eg. 7) instructions, so the resulting performance
loss is negligible unless you plan to execute client requests
millions of times per second. Nevertheless, if that is still a
problem, you can compile with the NVALGRIND symbol defined (gcc
-DNVALGRIND) so that client requests are not even compiled in. */
It just seems that we're using two checks where we really want one. We check to
see if memcheck.h exists, and if it does, we include it. But if the user
doesn't want valgrind, then we disable using it through NVALGRIND.
How about something more like:
if with-valgrind is set then {
if memcheck is found then
INCLUDE_MEMCHECK_H = 1
if with_valgrind then set CPPFLAGS
else
error
}
The error message in your second patch is a little misleading otherwise, since
it could occur even though valgrind support was not requested.
- Sean
Basically, you are right.
I wrote this piece of code based on the libibverbs to be consistent with
it, maybe Roland can contribute to this thread too ...
I think that the way it is written now, it allows to the library to be
prepared to valgrind anyway and use its header file when possible
(to allow the user later on use valgrind) unless the user explicitly
don't want to use valgrind (to avoid the minor overhead of marking
the buffer as valid) or if the user explicitly specified that he wants
valgrind, but the requested header file doesn't exist.
I think that we should keep this as the way i suggested because
libibverbs work this way for quite a while and there wasn't any problem
with this implementation and i would like to be consistent with it.
what do you think?
thanks
Dotan
___
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[ofa-general] RE: OFED 1.2.5 - GA release
Quoting Kilian Cavalotti [EMAIL PROTECTED]: Subject: Re: OFED 1.2.5 - GA release Hi all, Quoting Tziporet Koren [EMAIL PROTECTED]: I am happy to announce on OFED 1.2.5 GA release. Thanks for the release. I just wanted to let you know that I got a compilation error (using RHEL4) in ofa_kernel: In file included from /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/scsi/attri bute_container.c:1: /var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/include/../drivers/base/attribute_contai ner.c:23:18: base.h: No such file or directory make[5]: *** [/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/scsi/attribute_con tainer.o] Error 1 make[4]: *** [/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5/drivers/scsi] Error 2 make[3]: *** [_module_/var/tmp/OFEDRPM/BUILD/ofa_kernel-1.2.5] Error 2 make[2]: *** [modules] Error 2 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.9-55.EL_lustre-1.6.1-obj/x86_64/s mp' make: *** [kernel] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.56294 (%install) The drivers/base/attribute_container.c include a base.h which is not provided. Copying the vanilla kernel drivers/base/base.h file in the ofa_kernel drivers/base directory works, as well as the following dirty patch: --- attribute_container.c.orig 2007-08-16 10:59:08.0 -0700 +++ attribute_container.c 2007-08-16 10:57:21.0 -0700 @@ -20,7 +20,7 @@ #include linux/module.h #include linux/mutex.h -#include base.h +#include ../drivers/base/base.h /* This is a private structure used to tie the classdev and the * container .. it should never be visible outside this file */ This is iser stuff. A simple workaround is to disable iser before build. Erez, can you check this please? Strange. Are you testing it on a standard RHAS4 up5 machine? Can you send the ofed.conf file that you were using? I'd like to try that in our lab. Erez ___ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
