* One Million Pounds has been Awarded to in you in our BT PROMO.Send your
From: British Telecom @ 2010-05-20 6:28 UTC (permalink / raw)
To: info-AyqxTnQTQtw
Names...
Country...
Occupation...
Tel...
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 01/11] RDMA/cxgb4: Detach from the LLD after unregistering with the RDMA core.
From: Steve Wise @ 2010-05-20 21:57 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In the RDMA core unregister path, kernel users will be calling down
into the T4 provider to release resources. So we cannot detach from
the LLD until this process completes.
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/device.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/device.c b/drivers/infiniband/hw/cxgb4/device.c
index be23b5e..c7e2484 100644
--- a/drivers/infiniband/hw/cxgb4/device.c
+++ b/drivers/infiniband/hw/cxgb4/device.c
@@ -504,14 +504,12 @@ static void __exit c4iw_exit_module(void)
{
struct c4iw_dev *dev, *tmp;
- cxgb4_unregister_uld(CXGB4_ULD_RDMA);
-
mutex_lock(&dev_mutex);
list_for_each_entry_safe(dev, tmp, &dev_list, entry) {
c4iw_remove(dev);
}
mutex_unlock(&dev_mutex);
-
+ cxgb4_unregister_uld(CXGB4_ULD_RDMA);
c4iw_cm_term();
debugfs_remove_recursive(c4iw_debugfs_root);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 02/11] RDMA/cxgb4: register rdma provider based on LLD state_change events.
From: Steve Wise @ 2010-05-20 21:57 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100520215727.32394.90669.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
The LLD now supports proper UP state change events, so move the rdma
provider registration to UP path.
NOTE: This fixes a crash when loading iw_cxgb4 _after_ the NFSRDMA
transport is up and running.
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/device.c | 46 +++++++++++++++++++++++++-------
drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 1 +
drivers/infiniband/hw/cxgb4/provider.c | 2 +
3 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/device.c b/drivers/infiniband/hw/cxgb4/device.c
index c7e2484..d870f9c 100644
--- a/drivers/infiniband/hw/cxgb4/device.c
+++ b/drivers/infiniband/hw/cxgb4/device.c
@@ -306,7 +306,8 @@ static void c4iw_remove(struct c4iw_dev *dev)
PDBG("%s c4iw_dev %p\n", __func__, dev);
cancel_delayed_work_sync(&dev->db_drop_task);
list_del(&dev->entry);
- c4iw_unregister_device(dev);
+ if (dev->registered)
+ c4iw_unregister_device(dev);
c4iw_rdev_close(&dev->rdev);
idr_destroy(&dev->cqidr);
idr_destroy(&dev->qpidr);
@@ -343,12 +344,6 @@ static struct c4iw_dev *c4iw_alloc(const struct cxgb4_lld_info *infop)
list_add_tail(&devp->entry, &dev_list);
mutex_unlock(&dev_mutex);
- if (c4iw_register_device(devp)) {
- printk(KERN_ERR MOD "Unable to register device\n");
- mutex_lock(&dev_mutex);
- c4iw_remove(devp);
- mutex_unlock(&dev_mutex);
- }
if (c4iw_debugfs_root) {
devp->debugfs_root = debugfs_create_dir(
pci_name(devp->rdev.lldi.pdev),
@@ -379,9 +374,6 @@ static void *c4iw_uld_add(const struct cxgb4_lld_info *infop)
for (i = 0; i < dev->rdev.lldi.nrxq; i++)
PDBG("rxqid[%u] %u\n", i, dev->rdev.lldi.rxq_ids[i]);
-
- printk(KERN_INFO MOD "Initialized device %s\n",
- pci_name(dev->rdev.lldi.pdev));
out:
return dev;
}
@@ -471,7 +463,41 @@ nomem:
static int c4iw_uld_state_change(void *handle, enum cxgb4_state new_state)
{
+ struct c4iw_dev *dev = handle;
+
PDBG("%s new_state %u\n", __func__, new_state);
+ switch (new_state) {
+ case CXGB4_STATE_UP:
+ printk(KERN_INFO MOD "%s: Up\n", pci_name(dev->rdev.lldi.pdev));
+ if (!dev->registered) {
+ int ret;
+ ret = c4iw_register_device(dev);
+ if (ret)
+ printk(KERN_ERR MOD
+ "%s: RDMA registration failed: %d\n",
+ pci_name(dev->rdev.lldi.pdev), ret);
+ }
+ break;
+ case CXGB4_STATE_DOWN:
+ printk(KERN_INFO MOD "%s: Down\n",
+ pci_name(dev->rdev.lldi.pdev));
+ if (dev->registered)
+ c4iw_unregister_device(dev);
+ break;
+ case CXGB4_STATE_START_RECOVERY:
+ printk(KERN_INFO MOD "%s: Fatal Error\n",
+ pci_name(dev->rdev.lldi.pdev));
+ if (dev->registered)
+ c4iw_unregister_device(dev);
+ break;
+ case CXGB4_STATE_DETACH:
+ printk(KERN_INFO MOD "%s: Detach\n",
+ pci_name(dev->rdev.lldi.pdev));
+ mutex_lock(&dev_mutex);
+ c4iw_remove(dev);
+ mutex_unlock(&dev_mutex);
+ break;
+ }
return 0;
}
diff --git a/drivers/infiniband/hw/cxgb4/iw_cxgb4.h b/drivers/infiniband/hw/cxgb4/iw_cxgb4.h
index a626998..277ab58 100644
--- a/drivers/infiniband/hw/cxgb4/iw_cxgb4.h
+++ b/drivers/infiniband/hw/cxgb4/iw_cxgb4.h
@@ -152,6 +152,7 @@ struct c4iw_dev {
struct list_head entry;
struct delayed_work db_drop_task;
struct dentry *debugfs_root;
+ u8 registered;
};
static inline struct c4iw_dev *to_c4iw_dev(struct ib_device *ibdev)
diff --git a/drivers/infiniband/hw/cxgb4/provider.c b/drivers/infiniband/hw/cxgb4/provider.c
index dfc4902..322134b 100644
--- a/drivers/infiniband/hw/cxgb4/provider.c
+++ b/drivers/infiniband/hw/cxgb4/provider.c
@@ -496,6 +496,7 @@ int c4iw_register_device(struct c4iw_dev *dev)
if (ret)
goto bail2;
}
+ dev->registered = 1;
return 0;
bail2:
ib_unregister_device(&dev->ibdev);
@@ -514,5 +515,6 @@ void c4iw_unregister_device(struct c4iw_dev *dev)
c4iw_class_attributes[i]);
ib_unregister_device(&dev->ibdev);
kfree(dev->ibdev.iwcm);
+ dev->registered = 0;
return;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 03/11] RDMA/cxgb4: CQ size must be IQ size - 2.
From: Steve Wise @ 2010-05-20 21:57 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100520215727.32394.90669.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
1 for the status page
1 to always have 1 free entry to detect full.
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/cq.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/cq.c b/drivers/infiniband/hw/cxgb4/cq.c
index fb1aafc..46ac00f 100644
--- a/drivers/infiniband/hw/cxgb4/cq.c
+++ b/drivers/infiniband/hw/cxgb4/cq.c
@@ -780,6 +780,9 @@ struct ib_cq *c4iw_create_cq(struct ib_device *ibdev, int entries,
/* account for the status page. */
entries++;
+ /* IQ needs one extra entry to differentiate full vs empty. */
+ entries++;
+
/*
* entries must be multiple of 16 for HW.
*/
@@ -801,7 +804,7 @@ struct ib_cq *c4iw_create_cq(struct ib_device *ibdev, int entries,
chp->rhp = rhp;
chp->cq.size--; /* status page */
- chp->ibcq.cqe = chp->cq.size;
+ chp->ibcq.cqe = chp->cq.size - 1;
spin_lock_init(&chp->lock);
atomic_set(&chp->refcnt, 1);
init_waitqueue_head(&chp->wait);
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 04/11] RDMA/cxgb4: Optimize CQ overflow detection.
From: Steve Wise @ 2010-05-20 21:57 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100520215727.32394.90669.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
1) save the timestamp flit in the cq when we consume a CQE
2) always compare the saved flit with the previous entry flit when reading
the next CQE entry. If the flits don't compare, then we have overflowed.
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/cq.c | 1 +
drivers/infiniband/hw/cxgb4/t4.h | 28 ++++++++++++++++------------
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/cq.c b/drivers/infiniband/hw/cxgb4/cq.c
index 46ac00f..2447f52 100644
--- a/drivers/infiniband/hw/cxgb4/cq.c
+++ b/drivers/infiniband/hw/cxgb4/cq.c
@@ -373,6 +373,7 @@ static void create_read_req_cqe(struct t4_wq *wq, struct t4_cqe *hw_cqe,
V_CQE_SWCQE(SW_CQE(hw_cqe)) |
V_CQE_OPCODE(FW_RI_READ_REQ) |
V_CQE_TYPE(1));
+ read_cqe->bits_type_ts = hw_cqe->bits_type_ts;
}
/*
diff --git a/drivers/infiniband/hw/cxgb4/t4.h b/drivers/infiniband/hw/cxgb4/t4.h
index d0e8af3..712bc56 100644
--- a/drivers/infiniband/hw/cxgb4/t4.h
+++ b/drivers/infiniband/hw/cxgb4/t4.h
@@ -434,7 +434,7 @@ struct t4_cq {
struct c4iw_rdev *rdev;
u64 ugts;
size_t memsize;
- u64 timestamp;
+ __be64 bits_type_ts;
u32 cqid;
u16 size; /* including status page */
u16 cidx;
@@ -487,6 +487,7 @@ static inline void t4_swcq_consume(struct t4_cq *cq)
static inline void t4_hwcq_consume(struct t4_cq *cq)
{
+ cq->bits_type_ts = cq->queue[cq->cidx].bits_type_ts;
cq->cidx_inc++;
if (++cq->cidx == cq->size) {
cq->cidx = 0;
@@ -501,20 +502,23 @@ static inline int t4_valid_cqe(struct t4_cq *cq, struct t4_cqe *cqe)
static inline int t4_next_hw_cqe(struct t4_cq *cq, struct t4_cqe **cqe)
{
- int ret = 0;
- u64 bits_type_ts = be64_to_cpu(cq->queue[cq->cidx].bits_type_ts);
+ int ret;
+ u16 prev_cidx;
- if (G_CQE_GENBIT(bits_type_ts) == cq->gen) {
- *cqe = &cq->queue[cq->cidx];
- cq->timestamp = G_CQE_TS(bits_type_ts);
- } else if (G_CQE_TS(bits_type_ts) > cq->timestamp)
- ret = -EOVERFLOW;
+ if (cq->cidx == 0)
+ prev_cidx = cq->size - 1;
else
- ret = -ENODATA;
- if (ret == -EOVERFLOW) {
- printk(KERN_ERR MOD "cq overflow cqid %u\n", cq->cqid);
+ prev_cidx = cq->cidx - 1;
+
+ if (cq->queue[prev_cidx].bits_type_ts != cq->bits_type_ts) {
+ ret = -EOVERFLOW;
cq->error = 1;
- }
+ printk(KERN_ERR MOD "cq overflow cqid %u\n", cq->cqid);
+ } else if (t4_valid_cqe(cq, &cq->queue[cq->cidx])) {
+ *cqe = &cq->queue[cq->cidx];
+ ret = 0;
+ } else
+ ret = -ENODATA;
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 05/11] RDMA/cxgb4: Fix overflow bug in cq arm.
From: Steve Wise @ 2010-05-20 21:57 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100520215727.32394.90669.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
- wrap cq->cqidx_inc based on cq size.
- optimize t4_arm_cq logic.
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/t4.h | 31 ++++++++++++-------------------
1 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/t4.h b/drivers/infiniband/hw/cxgb4/t4.h
index 712bc56..333abd3 100644
--- a/drivers/infiniband/hw/cxgb4/t4.h
+++ b/drivers/infiniband/hw/cxgb4/t4.h
@@ -449,25 +449,17 @@ struct t4_cq {
static inline int t4_arm_cq(struct t4_cq *cq, int se)
{
u32 val;
- u16 inc;
-
- do {
- /*
- * inc must be less the both the max update value -and-
- * the size of the CQ.
- */
- inc = cq->cidx_inc <= CIDXINC_MASK ? cq->cidx_inc :
- CIDXINC_MASK;
- inc = inc <= (cq->size - 1) ? inc : (cq->size - 1);
- if (inc == cq->cidx_inc)
- val = SEINTARM(se) | CIDXINC(inc) | TIMERREG(6) |
- INGRESSQID(cq->cqid);
- else
- val = SEINTARM(0) | CIDXINC(inc) | TIMERREG(7) |
- INGRESSQID(cq->cqid);
- cq->cidx_inc -= inc;
+
+ while (cq->cidx_inc > CIDXINC_MASK) {
+ val = SEINTARM(0) | CIDXINC(CIDXINC_MASK) | TIMERREG(7) |
+ INGRESSQID(cq->cqid);
writel(val, cq->gts);
- } while (cq->cidx_inc);
+ cq->cidx_inc -= CIDXINC_MASK;
+ }
+ val = SEINTARM(se) | CIDXINC(cq->cidx_inc) | TIMERREG(6) |
+ INGRESSQID(cq->cqid);
+ writel(val, cq->gts);
+ cq->cidx_inc = 0;
return 0;
}
@@ -488,7 +480,8 @@ static inline void t4_swcq_consume(struct t4_cq *cq)
static inline void t4_hwcq_consume(struct t4_cq *cq)
{
cq->bits_type_ts = cq->queue[cq->cidx].bits_type_ts;
- cq->cidx_inc++;
+ if (++cq->cidx_inc == cq->size)
+ cq->cidx_inc = 0;
if (++cq->cidx == cq->size) {
cq->cidx = 0;
cq->gen ^= 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 06/11] RDMA/cxgb4: Return proper errors in fastreg mr/pbl allocation.
From: Steve Wise @ 2010-05-20 21:57 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100520215727.32394.90669.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/mem.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/mem.c b/drivers/infiniband/hw/cxgb4/mem.c
index e54ff6d..993ed1f 100644
--- a/drivers/infiniband/hw/cxgb4/mem.c
+++ b/drivers/infiniband/hw/cxgb4/mem.c
@@ -712,8 +712,10 @@ struct ib_mr *c4iw_alloc_fast_reg_mr(struct ib_pd *pd, int pbl_depth)
php = to_c4iw_pd(pd);
rhp = php->rhp;
mhp = kzalloc(sizeof(*mhp), GFP_KERNEL);
- if (!mhp)
+ if (!mhp) {
+ ret = -ENOMEM;
goto err;
+ }
mhp->rhp = rhp;
ret = alloc_pbl(mhp, pbl_depth);
@@ -730,8 +732,10 @@ struct ib_mr *c4iw_alloc_fast_reg_mr(struct ib_pd *pd, int pbl_depth)
mhp->attr.state = 1;
mmid = (stag) >> 8;
mhp->ibmr.rkey = mhp->ibmr.lkey = stag;
- if (insert_handle(rhp, &rhp->mmidr, mhp, mmid))
+ if (insert_handle(rhp, &rhp->mmidr, mhp, mmid)) {
+ ret = -ENOMEM;
goto err3;
+ }
PDBG("%s mmid 0x%x mhp %p stag 0x%x\n", __func__, mmid, mhp, stag);
return &(mhp->ibmr);
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 07/11] RDMA/cxgb4: Don't limit fastreg page list depth.
From: Steve Wise @ 2010-05-20 21:57 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100520215727.32394.90669.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/mem.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/mem.c b/drivers/infiniband/hw/cxgb4/mem.c
index 993ed1f..7f94da1 100644
--- a/drivers/infiniband/hw/cxgb4/mem.c
+++ b/drivers/infiniband/hw/cxgb4/mem.c
@@ -759,9 +759,6 @@ struct ib_fast_reg_page_list *c4iw_alloc_fastreg_pbl(struct ib_device *device,
dma_addr_t dma_addr;
int size = sizeof *c4pl + page_list_len * sizeof(u64);
- if (page_list_len > T4_MAX_FR_DEPTH)
- return ERR_PTR(-EINVAL);
-
c4pl = dma_alloc_coherent(&dev->rdev.lldi.pdev->dev, size,
&dma_addr, GFP_KERNEL);
if (!c4pl)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 08/11] RDMA/cxgb4: Update some HW limits.
From: Steve Wise @ 2010-05-20 21:58 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100520215727.32394.90669.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/t4.h | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/t4.h b/drivers/infiniband/hw/cxgb4/t4.h
index 333abd3..1057cb9 100644
--- a/drivers/infiniband/hw/cxgb4/t4.h
+++ b/drivers/infiniband/hw/cxgb4/t4.h
@@ -41,11 +41,13 @@
#define T4_MAX_NUM_QP (1<<16)
#define T4_MAX_NUM_CQ (1<<15)
#define T4_MAX_NUM_PD (1<<15)
-#define T4_MAX_PBL_SIZE 256
-#define T4_MAX_RQ_SIZE 1024
-#define T4_MAX_SQ_SIZE 1024
-#define T4_MAX_QP_DEPTH (T4_MAX_RQ_SIZE-1)
-#define T4_MAX_CQ_DEPTH 8192
+#define T4_EQ_STATUS_ENTRIES (L1_CACHE_BYTES > 64 ? 2 : 1)
+#define T4_MAX_EQ_SIZE (65520 - T4_EQ_STATUS_ENTRIES)
+#define T4_MAX_IQ_SIZE (65520 - 1)
+#define T4_MAX_RQ_SIZE (8192 - T4_EQ_STATUS_ENTRIES)
+#define T4_MAX_SQ_SIZE (T4_MAX_EQ_SIZE - 1)
+#define T4_MAX_QP_DEPTH (T4_MAX_RQ_SIZE - 1)
+#define T4_MAX_CQ_DEPTH (T4_MAX_IQ_SIZE - 1)
#define T4_MAX_NUM_STAG (1<<15)
#define T4_MAX_MR_SIZE (~0ULL - 1)
#define T4_PAGESIZE_MASK 0xffff000 /* 4KB-128MB */
@@ -79,12 +81,11 @@ struct t4_status_page {
sizeof(struct fw_ri_isgl)) / sizeof(struct fw_ri_sge))
#define T4_MAX_FR_IMMD ((T4_SQ_NUM_BYTES - sizeof(struct fw_ri_fr_nsmr_wr) - \
sizeof(struct fw_ri_immd)))
-#define T4_MAX_FR_DEPTH 255
+#define T4_MAX_FR_DEPTH (T4_MAX_FR_IMMD / sizeof(u64))
#define T4_RQ_NUM_SLOTS 2
#define T4_RQ_NUM_BYTES (T4_EQ_SIZE * T4_RQ_NUM_SLOTS)
-#define T4_MAX_RECV_SGE ((T4_RQ_NUM_BYTES - sizeof(struct fw_ri_recv_wr) - \
- sizeof(struct fw_ri_isgl)) / sizeof(struct fw_ri_sge))
+#define T4_MAX_RECV_SGE 4
union t4_wr {
struct fw_ri_res_wr res;
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 09/11] RDMA/cxgb4: Set fence flag for inv-local-stag work requests.
From: Steve Wise @ 2010-05-20 21:58 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100520215727.32394.90669.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/qp.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/qp.c b/drivers/infiniband/hw/cxgb4/qp.c
index 83a01dc..9fb52fa 100644
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -588,6 +588,8 @@ int c4iw_post_send(struct ib_qp *ibqp, struct ib_send_wr *wr,
err = build_fastreg(wqe, wr, &len16);
break;
case IB_WR_LOCAL_INV:
+ if (wr->send_flags & IB_SEND_FENCE)
+ fw_flags |= FW_RI_LOCAL_FENCE_FLAG;
fw_opcode = FW_RI_INV_LSTAG_WR;
swsqe->opcode = FW_RI_LOCAL_INV;
err = build_inv_stag(wqe, wr, &len16);
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 10/11] RDMA/cxgb4: Support IB_WR_READ_WITH_INV opcode.
From: Steve Wise @ 2010-05-20 21:58 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100520215727.32394.90669.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/qp.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/qp.c b/drivers/infiniband/hw/cxgb4/qp.c
index 9fb52fa..a41881b 100644
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -572,9 +572,13 @@ int c4iw_post_send(struct ib_qp *ibqp, struct ib_send_wr *wr,
err = build_rdma_write(wqe, wr, &len16);
break;
case IB_WR_RDMA_READ:
+ case IB_WR_RDMA_READ_WITH_INV:
fw_opcode = FW_RI_RDMA_READ_WR;
swsqe->opcode = FW_RI_READ_REQ;
- fw_flags = 0;
+ if (wr->opcode == IB_WR_RDMA_READ_WITH_INV)
+ fw_flags |= FW_RI_RDMA_READ_INVALIDATE;
+ else
+ fw_flags = 0;
err = build_rdma_read(wqe, wr, &len16);
if (err)
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 11/11] RDMA/cxgb4: Only insert sq qid in lookup table.
From: Steve Wise @ 2010-05-20 21:58 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100520215727.32394.90669.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
Signed-off-by: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
---
drivers/infiniband/hw/cxgb4/qp.c | 25 +++++++++----------------
1 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb4/qp.c b/drivers/infiniband/hw/cxgb4/qp.c
index a41881b..0c28ed1 100644
--- a/drivers/infiniband/hw/cxgb4/qp.c
+++ b/drivers/infiniband/hw/cxgb4/qp.c
@@ -1345,7 +1345,6 @@ int c4iw_destroy_qp(struct ib_qp *ib_qp)
wait_event(qhp->wait, !qhp->ep);
remove_handle(rhp, &rhp->qpidr, qhp->wq.sq.qid);
- remove_handle(rhp, &rhp->qpidr, qhp->wq.rq.qid);
atomic_dec(&qhp->refcnt);
wait_event(qhp->wait, !atomic_read(&qhp->refcnt));
@@ -1448,30 +1447,26 @@ struct ib_qp *c4iw_create_qp(struct ib_pd *pd, struct ib_qp_init_attr *attrs,
if (ret)
goto err2;
- ret = insert_handle(rhp, &rhp->qpidr, qhp, qhp->wq.rq.qid);
- if (ret)
- goto err3;
-
if (udata) {
mm1 = kmalloc(sizeof *mm1, GFP_KERNEL);
if (!mm1) {
ret = -ENOMEM;
- goto err4;
+ goto err3;
}
mm2 = kmalloc(sizeof *mm2, GFP_KERNEL);
if (!mm2) {
ret = -ENOMEM;
- goto err5;
+ goto err4;
}
mm3 = kmalloc(sizeof *mm3, GFP_KERNEL);
if (!mm3) {
ret = -ENOMEM;
- goto err6;
+ goto err5;
}
mm4 = kmalloc(sizeof *mm4, GFP_KERNEL);
if (!mm4) {
ret = -ENOMEM;
- goto err7;
+ goto err6;
}
uresp.qid_mask = rhp->rdev.qpmask;
@@ -1493,7 +1488,7 @@ struct ib_qp *c4iw_create_qp(struct ib_pd *pd, struct ib_qp_init_attr *attrs,
spin_unlock(&ucontext->mmap_lock);
ret = ib_copy_to_udata(udata, &uresp, sizeof uresp);
if (ret)
- goto err8;
+ goto err7;
mm1->key = uresp.sq_key;
mm1->addr = virt_to_phys(qhp->wq.sq.queue);
mm1->len = PAGE_ALIGN(qhp->wq.sq.memsize);
@@ -1517,16 +1512,14 @@ struct ib_qp *c4iw_create_qp(struct ib_pd *pd, struct ib_qp_init_attr *attrs,
__func__, qhp, qhp->attr.sq_num_entries, qhp->attr.rq_num_entries,
qhp->wq.sq.qid);
return &qhp->ibqp;
-err8:
- kfree(mm4);
err7:
- kfree(mm3);
+ kfree(mm4);
err6:
- kfree(mm2);
+ kfree(mm3);
err5:
- kfree(mm1);
+ kfree(mm2);
err4:
- remove_handle(rhp, &rhp->qpidr, qhp->wq.rq.qid);
+ kfree(mm1);
err3:
remove_handle(rhp, &rhp->qpidr, qhp->wq.sq.qid);
err2:
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* RE: [PATCH 03/11] RDMA/cxgb4: CQ size must be IQ size - 2.
From: Sean Hefty @ 2010-05-20 22:08 UTC (permalink / raw)
To: 'Steve Wise', linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100520215738.32394.60360.stgit-T4OLL4TyM9aNDNWfRnPdfg@public.gmane.org>
> /* account for the status page. */
> entries++;
>
>+ /* IQ needs one extra entry to differentiate full vs empty. */
>+ entries++;
>+
> /*
> * entries must be multiple of 16 for HW.
> */
>@@ -801,7 +804,7 @@ struct ib_cq *c4iw_create_cq(struct ib_device *ibdev, int
>entries,
>
> chp->rhp = rhp;
> chp->cq.size--; /* status page */
>- chp->ibcq.cqe = chp->cq.size;
>+ chp->ibcq.cqe = chp->cq.size - 1;
Why does the status page adjust using size--, but we use size - 1 for the extra
entry?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 03/11] RDMA/cxgb4: CQ size must be IQ size - 2.
From: Steve Wise @ 2010-05-20 22:16 UTC (permalink / raw)
To: Sean Hefty; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <27BBA4336B784434AAE16BB1126AD59C-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>
Sean Hefty wrote:
>> /* account for the status page. */
>> entries++;
>>
>> + /* IQ needs one extra entry to differentiate full vs empty. */
>> + entries++;
>> +
>> /*
>> * entries must be multiple of 16 for HW.
>> */
>> @@ -801,7 +804,7 @@ struct ib_cq *c4iw_create_cq(struct ib_device *ibdev, int
>> entries,
>>
>> chp->rhp = rhp;
>> chp->cq.size--; /* status page */
>> - chp->ibcq.cqe = chp->cq.size;
>> + chp->ibcq.cqe = chp->cq.size - 1;
>>
>
> Why does the status page adjust using size--, but we use size - 1 for the extra
> entry?
>
>
chp->cq.size is the actual number of entries that can write-to by the
HW. But since one must always be available to detect "full" vs "empty",
we tell the ULP that the size is one less than that.
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Proposal for adding ib_usa to the Linux Infiniband Subsystem
From: Mike Heinz @ 2010-05-21 13:42 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Hello, all.
For the past few years, we (QLogic) have been using the IB user space SA module that was originally written by Sean Hefty. We think it would be great if this module were to become part of the official Linux Infiniband subsystem - but rather than simply dumping this on Roland as a surprise, I thought it might be a good idea to talk about it, first, and find out what the best approach would be.
What is ib_usa?
---------------
The ib_usa module adds two features to the Infiniband Subsystem. It allows user applications to subscribe to SA notifications (remote port up, remote port down, etc.) and it allows user applications to subscribe to multicast groups. It does this via a device file, /dev/infiniband/ib_usa, similar to /dev/infiniband/uverbs and /dev/infiniband/umad.
Why is this needed?
-------------------
The SA protocol allows notices and multicast membership to be managed at a CA port level. As a result, if multiple processes want to receive notices or join multicast groups, that registration must be coordinated per CA port. Existing code in the Linux kernel exists for this purpose, coordinating the needs of various Infiniband kernel modules and presenting a single "per server CA port" perspective to the SA. The IB user space SA module provides a mechanism for user space applications to take advantage of this existing kernel code for managing SA registrations.
By providing this mechanism, ib_usa provides a convenient and useful way for user applications to detect when nodes enter or leave the fabric. This is useful for fabric monitoring applications (like a system admin dashboard) or, conceivably, to allow a cluster application to detect problems and to dynamically balance a computational load across the fabric.
In addition, the multicast functionality will allow user applications to use properly verbs to receive multicast traffic.
How will it integrate into the existing Infiniband subsystem?
-------------------------------------------------------------
We recommend including Sean's original module, and we can provide a version of it that works fine with the latest versions of OFED. This will add a new kernel module to the ofa_kernel package, ib_usa.ko.
In addition, there will be a need for a shared library to provide an API to provide access to ib_usa. I would suggest adding the needed functions to OFED management module, as part of the libibumad library, or to their own libibusa library. In either case, I would provide the needed code and a sample/test application.
So, how about it? What's the best way forward here?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v2] libibverbs: add path record definitions to sa.h
From: Walukiewicz, Miroslaw @ 2010-05-21 14:58 UTC (permalink / raw)
To: Steve Wise; +Cc: Roland Dreier, Hefty, Sean, linux-rdma
In-Reply-To: <4BF40B09.6070809-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
Hello Steve,
I want to add a change preventing creation of the L2 RAW_QPT from user priviledge (uid = 0 will be able to do such operation)
What is the best place to do such change: ibv_create_qp in libibverbs(verbs.c) or allowing to decide for NIC vendors if they want to enable such API to user or root. In that case the change is requested only for libnes library?
Regards,
Mirek
-----Original Message-----
From: Steve Wise [mailto:swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org]
Sent: Wednesday, May 19, 2010 6:00 PM
To: Walukiewicz, Miroslaw
Cc: Roland Dreier; Hefty, Sean; linux-rdma
Subject: Re: [PATCH v2] libibverbs: add path record definitions to sa.h
Walukiewicz, Miroslaw wrote:
> Hello Steve,
>
> Do you plan some changes in the core code related to RAW_QPT?
>
>
The only changes I see needed to the kernel core is the mcast change you
already proposed to allow mcast attach/detach for RAW_ETY qps...
> Could you explain me better what means "priviledged interface" for you?
>
>
I just mean that allocating these raw qps should only be allowed by
effective UID 0. This is analogous to PF_PACKET sockets which are
privileged as well.
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] libibverbs: add path record definitions to sa.h
From: Steve Wise @ 2010-05-21 15:03 UTC (permalink / raw)
To: Walukiewicz, Miroslaw; +Cc: Roland Dreier, Hefty, Sean, linux-rdma
In-Reply-To: <BE2BFE91933D1B4089447C64486040801D5370A4-IGOiFh9zz4wLt2AQoY/u9bfspsVTdybXVpNB7YpNyf8@public.gmane.org>
Walukiewicz, Miroslaw wrote:
> Hello Steve,
>
> I want to add a change preventing creation of the L2 RAW_QPT from user priviledge (uid = 0 will be able to do such operation)
>
> What is the best place to do such change: ibv_create_qp in libibverbs(verbs.c) or allowing to decide for NIC vendors if they want to enable such API to user or root. In that case the change is requested only for libnes library?
>
>
I think it should be done in your kernel driver in your create_qp
function. The user space libraries really aren't trusted. IE someone
would write their own library to call into the kernel to create this
qp. So only in the kernel can you enforce privs.
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: Proposal for adding ib_usa to the Linux Infiniband Subsystem
From: Sean Hefty @ 2010-05-21 15:29 UTC (permalink / raw)
To: 'Mike Heinz', linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4C2744E8AD2982428C5BFE523DF8CDCB49A488D12E-amwN6d8PyQWXx9kJd3VG2h2eb7JE58TQ@public.gmane.org>
>Why is this needed?
>-------------------
>The SA protocol allows notices and multicast membership to be managed at a CA
>port level. As a result, if multiple processes want to receive notices or join
>multicast groups, that registration must be coordinated per CA port. Existing
>code in the Linux kernel exists for this purpose, coordinating the needs of
>various Infiniband kernel modules and presenting a single "per server CA port"
>perspective to the SA. The IB user space SA module provides a mechanism for
>user space applications to take advantage of this existing kernel code for
>managing SA registrations.
The AF_IB support that is being requested for the rdma_cm would provide greater
support for IB multicast join/leave membership. Some additional work would be
needed to allow the user to specify the full MCMemberRecord, but the basic
infrastructure should be there. Just mentioning this as a possibility. (The IB
ACM code joins multicast groups using libibumad and sends MADs directly to the
SA.)
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: Proposal for adding ib_usa to the Linux Infiniband Subsystem
From: Mike Heinz @ 2010-05-21 15:57 UTC (permalink / raw)
To: Sean Hefty, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <C14850BAABFD4BE789736D497B1DC825-Zpru7NauK7drdx17CPfAsdBPR1lH4CV8@public.gmane.org>
Would it be better to omit the multicast support from ib_usa and simply add it as a way to handle notifications?
-----Original Message-----
From: Sean Hefty [mailto:sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org]
Sent: Friday, May 21, 2010 11:30 AM
To: Mike Heinz; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: RE: Proposal for adding ib_usa to the Linux Infiniband Subsystem
>Why is this needed?
>-------------------
>The SA protocol allows notices and multicast membership to be managed at a CA
>port level. As a result, if multiple processes want to receive notices or join
>multicast groups, that registration must be coordinated per CA port. Existing
>code in the Linux kernel exists for this purpose, coordinating the needs of
>various Infiniband kernel modules and presenting a single "per server CA port"
>perspective to the SA. The IB user space SA module provides a mechanism for
>user space applications to take advantage of this existing kernel code for
>managing SA registrations.
The AF_IB support that is being requested for the rdma_cm would provide greater
support for IB multicast join/leave membership. Some additional work would be
needed to allow the user to specify the full MCMemberRecord, but the basic
infrastructure should be there. Just mentioning this as a possibility. (The IB
ACM code joins multicast groups using libibumad and sends MADs directly to the
SA.)
- Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: Proposal for adding ib_usa to the Linux Infiniband Subsystem
From: Sean Hefty @ 2010-05-21 16:31 UTC (permalink / raw)
To: 'Mike Heinz', linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4C2744E8AD2982428C5BFE523DF8CDCB49A488D170-amwN6d8PyQWXx9kJd3VG2h2eb7JE58TQ@public.gmane.org>
>Would it be better to omit the multicast support from ib_usa and simply add it
>as a way to handle notifications?
I think so, since it limits the number of interfaces and libraries that a user
needs to learn.
I'm not sure of the best userspace interface for notifications. Maybe there's a
way to extend the async event reporting in libibverbs?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] opensm/complib use portable macro syntax
From: Smith, Stan @ 2010-05-21 16:45 UTC (permalink / raw)
To: Sasha Khapyorsky
Cc: ofw-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Use portable macro argument syntax.
signed-of-by: stan smith <stan.smith-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
diff --git a/opensm/complib/cl_event_wheel.c b/opensm/complib/cl_event_wheel.c
index ef6d598..eb894a6 100644
--- a/opensm/complib/cl_event_wheel.c
+++ b/opensm/complib/cl_event_wheel.c
@@ -42,7 +42,7 @@
#include <complib/cl_event_wheel.h>
#include <complib/cl_debug.h>
-#define CL_DBG(fmt, arg...)
+#define CL_DBG(fmt, ...)
static cl_status_t __event_will_age_before(IN const cl_list_item_t *
const p_list_item, IN void *context)
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] opensm - use portable macro definition for tmp file path
From: Smith, Stan @ 2010-05-21 16:48 UTC (permalink / raw)
To: Sasha Khapyorsky
Cc: ofw-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Use defined macro for tmp file path.
signed-off-by: stan smith <stan.smith-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
diff --git a/opensm/opensm/osm_db_files.c b/opensm/opensm/osm_db_files.c
index dd9f772..5771e6e 100644
--- a/opensm/opensm/osm_db_files.c
+++ b/opensm/opensm/osm_db_files.c
@@ -615,7 +615,7 @@ int main(int argc, char **argv)
cl_list_construct(&keys);
cl_list_init(&keys, 10);
- osm_log_init_v2(&log, TRUE, 0xff, "/var/log/osm_db_test.log", 0, FALSE);
+ osm_log_init_v2(&log, TRUE, 0xff, OSM_DEFAULT_TMP_DIR "osm_db_test.log", 0, FALSE);
osm_db_construct(&db);
if (osm_db_init(&db, &log)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: Proposal for adding ib_usa to the Linux Infiniband Subsystem
From: Jason Gunthorpe @ 2010-05-21 16:50 UTC (permalink / raw)
To: Mike Heinz; +Cc: Sean Hefty, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <4C2744E8AD2982428C5BFE523DF8CDCB49A488D170-amwN6d8PyQWXx9kJd3VG2h2eb7JE58TQ@public.gmane.org>
I've said this before, but again..
There are too many orthogonal interfaces here. We really don't need
more libraries or kernel modules or /dev/ devices. Really.
Subscribing and multiplexing notifications from a GSI service should
just be a general function in the mad code..
On Fri, May 21, 2010 at 10:57:48AM -0500, Mike Heinz wrote:
> Would it be better to omit the multicast support from ib_usa and simply add it as a way to handle notifications?
>
> From: Sean Hefty [mailto:sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org]
> Sent: Friday, May 21, 2010 11:30 AM
> To: Mike Heinz; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: RE: Proposal for adding ib_usa to the Linux Infiniband Subsystem
>
> >Why is this needed?
> >The SA protocol allows notices and multicast membership to be managed at a CA
> >port level.? As a result, if multiple processes want to receive notices or join
> >multicast groups, that registration must be coordinated per CA port.? Existing
> >code in the Linux kernel exists for this purpose, coordinating the needs of
> >various Infiniband kernel modules and presenting a single "per server CA port"
> >perspective to the SA.? The IB user space SA module provides a mechanism for
> >user space applications to take advantage of this existing kernel code for
> >managing SA registrations.
>
> The AF_IB support that is being requested for the rdma_cm would provide greater
> support for IB multicast join/leave membership. Some additional work would be
> needed to allow the user to specify the full MCMemberRecord, but the basic
> infrastructure should be there. Just mentioning this as a possibility. (The IB
> ACM code joins multicast groups using libibumad and sends MADs directly to the
> SA.)
>
> - Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] use macro for tmp file path
From: Smith, Stan @ 2010-05-21 16:51 UTC (permalink / raw)
To: Sasha Khapyorsky
Cc: ofw-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Use defined macro for tmp file path
signed-off-by: stan smith <stan.smith-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
diff --git a/opensm/opensm/st.c b/opensm/opensm/st.c
index ea76038..2d39117 100644
--- a/opensm/opensm/st.c
+++ b/opensm/opensm/st.c
@@ -174,7 +174,7 @@ static int init_st = 0;
static void stat_col()
{
- FILE *f = fopen("/var/log/osm_st_col", "w");
+ FILE *f = fopen( OSM_DEFAULT_TMP_DIR "osm_st_col", "w");
fprintf(f, "collision: %d\n", collision);
fclose(f);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* RE: Proposal for adding ib_usa to the Linux Infiniband Subsystem
From: Mike Heinz @ 2010-05-21 17:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Sean Hefty, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20100521165018.GA8856-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
I have to agree that in some ways this seems a good fit with ibverbs. Also, without the multicast support, the whole thing is well under 1 kloc in the kernel, making it a good candidate for being combined with another module.
My biggest objections, though, would be:
1. If it's been working for a couple of years now, do we really need to change it?
2. The async events in ibverbs are all local events, are we really keeping things simple by adding remote notifications to mix, or making a simple interface much more complicated?
-----Original Message-----
From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Jason Gunthorpe
Sent: Friday, May 21, 2010 12:50 PM
To: Mike Heinz
Cc: Sean Hefty; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Proposal for adding ib_usa to the Linux Infiniband Subsystem
I've said this before, but again..
There are too many orthogonal interfaces here. We really don't need
more libraries or kernel modules or /dev/ devices. Really.
Subscribing and multiplexing notifications from a GSI service should
just be a general function in the mad code..
On Fri, May 21, 2010 at 10:57:48AM -0500, Mike Heinz wrote:
> Would it be better to omit the multicast support from ib_usa and simply add it as a way to handle notifications?
>
> From: Sean Hefty [mailto:sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org]
> Sent: Friday, May 21, 2010 11:30 AM
> To: Mike Heinz; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: RE: Proposal for adding ib_usa to the Linux Infiniband Subsystem
>
> >Why is this needed?
> >The SA protocol allows notices and multicast membership to be managed at a CA
> >port level.? As a result, if multiple processes want to receive notices or join
> >multicast groups, that registration must be coordinated per CA port.? Existing
> >code in the Linux kernel exists for this purpose, coordinating the needs of
> >various Infiniband kernel modules and presenting a single "per server CA port"
> >perspective to the SA.? The IB user space SA module provides a mechanism for
> >user space applications to take advantage of this existing kernel code for
> >managing SA registrations.
>
> The AF_IB support that is being requested for the rdma_cm would provide greater
> support for IB multicast join/leave membership. Some additional work would be
> needed to allow the user to specify the full MCMemberRecord, but the basic
> infrastructure should be there. Just mentioning this as a possibility. (The IB
> ACM code joins multicast groups using libibumad and sends MADs directly to the
> SA.)
>
> - Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox