Re: [openib-general] Re: inline support in Gen2
I just checked in implementations of ibv_attach_mcast() and ibv_detach_mcast(). I didn't really test them, so please let me know if you see any problems using them. - 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
Re: [openib-general] Re: slab error in kmem_cache_destroy(): cache `ib_mad': Can't free all objects
On Fri, 2005-05-06 at 12:52, Hal Rosenstock wrote:
> On Wed, 2005-05-04 at 02:57, Michael S. Tsirkin wrote:
> > > If this only occurs on machines which are running OpenSM, it could be a
> > > problem with the local MAD handling where ib_free_recv_mad is not called
> > > for some case where it should. I will look into this if this is the
> > > case.
> > >
> > > -- Hal
> > >
> >
> > This is the case for me: the error only occurs on machines which are
> > running OpenSM.
>
> So assuming mthca sets the bits properly for local MAD handling (and I
> have no reason to think otherwise), this is likely a local MAD handling
> error in mad.c where some path does not return an allocation to the MAD
> cache. I inspected the code to try and find it but couldn't. I will need
> to dig deeper. This will take some more time. (I will add some
> accounting in and see what this shows up). Please bear with me.
This patch works for me. Can you try it out ? If it works for you, I
will check it in.
-- Hal
Index: mad.c
===
-- mad.c(revision 2331)
+++ mad.c (working copy)
@@ -1602,7 +1602,6 @@
INIT_LIST_HEAD(&mad_recv_wc->rmpp_list);
list_add(&mad_recv_wc->recv_buf.list, &mad_recv_wc->rmpp_list);
-
if (mad_agent_priv->agent.rmpp_version) {
mad_recv_wc = ib_process_rmpp_recv_wc(mad_agent_priv,
mad_recv_wc);
@@ -2054,6 +2053,8 @@
/* Empty wait list to prevent receives from finding a request */
list_splice_init(&mad_agent_priv->wait_list, &cancel_list);
+ /* Empty local completion list as well */
+ list_splice_init(&mad_agent_priv->local_list, &cancel_list);
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
/* Report all cancelled requests */
@@ -2168,6 +2169,7 @@
struct ib_mad_local_private *local;
struct ib_mad_agent_private *recv_mad_agent;
unsigned long flags;
+ int recv = 0;
struct ib_wc wc;
struct ib_mad_send_wc mad_send_wc;
@@ -2183,10 +2185,10 @@
recv_mad_agent = local->recv_mad_agent;
if (!recv_mad_agent) {
printk(KERN_ERR PFX "No receive MAD agent for
local completion\n");
- kmem_cache_free(ib_mad_cache, local->mad_priv);
goto local_send_completion;
}
+ recv = 1;
/*
* Defined behavior is to complete response
* before request
@@ -2199,6 +2201,8 @@
local->mad_priv->header.recv_wc.mad_len =
sizeof(struct ib_mad);
INIT_LIST_HEAD(&local->mad_priv->header.recv_wc.rmpp_list);
+ list_add(&local->mad_priv->header.recv_wc.recv_buf.list,
+&local->mad_priv->header.recv_wc.rmpp_list);
local->mad_priv->header.recv_wc.recv_buf.grh = NULL;
local->mad_priv->header.recv_wc.recv_buf.mad =
&local->mad_priv->mad.mad;
@@ -2229,6 +2233,8 @@
spin_lock_irqsave(&mad_agent_priv->lock, flags);
list_del(&local->completion_list);
atomic_dec(&mad_agent_priv->refcount);
+ if (!recv)
+ kmem_cache_free(ib_mad_cache, local->mad_priv);
kfree(local);
}
spin_unlock_irqrestore(&mad_agent_priv->lock, flags);
___
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] Re: inline support in Gen2
The max_inline_data changes are now checked in. You can pass a request for a max_inline_data value into ibv_create_qp() via qp_attr.cap.max_inline_data, and the actual value (guaranteed to be at least as much as you requested) will be returned in the same location. - R. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] [kdapl] CM: Eliminate explicit send DREQ on error in do_rep_recv
CM: Eliminate explicit send DREQ on error in do_rep_recv Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> Index: dapl_openib_cm.c === --- dapl_openib_cm.c(revision 2348) +++ dapl_openib_cm.c(working copy) @@ -99,7 +99,6 @@ return; disc: - ib_send_cm_dreq(conn->cm_id, NULL, 0); /* ??? */ dapl_evd_connection_callback(conn, IB_CME_LOCAL_FAILURE, NULL, conn->ep); } ___ 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] kDAPL: change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL
On Fri, 2005-05-13 at 11:52 -0700, Caitlin Bestler wrote: > What about kernel clients that are compiled separately from the kernel > that want to be OS neutral and use kdat.h as published by the DAT > Collaborative? Make sure this doesn't happen. Signed-off-by: Tom Duffy <[EMAIL PROTECTED]> Index: linux-kernel-gpl/dat/api.c === --- linux-kernel-gpl/dat/api.c (revision 2338) +++ linux-kernel-gpl/dat/api.c (working copy) @@ -619,7 +619,7 @@ u32 dat_ia_openv(const char *name, int a name, async_event_qlen, async_event_handle, ia_handle); } -EXPORT_SYMBOL(dat_ia_openv); +EXPORT_SYMBOL_GPL(dat_ia_openv); /*** * Function: dat_ia_close @@ -673,7 +673,7 @@ u32 dat_ia_close(DAT_IA_HANDLE ia_handle return status; } -EXPORT_SYMBOL(dat_ia_close); +EXPORT_SYMBOL_GPL(dat_ia_close); /*** * Function: dat_strerror @@ -706,7 +706,7 @@ u32 dat_strerror(u32 value, const char * return DAT_SUCCESS; } -EXPORT_SYMBOL(dat_strerror); +EXPORT_SYMBOL_GPL(dat_strerror); /*** * Function: dat_registry_add_provider @@ -731,7 +731,7 @@ u32 dat_registry_add_provider(const stru return dat_dr_insert(provider_info, provider->ia_open_func); } -EXPORT_SYMBOL(dat_registry_remove_provider); +EXPORT_SYMBOL_GPL(dat_registry_remove_provider); /*** * Function: dat_registry_remove_provider @@ -750,7 +750,7 @@ u32 dat_registry_remove_provider(const s return dat_dr_remove(provider_info); } -EXPORT_SYMBOL(dat_registry_add_provider); +EXPORT_SYMBOL_GPL(dat_registry_add_provider); /*** * Function: dat_registry_list_providers @@ -787,4 +787,4 @@ u32 dat_registry_list_providers(int max_ return status; } -EXPORT_SYMBOL(dat_registry_list_providers); +EXPORT_SYMBOL_GPL(dat_registry_list_providers); ___ 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] Re: [PATCH 1/2] (fixed) mthca: max_inline_data support
Thanks, I ended up committing this slightly modified patch:
--- infiniband/hw/mthca/mthca_dev.h (revision 2287)
+++ infiniband/hw/mthca/mthca_dev.h (working copy)
@@ -439,12 +439,14 @@ int mthca_alloc_qp(struct mthca_dev *dev
struct mthca_cq *recv_cq,
enum ib_qp_type type,
enum ib_sig_type send_policy,
+ struct ib_qp_cap *cap,
struct mthca_qp *qp);
int mthca_alloc_sqp(struct mthca_dev *dev,
struct mthca_pd *pd,
struct mthca_cq *send_cq,
struct mthca_cq *recv_cq,
enum ib_sig_type send_policy,
+ struct ib_qp_cap *cap,
int qpn,
int port,
struct mthca_sqp *sqp);
--- infiniband/hw/mthca/mthca_provider.c(revision 2287)
+++ infiniband/hw/mthca/mthca_provider.c(working copy)
@@ -486,16 +486,11 @@ static struct ib_qp *mthca_create_qp(str
qp->rq.db_index = ucmd.rq_db_index;
}
- qp->sq.max= init_attr->cap.max_send_wr;
- qp->rq.max= init_attr->cap.max_recv_wr;
- qp->sq.max_gs = init_attr->cap.max_send_sge;
- qp->rq.max_gs = init_attr->cap.max_recv_sge;
-
err = mthca_alloc_qp(to_mdev(pd->device), to_mpd(pd),
to_mcq(init_attr->send_cq),
to_mcq(init_attr->recv_cq),
init_attr->qp_type, init_attr->sq_sig_type,
-qp);
+&init_attr->cap, qp);
if (err && pd->uobject) {
context = to_mucontext(pd->uobject->context);
@@ -524,17 +519,12 @@ static struct ib_qp *mthca_create_qp(str
if (!qp)
return ERR_PTR(-ENOMEM);
- qp->sq.max= init_attr->cap.max_send_wr;
- qp->rq.max= init_attr->cap.max_recv_wr;
- qp->sq.max_gs = init_attr->cap.max_send_sge;
- qp->rq.max_gs = init_attr->cap.max_recv_sge;
-
qp->ibqp.qp_num = init_attr->qp_type == IB_QPT_SMI ? 0 : 1;
err = mthca_alloc_sqp(to_mdev(pd->device), to_mpd(pd),
to_mcq(init_attr->send_cq),
to_mcq(init_attr->recv_cq),
- init_attr->sq_sig_type,
+ init_attr->sq_sig_type, &init_attr->cap,
qp->ibqp.qp_num, init_attr->port_num,
to_msqp(qp));
break;
@@ -552,6 +542,8 @@ static struct ib_qp *mthca_create_qp(str
init_attr->cap.max_inline_data = 0;
init_attr->cap.max_send_wr = qp->sq.max;
init_attr->cap.max_recv_wr = qp->rq.max;
+ init_attr->cap.max_send_sge= qp->sq.max_gs;
+ init_attr->cap.max_recv_sge= qp->rq.max_gs;
return &qp->ibqp;
}
--- infiniband/hw/mthca/mthca_qp.c (revision 2287)
+++ infiniband/hw/mthca/mthca_qp.c (working copy)
@@ -46,7 +46,9 @@ enum {
MTHCA_MAX_DIRECT_QP_SIZE = 4 * PAGE_SIZE,
MTHCA_ACK_REQ_FREQ = 10,
MTHCA_FLIGHT_LIMIT = 9,
- MTHCA_UD_HEADER_SIZE = 72 /* largest UD header possible */
+ MTHCA_UD_HEADER_SIZE = 72, /* largest UD header possible */
+ MTHCA_INLINE_HEADER_SIZE = 4, /* data segment overhead for inline */
+ MTHCA_INLINE_CHUNK_SIZE = 16 /* inline data segment chunk */
};
enum {
@@ -1205,22 +1207,31 @@ static int mthca_alloc_qp_common(struct
return 0;
}
-static void mthca_align_qp_size(struct mthca_dev *dev, struct mthca_qp *qp)
+static int mthca_set_qp_size(struct mthca_dev *dev, struct ib_qp_cap *cap,
+struct mthca_qp *qp)
{
- int i;
-
- if (!mthca_is_memfree(dev))
- return;
-
- for (i = 0; 1 << i < qp->rq.max; ++i)
- ; /* nothing */
+ if (mthca_is_memfree(dev)) {
+ qp->rq.max = roundup_pow_of_two(cap->max_recv_wr);
+ qp->sq.max = roundup_pow_of_two(cap->max_send_wr);
+ } else {
+ qp->rq.max = cap->max_recv_wr;
+ qp->sq.max = cap->max_send_wr;
+ }
- qp->rq.max = 1 << i;
+ qp->rq.max_gs = cap->max_recv_sge;
+ qp->sq.max_gs = max_t(int, cap->max_send_sge,
+ ALIGN(cap->max_inline_data +
MTHCA_INLINE_HEADER_SIZE,
+ MTHCA_INLINE_CHUNK_SIZE) / sizeof (struct
mthca_data_seg));
- for (i = 0; 1 << i < qp->sq.max; ++i)
- ; /* nothing */
+ /*
+* For MLX transport we need 2 extra S/G entries:
+* one for the header and one for the checksum at the end
+*/
+
Re: [openib-general] [PATCH 2/2] libmthca: max_inline_data support
Thanks, I committed the following patch. I fixed the computation
+ qp->sq.max_gs= align(cap->max_inline_data +
+sizeof (struct mthca_inline_seg),
+sizeof (struct mthca_data_seg));
to divide by sizeof (struct mthca_data_seg) -- otherwise it seems that
max_gs will end up far too large. I also added some code to return
the actual values allocated back to the consumer.
- R.
--- libmthca/src/qp.c (revision 2206)
+++ libmthca/src/qp.c (working copy)
@@ -718,10 +718,17 @@ out:
return ret;
}
-int mthca_alloc_qp_buf(struct ibv_pd *pd, struct mthca_qp *qp)
+int mthca_alloc_qp_buf(struct ibv_pd *pd, struct ibv_qp_cap *cap,
+ struct mthca_qp *qp)
{
int size;
+ qp->rq.max_gs= cap->max_recv_sge;
+ qp->sq.max_gs= align(cap->max_inline_data + sizeof (struct
mthca_inline_seg),
+sizeof (struct mthca_data_seg)) / sizeof
(struct mthca_data_seg);
+ if (qp->sq.max_gs < cap->max_send_sge)
+ qp->sq.max_gs = cap->max_send_sge;
+
qp->wrid = malloc((qp->rq.max + qp->sq.max) * sizeof (uint64_t));
if (!qp->wrid)
return -1;
@@ -796,6 +803,39 @@ int mthca_alloc_qp_buf(struct ibv_pd *pd
return 0;
}
+void mthca_return_cap(struct ibv_pd *pd, struct mthca_qp *qp, struct
ibv_qp_cap *cap)
+{
+ /*
+* Maximum inline data size is the full WQE size less the size
+* of the next segment, inline segment and other non-data segments.
+*/
+ cap->max_inline_data = (1 << qp->sq.wqe_shift) -
+ sizeof (struct mthca_next_seg) -
+ sizeof (struct mthca_inline_seg);
+
+ switch (qp->qpt) {
+ case IBV_QPT_UD:
+ if (mthca_is_memfree(pd->context))
+ cap->max_inline_data -= sizeof (struct
mthca_arbel_ud_seg);
+ else
+ cap->max_inline_data -= sizeof (struct
mthca_tavor_ud_seg);
+ break;
+
+ default:
+ /*
+* inline data won't be used in the same WQE as an
+* atomic or bind segment, so we don't have to
+* subtract anything off here.
+*/
+ break;
+ }
+
+ cap->max_send_wr = qp->sq.max;
+ cap->max_recv_wr = qp->rq.max;
+ cap->max_send_sge= qp->sq.max_gs;
+ cap->max_recv_sge= qp->rq.max_gs;
+}
+
struct mthca_qp *mthca_find_qp(struct mthca_context *ctx, uint32_t qpn)
{
int tind = (qpn & (ctx->num_qps - 1)) >> ctx->qp_table_shift;
--- libmthca/src/verbs.c(revision 2206)
+++ libmthca/src/verbs.c(working copy)
@@ -270,7 +270,6 @@ struct ibv_qp *mthca_create_qp(struct ib
qp->qpt = attr->qp_type;
qp->sq.max = align_qp_size(pd->context, attr->cap.max_send_wr);
- qp->sq.max_gs= attr->cap.max_send_sge;
qp->sq.next_ind = 0;
qp->sq.last_comp = qp->sq.max - 1;
qp->sq.head = 0;
@@ -278,14 +277,13 @@ struct ibv_qp *mthca_create_qp(struct ib
qp->sq.last = NULL;
qp->rq.max = align_qp_size(pd->context, attr->cap.max_recv_wr);
- qp->rq.max_gs= attr->cap.max_recv_sge;
qp->rq.next_ind = 0;
qp->rq.last_comp = qp->rq.max - 1;
qp->rq.head = 0;
qp->rq.tail = 0;
qp->rq.last = NULL;
- if (mthca_alloc_qp_buf(pd, qp))
+ if (mthca_alloc_qp_buf(pd, &attr->cap, qp))
goto err;
if (pthread_spin_init(&qp->sq.lock, PTHREAD_PROCESS_PRIVATE) ||
@@ -332,6 +330,8 @@ struct ibv_qp *mthca_create_qp(struct ib
if (ret)
goto err_destroy;
+ mthca_return_cap(pd, qp, &attr->cap);
+
return &qp->ibv_qp;
err_destroy:
--- libmthca/src/mthca.h(revision 2190)
+++ libmthca/src/mthca.h(working copy)
@@ -284,7 +284,10 @@ extern int mthca_arbel_post_send(struct
struct ibv_send_wr **bad_wr);
extern int mthca_arbel_post_recv(struct ibv_qp *ibqp, struct ibv_recv_wr *wr,
struct ibv_recv_wr **bad_wr);
-extern int mthca_alloc_qp_buf(struct ibv_pd *pd, struct mthca_qp *qp);
+extern int mthca_alloc_qp_buf(struct ibv_pd *pd, struct ibv_qp_cap *cap,
+ struct mthca_qp *qp);
+extern void mthca_return_cap(struct ibv_pd *pd, struct mthca_qp *qp,
+struct ibv_qp_cap *cap);
extern struct mthca_qp *mthca_find_qp(struct mthca_context *ctx, uint32_t qpn);
extern int mthca_store_qp(struct mthca_context *ctx, uint32_t qpn, struct
mthca_qp *qp);
extern void mthca_clear_qp(struct mthca_context *ctx, uint32_t qpn);
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit ht
[openib-general] Re: MAD module removal and MAD cache
On Fri, 2005-05-13 at 15:31, Sean Hefty wrote: > Hal Rosenstock wrote: > > Hi Sean, > > > > The MAD send code can place a send request on the send list, the QP's > > send queue, or overflow list. > > > > On port close, I see the receive queue being cleaned up but not these. > > > > Am I missing something ? If I'm not, then this may be the MAD cache leak > > which causes a problem when running SM, killing it, and trying to remove > > the modules. > > When a MAD is sent, a reference is taken on the mad_agent. Cleanup of these > lists should occur automatically as a send operation completes. We need to > be careful about trying to perform cleanup during mad_agent destruction, > since the MAD may be posted to the QP. If it is, we need to wait until we > see its completion. > > When a mad_agent is destroyed, all outstanding MADs on its send_list are > canceled. This will complete all MADs waiting for a response, but those on > the QP's send_queue or overflow_list still need to wait for a completion. > > If the mad_agent destruction is proceeding, then it sounds like these lists > are empty. To verify, you could add a check that the mad_agent's send_list > is empty before deregister returns. I forgot that was how it worked.. I used to know this. The completions are not occuring in that case: May 13 16:17:47 localhost kernel: ib_mad: handle_outgoing_dr_smp: MAD 0xce9a4030 allocated May 13 16:17:47 localhost kernel: ib_mad: handle_outgoing_dr_smp: MAD 0xce9a41c0 allocated May 13 16:17:47 localhost kernel: ib_mad: handle_outgoing_dr_smp: MAD 0xce9a4350 allocated May 13 16:17:47 localhost kernel: ib_mad: handle_outgoing_dr_smp: MAD 0xce9a44e0 allocated May 13 16:17:47 localhost kernel: ib_mad: handle_outgoing_dr_smp: MAD 0xc2ea5e40 allocated I think this is because handle_outgoing_dr_smp isn't "playing by the rules" in ib_post_send_mad so it is not being tracked appropriately :-( My bad... -- Hal ___ 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] [CM] reject stale connections
The following patch will reject stale connection requests.
It also fixes a couple of minor error handling cleanup issues
found during testing, and fixes a bug handling a stale
connection reject message where the cm_id would access an
invalid timewait pointer.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
Index: core/cm.c
===
--- core/cm.c (revision 2346)
+++ core/cm.c (working copy)
@@ -185,10 +185,35 @@ static int cm_alloc_msg(struct cm_id_pri
return 0;
}
+static int cm_alloc_response_msg(struct cm_port *port,
+struct ib_mad_recv_wc *mad_recv_wc,
+struct ib_mad_send_buf **msg)
+{
+ struct ib_mad_send_buf *m;
+ struct ib_ah *ah;
+
+ ah = ib_create_ah_from_wc(port->mad_agent->qp->pd, mad_recv_wc->wc,
+ mad_recv_wc->recv_buf.grh, port->port_num);
+ if (IS_ERR(ah))
+ return PTR_ERR(ah);
+
+ m = ib_create_send_mad(port->mad_agent, 1, mad_recv_wc->wc->pkey_index,
+ ah, 0, sizeof(struct ib_mad_hdr),
+ sizeof(struct ib_mad)-sizeof(struct ib_mad_hdr),
+ GFP_ATOMIC);
+ if (IS_ERR(m)) {
+ ib_destroy_ah(ah);
+ return PTR_ERR(m);
+ }
+ *msg = m;
+ return 0;
+}
+
static void cm_free_msg(struct ib_mad_send_buf *msg)
{
ib_destroy_ah(msg->send_wr.wr.ud.ah);
- cm_deref_id(msg->context[0]);
+ if (msg->context[0])
+ cm_deref_id(msg->context[0]);
ib_free_send_mad(msg);
}
@@ -531,10 +556,7 @@ static void cm_cleanup_timewait(struct c
spin_unlock_irqrestore(&cm.lock, flags);
}
-static struct cm_timewait_info * cm_create_timewait_info(u32 local_id,
-u32 remote_id,
-u64 remote_ca_guid,
-u32 remote_qpn)
+static struct cm_timewait_info * cm_create_timewait_info(u32 local_id)
{
struct cm_timewait_info *timewait_info;
@@ -544,10 +566,6 @@ static struct cm_timewait_info * cm_crea
memset(timewait_info, 0, sizeof *timewait_info);
timewait_info->work.local_id = local_id;
- timewait_info->work.remote_id = remote_id;
- timewait_info->remote_ca_guid = remote_ca_guid;
- timewait_info->remote_qpn = remote_qpn;
-
INIT_WORK(&timewait_info->work.work, cm_work_handler,
&timewait_info->work);
timewait_info->work.cm_event.event = IB_CM_TIMEWAIT_EXIT;
@@ -674,30 +692,33 @@ int ib_cm_listen(struct ib_cm_id *cm_id,
}
EXPORT_SYMBOL(ib_cm_listen);
-static void cm_format_mad_hdr(struct ib_mad_hdr *hdr,
- struct cm_id_private *cm_id_priv,
- enum cm_msg_attr_id attr_id,
- enum cm_msg_sequence msg_seq)
+static u64 cm_form_tid(struct cm_id_private *cm_id_priv,
+ enum cm_msg_sequence msg_seq)
{
u64 hi_tid, low_tid;
+ hi_tid = ((u64) cm_id_priv->av.port->mad_agent->hi_tid) << 32;
+ low_tid = (u64) (cm_id_priv->id.local_id | (msg_seq << 30));
+ return cpu_to_be64(hi_tid | low_tid);
+}
+
+static void cm_format_mad_hdr(struct ib_mad_hdr *hdr,
+ enum cm_msg_attr_id attr_id, u64 tid)
+{
hdr->base_version = IB_MGMT_BASE_VERSION;
hdr->mgmt_class= IB_MGMT_CLASS_CM;
hdr->class_version = IB_CM_CLASS_VERSION;
hdr->method= IB_MGMT_METHOD_SEND;
hdr->attr_id = attr_id;
-
- hi_tid = ((u64) cm_id_priv->av.port->mad_agent->hi_tid) << 32;
- low_tid = (u64) (cm_id_priv->id.local_id | (msg_seq << 30));
- hdr->tid = cpu_to_be64(hi_tid | low_tid);
+ hdr->tid = tid;
}
static void cm_format_req(struct cm_req_msg *req_msg,
struct cm_id_private *cm_id_priv,
struct ib_cm_req_param *param)
{
- cm_format_mad_hdr(&req_msg->hdr, cm_id_priv,
- CM_REQ_ATTR_ID, CM_MSG_SEQUENCE_REQ);
+ cm_format_mad_hdr(&req_msg->hdr, CM_REQ_ATTR_ID,
+ cm_form_tid(cm_id_priv, CM_MSG_SEQUENCE_REQ));
req_msg->local_comm_id = cm_id_priv->id.local_id;
req_msg->service_id = param->service_id;
@@ -755,6 +776,10 @@ static void cm_format_req(struct cm_req_
static inline int cm_validate_req_param(struct ib_cm_req_param *param)
{
+ /* peer-to-peer not supported */
+ if (param->peer_to_peer)
+ return -EINVAL;
+
if (!param->primary_path)
return -EINVAL;
@@ -796,14 +821,19 @@ int ib_send_cm_req(struct ib_cm_id *cm_i
}
spin_unlock_irqrestore(&cm_id_priv->lock, flags);
+ cm_id_priv->timewait_info = cm
[openib-general] Re: [PATCH][TRIVIAL] [kdapl] Minor CM Changes
Committed in revision 2346.
On Fri, 13 May 2005, Hal Rosenstock wrote:
halr> Minor CM changes
halr> Change label in do_rep_recv to more appropriate name
halr>
halr> Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
halr>
halr> Index: dapl_openib_cm.c
halr> ===
halr> -- dapl_openib_cm.c (revision 2331)
halr> +++ dapl_openib_cm.c (working copy)
halr> @@ -68,7 +68,7 @@
halr> if (conn->ep->qp_handle == IB_INVALID_HANDLE) {
halr> dapl_dbg_log(DAPL_DBG_TYPE_ERR, " do_rep_recv: invalid qp "
halr>"handle\n");
halr> - goto reject;
halr> + goto disc;
halr> }
halr>
halr> /* First, transition QP to RTR */
halr> @@ -76,7 +76,7 @@
halr> if (status) {
halr> dapl_dbg_log(DAPL_DBG_TYPE_ERR, " do_rep_recv: could not "
halr>"modify QP state to RTR status %d\n", status);
halr> - goto reject;
halr> + goto disc;
halr> }
halr>
halr> /* Now, transition QP to RTS */
halr> @@ -84,23 +84,22 @@
halr> if (status) {
halr> dapl_dbg_log(DAPL_DBG_TYPE_ERR, " do_rep_recv: could not "
halr>"modify QP state to RTS status %d\n", status);
halr> - goto reject;
halr> + goto disc;
halr> }
halr>
halr> status = ib_send_cm_rtu(conn->cm_id, NULL, 0);
halr> if (status) {
halr> dapl_dbg_log(DAPL_DBG_TYPE_ERR, " do_rep_recv: ib_send_cm_rtu "
halr>"failed: %d\n", status);
halr> - goto reject;
halr> + goto disc;
halr> }
halr>
halr> dapl_evd_connection_callback(conn, IB_CME_CONNECTED,
halr>rep_recv_param->private_data, conn->ep);
halr> return;
halr>
halr> -reject:
halr> - ib_send_cm_rej(conn->cm_id, IB_CM_REJ_CONSUMER_DEFINED, NULL, 0,
halr> -NULL, 0);
halr> +disc:
halr> + ib_send_cm_dreq(conn->cm_id, NULL, 0); /* ??? */
halr> dapl_evd_connection_callback(conn, IB_CME_LOCAL_FAILURE, NULL,
halr>conn->ep);
halr> }
halr> @@ -456,7 +455,7 @@
halr> if (status < 0) {
halr> dapl_dbg_log(DAPL_DBG_TYPE_ERR, " ib_at_route_by_ip failed "
halr>"with status %d\n", status);
halr> - dapl_destroy_cm_id(conn);
halr> + dapl_destroy_cm_id(conn); /* ??? */
halr> return DAT_INTERNAL_ERROR;
halr> }
halr>
halr>
halr>
___
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] Re: MAD module removal and MAD cache
Hal Rosenstock wrote: Hi Sean, The MAD send code can place a send request on the send list, the QP's send queue, or overflow list. On port close, I see the receive queue being cleaned up but not these. Am I missing something ? If I'm not, then this may be the MAD cache leak which causes a problem when running SM, killing it, and trying to remove the modules. When a MAD is sent, a reference is taken on the mad_agent. Cleanup of these lists should occur automatically as a send operation completes. We need to be careful about trying to perform cleanup during mad_agent destruction, since the MAD may be posted to the QP. If it is, we need to wait until we see its completion. When a mad_agent is destroyed, all outstanding MADs on its send_list are canceled. This will complete all MADs waiting for a response, but those on the QP's send_queue or overflow_list still need to wait for a completion. If the mad_agent destruction is proceeding, then it sounds like these lists are empty. To verify, you could add a check that the mad_agent's send_list is empty before deregister returns. - 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] Re: [PATCH] libibcm building
On Fri, May 13, 2005 at 10:22:53AM -0400, Hal Rosenstock wrote: > Hi Libor, > > A couple of minor libibcm building comments: > > 1. When running autogen.sh, it warns about: > Makefile.am:19: variable `ucm_version_script' not defined > > 2. example/simple is not built by the current makefile generated. Below > is a patch for this. > > Add building of simple example for user CM to generated makefile > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> Thanks, applied and checked in. -Libor ___ 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] Re: [openib-commits] r2337 - gen2/users/jlentini/linux-kernel
James> I had a hard time checking in this update. Subversion kept James> spitting out messages that my text-base file didn't have James> the correct checksum value. Has anyone ever seen that? Is it possible that you modified a file in a .svn directory somewhere? Based on the typo checked into the TODO, it seems like maybe you did a recursive search and replace of 'spin_lock' with 'spin_lock_irqsave' in your source tree, which could screw up subversion's private original copy of the TODO file. - 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] Re: [PATCH] libibcm/examples/simple.c: Eliminate a couple of warnings
On Fri, May 13, 2005 at 10:41:57AM -0400, Hal Rosenstock wrote: > libibcm/examples/simple.c: Eliminate a couple of warnings > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> Applied, but including netinet/in.h required me to rename connect() because of the type conflict in socket.h. Also I rmeoved the ifdef'd code. Thanks. -Libor ___ 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] MAD module removal and MAD cache
Hi Sean, The MAD send code can place a send request on the send list, the QP's send queue, or overflow list. On port close, I see the receive queue being cleaned up but not these. Am I missing something ? If I'm not, then this may be the MAD cache leak which causes a problem when running SM, killing it, and trying to remove the modules. -- Hal ___ 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] Re: [PATCHv2] kDAPL: remove DAT_RETURN
Caitlin, there has been sufficient discussion about user vs kernel space on this list in the past. I'll recap key points. But you'll want to use google (or something) to read some of the previous discussion on this topic. On Fri, May 13, 2005 at 11:52:34AM -0700, Caitlin Bestler wrote: > What about kernel clients that are compiled separately from the kernel > that want to be OS neutral and use kdat.h as published by the DAT > Collaborative? There is no such thing as OS neutral code when we are talking about kernel support. Some code ports more easily between OSs. Open source community is sensitive to this issue only because the support model is different. > Secondly, many routines are identical in user and kernel (in fact the > common directory is bigger than either the udapl or kdapl directory > on the sourceforge implementation) requiring that this code be > maintained in parallel for the kernel and partner udapl librarires > seems like a lot of extra long term work. kernel and user space do not have the same requirements. kernel is ultimately responsible for enforcing userspace policies (e.g. security, fairness, access rights, etc). Some of the code can be shared with userspace, but don't expect that shared code to be OS agnostic as well. Bottomline is some of the code will need to be maintained in parallel. grant ___ 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] Re: [openib-commits] r2337 - gen2/users/jlentini/linux-kernel
On Fri, 2005-05-13 at 14:10 -0400, James Lentini wrote: > I had a hard time checking in this update. Subversion kept spitting > out messages that my text-base file didn't have the correct checksum > value. Has anyone ever seen that? I haven't. I might suggest blowing away your whole archive and pulling a fresh copy. Also, probably a good idea to make sure you are using the latest version of subversion. [EMAIL PROTECTED] dat-provider]$ svn --version svn, version 1.1.4 (r13838) compiled Apr 13 2005, 12:25:53 -tduffy signature.asc Description: This is a digitally signed message part ___ 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] Re: [PATCH] [kdapl]: Reduce CM retry count
Committed in revision 2341.
On Fri, 13 May 2005, Hal Rosenstock wrote:
halr> Reduce CM retry count
halr>
halr> Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
halr>
halr> Index: dapl_openib_cm.h
halr> ===
halr> -- dapl_openib_cm.h(revision 2331)
halr> +++ dapl_openib_cm.h(working copy)
halr> @@ -40,7 +40,7 @@
halr> #define DAPL_OPENIB_RC_RETRY_COUNT 7
halr> #define DAPL_OPENIB_RNR_RETRY_COUNT 6
halr> #define DAPL_OPENIB_CM_RESPONSE_TIMEOUT 20 /* 4 sec */
halr> -#define DAPL_OPENIB_MAX_CM_RETRIES 15
halr> +#define DAPL_OPENIB_MAX_CM_RETRIES 4
halr>
halr> typedef enum {
halr> IB_CME_CONNECTED,
halr>
___
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] Re: [PATCHv2] kDAPL: remove DAT_RETURN
On Fri, 2005-05-13 at 11:52 -0700, Caitlin Bestler wrote: > What about kernel clients that are compiled separately from the kernel > that want to be OS neutral and use kdat.h as published by the DAT > Collaborative? That never want to be put back into mainline Linux? Too bad. Not our problem. -tduffy signature.asc Description: This is a digitally signed message part ___ 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] Re: [PATCH] make private data pointers const
>> This patch affects ib_cm.h and cm.c, which appear to be maintained >> by Sean, and ucm.c, which appears to be maintained by Libor. >> >> The patch adds the const qualifier to private data pointers passed >> into the IB layer. > >Sean, if you're going to check in the CM portion, go ahead and check >in ucm.c as well. Can do. I'll do this within the next couple of work days. - 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] Re: [PATCHv2] kDAPL: remove DAT_RETURN
On 5/13/05, James Lentini <[EMAIL PROTECTED]> wrote: > > caitlin> DAT_RETURN serves two distinct purposes: it is an immediate return > caitlin> to a kernel specific caller, and it is a standardized error encoding > for > caitlin> clients outside of the linux kernel (loadable modules and or proxied > caitlin> user consumers). > caitlin> > caitlin> Even if the functional return to in-kernel clients is converted to > comply > caitlin> with kernel coding conventions, the information currently encoded > caitlin> in the DAT_RETURN needs to be deliverable to DAPL clients that > caitlin> are outside of the linux kernel. > > DAPL clients outside the linux kernel, userspace clients, should use > the uDAPL API. No changes are being proposed for the uDAPL API. > What about kernel clients that are compiled separately from the kernel that want to be OS neutral and use kdat.h as published by the DAT Collaborative? Secondly, many routines are identical in user and kernel (in fact the common directory is bigger than either the udapl or kdapl directory on the sourceforge implementation) requiring that this code be maintained in parallel for the kernel and partner udapl librarires seems like a lot of extra long term work. ___ 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] Re: [PATCH] SDP & CM: change some functions to return void
On Fri, May 13, 2005 at 09:30:32AM -0700, Sean Hefty wrote: > Tom Duffy wrote: > > This patch changes some functions to return void rather than an int > > since they were always returning 0, thus making checking return values > > rather pointless. The patch touches both SDP and CM. > > Thanks, Tom. Since the majority of these changes affect SDP, and the > check-ins should be coordinated, I'll ask Libor if he can commit the CM > changes when he commits the SDP changes. > > Libor, can you commit the CM changes when you commit the SDP changes? :) > There are also some (void)ib_destroy_cm_id casts in umc.c that could lose > the casts with this change as well. OK, I applied and commited the patch. Thanks Tom. -Libor ___ 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] Re: [PATCH] make private data pointers const
On Thu, May 12, 2005 at 10:00:47PM -0400, James Lentini wrote: > > This patch affects ib_cm.h and cm.c, which appear to be maintained > by Sean, and ucm.c, which appears to be maintained by Libor. > > The patch adds the const qualifier to private data pointers passed > into the IB layer. Sean, if you're going to check in the CM portion, go ahead and check in ucm.c as well. Thanks. -Libor ___ 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] Re: [PATCHv2] kDAPL: remove DAT_RETURN
caitlin> DAT_RETURN serves two distinct purposes: it is an immediate return caitlin> to a kernel specific caller, and it is a standardized error encoding for caitlin> clients outside of the linux kernel (loadable modules and or proxied caitlin> user consumers). caitlin> caitlin> Even if the functional return to in-kernel clients is converted to comply caitlin> with kernel coding conventions, the information currently encoded caitlin> in the DAT_RETURN needs to be deliverable to DAPL clients that caitlin> are outside of the linux kernel. DAPL clients outside the linux kernel, userspace clients, should use the uDAPL API. No changes are being proposed for the uDAPL API. caitlin> Therefore the current enums need to be retained, and there should caitlin> be some mechanism for these precise diagnostics to be relayed caitlin> to non-kernel clients. An external shim cannot do this *after* caitlin> the information is lost by using a standard error return. (I am caitlin> assuming that creating a list of error returns that encompass caitlin> everything that DAT_RETURN *Can* encode is out of the caitlin> question, there's a reason it's multi-layer now). Many of the DAT_RETURN values are useful for debugging (e.g. the ability to say that parameter number 4 is invalid). However, I can't imagine a DAT API consumer that would actually provide error recovery code for each of the 22 major * 102 minor = 2244 different possible error values, let alone warning values, for every API call. I think that some of this information can be logged or obtained during debugging. caitlin> One possibility would be to add an external_client_dat_return * caitlin> out parameter that would allow a shim to restore the full caitlin> DAT defined error code for non-kernel clients. Adding an additional out parameter to every API function would clutter the interface. caitlin> On 5/12/05, Tom Duffy <[EMAIL PROTECTED]> wrote: caitlin> > On Thu, 2005-05-12 at 11:50 -0400, James Lentini wrote: caitlin> > > Thanks for the updated patch Tom. It is committed in revision 2316. caitlin> > > caitlin> > > Eventually we will need to remove our dat_return_* enums and replace caitlin> > > our return values with errno values. Correct? caitlin> > caitlin> > That is right. This is just a first pass at cleaning it up. caitlin> > caitlin> > -tduffy ___ 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] $B?75,EPO?$NJ}$O(B10000$B1_J,L5NA(B
$B0lK|1_J,!*40A4L5NA$G;HMQ(BOK $B"#:#$J$i4V$K9g$&(BW$B%A%c%s%9!*L5NA%]%$%s%H%"%C%W3Z$7$5(B100$BG\!*"#(B $B"([EMAIL PROTECTED](B $B0l0L!'5U1g!J(B189$BL>EPO?!K(B $BFs0L!'1g8r!J(B429$BL>EPO?!K(B $B;00L!'(BSM$B5U1g!J(B243$BL>EPO?!K(B $B;M0L!'%;%U%l!J(B1038$BL>EPO?!K(B $B8^0L!'ITNQ!J(B2421$BL>EPO?!K(B $BO;0L!'%F%l%(%C%A!J(B3463$BL>EPO?!K(B $B!&(B $B!&(B $B!&(B $B0lK|1_J,40A4L5NA$G$*;n$7$O(B $B"-"-"-(B http://awg.webchu.com/?summer29 $BB~:#!*?75,EPO?$7$?J}$K$OL5NA$G(B10,000$B1_J,$4MxMQ=PMh$^$9!#(B $B!ZL5NA%]%$%s%HFb$G==J,$K%Q!<%H%J!<$rC5$9;v$,=PMh$^$9!#![(B $B"((B18$B:P0J>e$NHkL)87http://awg.webchu.com/?summer29 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= $B"((B18$B:PL$K~$N$4MxMQ1sN82<$5$$!#(B $B:#8e!"%a!<%k$Nl9g$O2<5-(BURL$B$KJV?.2<$5$$!#(B [EMAIL PROTECTED] ___ 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] Re: [openib-commits] r2337 - gen2/users/jlentini/linux-kernel
On Fri, 13 May 2005, Tom Duffy wrote: tduffy> On Fri, 2005-05-13 at 10:51 -0700, [EMAIL PROTECTED] wrote: tduffy> > Modified: gen2/users/jlentini/linux-kernel/TODO tduffy> > === tduffy> > --- gen2/users/jlentini/linux-kernel/TODO 2005-05-13 17:31:24 UTC (rev 2336) tduffy> > +++ gen2/users/jlentini/linux-kernel/TODO 2005-05-13 17:51:11 UTC (rev 2337) tduffy> > @@ -1,5 +1,5 @@ tduffy> > *) Test static compilation of DAT and IB DAT PROVIDER tduffy> > -*) consider using spin_lock_irqsave() instead of spin_lock() tduffy> > +*) consider using spin_lock_irqsave() instead of spin_lock_irqsave() tduffy> tduffy> huh? I know :) I don't know what happened there. That change was not intentional. Hal pointed it out and I've fixed it. I had a hard time checking in this update. Subversion kept spitting out messages that my text-base file didn't have the correct checksum value. Has anyone ever seen that? james ___ 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] Re: [openib-commits] r2337 - gen2/users/jlentini/linux-kernel
On Fri, 2005-05-13 at 11:04 -0700, Tom Duffy wrote: > On Fri, 2005-05-13 at 10:51 -0700, [EMAIL PROTECTED] wrote: > > Modified: gen2/users/jlentini/linux-kernel/TODO > > === > > --- gen2/users/jlentini/linux-kernel/TODO 2005-05-13 17:31:24 UTC (rev > > 2336) > > +++ gen2/users/jlentini/linux-kernel/TODO 2005-05-13 17:51:11 UTC (rev > > 2337) > > @@ -1,5 +1,5 @@ > > *) Test static compilation of DAT and IB DAT PROVIDER > > -*) consider using spin_lock_irqsave() instead of spin_lock() > > +*) consider using spin_lock_irqsave() instead of spin_lock_irqsave() > > huh? nevermind. -tduffy signature.asc Description: This is a digitally signed message part ___ 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] Re: [openib-commits] r2337 - gen2/users/jlentini/linux-kernel
On Fri, 2005-05-13 at 10:51 -0700, [EMAIL PROTECTED] wrote: > Modified: gen2/users/jlentini/linux-kernel/TODO > === > --- gen2/users/jlentini/linux-kernel/TODO 2005-05-13 17:31:24 UTC (rev > 2336) > +++ gen2/users/jlentini/linux-kernel/TODO 2005-05-13 17:51:11 UTC (rev > 2337) > @@ -1,5 +1,5 @@ > *) Test static compilation of DAT and IB DAT PROVIDER > -*) consider using spin_lock_irqsave() instead of spin_lock() > +*) consider using spin_lock_irqsave() instead of spin_lock_irqsave() huh? -tduffy signature.asc Description: This is a digitally signed message part ___ 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] Re: user-mode verbs on Itanium
On Thu, May 12, 2005 at 08:55:50AM -0700, Grant Grundler wrote: >On Wed, May 11, 2005 at 10:21:38AM +0300, Michael S. Tsirkin wrote: >> You mean just sample the clock before the first post? > >Yes. > >> That would be easy, but lets look at what does it measure: >> >> On the client, you just get the time it takes to perform the >> first post_send operation. If this is interesting to you, I agree, >> but lets take the timestamps around each post send operation to >> make it statistically relevant. >> Let me know - and need to think of a way to do this without >> affecting latency numbers. > >Yes, I'd like to try that. >But a few more of my pending patches need to either be rejected >or (preferably) accepted. Grant, please add the perftest.05 patch to the batch since without it the test is broken for i386. TIA, Bernhard ___ 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] Re: use of virt_to_phys in sdp
Libor> It is incorrect. The regular send/recv path uses the DMA Libor> API correctly, but RDMA to internal buffers on both the Libor> send and receive path is still using plain old Libor> virt_to_phys. Also, does FMR map/unmap use the DMA API, or Libor> does that need to be taken care of as well? The FMR verbs functions just take the addresses passed in by the consumer and write them directly into the HCA's page table. So the consumer needs to use the DMA API to get bus addresses. - 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] Re: [PATCH] kDAPL: remove typedef DAT_NAME_PTR
Committed in revision 2336.
On Thu, 12 May 2005, Tom Duffy wrote:
tduffy> Remove typedef DAT_NAME_PTR. Also get rid of DAT_UVERYLONG & DAT_PADDR
tduffy> that are not used anywhere outside of dat.h. Also, a little more
tduffy> whitespace cleaning that should have been done with the DAT_RETURN
tduffy> patch.
tduffy>
tduffy> Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
tduffy>
tduffy> diff -Nurp -X /home/tduffy/dontdiff linux-kernel/dat/api.c
linux-kernel2/dat/api.c
tduffy> --- linux-kernel/dat/api.c 2005-05-12 10:08:24.77400 -0700
tduffy> +++ linux-kernel2/dat/api.c 2005-05-12 11:02:59.847003000 -0700
tduffy> @@ -575,7 +575,7 @@ static u32 dat_strerror_minor(u32 value,
tduffy> * Function: dat_ia_openv
tduffy>
***/
tduffy>
tduffy> -u32 dat_ia_openv(const DAT_NAME_PTR name, int async_event_qlen,
tduffy> +u32 dat_ia_openv(const char *name, int async_event_qlen,
tduffy> DAT_EVD_HANDLE *async_event_handle, DAT_IA_HANDLE
*ia_handle,
tduffy> u32 dat_major, u32 dat_minor, boolean_t thread_safety)
tduffy> {
tduffy> diff -Nurp -X /home/tduffy/dontdiff linux-kernel/dat/dat.h
linux-kernel2/dat/dat.h
tduffy> --- linux-kernel/dat/dat.h 2005-05-12 10:25:26.111007000 -0700
tduffy> +++ linux-kernel2/dat/dat.h 2005-05-12 11:14:17.374001000 -0700
tduffy> @@ -37,11 +37,6 @@
tduffy> #define DAT_VERSION_MINOR 2
tduffy> #define DAT_THREADSAFE FALSE
tduffy>
tduffy> -/* unsigned longest native to compiler */
tduffy> -typedef unsigned long long DAT_UVERYLONG;
tduffy> -
tduffy> -typedef u64 DAT_PADDR;
tduffy> -
tduffy> /*
tduffy> * All return codes are actually a 3-way tuple:
tduffy> *
tduffy> @@ -352,7 +347,6 @@ typedef enum dat_handle_type {
tduffy> DAT_HANDLE_TYPE_SRQ
tduffy> } DAT_HANDLE_TYPE;
tduffy>
tduffy> -typedef char *DAT_NAME_PTR;
tduffy> #define DAT_NAME_MAX_LENGTH 256
tduffy>
tduffy> struct dat_named_attr {
tduffy> @@ -370,7 +364,7 @@ typedef enum {
tduffy> typedef union dat_context {
tduffy> void *as_ptr;
tduffy> u64 as_64;
tduffy> - DAT_UVERYLONG as_index;
tduffy> + unsigned long long as_index;
tduffy> } DAT_CONTEXT;
tduffy>
tduffy> typedef DAT_CONTEXT DAT_DTO_COOKIE;
tduffy> @@ -983,7 +977,7 @@ typedef union dat_region_description {
tduffy> DAT_LMR_HANDLE for_lmr_handle;
tduffy> void *for_pointer; /* For kdapl only */
tduffy> void *for_array;/* For kdapl only */
tduffy> - DAT_PADDR for_pa; /* For kdapl only */
tduffy> + u64 for_pa; /* For kdapl only */
tduffy> } DAT_REGION_DESCRIPTION;
tduffy>
tduffy> /* LMR Arguments */
tduffy> @@ -1103,179 +1097,176 @@ struct dat_provider_attr {
tduffy> *
tduffy> /
tduffy>
tduffy> -typedef u32 (*DAT_IA_OPEN_FUNC) (
tduffy> -const DAT_NAME_PTR, int, DAT_EVD_HANDLE *, DAT_IA_HANDLE *);
tduffy> +typedef u32 (*DAT_IA_OPEN_FUNC)(const char *, int, DAT_EVD_HANDLE *,
tduffy> + DAT_IA_HANDLE *);
tduffy>
tduffy> -typedef u32 (*DAT_IA_OPENV_FUNC) (
tduffy> -const DAT_NAME_PTR, int, DAT_EVD_HANDLE *, DAT_IA_HANDLE *,
tduffy> -u32, u32, boolean_t);
tduffy> +typedef u32 (*DAT_IA_OPENV_FUNC)(const char *, int, DAT_EVD_HANDLE *,
tduffy> +DAT_IA_HANDLE *, u32, u32, boolean_t);
tduffy>
tduffy> -typedef u32 (*DAT_IA_CLOSE_FUNC) (DAT_IA_HANDLE, DAT_CLOSE_FLAGS);
tduffy> +typedef u32 (*DAT_IA_CLOSE_FUNC)(DAT_IA_HANDLE, DAT_CLOSE_FLAGS);
tduffy>
tduffy> -typedef u32 (*DAT_IA_QUERY_FUNC) (DAT_IA_HANDLE, DAT_EVD_HANDLE *,
tduffy> -struct dat_ia_attr *,
tduffy> -struct dat_provider_attr *);
tduffy> +typedef u32 (*DAT_IA_QUERY_FUNC)(DAT_IA_HANDLE, DAT_EVD_HANDLE *,
tduffy> +struct dat_ia_attr *,
tduffy> +struct dat_provider_attr *);
tduffy>
tduffy> -typedef u32 (*DAT_SET_CONSUMER_CONTEXT_FUNC) (DAT_HANDLE, DAT_CONTEXT);
tduffy> +typedef u32 (*DAT_SET_CONSUMER_CONTEXT_FUNC)(DAT_HANDLE, DAT_CONTEXT);
tduffy>
tduffy> -typedef u32 (*DAT_GET_CONSUMER_CONTEXT_FUNC) (DAT_HANDLE, DAT_CONTEXT
*);
tduffy> +typedef u32 (*DAT_GET_CONSUMER_CONTEXT_FUNC)(DAT_HANDLE, DAT_CONTEXT
*);
tduffy>
tduffy> -typedef u32 (*DAT_GET_HANDLE_TYPE_FUNC) (DAT_HANDLE, DAT_HANDLE_TYPE
*);
tduffy> +typedef u32 (*DAT_GET_HANDLE_TYPE_FUNC)(DAT_HANDLE, DAT_HANDLE_TYPE *);
tduffy>
tduffy> -typedef u32 (*DAT_CR_QUERY_FUNC) (DAT_CR_HANDLE, struct dat_cr_param
*);
tduffy> +typedef u32 (*DAT_CR_QUERY_FUNC)(DAT_CR_HANDLE, struct dat_cr_param *);
tduffy>
tduffy> -typedef u32 (*DAT_CR_ACCEPT_FUNC) (DAT_CR_HANDLE, DAT_EP_HANDLE, int,
tduffy> - const void*);
tduffy> +typedef u32 (*DAT_CR_ACCEPT_FUNC)(DAT_CR_HANDLE, DAT_EP_HANDLE, int,
tduf
[openib-general] Re: use of virt_to_phys in sdp
On Fri, May 13, 2005 at 05:06:00PM +0300, Michael S. Tsirkin wrote: > Use of virt_to_phys looks wrong in sdp_recv and sdp_send. > Must not the DMA API be used to get the physical address > to be put in ib_sge? It is incorrect. The regular send/recv path uses the DMA API correctly, but RDMA to internal buffers on both the send and receive path is still using plain old virt_to_phys. Also, does FMR map/unmap use the DMA API, or does that need to be taken care of as well? -Libor ___ 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] Re: [PATCH] (repost) sdp: replace mlock with get_user_pages
On Fri, May 13, 2005 at 04:51:45PM +0300, Michael S. Tsirkin wrote: > Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > > > > Libor> Always call aio_complete() immediately when > > Libor> iocb_complete() is called, and only spawn the work thread > > Libor> to unlock the memory after the aio_complete() call. The > > Libor> patch is below. > > Libor, I dont think its a good idea - this will break other assumptions, > like the assumption that the task mm isnt destroyed before we unlock > the memory. That's a good point. > > Another alternative would be to always complete aios asynchronously, > > which should preserve the order. I guess this would hurt latency for > > small ios... > > To avoid hurting latency, lets count the number of outstanding > asynchronous AIOs, and if there are asynchronous AIOs complete > all of them asynchronously. > > Does this make sense? Yes, except that the current iocb code does not reference individual sockets anywhere, and do_iocb_complete would have to be the function which decremented the per connection counter of outstanding AIOs. Also, since we don't have to do get_user_pages a second time on the send path, this would only need to be done on the recv path. -Libor ___ 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] CM: add invalid service ID handling
William Jordan wrote: Patch to respond to invalid REQs (no listener) with a REJ message. As just an FYI in case you're working on other CM areas, I'm working on sending REJs in the case of a stale connection, followed by adding in MRA support. I'm hoping to finish the state connection handling today or Monday. - 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] Re: [PATCH] SDP & CM: change some functions to return void
Tom Duffy wrote: This patch changes some functions to return void rather than an int since they were always returning 0, thus making checking return values rather pointless. The patch touches both SDP and CM. Thanks, Tom. Since the majority of these changes affect SDP, and the check-ins should be coordinated, I'll ask Libor if he can commit the CM changes when he commits the SDP changes. Libor, can you commit the CM changes when you commit the SDP changes? :) There are also some (void)ib_destroy_cm_id casts in umc.c that could lose the casts with this change as well. - 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] [PATCH] SDP & CM: change some functions to return void
This patch changes some functions to return void rather than an int
since they were always returning 0, thus making checking return values
rather pointless. The patch touches both SDP and CM.
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: linux-2.6.11-openib/drivers/infiniband/ulp/sdp/sdp_link.c
===
--- linux-2.6.11-openib/drivers/infiniband/ulp/sdp/sdp_link.c (revision 2334)
+++ linux-2.6.11-openib/drivers/infiniband/ulp/sdp/sdp_link.c (working copy)
@@ -720,19 +720,7 @@ int sdp_link_addr_init(void)
int result;
sdp_dbg_init("Link level services initialization.");
-#if 0
- /*
-* Install async event handler, to clear cache on port down
-*/
- result = tsIbAsynchronousEventHandlerRegister(TS_IB_PORT_ERROR,
- _tsSdpAsyncEventFunc,
- NULL,
- &_tsSdpAsyncHandle);
- if (result) {
-
- goto error_async;
- }
-#endif
+
info_cache = kmem_cache_create("sdp_path_info",
sizeof(struct sdp_path_info),
0, SLAB_HWCACHE_ALIGN,
@@ -784,7 +772,7 @@ error_path:
/*
* sdp_link_addr_cleanup - cleanup the link address retrival code
*/
-int sdp_link_addr_cleanup(void)
+void sdp_link_addr_cleanup(void)
{
struct sdp_path_info *info;
@@ -809,12 +797,4 @@ int sdp_link_addr_cleanup(void)
*/
kmem_cache_destroy(info_cache);
kmem_cache_destroy(wait_cache);
-#if 0
- /*
-* release async event handler
-*/
- (void)tsIbAsynchronousEventHandlerUnregister(_tsSdpAsyncHandle);
-#endif
-
- return 0;
}
Index: linux-2.6.11-openib/drivers/infiniband/ulp/sdp/sdp_inet.c
===
--- linux-2.6.11-openib/drivers/infiniband/ulp/sdp/sdp_inet.c (revision 2334)
+++ linux-2.6.11-openib/drivers/infiniband/ulp/sdp/sdp_inet.c (working copy)
@@ -1553,15 +1553,15 @@ static int __init sdp_init(void)
return 0;
error_sock:
- (void)sdp_conn_table_clear();
+ sdp_conn_table_clear();
error_conn:
- (void)sdp_buff_pool_destroy();
+ sdp_buff_pool_destroy();
error_buff:
- (void)sdp_link_addr_cleanup();
+ sdp_link_addr_cleanup();
error_link:
sdp_main_advt_cleanup();
error_advt:
- (void)sdp_main_proc_cleanup();
+ sdp_main_proc_cleanup();
error_proc:
return result; /* success */
}
@@ -1579,15 +1579,15 @@ static void __exit sdp_exit(void)
/*
* connection table
*/
- (void)sdp_conn_table_clear();
+ sdp_conn_table_clear();
/*
* delete buffer memory
*/
- (void)sdp_buff_pool_destroy();
+ sdp_buff_pool_destroy();
/*
* delete link information
*/
- (void)sdp_link_addr_cleanup();
+ sdp_link_addr_cleanup();
/*
* delete advertisment table
*/
@@ -1595,7 +1595,7 @@ static void __exit sdp_exit(void)
/*
* proc tables
*/
- (void)sdp_main_proc_cleanup();
+ sdp_main_proc_cleanup();
}
module_init(sdp_init);
Index: linux-2.6.11-openib/drivers/infiniband/ulp/sdp/sdp_proto.h
===
--- linux-2.6.11-openib/drivers/infiniband/ulp/sdp/sdp_proto.h (revision 2334)
+++ linux-2.6.11-openib/drivers/infiniband/ulp/sdp/sdp_proto.h (working copy)
@@ -186,13 +186,13 @@ void sdp_iocb_q_remove(struct sdpc_iocb
int sdp_iocb_register(struct sdpc_iocb *iocb, struct sdp_opt *conn);
-int sdp_iocb_release(struct sdpc_iocb *iocb);
+void sdp_iocb_release(struct sdpc_iocb *iocb);
int sdp_iocb_complete(struct sdpc_iocb *iocb, ssize_t status);
int sdp_iocb_lock(struct sdpc_iocb *iocb);
-int sdp_iocb_unlock(struct sdpc_iocb *iocb);
+void sdp_iocb_unlock(struct sdpc_iocb *iocb);
/*
* Generic object managment
@@ -236,7 +236,7 @@ void sdp_desc_q_clear(struct sdpc_desc_q
*/
int sdp_main_proc_init(void);
-int sdp_main_proc_cleanup(void);
+void sdp_main_proc_cleanup(void);
/*
* connection table
@@ -249,7 +249,7 @@ int sdp_conn_table_init(int proto_family
int send_buff_max,
int send_usig_max);
-int sdp_conn_table_clear(void);
+void sdp_conn_table_clear(void);
int sdp_proc_dump_conn_main(char *buffer,
int max_size,
@@ -434,7 +434,7 @@ int sdp_link_path_lookup(u32 dst_addr,
int sdp_link_addr_init(void);
-int sdp_link_addr_cleanup(void);
+void sdp_link_addr_cleanup(void);
/*
* Function types
Index: linux-2.6.11-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
===
--- linux-2.6.11-openib/drivers/in
[openib-general] $B?75,EPO?$NJ}$O(B10000$B1_J,L5NA(B
$B0lK|1_J,!*40A4L5NA$G;HMQ(BOK $B"#:#$J$i4V$K9g$&(BW$B%A%c%s%9!*L5NA%]%$%s%H%"%C%W3Z$7$5(B100$BG\!*"#(B $B"([EMAIL PROTECTED](B $B0l0L!'5U1g!J(B189$BL>EPO?!K(B $BFs0L!'1g8r!J(B429$BL>EPO?!K(B $B;00L!'(BSM$B5U1g!J(B243$BL>EPO?!K(B $B;M0L!'%;%U%l!J(B1038$BL>EPO?!K(B $B8^0L!'ITNQ!J(B2421$BL>EPO?!K(B $BO;0L!'%F%l%(%C%A!J(B3463$BL>EPO?!K(B $B!&(B $B!&(B $B!&(B $B0lK|1_J,40A4L5NA$G$*;n$7$O(B $B"-"-"-(B http://awg.webchu.com/?summer19 $BB~:#!*?75,EPO?$7$?J}$K$OL5NA$G(B10,000$B1_J,$4MxMQ=PMh$^$9!#(B $B!ZL5NA%]%$%s%HFb$G==J,$K%Q!<%H%J!<$rC5$9;v$,=PMh$^$9!#![(B $B"((B18$B:P0J>e$NHkL)87http://awg.webchu.com/?summer19 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= $B"((B18$B:PL$K~$N$4MxMQ1sN82<$5$$!#(B $B:#8e!"%a!<%k$Nl9g$O2<5-(BURL$B$KJV?.2<$5$$!#(B [EMAIL PROTECTED] ___ 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] libibcm/examples/simple.c: Eliminate a couple of warnings
libibcm/examples/simple.c: Eliminate a couple of warnings Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> Index: simple.c === --- simple.c(revision 2331) +++ simple.c(working copy) @@ -45,6 +45,7 @@ #include #include #include +#include #include #include @@ -63,7 +64,6 @@ struct ib_sa_path_rec sa; union ibv_gid *dst; union ibv_gid *src; - int result; param.qp_type = IBV_QPT_RC; param.qp_num= 0xff00; ___ 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] Re: DAPL CM Reject Questions
If I don't use a function's return value, I cast it to void to say "I know this function returns something but I don't want to use it". I'm not sure were I picked up this habit, but I think it is fairly common. Some compilers will give a warning if you don't perform the cast, although gcc does not appear to. Here are some of the places I've found this construct in the 2.6.11 sources: arch/i386/kernel/apm.c (line 924) arch/i386/mach-voyager/voyager_smp.c (line 1606) crypto/tcrypt.c (line 547) drivers/acpi/events/evxface.c (line 95) On Thu, 12 May 2005, Tom Duffy wrote: tduffy> On Thu, 2005-05-12 at 17:31 -0400, James Lentini wrote: tduffy> > I've changed the above line to tduffy> > tduffy> > (void) ib_send_cm_dreq(conn->cm_id, NULL, 0); tduffy> tduffy> Is there a reason for the leading (void)? tduffy> tduffy> -tduffy tduffy> ___ 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] libibcm building
Hi Libor, A couple of minor libibcm building comments: 1. When running autogen.sh, it warns about: Makefile.am:19: variable `ucm_version_script' not defined 2. example/simple is not built by the current makefile generated. Below is a patch for this. -- Hal Add building of simple example for user CM to generated makefile Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> Index: Makefile.am === --- Makefile.am (revision 2331) +++ Makefile.am (working copy) @@ -5,7 +5,7 @@ ibcmlibdir = $(libdir)/infiniband -ibcmlib_LTLIBRARIES = src/ibcm.la +ibcmlib_LTLIBRARIES = src/libibcm.la src_ibcm_la_CFLAGS = -g -Wall -D_GNU_SOURCE @@ -15,9 +15,13 @@ ibcm_version_script = endif -src_ibcm_la_SOURCES = src/cm.c -src_ibcm_la_LDFLAGS = -avoid-version -module $(ucm_version_script) +src_libibcm_la_SOURCES = src/cm.c +src_libibcm_la_LDFLAGS = -avoid-version -module $(ucm_version_script) +bin_PROGRAMS = examples/ucm_simple +examples_ucm_simple_SOURCES = examples/simple.c +examples_ucm_simple_LDADD = $(top_builddir)/src/libibcm.la + libibcmincludedir = $(includedir)/infiniband libibcminclude_HEADERS = include/infiniband/cm_abi.h \ ___ 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] Re: [PATCH] Re: 0 op factor
Quoting r. Libor Michalek <[EMAIL PROTECTED]>: > Subject: Re: [PATCH] Re: 0 op factor > > On Tue, May 10, 2005 at 05:47:00PM -0700, Libor Michalek wrote: > > On Sat, May 07, 2005 at 07:47:18PM +0200, Bernhard Fischer wrote: > > > > > - remove expect from _sdp_cm_path_complete(). > > > > When I said that the SDP_EXPECT should eventually be removed, I meant > > that the functions which have their return values checked by SDP_EXPECT > > should either be turned into void return functions, or something > > intelligent should be done with the return value, such as error recovery > > or propogation. The functions which should be turned into void functions > > are the ones which will never return anything but success. > > To expand on the last point. There are a lot of functions, for > example those in sdp_buff.c, which check for incorrect function > usage, such as checking that a buffer is not already in a queue before > inserting it into a queue. These checks could be removed entirely or > the checks could be made and a call to BUG() in case the condition > is met. I prefer the later since the former would corrupt the entire > queue. I'm not sure which is preferable to everyone else, either way > the result is that the function becomes a void. > > -Libor IMO BUG_ON is the way to go. -- MST - Michael S. Tsirkin ___ 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] use of virt_to_phys in sdp
Use of virt_to_phys looks wrong in sdp_recv and sdp_send. Must not the DMA API be used to get the physical address to be put in ib_sge? -- MST - Michael S. Tsirkin ___ 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] Re: user-mode verbs on Itanium
Quoting r. Grant Grundler <[EMAIL PROTECTED]>: > Subject: Re: user-mode verbs on Itanium > > On Wed, May 11, 2005 at 10:21:38AM +0300, Michael S. Tsirkin wrote: > > You mean just sample the clock before the first post? > > Yes. > > > That would be easy, but lets look at what does it measure: > > > > On the client, you just get the time it takes to perform the > > first post_send operation. If this is interesting to you, I agree, > > but lets take the timestamps around each post send operation to > > make it statistically relevant. > > Let me know - and need to think of a way to do this without > > affecting latency numbers. > > Yes, I'd like to try that. > But a few more of my pending patches need to either be rejected > or (preferably) accepted. I plan to go over that on Sunday. -- MST - Michael S. Tsirkin ___ 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] Re: [PATCH] (repost) sdp: replace mlock with get_user_pages
Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > Subject: Re: [openib-general] Re: [PATCH] (repost) sdp: replace mlock with > get_user_pages > > Libor> Always call aio_complete() immediately when > Libor> iocb_complete() is called, and only spawn the work thread > Libor> to unlock the memory after the aio_complete() call. The > Libor> patch is below. Libor, I dont think its a good idea - this will break other assumptions, like the assumption that the task mm isnt destroyed before we unlock the memory. > Another alternative would be to always complete aios asynchronously, > which should preserve the order. I guess this would hurt latency for > small ios... > > - R. > To avoid hurting latency, lets count the number of outstanding asynchronous AIOs, and if there are asynchronous AIOs complete all of them asynchronously. Does this make sense? -- MST - Michael S. Tsirkin ___ 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] user_mad: Support RMPP on send side
user_mad: Support RMPP on send side
Note that this change will need a coordinated change to OpenSM and some
userspace/management libraries which will be done as soon as possible
once this patch is accepted.
Receive side support for RMPP will be added separately.
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: infiniband/include/ib_user_mad.h
===
--- infiniband/include/ib_user_mad.h(revision 2331)
+++ infiniband/include/ib_user_mad.h(working copy)
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2004 Topspin Communications. All rights reserved.
+ * Copyright (c) 2005 Voltaire, 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
@@ -42,7 +43,7 @@
* Increment this value if any changes that break userspace ABI
* compatibility are made.
*/
-#define IB_USER_MAD_ABI_VERSION2
+#define IB_USER_MAD_ABI_VERSION3
/*
* Make sure that all structs defined in this file remain laid out so
@@ -51,8 +52,7 @@
*/
/**
- * ib_user_mad - MAD packet
- * @data - Contents of MAD
+ * ib_user_mad_hdr - MAD packet header
* @id - ID of agent MAD received with/to be sent with
* @status - 0 on successful receive, ETIMEDOUT if no response
* received (transaction ID in data[] will be set to TID of original
@@ -72,8 +72,7 @@
*
* All multi-byte quantities are stored in network (big endian) byte
order.
*/
-struct ib_user_mad {
- __u8data[256];
+struct ib_user_mad_hdr {
__u32 id;
__u32 status;
__u32 timeout_ms;
@@ -91,6 +90,17 @@
};
/**
+ * ib_user_mad - MAD packet
+ * @hdr - MAD packet header
+ * @data - Contents of MAD
+ *
+ */
+struct ib_user_mad {
+ struct ib_user_mad_hdr hdr;
+ __u8data[0];
+};
+
+/**
* ib_user_mad_reg_req - MAD registration request
* @id - Set by the kernel; used to identify agent in future requests.
* @qpn - Queue pair number; must be 0 or 1.
@@ -103,6 +113,8 @@
* management class to receive.
* @oui: Indicates IEEE OUI when mgmt_class is a vendor class
* in the range from 0x30 to 0x4f. Otherwise not used.
+ * @rmpp_version: If set, indicates the RMPP version used.
+ *
*/
struct ib_user_mad_reg_req {
__u32 id;
@@ -111,6 +123,7 @@
__u8mgmt_class;
__u8mgmt_class_version;
__u8oui[3];
+ __u8rmpp_version;
};
#define IB_IOCTL_MAGIC 0x1b
Index: infiniband/core/user_mad.c
===
--- infiniband/core/user_mad.c (revision 2331)
+++ infiniband/core/user_mad.c (working copy)
@@ -1,5 +1,6 @@
/*
* Copyright (c) 2004 Topspin Communications. All rights reserved.
+ * Copyright (c) 2005 Voltaire, 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
@@ -94,10 +95,12 @@
};
struct ib_umad_packet {
- struct ib_user_mad mad;
struct ib_ah *ah;
+ struct ib_mad_send_buf *msg;
struct list_head list;
+ intlength;
DECLARE_PCI_UNMAP_ADDR(mapping)
+ struct ib_user_mad mad;
};
static const dev_t base_dev = MKDEV(IB_UMAD_MAJOR, IB_UMAD_MINOR_BASE);
@@ -114,10 +117,10 @@
int ret = 1;
down_read(&file->agent_mutex);
- for (packet->mad.id = 0;
-packet->mad.id < IB_UMAD_MAX_AGENTS;
-packet->mad.id++)
- if (agent == file->agent[packet->mad.id]) {
+ for (packet->mad.hdr.id = 0;
+packet->mad.hdr.id < IB_UMAD_MAX_AGENTS;
+packet->mad.hdr.id++)
+ if (agent == file->agent[packet->mad.hdr.id]) {
spin_lock_irq(&file->recv_lock);
list_add_tail(&packet->list, &file->recv_list);
spin_unlock_irq(&file->recv_lock);
@@ -138,14 +141,11 @@
struct ib_umad_packet *packet =
(void *) (unsigned long) send_wc->wr_id;
- dma_unmap_single(agent->device->dma_device,
-pci_unmap_addr(packet, mapping),
-sizeof packet->mad.data,
-DMA_TO_DEVICE);
- ib_destroy_ah(packet->ah);
+ ib_free_send_mad(packet->msg);
+ ib_destroy_ah(packet->msg->send_wr.wr.ud.ah);
if (send_wc->status == IB_WC_RESP_TIMEOUT_ERR) {
- packet->mad.status = ETIMEDOUT;
+ packet->mad.hdr.status = ETIMEDOUT;
if (!queue_packet(file, agent, packet))
return;
@@ -159,30 +159,34 @@
{
struct ib_umad_file *file = agent->context;
struct ib_umad_packet *packet;
+ int length;
+
if (mad_recv_wc->wc->status != IB_WC_SUCCESS)
goto out;
- packet = kmalloc(sizeof *packet, GFP
[openib-general] [PATCH][TRIVIAL] [kdapl] Minor CM Changes
Minor CM changes
Change label in do_rep_recv to more appropriate name
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: dapl_openib_cm.c
===
-- dapl_openib_cm.c (revision 2331)
+++ dapl_openib_cm.c(working copy)
@@ -68,7 +68,7 @@
if (conn->ep->qp_handle == IB_INVALID_HANDLE) {
dapl_dbg_log(DAPL_DBG_TYPE_ERR, " do_rep_recv: invalid qp "
"handle\n");
- goto reject;
+ goto disc;
}
/* First, transition QP to RTR */
@@ -76,7 +76,7 @@
if (status) {
dapl_dbg_log(DAPL_DBG_TYPE_ERR, " do_rep_recv: could not "
"modify QP state to RTR status %d\n", status);
- goto reject;
+ goto disc;
}
/* Now, transition QP to RTS */
@@ -84,23 +84,22 @@
if (status) {
dapl_dbg_log(DAPL_DBG_TYPE_ERR, " do_rep_recv: could not "
"modify QP state to RTS status %d\n", status);
- goto reject;
+ goto disc;
}
status = ib_send_cm_rtu(conn->cm_id, NULL, 0);
if (status) {
dapl_dbg_log(DAPL_DBG_TYPE_ERR, " do_rep_recv: ib_send_cm_rtu "
"failed: %d\n", status);
- goto reject;
+ goto disc;
}
dapl_evd_connection_callback(conn, IB_CME_CONNECTED,
rep_recv_param->private_data, conn->ep);
return;
-reject:
- ib_send_cm_rej(conn->cm_id, IB_CM_REJ_CONSUMER_DEFINED, NULL, 0,
- NULL, 0);
+disc:
+ ib_send_cm_dreq(conn->cm_id, NULL, 0); /* ??? */
dapl_evd_connection_callback(conn, IB_CME_LOCAL_FAILURE, NULL,
conn->ep);
}
@@ -456,7 +455,7 @@
if (status < 0) {
dapl_dbg_log(DAPL_DBG_TYPE_ERR, " ib_at_route_by_ip failed "
"with status %d\n", status);
- dapl_destroy_cm_id(conn);
+ dapl_destroy_cm_id(conn); /* ??? */
return DAT_INTERNAL_ERROR;
}
___
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] [kdapl]: Reduce CM retry count
Reduce CM retry count
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: dapl_openib_cm.h
===
-- dapl_openib_cm.h(revision 2331)
+++ dapl_openib_cm.h(working copy)
@@ -40,7 +40,7 @@
#define DAPL_OPENIB_RC_RETRY_COUNT 7
#define DAPL_OPENIB_RNR_RETRY_COUNT 6
#define DAPL_OPENIB_CM_RESPONSE_TIMEOUT 20 /* 4 sec */
-#define DAPL_OPENIB_MAX_CM_RETRIES 15
+#define DAPL_OPENIB_MAX_CM_RETRIES 4
typedef enum {
IB_CME_CONNECTED,
___
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] Check it out!
We offer three products at this point of time, please read the complete email for more information on each. Digital Cable Filters: http://SG3D.1clickresults.info Fuel Savers: http://ow1B.1clicktime.info Ebay Business Traning Program: http://SqX6.1clickaccess.info Free PPV: Unlock: *PPV channels *Boxing and any other Sports Event on PPV *Adult Channels *Movies *And anything else on PPV channels. http://S5Do.1clickresults.info This is the NEWEST AND BEST Digital CATV Filter/Descrambler that can test your digital cable PPV purchase functions along with eliminating unwanted interference caused by your broadband connection. This is a "True" universal product. It will work on 99% of all digital cable systems in use today. This little filter has many different uses: Interference filter, PPV tester and "Digital Descrambler". These will work with the following receivers: Scientific Atlanta Jerrold/General Instruments Zenith Tocom Starcom Explorer Series Motorola Simple to Install. ATTENTION: Because the Cable Company has no way of telling you are using this product you need to notify them of any movie purchases. If you are getting interference on your television set while connected to your broadband connection,simply installing this device prior to your cable converter will dramatically improve your reception. Try us out, You wont regret it! http://fd0l.1clickresults.info --- Maybe your looking for something else? Fuel savers? http://r3hn.1clicktime.info Installs in seconds (No tools or experience required) Fuel savings of upto 27% - more milage. One time purchase. The super Ecnofuels that is proven to increase gas mileage upto 27%, it snaps on easily over the fuel line, no tools or experience required. It is a magnetic frequency resonater- Using its patented Neodymium super-conducters it generates the specific resonance frequency, that when installed over the fuel line, makes combustion more efficient. http://mpQk.1clicktime.info -- Or maybe your looking for an interactive eBay Business Training Program on CD? http://lCW8.1clickaccess.info Check us out! Digital Cable Filters: http://6ukp.1clickresults.info Fuel Savers: http://o5o7.1clicktime.info Ebay Business Traning Program: http://JpRV.1clickaccess.info Regards, Damon Karen ___ 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@openib.org
$B"v!&!yL5NAEPO?%-%c%s%Z!<%sCf!y!&"v(B $B!!$d$C$Q$j=P0)$&$J$i$46a=j$G2q$($kAjhttp://www.jumpb2.net/?join $B!!%3%3$K%"%I8x3+$GBT$C$F$$$k$46a=jL<$,$$$C$Q$$(B(o^$B"O(B^o)[EMAIL PROTECTED]&!&(B $BEPO?8e(B5$BJ,0JFb$K$46a=j$G2q$([EMAIL PROTECTED]>R2pCW$7$^$9!#(B $B$^$:$O$*;n$7L5NAEPO?$+$i(B $B!!"-"-"-"-"-"-(B $B(Bhttp://www.jumpb2.net/?join $B(B $B!!(B $B%U%j!<%a!<%kBP1~$G$9!*(B $B5qH](B [EMAIL PROTECTED] ___ 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: [PATCH] Re: [openib-general] 0 op factor
On Thu, May 12, 2005 at 03:48:57PM -0700, Libor Michalek wrote: >On Tue, May 10, 2005 at 05:47:00PM -0700, Libor Michalek wrote: >> On Sat, May 07, 2005 at 07:47:18PM +0200, Bernhard Fischer wrote: >> >> > - remove expect from _sdp_cm_path_complete(). >> >> When I said that the SDP_EXPECT should eventually be removed, I meant >> that the functions which have their return values checked by SDP_EXPECT >> should either be turned into void return functions, or something >> intelligent should be done with the return value, such as error recovery >> or propogation. The functions which should be turned into void functions >> are the ones which will never return anything but success. > > To expand on the last point. There are a lot of functions, for >example those in sdp_buff.c, which check for incorrect function >usage, such as checking that a buffer is not already in a queue before >inserting it into a queue. These checks could be removed entirely or >the checks could be made and a call to BUG() in case the condition >is met. I prefer the later since the former would corrupt the entire >queue. I'm not sure which is preferable to everyone else, either way >the result is that the function becomes a void. BUG_ON would be fine with me, fwiw. Guess others might have a stronger opinion regarding either, though. ___ 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: [PATCH] Re: [openib-general] 0 op factor
On Tue, May 10, 2005 at 05:47:00PM -0700, Libor Michalek wrote: >On Sat, May 07, 2005 at 07:47:18PM +0200, Bernhard Fischer wrote: >> - remove '0 operator factor' statements. >> - a bit of whitespace removal. >> - remove return at end of void functions. > > If you're removing the 'return' why not remove the blank line before >it as well. Should have done that too, yes. Would you ditch those blank lines while ci the whitespace stuff? If you want, i could send you a patchlet which does remove them sometimes not before end of next week. Please just drop the removal of the expect, it shouldn't have been it in the patch i sent. Thank you, Bernhard ___ 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
