Re: [openib-general] [PATCH] librdmacm: fix bug causing failure to work with partial membership pkey
Yes. Its a little bit confusing: partial and full members of an IPoIB IB partition use the same MGID. When an IPoIB MGID is constructed, the pkey placed by the driver is --always-- the full membership one. However, on a node with partial membership, what's plugged into the QP is the pkey index of the partial instance... So in this case, do both the full and partial keys need configuring for that port ? No. The SM configures --either-- the full or the partial pkey. However, no matter what the SM configures, the core ipoib code act as the full pkey is there. This is nice simplification and it works well. Or. ___ 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] [ofw] [Fwd: Re: [Fwd: Re: winrelated[was:Re:[PATCH 1/2] opensm: sigusr1: syslog() fixes]]]
OK, Hal let's try to close this. The windows openib project was agreed by everyone to be BSD only. The fact that it is BSD means that any partner (or non partner) of the Community can download the code and use it, the way he wants. This includes: 1) Running the code as is. 2) Making changes to the code and contributing them back. 3) Making changes to the code and *NOT* giving them back to the community. Starting to depend on GPL (or LGPL) code means that the freedom of the users to do (3) is broken. Mellanox thinks that this needs a wider agreement of the open-IB consortium, which we don't have. More than that, the ideas that were introduced here about sending users to other places in order for them to find the pthread implementation are also not that great as this starts to make the life of our users harder. Also it is not clear who will give support once there are problems, and who is responsible that the license of the library won't change. So, I hope this closes the subject of using LGPL software in open-IB. By the way, what implementation of pthreads were you thinking of? I have noticed that the first implementation that Google brings was only tested on uni-processor system. (http://sourceware.org/pthreads-win32/news.html). (this is really amazing, I thought that these servers were out of the market a long time ago). To be more practical: Can you give us a better view of what you are trying to achieve? In other words, as far as I know Opensm is using complib apis to handle threads. The implementation of this functions on windows is usually trivial. Do you intend to make a re-write of opensm so that it will use pthreads or do you intend to make a find/replace And replace the complib functions with Pthreads ones? If we are talking about the second, than one can simply implement the pthread functions using trivial win32 calls. And another question: What is the functionality that you are currently missing? Can this functionality be added? Thanks Tzachi By the way, rumors I have heard say that Voltaire doesn't always give it's code back to the community, but this are just rumors, right? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fab Tillier Sent: Tuesday, February 20, 2007 11:56 PM To: Hal Rosenstock Cc: ofw@lists.openfabrics.org; Gilad Shainer; OPENIB Subject: RE: [ofw] [Fwd: Re: [openib-general] [Fwd: Re: winrelated[was:Re:[PATCH 1/2] opensm: sigusr1: syslog() fixes]]] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hal Rosenstock Sent: Tuesday, February 20, 2007 1:43 PM On Tue, 2007-02-20 at 16:08, Fab Tillier wrote: -Original Message- From: Hal Rosenstock [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 20, 2007 10:57 AM On Tue, 2007-02-20 at 13:56, Fab Tillier wrote: [ftillier] This isn't just an install issue - it's a build issue. Anyone that wants to build OpenSM will need to find/download/install the pthreads library so that the build will succeed. If linking statically, the resulting executable will not require any special installation. It's only an install issue if you link dynamically to pitheads. OK; then build and install. How big an issue is this ? I thought DLLs were dynamically linked but I'm a Windows plebe. [ftillier] When you build, the linker needs the import library for pthreads so that the functions get resolved as being imported from the pthreads DLL. The dependency on the pthreads DLL is then created and the DLL will be loaded dynamically, assuming it can be found in the path. So for the build process, you need to have the pthreads library available to the build tool (path to the lib). This requires installing the pthreads developer package or however it's done. If you statically link the pthreads lib, rather than dynamically link, then all the pthreads goodies go directly into the executable and you remove the dependency on an external DLL. The build process requirements are no different than for the dynamically linked case. There is also the possibility to remove the link-time dependency by calling GetProcAddress to explicitly resolve the pthreads entrypoints. This method still requires having the DLL loaded on the user's systems. Pesonally, I would rather see static linkage to the pthreads library so that only the builds are affected (something only 'experts' will be doing), while not affecting the common user. -Fab ___ ofw mailing list ofw@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw ___ 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] ofa_1_2_kernel 20070221-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.17 Passed on i686 with linux-2.6.16 Passed on i686 with linux-2.6.12 Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.13 Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.14 Passed on i686 with linux-2.6.15 Passed on ppc64 with linux-2.6.18 Passed on powerpc with linux-2.6.19 Passed on x86_64 with linux-2.6.16 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.20 Passed on x86_64 with linux-2.6.17 Passed on ia64 with linux-2.6.19 Passed on powerpc with linux-2.6.17 Passed on x86_64 with linux-2.6.12 Passed on x86_64 with linux-2.6.15 Passed on x86_64 with linux-2.6.14 Passed on powerpc with linux-2.6.18 Passed on x86_64 with linux-2.6.13 Passed on x86_64 with linux-2.6.18 Passed on ia64 with linux-2.6.18 Passed on powerpc with linux-2.6.12 Passed on powerpc with linux-2.6.15 Passed on ppc64 with linux-2.6.15 Passed on powerpc with linux-2.6.13 Passed on powerpc with linux-2.6.14 Passed on ia64 with linux-2.6.15 Passed on ppc64 with linux-2.6.14 Passed on ia64 with linux-2.6.13 Passed on powerpc with linux-2.6.16 Passed on ppc64 with linux-2.6.16 Passed on ppc64 with linux-2.6.12 Passed on ppc64 with linux-2.6.19 Passed on ia64 with linux-2.6.16 Passed on ia64 with linux-2.6.17 Passed on ppc64 with linux-2.6.17 Passed on ppc64 with linux-2.6.13 Passed on ia64 with linux-2.6.14 Passed on ia64 with linux-2.6.12 Failed: ___ 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] [2.6 patch] drivers/infiniband/hw/cxgb3/: cleanups
On Tue, Feb 20, 2007 at 08:43:06AM -0600, Steve Wise wrote:
On Tue, 2007-02-20 at 01:02 +0100, Adrian Bunk wrote:
This patch contains the following possible cleanups:
- don't mark static functions in C files as inline - gcc should know
best whether inlining makes sense
- never compile the unused cxio_dbg.c
- make the following needlessly global functions static:
- cxio_hal.c: cxio_hal_clear_qp_ctx()
- iwch_provider.c: iwch_get_qp()
- #if 0 the following unused global functions:
- cxio_hal.c: cxio_allocate_stag()
- cxio_resource.: cxio_hal_get_rhdl()
- cxio_resource.: cxio_hal_put_rhdl()
You could just remove the code instead of #if 0...
...
Updated patch below.
cu
Adrian
-- snip --
This patch contains the following possible cleanups:
- don't mark static functions in C files as inline - gcc should know
best whether inlining makes sense
- never compile the unused cxio_dbg.c
- make the following needlessly global functions static:
- cxio_hal.c: cxio_hal_clear_qp_ctx()
- iwch_provider.c: iwch_get_qp()
- remove the following unused global functions:
- cxio_hal.c: cxio_allocate_stag()
- cxio_resource.: cxio_hal_get_rhdl()
- cxio_resource.: cxio_hal_put_rhdl()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/Makefile|1
drivers/infiniband/hw/cxgb3/cxio_hal.c | 31 +---
drivers/infiniband/hw/cxgb3/cxio_hal.h |5 ---
drivers/infiniband/hw/cxgb3/cxio_resource.c | 14 +
drivers/infiniband/hw/cxgb3/iwch_cm.c |5 +--
drivers/infiniband/hw/cxgb3/iwch_provider.c |2 -
drivers/infiniband/hw/cxgb3/iwch_provider.h |1
drivers/infiniband/hw/cxgb3/iwch_qp.c | 29 --
8 files changed, 27 insertions(+), 61 deletions(-)
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/Makefile.old 2007-02-17
17:21:03.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/Makefile 2007-02-17
17:21:08.0 +0100
@@ -8,5 +8,4 @@
ifdef CONFIG_INFINIBAND_CXGB3_DEBUG
EXTRA_CFLAGS += -DDEBUG
-iw_cxgb3-y += cxio_dbg.o
endif
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/cxio_hal.h.old 2007-02-17
17:22:53.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/cxio_hal.h 2007-02-17
17:25:08.0 +0100
@@ -144,7 +144,6 @@
void cxio_rdev_close(struct cxio_rdev *rdev);
int cxio_hal_cq_op(struct cxio_rdev *rdev, struct t3_cq *cq,
enum t3_cq_opcode op, u32 credit);
-int cxio_hal_clear_qp_ctx(struct cxio_rdev *rdev, u32 qpid);
int cxio_create_cq(struct cxio_rdev *rdev, struct t3_cq *cq);
int cxio_destroy_cq(struct cxio_rdev *rdev, struct t3_cq *cq);
int cxio_resize_cq(struct cxio_rdev *rdev, struct t3_cq *cq);
@@ -155,8 +154,6 @@
int cxio_destroy_qp(struct cxio_rdev *rdev, struct t3_wq *wq,
struct cxio_ucontext *uctx);
int cxio_peek_cq(struct t3_wq *wr, struct t3_cq *cq, int opcode);
-int cxio_allocate_stag(struct cxio_rdev *rdev, u32 * stag, u32 pdid,
- enum tpt_mem_perm perm, u32 * pbl_size, u32 * pbl_addr);
int cxio_register_phys_mem(struct cxio_rdev *rdev, u32 * stag, u32 pdid,
enum tpt_mem_perm perm, u32 zbva, u64 to, u32 len,
u8 page_size, __be64 *pbl, u32 *pbl_size,
@@ -172,8 +169,6 @@
int cxio_rdma_init(struct cxio_rdev *rdev, struct t3_rdma_init_attr *attr);
void cxio_register_ev_cb(cxio_hal_ev_callback_func_t ev_cb);
void cxio_unregister_ev_cb(cxio_hal_ev_callback_func_t ev_cb);
-u32 cxio_hal_get_rhdl(void);
-void cxio_hal_put_rhdl(u32 rhdl);
u32 cxio_hal_get_pdid(struct cxio_hal_resource *rscp);
void cxio_hal_put_pdid(struct cxio_hal_resource *rscp, u32 pdid);
int __init cxio_hal_init(void);
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/iwch_provider.h.old
2007-02-17 17:25:35.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/iwch_provider.h
2007-02-17 17:25:41.0 +0100
@@ -179,7 +179,6 @@
void iwch_qp_add_ref(struct ib_qp *qp);
void iwch_qp_rem_ref(struct ib_qp *qp);
-struct ib_qp *iwch_get_qp(struct ib_device *dev, int qpn);
struct iwch_ucontext {
struct ib_ucontext ibucontext;
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/iwch_provider.c.old
2007-02-17 17:25:50.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/iwch_provider.c
2007-02-17 17:25:57.0 +0100
@@ -949,7 +949,7 @@
wake_up((to_iwch_qp(qp)-wait));
}
-struct ib_qp *iwch_get_qp(struct ib_device *dev, int qpn)
+static struct ib_qp *iwch_get_qp(struct ib_device *dev, int qpn)
{
PDBG(%s ib_dev %p qpn 0x%x\n, __FUNCTION__, dev, qpn);
return (struct ib_qp *)get_qhp(to_iwch_dev(dev), qpn);
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/iwch_qp.c.old 2007-02-17
17:27:31.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/iwch_qp.c 2007-02-17
17:38:07.0 +0100
@@ -37,8 +37,8 @@
Re: [openib-general] [PATCH] librdmacm: fix bug causing failure to work with partial membership pkey
On Wed, 2007-02-21 at 01:43, Or Gerlitz wrote: Hal Rosenstock wrote: On Tue, 2007-02-20 at 10:38, Or Gerlitz wrote: Yes. Its a little bit confusing: partial and full members of an IPoIB IB partition use the same MGID. When an IPoIB MGID is constructed, the pkey placed by the driver is --always-- the full membership one. However, on a node with partial membership, what's plugged into the QP is the pkey index of the partial instance... So in this case, do both the full and partial keys need configuring for that port ? No. The SM configures --either-- the full or the partial pkey. That's what I was afraid of :-( However, no matter what the SM configures, the core ipoib code act as the full pkey is there. This is nice simplification and it works well. I believe it is a spec (compliance) violation for the port to be a partial member and join as a full member. -- Hal Or. ___ 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
However, no matter what the SM configures, the core ipoib code act as the full pkey is there. This is nice simplification and it works well. I believe it is a spec (compliance) violation for the port to be a partial member and join as a full member. Since partial members can't talk among themselves, there is no reason to form a multicast group containing --only-- ports that can --not-- talk to each other... So if the spec does not allow this (having a partial member joining with the full member pkey) - it a spec bug... Or. ___ 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 for-2.6.21] IPoIB/cm: improve small message bandwidth
Michael S. Tsirkin wrote:
Avoid overhead of freeing/reallocating and mapping/unmapping for dma
for pages that have not been written to by hardware.
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 8ee6f06..a23c8e3 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -68,14 +68,14 @@ struct ipoib_cm_id {
static int ipoib_cm_tx_handler(struct ib_cm_id *cm_id,
struct ib_cm_event *event);
-static void ipoib_cm_dma_unmap_rx(struct ipoib_dev_priv *priv,
+static void ipoib_cm_dma_unmap_rx(struct ipoib_dev_priv *priv, int frags,
u64 mapping[IPOIB_CM_RX_SG])
{
int i;
ib_dma_unmap_single(priv-ca, mapping[0], IPOIB_CM_HEAD_SIZE,
DMA_FROM_DEVICE);
- for (i = 0; i IPOIB_CM_RX_SG - 1; ++i)
+ for (i = 0; i frags; ++i)
ib_dma_unmap_single(priv-ca, mapping[i + 1], PAGE_SIZE,
DMA_FROM_DEVICE);
}
I understand that in ipoib_cm_alloc_rx_skb you call dma_map_page on
IPOIB_CM_RX_SG pages where here you call dma_unmap_single only $frags
times, correct? does this means you are trashing the IOMMU etc etc of
the system?
Or.
___
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 for-2.6.21] IPoIB/cm: improve small message bandwidth
Quoting r. Or Gerlitz [EMAIL PROTECTED]:
Subject: Re: [openib-general] [PATCH for-2.6.21] IPoIB/cm: improve small
message bandwidth
Michael S. Tsirkin wrote:
Avoid overhead of freeing/reallocating and mapping/unmapping for dma
for pages that have not been written to by hardware.
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
index 8ee6f06..a23c8e3 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_cm.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_cm.c
@@ -68,14 +68,14 @@ struct ipoib_cm_id {
static int ipoib_cm_tx_handler(struct ib_cm_id *cm_id,
struct ib_cm_event *event);
-static void ipoib_cm_dma_unmap_rx(struct ipoib_dev_priv *priv,
+static void ipoib_cm_dma_unmap_rx(struct ipoib_dev_priv *priv, int frags,
u64 mapping[IPOIB_CM_RX_SG])
{
int i;
ib_dma_unmap_single(priv-ca, mapping[0], IPOIB_CM_HEAD_SIZE,
DMA_FROM_DEVICE);
- for (i = 0; i IPOIB_CM_RX_SG - 1; ++i)
+ for (i = 0; i frags; ++i)
ib_dma_unmap_single(priv-ca, mapping[i + 1], PAGE_SIZE,
DMA_FROM_DEVICE);
}
I understand that in ipoib_cm_alloc_rx_skb you call dma_map_page on
IPOIB_CM_RX_SG pages where here you call dma_unmap_single only $frags
times, correct?
No.
does this means you are trashing the IOMMU etc etc of
the system?
I don't think so.
--
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] librdmacm: fix bug causing failure to work with partial membership pkey
On Wed, 2007-02-21 at 07:35, Or Gerlitz wrote: However, no matter what the SM configures, the core ipoib code act as the full pkey is there. This is nice simplification and it works well. I believe it is a spec (compliance) violation for the port to be a partial member and join as a full member. Since partial members can't talk among themselves, there is no reason to form a multicast group containing --only-- ports that can --not-- talk to each other... So if the spec does not allow this (having a partial member joining with the full member pkey) - it a spec bug... I think there are two issues here then: 1. If this is the case, getting the spec changed to accomodate this use case. 2. I believe that OpenIB code is supposed to be spec compliant. -- Hal Or. ___ 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] [2.6 patch] drivers/infiniband/hw/cxgb3/: cleanups
Thanks Adrian!
Acked-by: Steve Wise [EMAIL PROTECTED]
On Wed, 2007-02-21 at 11:52 +0100, Adrian Bunk wrote:
On Tue, Feb 20, 2007 at 08:43:06AM -0600, Steve Wise wrote:
On Tue, 2007-02-20 at 01:02 +0100, Adrian Bunk wrote:
This patch contains the following possible cleanups:
- don't mark static functions in C files as inline - gcc should know
best whether inlining makes sense
- never compile the unused cxio_dbg.c
- make the following needlessly global functions static:
- cxio_hal.c: cxio_hal_clear_qp_ctx()
- iwch_provider.c: iwch_get_qp()
- #if 0 the following unused global functions:
- cxio_hal.c: cxio_allocate_stag()
- cxio_resource.: cxio_hal_get_rhdl()
- cxio_resource.: cxio_hal_put_rhdl()
You could just remove the code instead of #if 0...
...
Updated patch below.
cu
Adrian
-- snip --
This patch contains the following possible cleanups:
- don't mark static functions in C files as inline - gcc should know
best whether inlining makes sense
- never compile the unused cxio_dbg.c
- make the following needlessly global functions static:
- cxio_hal.c: cxio_hal_clear_qp_ctx()
- iwch_provider.c: iwch_get_qp()
- remove the following unused global functions:
- cxio_hal.c: cxio_allocate_stag()
- cxio_resource.: cxio_hal_get_rhdl()
- cxio_resource.: cxio_hal_put_rhdl()
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/Makefile|1
drivers/infiniband/hw/cxgb3/cxio_hal.c | 31 +---
drivers/infiniband/hw/cxgb3/cxio_hal.h |5 ---
drivers/infiniband/hw/cxgb3/cxio_resource.c | 14 +
drivers/infiniband/hw/cxgb3/iwch_cm.c |5 +--
drivers/infiniband/hw/cxgb3/iwch_provider.c |2 -
drivers/infiniband/hw/cxgb3/iwch_provider.h |1
drivers/infiniband/hw/cxgb3/iwch_qp.c | 29 --
8 files changed, 27 insertions(+), 61 deletions(-)
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/Makefile.old 2007-02-17
17:21:03.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/Makefile 2007-02-17
17:21:08.0 +0100
@@ -8,5 +8,4 @@
ifdef CONFIG_INFINIBAND_CXGB3_DEBUG
EXTRA_CFLAGS += -DDEBUG
-iw_cxgb3-y += cxio_dbg.o
endif
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/cxio_hal.h.old
2007-02-17 17:22:53.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/cxio_hal.h 2007-02-17
17:25:08.0 +0100
@@ -144,7 +144,6 @@
void cxio_rdev_close(struct cxio_rdev *rdev);
int cxio_hal_cq_op(struct cxio_rdev *rdev, struct t3_cq *cq,
enum t3_cq_opcode op, u32 credit);
-int cxio_hal_clear_qp_ctx(struct cxio_rdev *rdev, u32 qpid);
int cxio_create_cq(struct cxio_rdev *rdev, struct t3_cq *cq);
int cxio_destroy_cq(struct cxio_rdev *rdev, struct t3_cq *cq);
int cxio_resize_cq(struct cxio_rdev *rdev, struct t3_cq *cq);
@@ -155,8 +154,6 @@
int cxio_destroy_qp(struct cxio_rdev *rdev, struct t3_wq *wq,
struct cxio_ucontext *uctx);
int cxio_peek_cq(struct t3_wq *wr, struct t3_cq *cq, int opcode);
-int cxio_allocate_stag(struct cxio_rdev *rdev, u32 * stag, u32 pdid,
-enum tpt_mem_perm perm, u32 * pbl_size, u32 * pbl_addr);
int cxio_register_phys_mem(struct cxio_rdev *rdev, u32 * stag, u32 pdid,
enum tpt_mem_perm perm, u32 zbva, u64 to, u32 len,
u8 page_size, __be64 *pbl, u32 *pbl_size,
@@ -172,8 +169,6 @@
int cxio_rdma_init(struct cxio_rdev *rdev, struct t3_rdma_init_attr *attr);
void cxio_register_ev_cb(cxio_hal_ev_callback_func_t ev_cb);
void cxio_unregister_ev_cb(cxio_hal_ev_callback_func_t ev_cb);
-u32 cxio_hal_get_rhdl(void);
-void cxio_hal_put_rhdl(u32 rhdl);
u32 cxio_hal_get_pdid(struct cxio_hal_resource *rscp);
void cxio_hal_put_pdid(struct cxio_hal_resource *rscp, u32 pdid);
int __init cxio_hal_init(void);
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/iwch_provider.h.old
2007-02-17 17:25:35.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/iwch_provider.h
2007-02-17 17:25:41.0 +0100
@@ -179,7 +179,6 @@
void iwch_qp_add_ref(struct ib_qp *qp);
void iwch_qp_rem_ref(struct ib_qp *qp);
-struct ib_qp *iwch_get_qp(struct ib_device *dev, int qpn);
struct iwch_ucontext {
struct ib_ucontext ibucontext;
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/iwch_provider.c.old
2007-02-17 17:25:50.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/iwch_provider.c
2007-02-17 17:25:57.0 +0100
@@ -949,7 +949,7 @@
wake_up((to_iwch_qp(qp)-wait));
}
-struct ib_qp *iwch_get_qp(struct ib_device *dev, int qpn)
+static struct ib_qp *iwch_get_qp(struct ib_device *dev, int qpn)
{
PDBG(%s ib_dev %p qpn 0x%x\n, __FUNCTION__, dev, qpn);
return (struct ib_qp *)get_qhp(to_iwch_dev(dev), qpn);
---
[openib-general] Fwd: Address List Change for Friday, 2/23/2007
FYI. In case you missed it the first time: THIS LIST IS CHANGING ON FRIDAY 2/23/2007 (2 days from now). Please update your addressbooks! See the notice below for the details. Begin forwarded message: From: Lee, Michael Paichi [EMAIL PROTECTED] Date: February 19, 2007 10:43:23 AM EST To: openib-general@openib.org Subject: [openib-general] Address List Change for Friday, 2/23/2007 We're in the process of migrating the maillists from the old openib.org server to the new lists.openfabrics.org machine. The list openib-general will be moved this Friday, February 23, 2007. The new address for the maillist will be [EMAIL PROTECTED] What this means is that messages will come from [EMAIL PROTECTED] Conversely, replies should be made to this address as well. Messages will also have a new subject line prefix of [OFA General]. If you have configured your e-mail client to filter based on maillist address or subject headers, you may need to make some adjustments for filtering. However, for the sake of transition, messages sent to the previous maillist address on the old server will forward to the new server. This forward will remain in place until the old server is taken offline and final DNS changes are made. We expect the old server to go offline sometime in early March. The web archives will also be migrated to the new web address shortly, http://lists.openfabrics.org. If you have any questions, please don't hesitate to contact me at [EMAIL PROTECTED] Regards, Michael Lee ___ 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 -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ 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] Fwd: Address List Change for Friday, 2/23/2007
Could an example message be please sent *today* to the new list, so that client rules can be updated? I can't access my inbox on Friday or Saturday, and this change will cause problems and message loss for me unless I can prepare beforehand. Quoting Jeff Squyres [EMAIL PROTECTED]: Subject: Fwd: Address List Change for Friday, 2/23/2007 FYI. In case you missed it the first time: THIS LIST IS CHANGING ON FRIDAY 2/23/2007 (2 days from now). Please update your addressbooks! See the notice below for the details. Begin forwarded message: From: Lee, Michael Paichi [EMAIL PROTECTED] Date: February 19, 2007 10:43:23 AM EST To: openib-general@openib.org Subject: [openib-general] Address List Change for Friday, 2/23/2007 We're in the process of migrating the maillists from the old openib.org server to the new lists.openfabrics.org machine. The list openib-general will be moved this Friday, February 23, 2007. The new address for the maillist will be [EMAIL PROTECTED] What this means is that messages will come from [EMAIL PROTECTED] Conversely, replies should be made to this address as well. Messages will also have a new subject line prefix of [OFA General]. If you have configured your e-mail client to filter based on maillist address or subject headers, you may need to make some adjustments for filtering. However, for the sake of transition, messages sent to the previous maillist address on the old server will forward to the new server. This forward will remain in place until the old server is taken offline and final DNS changes are made. We expect the old server to go offline sometime in early March. The web archives will also be migrated to the new web address shortly, http://lists.openfabrics.org. If you have any questions, please don't hesitate to contact me at [EMAIL PROTECTED] Regards, Michael Lee ___ 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 -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ 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 -- 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] [ofw] [Fwd: Re: [Fwd: Re: winrelated[was:Re:[PATCH 1/2] opensm: sigusr1: syslog() fixes]]]
Tzachi, On Wed, 2007-02-21 at 03:47, Tzachi Dar wrote: OK, Hal let's try to close this. Thanks. The windows openib project was agreed by everyone to be BSD only. The fact that it is BSD means that any partner (or non partner) of the Community can download the code and use it, the way he wants. This includes: 1) Running the code as is. 2) Making changes to the code and contributing them back. 3) Making changes to the code and *NOT* giving them back to the community. Starting to depend on GPL (or LGPL) code means that the freedom of the users to do (3) is broken. Mellanox thinks that this needs a wider agreement of the open-IB consortium, which we don't have. The package in question is licensed with LGPL. I don't think that LGPL precludes usage #3 (although GPL precludes usage #3). See http://www.gnu.org/licenses/lgpl.html particularly #5 and #6. More than that, the ideas that were introduced here about sending users to other places in order for them to find the pthread implementation are also not that great as this starts to make the life of our users harder. Is this a major hurdle ? Is it substantially harder ? Also it is not clear who will give support once there are problems, I would think it is from wherever they get OpenSM support. That support may need to interact with this project on some basis. Is this different from Linux (and pthreads) ? I agree that it is a change from the existing model. and who is responsible that the license of the library won't change. I'm not sure how to answer this one but I don't think the license can just change. I guess if it did, we would need to deal with this when that occurred. Are you aware of some impending change here ? So, I hope this closes the subject of using LGPL software in open-IB. I don't think we're there yet... By the way, what implementation of pthreads were you thinking of? I have noticed that the first implementation that Google brings was only tested on uni-processor system. (http://sourceware.org/pthreads-win32/news.html). (this is really amazing, I thought that these servers were out of the market a long time ago). I think that is old information and this also supports 64 bit architectures as well. To be more practical: Can you give us a better view of what you are trying to achieve? In other words, as far as I know Opensm is using complib apis to handle threads. The implementation of this functions on windows is usually trivial. Do you intend to make a re-write of opensm so that it will use pthreads or do you intend to make a find/replace And replace the complib functions with Pthreads ones? If we are talking about the second, than one can simply implement the pthread functions using trivial win32 calls. And another question: What is the functionality that you are currently missing? Can this functionality be added? There will be another posting addressing these questions. -- Hal Thanks Tzachi By the way, rumors I have heard say that Voltaire doesn't always give it's code back to the community, but this are just rumors, right? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fab Tillier Sent: Tuesday, February 20, 2007 11:56 PM To: Hal Rosenstock Cc: ofw@lists.openfabrics.org; Gilad Shainer; OPENIB Subject: RE: [ofw] [Fwd: Re: [openib-general] [Fwd: Re: winrelated[was:Re:[PATCH 1/2] opensm: sigusr1: syslog() fixes]]] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hal Rosenstock Sent: Tuesday, February 20, 2007 1:43 PM On Tue, 2007-02-20 at 16:08, Fab Tillier wrote: -Original Message- From: Hal Rosenstock [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 20, 2007 10:57 AM On Tue, 2007-02-20 at 13:56, Fab Tillier wrote: [ftillier] This isn't just an install issue - it's a build issue. Anyone that wants to build OpenSM will need to find/download/install the pthreads library so that the build will succeed. If linking statically, the resulting executable will not require any special installation. It's only an install issue if you link dynamically to pitheads. OK; then build and install. How big an issue is this ? I thought DLLs were dynamically linked but I'm a Windows plebe. [ftillier] When you build, the linker needs the import library for pthreads so that the functions get resolved as being imported from the pthreads DLL. The dependency on the pthreads DLL is then created and the DLL will be loaded dynamically, assuming it can be found in the path. So for the build process, you need to have the pthreads library available to the build tool (path to the lib). This requires installing the pthreads developer package or however it's done. If you statically link the pthreads lib, rather than dynamically link, then all the pthreads goodies go directly into
Re: [openib-general] [ofw] [Fwd: Re: [Fwd: Re: winrelated[was:Re:[PATCH 1/2] opensm: sigusr1: syslog() fixes]]]
On Wed, 2007-02-21 at 09:31, Hal Rosenstock wrote: Tzachi, On Wed, 2007-02-21 at 03:47, Tzachi Dar wrote: OK, Hal let's try to close this. Thanks. The windows openib project was agreed by everyone to be BSD only. The fact that it is BSD means that any partner (or non partner) of the Community can download the code and use it, the way he wants. This includes: 1) Running the code as is. 2) Making changes to the code and contributing them back. 3) Making changes to the code and *NOT* giving them back to the community. Starting to depend on GPL (or LGPL) code means that the freedom of the users to do (3) is broken. Mellanox thinks that this needs a wider agreement of the open-IB consortium, which we don't have. The package in question is licensed with LGPL. I don't think that LGPL precludes usage #3 (although GPL precludes usage #3). See http://www.gnu.org/licenses/lgpl.html particularly #5 and #6. More than that, the ideas that were introduced here about sending users to other places in order for them to find the pthread implementation are also not that great as this starts to make the life of our users harder. Is this a major hurdle ? Is it substantially harder ? Also it is not clear who will give support once there are problems, I would think it is from wherever they get OpenSM support. That support may need to interact with this project on some basis. Is this different from Linux (and pthreads) ? I agree that it is a change from the existing model. and who is responsible that the license of the library won't change. I'm not sure how to answer this one but I don't think the license can just change. I guess if it did, we would need to deal with this when that occurred. Are you aware of some impending change here ? So, I hope this closes the subject of using LGPL software in open-IB. I don't think we're there yet... By the way, what implementation of pthreads were you thinking of? I have noticed that the first implementation that Google brings was only tested on uni-processor system. (http://sourceware.org/pthreads-win32/news.html). (this is really amazing, I thought that these servers were out of the market a long time ago). I think that is old information and this also supports 64 bit architectures as well. I think I found what you were referring to: http://sources.redhat.com/pthreads-win32/news.html RELEASE 2.8.0 - Testing and verification This release has not yet been tested on SMP architechtures. All tests pass on a uni-processor system. RELEASE 2.7.0 - Testing and verification This release has been tested (passed the test suite) on both uni-processor and multi-processor systems. Release 2.8.0 is relatively new (2006-12-22). To be more practical: Can you give us a better view of what you are trying to achieve? In other words, as far as I know Opensm is using complib apis to handle threads. The implementation of this functions on windows is usually trivial. Do you intend to make a re-write of opensm so that it will use pthreads or do you intend to make a find/replace And replace the complib functions with Pthreads ones? If we are talking about the second, than one can simply implement the pthread functions using trivial win32 calls. And another question: What is the functionality that you are currently missing? Can this functionality be added? There will be another posting addressing these questions. -- Hal Thanks Tzachi By the way, rumors I have heard say that Voltaire doesn't always give it's code back to the community, but this are just rumors, right? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fab Tillier Sent: Tuesday, February 20, 2007 11:56 PM To: Hal Rosenstock Cc: ofw@lists.openfabrics.org; Gilad Shainer; OPENIB Subject: RE: [ofw] [Fwd: Re: [openib-general] [Fwd: Re: winrelated[was:Re:[PATCH 1/2] opensm: sigusr1: syslog() fixes]]] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hal Rosenstock Sent: Tuesday, February 20, 2007 1:43 PM On Tue, 2007-02-20 at 16:08, Fab Tillier wrote: -Original Message- From: Hal Rosenstock [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 20, 2007 10:57 AM On Tue, 2007-02-20 at 13:56, Fab Tillier wrote: [ftillier] This isn't just an install issue - it's a build issue. Anyone that wants to build OpenSM will need to find/download/install the pthreads library so that the build will succeed. If linking statically, the resulting executable will not require any special installation. It's only an install issue if you link dynamically to pitheads. OK; then build and install. How big an issue is this ? I thought DLLs were dynamically
Re: [openib-general] Address List Change for Friday, 2/23/2007
Can you look at the other lists that have migrated for examples? (e.g., ewg) It may be complex to send an actual example message *before* the list moves. On Feb 21, 2007, at 9:21 AM, Michael S. Tsirkin wrote: Could an example message be please sent *today* to the new list, so that client rules can be updated? I can't access my inbox on Friday or Saturday, and this change will cause problems and message loss for me unless I can prepare beforehand. Quoting Jeff Squyres [EMAIL PROTECTED]: Subject: Fwd: Address List Change for Friday, 2/23/2007 FYI. In case you missed it the first time: THIS LIST IS CHANGING ON FRIDAY 2/23/2007 (2 days from now). Please update your addressbooks! See the notice below for the details. Begin forwarded message: From: Lee, Michael Paichi [EMAIL PROTECTED] Date: February 19, 2007 10:43:23 AM EST To: openib-general@openib.org Subject: [openib-general] Address List Change for Friday, 2/23/2007 We're in the process of migrating the maillists from the old openib.org server to the new lists.openfabrics.org machine. The list openib-general will be moved this Friday, February 23, 2007. The new address for the maillist will be [EMAIL PROTECTED] What this means is that messages will come from [EMAIL PROTECTED] Conversely, replies should be made to this address as well. Messages will also have a new subject line prefix of [OFA General]. If you have configured your e-mail client to filter based on maillist address or subject headers, you may need to make some adjustments for filtering. However, for the sake of transition, messages sent to the previous maillist address on the old server will forward to the new server. This forward will remain in place until the old server is taken offline and final DNS changes are made. We expect the old server to go offline sometime in early March. The web archives will also be migrated to the new web address shortly, http://lists.openfabrics.org. If you have any questions, please don't hesitate to contact me at [EMAIL PROTECTED] Regards, Michael Lee ___ 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 -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ 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 -- MST -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ 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] OFED-1.2-20070221-1741.tgz package is available
On Wed, 2007-02-21 at 12:02 -0600, Steve Wise wrote: Hey Vlad, What about bugs: 355 and 357? Bug: 355 (problems building modules that depend on OFED 1.2 modules) In order to build kernel modules depending on OFED's modules you need to take Modules.symvers file from prefix/src/openib/Modules.symvers (part of kernel-ib-devel RPM) and copy this to modules subdir and then compile your module. Currently I see that prefix/src/openib/Modules.symvers is empty. I will check this issue. For now you can use the attached script to create Modules.symvers file. Bug: 357 (cxgb3 can't be selected on sles9sp3) cxgb3 driver compilation failed on sles9sp3 in previous OFED build. Then it was disabled in build_env.sh script in order to prevent OFED installation failure. Did you fixed this compilation issue? -- Vladimir Sokolovsky [EMAIL PROTECTED] Mellanox Technologies Ltd. create_Module.symvers.sh Description: application/shellscript ___ 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] [ewg] Re: OFED-1.2-20070221-1741.tgz package is available
On Wed, 2007-02-21 at 20:14 +0200, Michael S. Tsirkin wrote: Steve, can't you post a patch for 357? I could, but I'm not sure what is _not_ supported for SLES9SP3. The script currently only allows mthca, sdp, and ipoib. cxgb3 should be allowed. But probably most other drivers too... I can provide a patch to allow cxgb3 if that's what you want... Steve. ___ 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] Git on hosting.openfabrics.org server seems broken
I appears that when I clone anyone's git tree locally on the hosting.openfabrics.org server, it only clones the master branch and I get none of the branches. The only difference in what I do now from what I did before is that the git version on the server is now 1.5.0., and before it was git version 1.4.4.3. Has anyone tried to do a clone of a git tree on the server lately ? Can you see the git branches of the cloned tree with git-branch. woody ___ 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] Git on hosting.openfabrics.org server seems broken
On 10:49 Wed 21 Feb , Woodruff, Robert J wrote: I appears that when I clone anyone's git tree locally on the hosting.openfabrics.org server, it only clones the master branch and I get none of the branches. The only difference in what I do now from what I did before is that the git version on the server is now 1.5.0., and before it was git version 1.4.4.3. Default branch layout was slightly changed with 1.5.0. Look at: http://lkml.org/lkml/2007/2/13/426 (but I think it should be due to your local git version, not?) Has anyone tried to do a clone of a git tree on the server lately ? Can you see the git branches of the cloned tree with git-branch. git-branch -r Sasha ___ 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] Git on hosting.openfabrics.org server seems broken
Aaarg!!! Not only is git terse and difficult to use, but once you finally learn the commands, they change them on you in the next version. -Original Message- From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 11:09 AM To: Woodruff, Robert J Cc: OPENIB; Michael S. Tsirkin Subject: Re: Git on hosting.openfabrics.org server seems broken On 10:49 Wed 21 Feb , Woodruff, Robert J wrote: I appears that when I clone anyone's git tree locally on the hosting.openfabrics.org server, it only clones the master branch and I get none of the branches. The only difference in what I do now from what I did before is that the git version on the server is now 1.5.0., and before it was git version 1.4.4.3. Default branch layout was slightly changed with 1.5.0. Look at: http://lkml.org/lkml/2007/2/13/426 (but I think it should be due to your local git version, not?) Has anyone tried to do a clone of a git tree on the server lately ? Can you see the git branches of the cloned tree with git-branch. git-branch -r Sasha ___ 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] IB routing discussion summary
I sent a message on this topic to the IBTA several days ago, but I am still awaiting details (likely early next week). It should not be carried in the CM REQ. The SLID / DLID of the router ports should be derived through local subnet SA / SM query. When a CM REQ traverses one or more subnets there will be potentially many SLID / DLID involved in the communication. Each router should be populating its routing tables in order to build the new LRH attached to the GRH / CM REQ that it is forwarding to the next hop. I'm referring to configuration of the QP, not the operation of the routers. To establish a connection, the passive side QP needs to transition from Init to RTR. As part of that transition, the modify QP verb needs as input the Destination LID of its local router. It sounds like you expect the passive side to perform an SA query to obtain its own local routing information, which would essentially invalidate the data carried in the primary and alternate path fields in the CM REQ. From reading 12.7.11, 13.5.1, and 17.4, I do not believe that such a requirement was expected to be placed on the passive side of a connection. The initial response I received agreed with this. I'd need to go back but the architecture is predicated that the SM and SA are strictly local and for security purposes their communication should remain local. Higher level management entities built to communicate with SM and SA are responsible for cross subnet communications without exposing the SA or SM to direct interaction. P_Key and Q_Key management across subnets is an example of such communication across subnets that would not be exposed to the SA and SM. My initial thoughts are that this sounds like a good idea. It's not eliminating the need for interacting with a remote SA, so much as it abstracts it to another entity. My hope is that we can reach an agreement on the CM REQ. Depending on that, it still needs to determine if the existing SA attributes are sufficient to allow forming inter-subnet connections, and if they are, can such attributes be obtained. - 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 2/21/07, Sean Hefty [EMAIL PROTECTED] wrote: However, no matter what the SM configures, the core ipoib code act as the full pkey is there. This is nice simplification and it works well. Is the problem here really in the librdmacm or in the core/ipoib software? There is no problem. As i have explained over this thread the ipoib and the core abstract away from the user the actual value of the MSb of the pkey, that is whether it is a full or partial membership pkey. IPoIB does it by OR-ing 0x8000 to the pkey it uses and the core does it in ib_find_cached_pkey() which when provided a pkey, return the index of $pkey or of $pkey 0x7fff which ever one of the them is there. The only missing piece is for librdmacm to play this game as well and the patch does this. (I looked at the patch, but haven't looked into the full reason why it's needed.) start with checking me... tell the SM to configure 0x7fff instead of 0x to one of your nodes as the pkey at index 0, then see that ping is working but librdmacm RC utils such as rping or ib_rdma_bw -c do not. Then apply the patch and check again. Or. Or. ___ 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
There is no problem. As i have explained over this thread the ipoib and the core abstract away from the user the actual value of the MSb of the pkey, that is whether it is a full or partial membership pkey. But *why* does the kernel code do this, and should it? - 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 21 Feb 2007 08:20:23 -0500, Hal Rosenstock [EMAIL PROTECTED] wrote: On Wed, 2007-02-21 at 07:35, Or Gerlitz wrote: I believe it is a spec (compliance) violation for the port to be a partial member and join as a full member. Since partial members can't talk among themselves, there is no reason to form a multicast group containing --only-- ports that can --not-- talk to each other... So if the spec does not allow this (having a partial member joining with the full member pkey) - it a spec bug... I think there are two issues here then: 1. If this is the case, getting the spec changed to accomodate this use case 2. I believe that OpenIB code is supposed to be spec compliant. If the IPoIB spec does not allow both partial and full members of a partition to share a broadcast domain (eg the IPv4 broadcast group associated with the full membership pkey) or any other multicast group, burn it (or at least the relevant section). The OpenIB code supposed to work and as done with the RDMA CM header, the implementation should not wait for spec to be written or changed. Or. ___ 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 ofed_1_2] iw_cxgb3: Stop the EP Timer on BAD CLOSE.
Stop the ep timer in ec_status() if the status indicates a bad close. Signed-off-by: Steve Wise [EMAIL PROTECTED] --- drivers/infiniband/hw/cxgb3/iwch_cm.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c b/drivers/infiniband/hw/cxgb3/iwch_cm.c index e5442e3..d00e5dd 100644 --- a/drivers/infiniband/hw/cxgb3/iwch_cm.c +++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c @@ -1635,6 +1635,7 @@ static int ec_status(struct t3cdev *tdev printk(KERN_ERR MOD %s BAD CLOSE - Aborting tid %u\n, __FUNCTION__, ep-hwtid); + stop_ep_timer(ep); attrs.next_state = IWCH_QP_STATE_ERROR; iwch_modify_qp(ep-com.qp-rhp, ep-com.qp, IWCH_QP_ATTR_NEXT_STATE, ___ 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 1/2] ofed_1_2 Fix copyrights in the cxgb3 driver.
Vlad, Please apply this to ofed_1_2. Thanks, Steve. On Thu, 2007-02-15 at 13:59 -0600, Steve Wise wrote: Fix copyrights in the cxgb3 driver. Remove the Open Grid Computing copyright. It shouldn't be there. Signed-off-by: Steve Wise [EMAIL PROTECTED] --- drivers/net/cxgb3/cxgb3_defs.h|1 - drivers/net/cxgb3/cxgb3_offload.c |1 - drivers/net/cxgb3/cxgb3_offload.h |1 - drivers/net/cxgb3/l2t.c |1 - drivers/net/cxgb3/l2t.h |1 - drivers/net/cxgb3/t3cdev.h|1 - 6 files changed, 0 insertions(+), 6 deletions(-) diff --git a/drivers/net/cxgb3/cxgb3_defs.h b/drivers/net/cxgb3/cxgb3_defs.h old mode 100755 new mode 100644 index 16e0049..e14862b --- a/drivers/net/cxgb3/cxgb3_defs.h +++ b/drivers/net/cxgb3/cxgb3_defs.h @@ -1,6 +1,5 @@ /* * Copyright (c) 2006-2007 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006-2007 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU diff --git a/drivers/net/cxgb3/cxgb3_offload.c b/drivers/net/cxgb3/cxgb3_offload.c old mode 100755 new mode 100644 index c3a02d6..46e9068 --- a/drivers/net/cxgb3/cxgb3_offload.c +++ b/drivers/net/cxgb3/cxgb3_offload.c @@ -1,6 +1,5 @@ /* * Copyright (c) 2006-2007 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006-2007 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU diff --git a/drivers/net/cxgb3/cxgb3_offload.h b/drivers/net/cxgb3/cxgb3_offload.h old mode 100755 new mode 100644 index 0e6beb6..f15446a --- a/drivers/net/cxgb3/cxgb3_offload.h +++ b/drivers/net/cxgb3/cxgb3_offload.h @@ -1,6 +1,5 @@ /* * Copyright (c) 2006-2007 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006-2007 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU diff --git a/drivers/net/cxgb3/l2t.c b/drivers/net/cxgb3/l2t.c old mode 100755 new mode 100644 index 3c0cb85..d660af7 --- a/drivers/net/cxgb3/l2t.c +++ b/drivers/net/cxgb3/l2t.c @@ -1,6 +1,5 @@ /* * Copyright (c) 2003-2007 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006-2007 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU diff --git a/drivers/net/cxgb3/l2t.h b/drivers/net/cxgb3/l2t.h old mode 100755 new mode 100644 index ba5d2cb..d790013 --- a/drivers/net/cxgb3/l2t.h +++ b/drivers/net/cxgb3/l2t.h @@ -1,6 +1,5 @@ /* * Copyright (c) 2003-2007 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006-2007 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU diff --git a/drivers/net/cxgb3/t3cdev.h b/drivers/net/cxgb3/t3cdev.h old mode 100755 new mode 100644 index 9af3bcd..fa4099b --- a/drivers/net/cxgb3/t3cdev.h +++ b/drivers/net/cxgb3/t3cdev.h @@ -1,6 +1,5 @@ /* * Copyright (C) 2006-2007 Chelsio Communications. All rights reserved. - * Copyright (C) 2006-2007 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU ___ 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 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/2] ofed_1_2 Fix copyrights in the iw_cxgb3 driver.
And this one too... Thanks, Steve. On Thu, 2007-02-15 at 14:00 -0600, Steve Wise wrote: Fix copyrights in the iw_cxgb3 driver. Remove the Open Grid Computing copyright. It shouldn't be there. Signed-off-by: Steve Wise [EMAIL PROTECTED] --- drivers/infiniband/hw/cxgb3/core/cxio_dbg.c |1 - drivers/infiniband/hw/cxgb3/core/cxio_hal.c |1 - drivers/infiniband/hw/cxgb3/core/cxio_hal.h |1 - drivers/infiniband/hw/cxgb3/core/cxio_resource.c |1 - drivers/infiniband/hw/cxgb3/core/cxio_resource.h |1 - drivers/infiniband/hw/cxgb3/core/cxio_wr.h |1 - drivers/infiniband/hw/cxgb3/iwch.c |1 - drivers/infiniband/hw/cxgb3/iwch.h |1 - drivers/infiniband/hw/cxgb3/iwch_cm.c|1 - drivers/infiniband/hw/cxgb3/iwch_cm.h|1 - drivers/infiniband/hw/cxgb3/iwch_cq.c|1 - drivers/infiniband/hw/cxgb3/iwch_ev.c|1 - drivers/infiniband/hw/cxgb3/iwch_mem.c |1 - drivers/infiniband/hw/cxgb3/iwch_provider.c |1 - drivers/infiniband/hw/cxgb3/iwch_provider.h |1 - drivers/infiniband/hw/cxgb3/iwch_qp.c|1 - drivers/infiniband/hw/cxgb3/iwch_user.h |1 - 17 files changed, 0 insertions(+), 17 deletions(-) diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_dbg.c b/drivers/infiniband/hw/cxgb3/core/cxio_dbg.c index dfaa704..d6b6c97 100644 --- a/drivers/infiniband/hw/cxgb3/core/cxio_dbg.c +++ b/drivers/infiniband/hw/cxgb3/core/cxio_dbg.c @@ -1,6 +1,5 @@ /* * Copyright (c) 2006 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_hal.c b/drivers/infiniband/hw/cxgb3/core/cxio_hal.c index 5e31816..229edd5 100644 --- a/drivers/infiniband/hw/cxgb3/core/cxio_hal.c +++ b/drivers/infiniband/hw/cxgb3/core/cxio_hal.c @@ -1,6 +1,5 @@ /* * Copyright (c) 2006 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_hal.h b/drivers/infiniband/hw/cxgb3/core/cxio_hal.h index e5e702d..1553bda 100644 --- a/drivers/infiniband/hw/cxgb3/core/cxio_hal.h +++ b/drivers/infiniband/hw/cxgb3/core/cxio_hal.h @@ -1,6 +1,5 @@ /* * Copyright (c) 2006 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_resource.c b/drivers/infiniband/hw/cxgb3/core/cxio_resource.c index d1d8722..cf78050 100644 --- a/drivers/infiniband/hw/cxgb3/core/cxio_resource.c +++ b/drivers/infiniband/hw/cxgb3/core/cxio_resource.c @@ -1,6 +1,5 @@ /* * Copyright (c) 2006 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_resource.h b/drivers/infiniband/hw/cxgb3/core/cxio_resource.h index a6bbe83..a2703a3 100644 --- a/drivers/infiniband/hw/cxgb3/core/cxio_resource.h +++ b/drivers/infiniband/hw/cxgb3/core/cxio_resource.h @@ -1,6 +1,5 @@ /* * Copyright (c) 2006 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU diff --git a/drivers/infiniband/hw/cxgb3/core/cxio_wr.h b/drivers/infiniband/hw/cxgb3/core/cxio_wr.h index 234a084..6c7ac55 100644 --- a/drivers/infiniband/hw/cxgb3/core/cxio_wr.h +++ b/drivers/infiniband/hw/cxgb3/core/cxio_wr.h @@ -1,6 +1,5 @@ /* * Copyright (c) 2006 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a choice of one of two * licenses. You may choose to be licensed under the terms of the GNU diff --git a/drivers/infiniband/hw/cxgb3/iwch.c b/drivers/infiniband/hw/cxgb3/iwch.c index 0c95f2c..de44c57 100644 --- a/drivers/infiniband/hw/cxgb3/iwch.c +++ b/drivers/infiniband/hw/cxgb3/iwch.c @@ -1,6 +1,5 @@ /* * Copyright (c) 2006 Chelsio, Inc. All rights reserved. - * Copyright (c) 2006 Open Grid Computing, Inc. All rights reserved. * * This software is available to you under a
Re: [openib-general] [PATCH] librdmacm: fix bug causing failure to work with partial membership pkey
On 2/21/07, Sean Hefty [EMAIL PROTECTED] wrote: There is no problem. As i have explained over this thread the ipoib and the core abstract away from the user the actual value of the MSb of the pkey, that is whether it is a full or partial membership pkey. But *why* does the kernel code do this, and should it? It does this since its makes life simple and robust. Note that since the HCA validates the pkey in the in coming packet, no matter what the IB SW would do, partial members of a partition can't talk to each other. So the approach taken by the core/ipoib code was to just ignore the MSb in places where the code looks for the pkey --index-- and use the full member pkey when forming MGIDs. This seems fine to me. Or. ___ 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 2.6.21] iw_cxgb3: Stop the EP Timer on BAD CLOSE.
Stop the ep timer in ec_status() if the status indicates a bad close. Signed-off-by: Steve Wise [EMAIL PROTECTED] --- drivers/infiniband/hw/cxgb3/iwch_cm.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c b/drivers/infiniband/hw/cxgb3/iwch_cm.c index e5442e3..d00e5dd 100644 --- a/drivers/infiniband/hw/cxgb3/iwch_cm.c +++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c @@ -1635,6 +1635,7 @@ static int ec_status(struct t3cdev *tdev printk(KERN_ERR MOD %s BAD CLOSE - Aborting tid %u\n, __FUNCTION__, ep-hwtid); + stop_ep_timer(ep); attrs.next_state = IWCH_QP_STATE_ERROR; iwch_modify_qp(ep-com.qp-rhp, ep-com.qp, IWCH_QP_ATTR_NEXT_STATE, ___ 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 Wed, 2007-02-21 at 15:45, Or Gerlitz wrote: On 21 Feb 2007 08:20:23 -0500, Hal Rosenstock [EMAIL PROTECTED] wrote: On Wed, 2007-02-21 at 07:35, Or Gerlitz wrote: I believe it is a spec (compliance) violation for the port to be a partial member and join as a full member. Since partial members can't talk among themselves, there is no reason to form a multicast group containing --only-- ports that can --not-- talk to each other... So if the spec does not allow this (having a partial member joining with the full member pkey) - it a spec bug... I think there are two issues here then: 1. If this is the case, getting the spec changed to accomodate this use case 2. I believe that OpenIB code is supposed to be spec compliant. If the IPoIB spec does not allow both partial and full members of a partition to share a broadcast domain (eg the IPv4 broadcast group associated with the full membership pkey) or any other multicast group, burn it (or at least the relevant section). I was referring to the IB spec, not an IPoIB RFC. The OpenIB code supposed to work and as done with the RDMA CM header, the implementation should not wait for spec to be written or changed. Really ? Maybe I'm mistaken but I didn't think that OpenIB/OpenFabrics wanted to issue code which is not IBA spec compliant. -- Hal Or. ___ 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
It does this since its makes life simple and robust. Is an SM prevented from loading two PKeys into an HCA's PKey table that differ by only the membership bit? I can't think of any reason to do such a thing, but depending on which index was selected could limit which nodes you could communicate with. Note that since the HCA validates the pkey in the in coming packet, no matter what the IB SW would do, partial members of a partition can't talk to each other. So the approach taken by the core/ipoib code was to just ignore the MSb in places where the code looks for the pkey --index-- and use the full member pkey when forming MGIDs. This seems fine to me. My concern is that ib_find_cached_pkey() returns an index to a pkey that wasn't the one in the search. Can this lead to a QP being configured in such a way that communication with a remote QP would silently fail? I realize that a user could call ib_get_cached_pkey and see if the returned value matches the one in the original search, but this is a non-obvious way to check for a mismatch. I'm not against this patch, but I want to make sure that I understand the issues, so we're not creating a work-around solution. The patch is against the librdmacm, yet there's nothing that I see in the librdmacm that makes me think it's behaving incorrectly. - 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] OFED-1.2-20070221-1741.tgz package is available
Vlad: On Wed, 2007-02-21 at 20:16 +0200, Vladimir Sokolovsky wrote: On Wed, 2007-02-21 at 12:02 -0600, Steve Wise wrote: Hey Vlad, What about bugs: 355 and 357? Bug: 355 (problems building modules that depend on OFED 1.2 modules) In order to build kernel modules depending on OFED's modules you need to take Modules.symvers file from prefix/src/openib/Modules.symvers (part of kernel-ib-devel RPM) and copy this to modules subdir and then compile your module. Won't this blow away all the version information for the non-IB symbols? Currently I see that prefix/src/openib/Modules.symvers is empty. I will check this issue. For now you can use the attached script to create Modules.symvers file. Bug: 357 (cxgb3 can't be selected on sles9sp3) cxgb3 driver compilation failed on sles9sp3 in previous OFED build. Then it was disabled in build_env.sh script in order to prevent OFED installation failure. Did you fixed this compilation issue? ___ 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 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] GetTable path record query not returningDGID=SGID paths
We haven't looked into this in more detail yet. This was our observation while testing on a larger (64 node) cluster this morning that we don't have access to at the moment. With the local SA cache running, we were surprised to see any retries, and when we looked into it more, retries were always for loopback connections. Our investigation showed a couple of things. When we pulled our systems off into a small cluster and ran opensm, things were fine. The cache was working as normal, and we did get loopback paths from opensm. On our development cluster, the cache was never getting any path records. It would issue a GetTable query, and the SM would respond. The response had a status of 0 (success), but never returned any path records. I believe that the SM node is running OFED 1.1.1. I don't have the ability to modify the kernel on the larger 64-node cluster that we were testing on to see what is going on there. - 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 Wed, 2007-02-21 at 17:36, Sean Hefty wrote: It does this since its makes life simple and robust. Is an SM prevented from loading two PKeys into an HCA's PKey table that differ by only the membership bit? Nope. I can't think of any reason to do such a thing, Me neither. It would be a configuration error of sorts. but depending on which index was selected could limit which nodes you could communicate with. Note that since the HCA validates the pkey in the in coming packet, no matter what the IB SW would do, partial members of a partition can't talk to each other. So the approach taken by the core/ipoib code was to just ignore the MSb in places where the code looks for the pkey --index-- and use the full member pkey when forming MGIDs. This seems fine to me. My concern is that ib_find_cached_pkey() returns an index to a pkey that wasn't the one in the search. Can this lead to a QP being configured in such a way that communication with a remote QP would silently fail? I realize that a user could call ib_get_cached_pkey and see if the returned value matches the one in the original search, but this is a non-obvious way to check for a mismatch. I'm not against this patch, but I want to make sure that I understand the issues, so we're not creating a work-around solution. The patch is against the librdmacm, yet there's nothing that I see in the librdmacm that makes me think it's behaving incorrectly. I'm not sure it's this patch in particular but it appears that there may be some non compliant behavior being exercised IMO. -- Hal - 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] GetTable path record query not returningDGID=SGID paths
On Wed, 2007-02-21 at 18:05, Sean Hefty wrote: We haven't looked into this in more detail yet. This was our observation while testing on a larger (64 node) cluster this morning that we don't have access to at the moment. With the local SA cache running, we were surprised to see any retries, and when we looked into it more, retries were always for loopback connections. Our investigation showed a couple of things. When we pulled our systems off into a small cluster and ran opensm, things were fine. The cache was working as normal, and we did get loopback paths from opensm. On our development cluster, the cache was never getting any path records. It would issue a GetTable query, and the SM would respond. The response had a status of 0 (success), but never returned any path records. I believe that the SM node is running OFED 1.1.1. I'm unaware of any changes in this area of OpenSM which would cause this but maybe I'm forgetting something. Can you run opensm with -V and send the logs to me ? This should be instructive. -- Hal I don't have the ability to modify the kernel on the larger 64-node cluster that we were testing on to see what is going on there. - 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 Wed, 2007-02-21 at 17:53, Hal Rosenstock wrote: On Wed, 2007-02-21 at 17:36, Sean Hefty wrote: It does this since its makes life simple and robust. Is an SM prevented from loading two PKeys into an HCA's PKey table that differ by only the membership bit? Nope. I can't think of any reason to do such a thing, Me neither. It would be a configuration error of sorts. It is vendor dependent whether the SM would allow this. As Sasha points out, this cannot be done with OpenSM (at least currently). -- Hal but depending on which index was selected could limit which nodes you could communicate with. Note that since the HCA validates the pkey in the in coming packet, no matter what the IB SW would do, partial members of a partition can't talk to each other. So the approach taken by the core/ipoib code was to just ignore the MSb in places where the code looks for the pkey --index-- and use the full member pkey when forming MGIDs. This seems fine to me. My concern is that ib_find_cached_pkey() returns an index to a pkey that wasn't the one in the search. Can this lead to a QP being configured in such a way that communication with a remote QP would silently fail? I realize that a user could call ib_get_cached_pkey and see if the returned value matches the one in the original search, but this is a non-obvious way to check for a mismatch. I'm not against this patch, but I want to make sure that I understand the issues, so we're not creating a work-around solution. The patch is against the librdmacm, yet there's nothing that I see in the librdmacm that makes me think it's behaving incorrectly. I'm not sure it's this patch in particular but it appears that there may be some non compliant behavior being exercised IMO. -- Hal - 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 ___ 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] I created a git tree for the libibverbs man pages
Hi, Roland: What is the Max # of cards OFED driver/library can support on a single node ? Thanks. --CQ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roland Dreier Sent: Tuesday, February 20, 2007 6:12 PM To: Dotan Barak Cc: openib-general Subject: Re: [openib-general] I created a git tree for the libibverbs man pages I merged all these manpages into my libibverbs tree and pushed the result out to kernel.org. Please send any future updates as diffs against the libibverbs tree. Thanks, Roland ___ 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 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] I created a git tree for the libibverbs man pages
What is the Max # of cards OFED driver/library can support on a single node ? The lowest limit I know of is the # of device minors available for /dev/infiniband/uverbs files, which is 32. How many devices are you interested in supporting? This limit could probably be increased without too much trouble, but I doubt any realistic system will run into it anyway. - 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] [RFC/BUG] DMA vs. CQ race
In: http://openib.org/pipermail/openib-general/2006-December/030251.html I described a potential race between DMA and CQ updates on Altix systems. At that time the bug hadn't been observed, but was expected to be possible on large NUMA systems. A first-cut at a patch was sent out, some very reasonable objections were raised, and the thread fizzled out. Since that time we've been able to produce the bug, and show that the patch I sent fixes the problem. (OK, the patch I sent with the addition of a small but important patchlet.) The biggest concern with the earlier patch seemed to be backward compatibility. There was a stab at addressing that in http://tinyurl.com/2x3s52, but no commentary. (Too ugly for words?) Any suggestions as to how to proceed? Should I just code something up in order to have a concrete target to discuss? Or are there any new thoughts based on the previous emails? -- Arthur ___ 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] I created a git tree for the libibverbs man pages
Roland Dreier wrote: I merged all these manpages into my libibverbs tree and pushed the result out to kernel.org. Please send any future updates as diffs against the libibverbs tree. Thanks, Roland those are great news, thanks. Before the OFED 1.2 release i plan to send you a patch to fix some issues. thank again Dotan ___ 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] anyone have OFED 1.2 alpha1 compiling on ppc64
I tried both RHEL4 and SLES10 usinstall.sh, and get this. I filed bug 379, anyone else tried ppc64? gcc -DHAVE_CONFIG_H -I. -I. -I. -I./include/infiniband -I./../libibcommon/incl\ ude/infiniband -Wall -m64 -g -O2 -MT libibumad_la-umad.lo -MD -MP -MF .deps/lib\ ibumad_la-umad.Tpo -c src/umad.c -fPIC -DPIC -o .libs/libibumad_la-umad.o In file included from src/umad.c:50: ./include/infiniband/umad.h:37:31: infiniband/common.h: No such file or directo\ ry src/umad.c: In function `port_alloc': src/umad.c:94: warning: implicit declaration of function `IBWARN' src/umad.c: In function `get_port': src/umad.c:160: warning: implicit declaration of function `snprintf' src/umad.c:163: warning: implicit declaration of function `sys_read_uint' src/umad.c:177: warning: implicit declaration of function `sys_read_uint64' src/umad.c:182: warning: implicit declaration of function `sys_read_gid' src/umad.c: In function `get_ca': src/umad.c:354: warning: implicit declaration of function `sys_read_string' src/umad.c:363: warning: implicit declaration of function `sys_read_guid' make[3]: *** [libibumad_la-umad.lo] Error 1 make[3]: Leaving directory `/var/tmp/OFEDRPM/BUILD/ofa_user-1.2/src/userspace/m\ anagement/libibumad' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/OFEDRPM/BUILD/ofa_user-1.2/src/userspace/m\ anagement/libibumad' make[1]: *** [all] Error 2 make[1]: Leaving directory `/var/tmp/OFEDRPM/BUILD/ofa_user-1.2/src/userspace/m\ anagement/libibumad' make: *** [subdirs] Error 1 make: Leaving directory `/var/tmp/OFEDRPM/BUILD/ofa_user-1.2/src/userspace/mana\ gement' Scott Weitzenkamp SQA and Release Manager Server Virtualization Business Unit Cisco Systems ___ 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
Hal Rosenstock wrote: On Wed, 2007-02-21 at 15:45, Or Gerlitz wrote: On 21 Feb 2007 08:20:23 -0500, Hal Rosenstock [EMAIL PROTECTED] wrote: If the IPoIB spec does not allow both partial and full members of a partition to share a broadcast domain (eg the IPv4 broadcast group associated with the full membership pkey) or any other multicast group, burn it (or at least the relevant section). I was referring to the IB spec, not an IPoIB RFC. Can you provide a pointer? The OpenIB code supposed to work and as done with the RDMA CM header, the implementation should not wait for spec to be written or changed. Really ? Maybe I'm mistaken but I didn't think that OpenIB/OpenFabrics wanted to issue code which is not IBA spec compliant. The code resides in the Linux kernel, period. Linux is not under the control of this or that organization, period, period. Linux uses an hierarchic maintainship structure where Roland, Sean and yourself are listed as the maintainers, which means you are able to promote and/or block this or that agenda, go for it! Or. ___ 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
