[openib-general] Osmtest removal from Gen2 main trunk
Title: Osmtest removal from Gen2 main trunk Hi , Hal . Since now the Osmtest is updated (in all stack flavours) under ibtp repository (https://openib.org/svn/trunk/contrib/mellanox/ibtp/), I'd like to remove it from main trunk : https://openib.org/svn/gen2/trunk/src/userspace/management/osm/osmtest. New updates will be checked into ibtp repository only , thanks . -Original Message- From: Liran Sorani Sent: Sunday, October 23, 2005 9:01 AM To: 'Hal Rosenstock'; Liran Sorani Cc: openib-general@openib.org Subject: RE: [openib-general] InfiniBand Test Project (IBTP) - Update Currently only a minor bug fix in osmt_service flow , and cosmetics changes to fit WinIb stack . -Original Message- From: Hal Rosenstock [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 20, 2005 1:01 PM To: Liran Sorani Cc: openib-general@openib.org Subject: RE: [openib-general] InfiniBand Test Project (IBTP) - Update On Thu, 2005-10-20 at 03:49, Liran Sorani wrote: > Hi , Hal . > The Linux & WinIB are the same , except for several cosmetic changes . I was referring to the (differences in the) Linux one in ibtp and the Linux one under gen2/trunk. > Regarding Makefile.in , it's an outcome of autogen , I'll remove it . Thanks. -- Hal > -Original Message- > From: Hal Rosenstock [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 19, 2005 10:25 PM > To: Liran Sorani > Cc: openib-general@openib.org > Subject: Re: [openib-general] InfiniBand Test Project (IBTP) - Update > > > On Wed, 2005-10-19 at 15:33, Liran Sorani wrote: > > Hi , > > We've updated IBTP tree with Osmtest sources both on ibal (WinIB) > and > > Gen2 stacks : > > > https://openib.org/svn/trunk/contrib/mellanox/ibtp/ibal/ulp/opensm/user/osmtest > > > > > https://openib.org/svn/trunk/contrib/mellanox/ibtp/gen2/userspace/management/osm/osmtest > > > > Osmtest is the main verification tool for OpenSM , include various > SA > > (Good / Bad) flows. > > Attached to each directory a short README file for setup and usage > > information. > > How is the Linux one different from osmtest in the trunk ? > > Also, (nit): > I think > https://openib.org/svn/trunk/contrib/mellanox/ibtp/gen2/userspace/management/osm/osmtest/Makefile.in > is a generated file and should be removed. > > -- Hal > > > > Liran Sorani > > > Mellanox Technologies LTD. > > > mailto:[EMAIL PROTECTED] > > > Phone: +972(4)9097200 Ext: 214 > > > Israel, Yokneam P.O.B 586 ZIP 20692 > > > > > > > > > > > > > > > __ > > > > ___ > > openib-general mailing list > > openib-general@openib.org > > http://openib.org/mailman/listinfo/openib-general > > > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] Fix for MAD layer DMA mappings
Yeah, this looks fine to check in. I have a couple of trivial cleanups I'd like to do for sa_query.c and user_mad.c, but I can do them after you commit. Also, this chunk: > --- trunk/src/linux-kernel/infiniband/core/smi.h (revision 3830) > +++ trunk/src/linux-kernel/infiniband/core/smi.h (working copy) > @@ -35,10 +35,11 @@ > * > * $Id$ > */ > - > #ifndef __SMI_H_ > #define __SMI_H_ > looks bogus -- I'd prefer to keep that blank line there, since it looks ugly to me to have the #ifndef right after the closing */. - 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: [swg] Re: [openib-general] TCP/IP connection service over IB
Ted: I think it's relevant, so let's make sure my assumptions are correct: - The ITAPI will be a "ULP" on OpenIB - The ITAPI will create the IRD/ORD headers in its private data and submit this as part of its connection establishment. - The ITAPI consumer at the remote peer will use this data to configure it's local QP before accepting the connection Over IB, the IRD/ORD private data will be prepended with a "private data header" that contains the source and destination IP addresses, source port, etc... The remote peer will not see this data as part of the private data, but rather will see it in the CMA event in the upcall. Over iWARP/MPA, there will be nothing else in the private data except what was provided by the consumer (ITAPI in this case). The reason being that this extra information (IP addressing info) is in the protocol header proper. On Mon, 2005-10-24 at 17:17 -0700, Ted H. Kim wrote: > Just a comment on this one point ... > > Sean Hefty wrote: > >> I'm thinking that for iWARP, there won't be anything in the Private Data > >> at all except consumer private data. Is that your expectation? > > > > > > I believe so. This is only trying to define a TCP/IP connection service > > over IB. I'm assuming that there's no need to define something similar > > for iWarp. > > Not sure if this is relevant for your intended base, but ITAPI 2.0 > for iWARP has a 16-byte IOH (IRD/ORD header) > in MPA "private data" to note RDMA initiator/responder limits > like the corresponding fields in the IB CM protocol. > > -ted > ___ 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: [swg] Re: [openib-general] TCP/IP connection service over IB
Just a comment on this one point ... Sean Hefty wrote: I'm thinking that for iWARP, there won't be anything in the Private Data at all except consumer private data. Is that your expectation? I believe so. This is only trying to define a TCP/IP connection service over IB. I'm assuming that there's no need to define something similar for iWarp. Not sure if this is relevant for your intended base, but ITAPI 2.0 for iWARP has a 16-byte IOH (IRD/ORD header) in MPA "private data" to note RDMA initiator/responder limits like the corresponding fields in the IB CM protocol. -ted ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] RFC userspace CMA
I'm soliciting any comments that anyone might have on the general design for the userspace CMA before I get too far into the implementation. - The API will match the kernel API for the most part. The exception is that event handling will match other userspace libraries (get/ack event). - There will be a single CMA device exported through /sys/class/infiniband. - The kernel CMA will be modified to remove the requirement to use rdma_create_qp(). Users that want to allocate and manage their own QP states will be able to specify QP attributes (qpn, qp_type, srq) through the rdma_conn_param structure. - The kernel CMA will expose a new call, rdma_init_qp_attr() to initialize QP attributes used to modify the state of the QP. The call will be similar to the infiniband CM routine. Use of this call is optional. The CMA will automatically transition QPs created by rdma_create_qp(). - The uCMA will open devices for users and return them the device context with related events. The uCMA will close the device if there are no rdma_cma_id's associated with it. - To support device add, the uCMA will need a new verb's call: ibv_open_device_by_guid(). If a connection request occurs for a device that is not yet known by the uCMA, it will open the device. Comments? - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH/RFC] mthca: report catastrophic errors
On 24.10.2005 [15:33:57 -0700], Roland Dreier wrote: > Nishanth> I know akpm has been harping on this only recently (I > Nishanth> have yet to audit all the kernel, but will get around to > Nishanth> it eventually), but these three inits can be done via > Nishanth> setup_timer() now. > > Hmm, I can't find anything like setup_timer() in Linus's latest tree. > Is this an -mm thing? If so I'll wait until it hits mainline to > update this. Ah yes, sorry. I will probably do the IB update(s) for you when I hit all the other trees (eventually) Thanks, Nish ___ 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] Support for UC connections using the CM API?
Roland Dreier wrote: I think something like this will fix things. Does this look right to everyone? Looks fine to me. Thanks for catching this. - 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] Support for UC connections using the CM API?
I think something like this will fix things. Does this look right to everyone?
- R.
--- infiniband/hw/mthca/mthca_qp.c (revision 3852)
+++ infiniband/hw/mthca/mthca_qp.c (working copy)
@@ -338,8 +338,7 @@ static const struct {
[UC] = (IB_QP_AV |
IB_QP_PATH_MTU|
IB_QP_DEST_QPN|
-IB_QP_RQ_PSN |
-IB_QP_MAX_DEST_RD_ATOMIC),
+IB_QP_RQ_PSN),
[RC] = (IB_QP_AV |
IB_QP_PATH_MTU|
IB_QP_DEST_QPN|
@@ -368,8 +367,7 @@ static const struct {
.trans = MTHCA_TRANS_RTR2RTS,
.req_param = {
[UD] = IB_QP_SQ_PSN,
- [UC] = (IB_QP_SQ_PSN|
-IB_QP_MAX_QP_RD_ATOMIC),
+ [UC] = IB_QP_SQ_PSN,
[RC] = (IB_QP_TIMEOUT |
IB_QP_RETRY_CNT |
IB_QP_RNR_RETRY |
@@ -446,8 +444,6 @@ static const struct {
[UD] = (IB_QP_PKEY_INDEX|
IB_QP_QKEY),
[UC] = (IB_QP_AV|
-IB_QP_MAX_QP_RD_ATOMIC |
-IB_QP_MAX_DEST_RD_ATOMIC|
IB_QP_CUR_STATE |
IB_QP_ALT_PATH |
IB_QP_ACCESS_FLAGS |
@@ -478,7 +474,7 @@ static const struct {
.opt_param = {
[UD] = (IB_QP_CUR_STATE |
IB_QP_QKEY),
- [UC] = (IB_QP_CUR_STATE),
+ [UC] = IB_QP_CUR_STATE,
[RC] = (IB_QP_CUR_STATE |
IB_QP_MIN_RNR_TIMER),
[MLX] = (IB_QP_CUR_STATE |
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] Fix for MAD layer DMA mappings
Sean> Are there any objections to committing this? Sorry, I missed it on Friday. Let me give it a quick read through -- I'll NAK it by tonight if I see anything but I don't anticipate problems. - 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] Support for UC connections using the CM API?
Sean> Why was this needed? Atomic and reads apply only to RC. Sean> Were you seeing an error? I think it's a bug in mthca. I'll post a patch shortly. - 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] [PATCH] Fix for MAD layer DMA mappings
Sean Hefty wrote: The following patch should fix the MAD layer's DMA mapping issue. This patch includes all related patches that were previously posted. The fix involved changing the MAD layer API. All callers must now use the MAD layer to allocate and free send MADs. DMA mappings are done by the MAD layer. Are there any objections to committing this? - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH/RFC] mthca: report catastrophic errors
Nishanth> I know akpm has been harping on this only recently (I Nishanth> have yet to audit all the kernel, but will get around to Nishanth> it eventually), but these three inits can be done via Nishanth> setup_timer() now. Hmm, I can't find anything like setup_timer() in Linus's latest tree. Is this an -mm thing? If so I'll wait until it hits mainline to update this. - 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] Support for UC connections using the CM API?
Steven Wooding wrote: Your patch works if I put the IB_QP_MAX_QP_RD_ATOMIC mask into the UC (defualt) QP attr mask. Otherwise fine. Why was this needed? Atomic and reads apply only to RC. Were you seeing an error? - 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] Support for UC connections using the CM API?
Hi Sean,
Your patch works if I put the IB_QP_MAX_QP_RD_ATOMIC
mask into the UC (defualt) QP attr mask. Otherwise
fine.
Thanks,
Steve.
--- Sean Hefty <[EMAIL PROTECTED]> wrote:
> >I had a look at where the mask is set in cm.c
> >(cm_init_qp_rtr_attr() and cm_init_qp_rts_attr())
> but
> >I was unsure how to make the mask depend on the QP
> >type. Maybe you have a better idea of how to do
> this.
>
> Here's a patch (edited by hand, so let me know if
> there's any issue
> applying it) that should permit UC connections over
> the CM. I was able to
> test this using cmpost.
>
> Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
>
>
> Index: cm.c
>
===
> --- cm.c (revision 3830)
> +++ cm.c (working copy)
> @@ -135,6 +135,7 @@
> __be64 tid;
> __be32 local_qpn;
> __be32 remote_qpn;
> + enum ib_qp_type qp_type;
> __be32 sq_psn;
> __be32 rq_psn;
> int timeout_ms;
> @@ -926,6 +923,7 @@
> cm_id_priv->responder_resources =
> param->responder_resources;
> cm_id_priv->retry_count = param->retry_count;
> cm_id_priv->path_mtu = param->primary_path->mtu;
> + cm_id_priv->qp_type = param->qp_type;
>
> ret = cm_alloc_msg(cm_id_priv, &cm_id_priv->msg);
> if (ret)
> @@ -1320,6 +1314,7 @@
> cm_req_get_primary_local_ack_timeout(req_msg);
> cm_id_priv->retry_count =
> cm_req_get_retry_count(req_msg);
> cm_id_priv->rnr_retry_count =
> cm_req_get_rnr_retry_count(req_msg);
> + cm_id_priv->qp_type = cm_req_get_qp_type(req_msg);
>
> cm_format_req_event(work, cm_id_priv,
> &listen_cm_id_priv->id);
> cm_process_work(cm_id_priv, work);
> @@ -3079,10 +3035,10 @@
> case IB_CM_ESTABLISHED:
> *qp_attr_mask = IB_QP_STATE | IB_QP_ACCESS_FLAGS
> |
> IB_QP_PKEY_INDEX | IB_QP_PORT;
> - qp_attr->qp_access_flags = IB_ACCESS_LOCAL_WRITE;
> + qp_attr->qp_access_flags = IB_ACCESS_LOCAL_WRITE
> |
> +IB_ACCESS_REMOTE_WRITE;
> if (cm_id_priv->responder_resources)
> - qp_attr->qp_access_flags |=
> IB_ACCESS_REMOTE_WRITE |
> - IB_ACCESS_REMOTE_READ;
> + qp_attr->qp_access_flags |=
> IB_ACCESS_REMOTE_READ;
> qp_attr->pkey_index = cm_id_priv->av.pkey_index;
> qp_attr->port_num =
> cm_id_priv->av.port->port_num;
> ret = 0;
> @@ -3112,14 +3068,18 @@
> case IB_CM_MRA_REP_RCVD:
> case IB_CM_ESTABLISHED:
> *qp_attr_mask = IB_QP_STATE | IB_QP_AV |
> IB_QP_PATH_MTU |
> - IB_QP_DEST_QPN | IB_QP_RQ_PSN |
> - IB_QP_MAX_DEST_RD_ATOMIC | IB_QP_MIN_RNR_TIMER;
> + IB_QP_DEST_QPN | IB_QP_RQ_PSN;
> qp_attr->ah_attr = cm_id_priv->av.ah_attr;
> qp_attr->path_mtu = cm_id_priv->path_mtu;
> qp_attr->dest_qp_num =
> be32_to_cpu(cm_id_priv->remote_qpn);
> qp_attr->rq_psn =
> be32_to_cpu(cm_id_priv->rq_psn);
> - qp_attr->max_dest_rd_atomic =
> cm_id_priv->responder_resources;
> - qp_attr->min_rnr_timer = 0;
> + if (cm_id_priv->qp_type == IB_QPT_RC) {
> + *qp_attr_mask |= IB_QP_MAX_DEST_RD_ATOMIC |
> + IB_QP_MIN_RNR_TIMER;
> + qp_attr->max_dest_rd_atomic =
> + cm_id_priv->responder_resources;
> + qp_attr->min_rnr_timer = 0;
> + }
> if (cm_id_priv->alt_av.ah_attr.dlid) {
> *qp_attr_mask |= IB_QP_ALT_PATH;
> qp_attr->alt_ah_attr =
> cm_id_priv->alt_av.ah_attr;
> @@ -3148,14 +3108,17 @@
> case IB_CM_REP_SENT:
> case IB_CM_MRA_REP_RCVD:
> case IB_CM_ESTABLISHED:
> - *qp_attr_mask = IB_QP_STATE | IB_QP_TIMEOUT |
> IB_QP_RETRY_CNT |
> - IB_QP_RNR_RETRY | IB_QP_SQ_PSN |
> - IB_QP_MAX_QP_RD_ATOMIC;
> - qp_attr->timeout = cm_id_priv->local_ack_timeout;
> - qp_attr->retry_cnt = cm_id_priv->retry_count;
> - qp_attr->rnr_retry = cm_id_priv->rnr_retry_count;
> + *qp_attr_mask = IB_QP_STATE | IB_QP_SQ_PSN;
> qp_attr->sq_psn =
> be32_to_cpu(cm_id_priv->sq_psn);
> - qp_attr->max_rd_atomic =
> cm_id_priv->initiator_depth;
> + if (cm_id_priv->qp_type == IB_QPT_RC) {
> + *qp_attr_mask |= IB_QP_TIMEOUT | IB_QP_RETRY_CNT
> |
> + IB_QP_RNR_RETRY |
> + IB_QP_MAX_QP_RD_ATOMIC;
> + qp_attr->timeout =
> cm_id_priv->local_ack_timeout;
> + qp_attr->retr
Re: [openib-general] [PATCH/RFC] mthca: report catastrophic errors
On 24.10.2005 [13:54:25 -0700], Roland Dreier wrote:
> I just committed the following patch, which adds some initial support
> for detecting and reporting catastrophic errors reported by Mellanox
> HCAs. We start a periodic timer which polls the catastrophic error
> reporting buffer in device memory. If an error is detected, we dump
> the contents of the buffer for port-mortem debugging, and report a
> fatal asynchronous error to higher levels.
>
> In the future we can try to recover from these errors by resetting the
> device, but this will require some work in higher-level code as well.
> Let's get this in now, so that we at least get catastrophic errors
> reported in logs.
>
> Comments and criticisms gratefully accepted.
>
> - R.
>
> --- infiniband/hw/mthca/mthca_provider.c (revision 3852)
> +++ infiniband/hw/mthca/mthca_provider.c (working copy)
> +void mthca_start_catas_poll(struct mthca_dev *dev)
> +{
> + init_timer(&dev->catas_err.timer);
> + dev->catas_err.stop = 0;
> + dev->catas_err.map = NULL;
> +
> + if (!request_mem_region(dev->catas_err.addr,
> + dev->catas_err.size * 4,
> + DRV_NAME)) {
> + mthca_warn(dev, "couldn't request catastrophic error region "
> +"at 0x%llx/0x%x\n",
> +(unsigned long long) dev->catas_err.addr,
> +dev->catas_err.size * 4);
> + return;
> + }
> +
> + dev->catas_err.map = ioremap(dev->catas_err.addr, dev->catas_err.size *
> 4);
> + if (!dev->catas_err.map) {
> + mthca_warn(dev, "couldn't map catastrophic error region "
> +"at 0x%llx/0x%x\n",
> +(unsigned long long) dev->catas_err.addr,
> +dev->catas_err.size * 4);
> + release_mem_region(dev->catas_err.addr,
> +dev->catas_err.size * 4);
> + return;
> + }
> +
> + dev->catas_err.timer.data = (unsigned long) dev;
> + dev->catas_err.timer.function = poll_catas;
> + dev->catas_err.timer.expires = jiffies + MTHCA_CATAS_POLL_INTERVAL;
I know akpm has been harping on this only recently (I have yet to audit
all the kernel, but will get around to it eventually), but these three
inits can be done via setup_timer() now.
Thanks,
Nish
___
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] [RFC] OpenSM Interactive Console
On Mon, 2005-10-24 at 14:38, Eitan Zahavi wrote: > Hal Rosenstock wrote: > > On Mon, 2005-10-24 at 03:08, Eitan Zahavi wrote: > > > >>I would suggest to use SNMP for the tasks below. IETF IPoIB group has > >>defined an SNMP MIB that can support the required functionality below. > > > > > > The IETF SNMP MIBs are one way of presenting the information to the > > outside world. There are other possible management interfaces. The SNMP > > MIB instrumentation would need to use lower layer APIs to get this > > information out of the SM. > Yes but the IETF SM MIB is the only one that is close to a standard way. > It does not require low level interface if it will integrate into the OpenSM > code. > One way to do it is buy extending OpenSM with an AgentX interface. > > IMO one clear advantage of using SNMP for SM integration is that the code > will work with any SM that is IETF compliant. > Also if you want to write a "client server" type of application on top of an > SM you > can either stick to sending MADs which translate into SA client based > application or > you better stay with some known protocol for management (like SNMP) and not > develop yet another protocol for > doing exactly the same things as SNMP already supports. There are limitations in the SNMP MIBs. One is that they are RO so they are more for monitoring. Also, many environments do not use SNMP. It is unclear how much of a requirement it is to manage any SM or how many other SMs support the SM MIB. (There are other IB associated MIBs too). > >>Everything but the dynamic partitioning (OpenSM does not have > >>partition manager to this moment) > > > > > > What Troy meant by partitioning is not necessarily IB partitioning. > How are you sure about that? Troy - please comment. I think you missed an email on this. > >>and forwarding of Performance > >>Monitoring traps (which are generated by the PM) can be done through > >>osmsh or through SA client today. > > > > > > What PerfMgr are you referring to ? > No specific one. But the specification does not require the SM too. Huh ? What spec ? An SM is required in a subnet. There is no subnet without this. There is a subnet without a PerfMgr. > For various reasons (like load) it might make more sense to have the PM > distributed. Sure. Also, the PerfMgr need not be colocated with the SM anyhow. > Anyway, my point is that the SM is not the owner of PM trap reporting. It is > the PM that > should support Reporting (I.e InformInfo registration and Trap forwarding) > for PM traps. > But the spec does not define such traps anyway. My point was that the PerfMgr is beyond the IBA spec. It is only the PMA that is defined and has no traps so these will all need synthesis by the PerfMgr. -- 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] Re: [RFC] OpenSM Interactive Console
On Mon, 2005-10-24 at 14:24, Eitan Zahavi wrote: > > How do you get the old versions of this ? > It is in the main trunk ... > https://openib.org/svn/gen2/trunk/src/userspace/management/osm/doc/OpenSM_UM.pdf That's older than 1.7.1 1.7.0 manuals you had mentioned. Maybe nothing has changed in osmsh between the version of the manual in the trunk and currently. -- 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: [PATCH] perftest/rdma_bw; add support for RDMA read and starting PSN
Michael S. Tsirkin wrote: Thanks Arlin. I plan to look into integrating this. One question: for which psn values do you see performance drop on 4.6.0 FW? Any luck isolating this performance problem? I just want to understand the cause so I know for sure 4.7 FW is a solid fix. Didn't see anything in the 4.7 release notes that covered this issue. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH/RFC] mthca: report catastrophic errors
I just committed the following patch, which adds some initial support
for detecting and reporting catastrophic errors reported by Mellanox
HCAs. We start a periodic timer which polls the catastrophic error
reporting buffer in device memory. If an error is detected, we dump
the contents of the buffer for port-mortem debugging, and report a
fatal asynchronous error to higher levels.
In the future we can try to recover from these errors by resetting the
device, but this will require some work in higher-level code as well.
Let's get this in now, so that we at least get catastrophic errors
reported in logs.
Comments and criticisms gratefully accepted.
- R.
--- infiniband/hw/mthca/mthca_provider.c(revision 3852)
+++ infiniband/hw/mthca/mthca_provider.c(working copy)
@@ -1175,10 +1175,13 @@ int mthca_register_device(struct mthca_d
}
}
+ mthca_start_catas_poll(dev);
+
return 0;
}
void mthca_unregister_device(struct mthca_dev *dev)
{
+ mthca_stop_catas_poll(dev);
ib_unregister_device(&dev->ib_dev);
}
--- infiniband/hw/mthca/mthca_catas.c (revision 0)
+++ infiniband/hw/mthca/mthca_catas.c (revision 0)
@@ -0,0 +1,151 @@
+/*
+ * Copyright (c) 2005 Cisco Systems. 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
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ *copyright notice, this list of conditions and the following
+ *disclaimer in the documentation and/or other materials
+ *provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ * $Id$
+ */
+
+#include "mthca_dev.h"
+
+enum {
+ MTHCA_CATAS_POLL_INTERVAL = 5 * HZ,
+
+ MTHCA_CATAS_TYPE_INTERNAL = 0,
+ MTHCA_CATAS_TYPE_UPLINK = 3,
+ MTHCA_CATAS_TYPE_DDR= 4,
+ MTHCA_CATAS_TYPE_PARITY = 5,
+};
+
+static DEFINE_SPINLOCK(catas_lock);
+
+static void handle_catas(struct mthca_dev *dev)
+{
+ struct ib_event event;
+ const char *type;
+ int i;
+
+ event.device = &dev->ib_dev;
+ event.event = IB_EVENT_DEVICE_FATAL;
+ event.element.port_num = 0;
+
+ ib_dispatch_event(&event);
+
+ switch (swab32(readl(dev->catas_err.map)) >> 24) {
+ case MTHCA_CATAS_TYPE_INTERNAL:
+ type = "internal error";
+ break;
+ case MTHCA_CATAS_TYPE_UPLINK:
+ type = "uplink bus error";
+ break;
+ case MTHCA_CATAS_TYPE_DDR:
+ type = "DDR data error";
+ break;
+ case MTHCA_CATAS_TYPE_PARITY:
+ type = "internal parity error";
+ break;
+ default:
+ type = "unknown error";
+ break;
+ }
+
+ mthca_err(dev, "Catastrophic error detected: %s\n", type);
+ for (i = 0; i < dev->catas_err.size; ++i)
+ mthca_err(dev, " buf[%02x]: %08x\n",
+ i, swab32(readl(dev->catas_err.map + i)));
+}
+
+static void poll_catas(unsigned long dev_ptr)
+{
+ struct mthca_dev *dev = (struct mthca_dev *) dev_ptr;
+ unsigned long flags;
+ int i;
+
+ for (i = 0; i < dev->catas_err.size; ++i)
+ if (readl(dev->catas_err.map + i)) {
+ handle_catas(dev);
+ return;
+ }
+
+ spin_lock_irqsave(&catas_lock, flags);
+ if (dev->catas_err.stop)
+ mod_timer(&dev->catas_err.timer,
+ jiffies + MTHCA_CATAS_POLL_INTERVAL);
+ spin_unlock_irqrestore(&catas_lock, flags);
+
+ return;
+}
+
+void mthca_start_catas_poll(struct mthca_dev *dev)
+{
+ init_timer(&dev->catas_err.timer);
+ dev->catas_err.stop = 0;
+ dev->catas_err.map = NULL;
+
+ if (!request_mem_region(dev->catas_err.addr,
+ dev->catas_err.size * 4,
+
RE: [openib-general] last version for 2.6.9 backport
Philippe Gregoire wrote, >Is 3640 the lastest version for which a backport to 2.6.9 has been done ? >Or does someone is working on a newer version today ? I have a newer one based on 3796 that I just finished testing. I will commit it today. woody ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: [PATCH] [SRP] Fix bug w/ SRP task mgmt iu size
Thanks, applied. > Signed-off-by: John Kingman [EMAIL PROTECTED] Your email is supposed to be in angle brackets like "< >" -- cf Documentation/SubmittingPatches in the kernel tree. I fixed this in the commit message I used. - 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] [SRP] Fix bug w/ SRP task mgmt iu size
This patch fixes the problem of task management ius being the wrong length. Signed-off-by: John Kingman [EMAIL PROTECTED] Index: ib_srp.c === --- ib_srp.c(revision 3852) +++ ib_srp.c(working copy) @@ -1136,7 +1136,7 @@ static int srp_send_tsk_mgmt(struct scsi tsk_mgmt->tsk_mgmt_func = func; tsk_mgmt->task_tag = req_index; - if (__srp_post_send(target, iu, sizeof tsk_mgmt)) + if (__srp_post_send(target, iu, sizeof *tsk_mgmt)) goto out; req->tsk_mgmt = iu; ___ 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] max locked memory 32 Kb
All, Following the procedure outlined in your installation cheat sheet, after make modules modules_install and a reboot, the max locked memory (ulimit -a) changes from unlimited to 32Kb. The only changes made in the .config file should be associated with "Scroll to "device drivers", select it, select Infiniband support. Select userspace support, Mellanox HCA support." "Exit saving kernel configuration. " "make modules modules_install" Any thoughts? Thanks, Jim Barker James W. Barker, Ph.D. Los Alamos National Laboratory Computer and Computational Sciences Division Advanced Computing Laboratory - Resilient Technologies Team 505-665-9558 ___ 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: device add/remove in userspace
Tom Tucker wrote: I'm not sure of all the issues you're considering, but it seems to me at first blush that the user space stuff should talk the kernel CMA. If you don't do it in the kernel: - you will end up replicating transport dependent connection management logic in the user mode library - you will have to export, support and maintain a much larger number of kernel services - implementing security/provisioning policy in user mode is trickier than in the kernel My hope is that the userspace CMA can talk to the kernel CMA. Otherwise, I need to expose the kernel address translation and SA query services, plus deal with more complicated event handling. The issue is that the kernel CMA performs QP transitions, which would need to change for userspace QPs. To transition the QPs properly, the userspace CMA would need to do so based on IB CM messages, and not kernel CMA events. - 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] last version for 2.6.9 backport
Is 3640 the lastest version for which a backport to 2.6.9 has been done ? Or does someone is working on a newer version today ? thanks Philippe ___ 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: device add/remove in userspace
Sean> How difficult would it be to support a call such as Sean> ibv_open_device_by_guid() or ibv_open_device_by_name()? I don't think something like that would be hard. - 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: device add/remove in userspace
On Mon, 2005-10-24 at 11:37 -0700, Sean Hefty wrote: > Roland Dreier wrote: > > Sean> Is there a way for a userspace application to know if a > > Sean> device has been added or removed? > > > > We don't really handle this right now. It could probably be made to > > work on top of hotplug/udev/hal/something but it seems tricky to me. > > At this point, I'm still trying to decide if the userspace CMA should talk to > the userspace CM or kernel CMA, so I'm not sure what's needed yet. I'm not sure of all the issues you're considering, but it seems to me at first blush that the user space stuff should talk the kernel CMA. If you don't do it in the kernel: - you will end up replicating transport dependent connection management logic in the user mode library - you will have to export, support and maintain a much larger number of kernel services - implementing security/provisioning policy in user mode is trickier than in the kernel > How difficult would it be to support a call such as ibv_open_device_by_guid() > or > ibv_open_device_by_name()? > - Sean > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [RFC] OpenSM Interactive Console
Hal Rosenstock wrote: On Mon, 2005-10-24 at 03:08, Eitan Zahavi wrote: I would suggest to use SNMP for the tasks below. IETF IPoIB group has defined an SNMP MIB that can support the required functionality below. The IETF SNMP MIBs are one way of presenting the information to the outside world. There are other possible management interfaces. The SNMP MIB instrumentation would need to use lower layer APIs to get this information out of the SM. Yes but the IETF SM MIB is the only one that is close to a standard way. It does not require low level interface if it will integrate into the OpenSM code. One way to do it is buy extending OpenSM with an AgentX interface. IMO one clear advantage of using SNMP for SM integration is that the code will work with any SM that is IETF compliant. Also if you want to write a "client server" type of application on top of an SM you can either stick to sending MADs which translate into SA client based application or you better stay with some known protocol for management (like SNMP) and not develop yet another protocol for doing exactly the same things as SNMP already supports. Everything but the dynamic partitioning (OpenSM does not have partition manager to this moment) What Troy meant by partitioning is not necessarily IB partitioning. How are you sure about that? Troy - please comment. and forwarding of Performance Monitoring traps (which are generated by the PM) can be done through osmsh or through SA client today. What PerfMgr are you referring to ? No specific one. But the specification does not require the SM too. For various reasons (like load) it might make more sense to have the PM distributed. Anyway, my point is that the SM is not the owner of PM trap reporting. It is the PM that should support Reporting (I.e InformInfo registration and Trap forwarding) for PM traps. But the spec does not define such traps anyway. -- Hal EZ Eitan Zahavi Design Technology Director Mellanox Technologies LTD Tel:+972-4-9097208 Fax:+972-4-9593245 P.O. Box 586 Yokneam 20692 ISRAEL -Original Message- From: Troy Benjegerdes [mailto:[EMAIL PROTECTED] Sent: Thursday, October 20, 2005 3:23 AM To: Hal Rosenstock Cc: openib-general@openib.org Subject: Re: [openib-general] [RFC] OpenSM Interactive Console On Tue, Oct 18, 2005 at 03:10:31PM -0400, Hal Rosenstock wrote: Currently, OpenSM does not support an interactive console. There has been a desire to introduce the ability to change certain parameters (as well as display things) once OpenSM has started. This patch introduces the first most basic commands: help and loglevel. I am investgating adding smpriority to this. The console is invoked by specifying -console as an option on the opensm command line. If you have a request for a command you would like in the console, I would like to compile a list of these. Comments ? As well as a console, I'd like an API for some way for external programs (say a cluster queue manager) to be able to query the SM (or the sm + some helper library) for the following things: * Topology * guid/lid/IPoIB address/switch port mappings * link state Future neat things to do: * An interface to dynamically partition the fabric * Register for notifications for certain events (excessive traffic queueing, or error counts) ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: device add/remove in userspace
Roland Dreier wrote: Sean> Is there a way for a userspace application to know if a Sean> device has been added or removed? We don't really handle this right now. It could probably be made to work on top of hotplug/udev/hal/something but it seems tricky to me. At this point, I'm still trying to decide if the userspace CMA should talk to the userspace CM or kernel CMA, so I'm not sure what's needed yet. How difficult would it be to support a call such as ibv_open_device_by_guid() or ibv_open_device_by_name()? - 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] TCP/IP connection service over IB
At 12:50 PM 10/21/2005, Fab Tillier wrote: > From: James Lentini [ mailto:[EMAIL PROTECTED]] > Sent: Friday, October 21, 2005 12:38 PM > > On Fri, 21 Oct 2005, Sean Hefty wrote: > > > > sean> version(8) | reserved(8) | src port (16) > > version(1) | reserved(1) | src port (2) > > > sean> src ip (16) > > > sean> dst ip (16) > > > sean> user private data (56) /* for version 1 */ > > > > > > Are the numbers in parens in bytes or bits? It looks like a mixture to me. > > > > Uhm.. they were a mix. Changed above to bytes. > > Ok. I assume that your 1 byte of version information is broken into 2 > 4-bit pieces, one for the protocol version and one for the IP version. Doesn't leading-zero-padding the IPv4 addresses to be 16 bytes eliminates the need for an IP version field? Not really. The same logic was used in the SDP port mapper for iWARP where there was still an IP version provided so that the space remained constant while the end node would know how to parse the message. Mike ___ 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: [RFC] OpenSM Interactive Console
Hal Rosenstock wrote: On Wed, 2005-10-19 at 12:28, Eitan Zahavi wrote: Hal Rosenstock wrote: On Tue, 2005-10-18 at 17:11, Eitan Zahavi wrote: Hal Rosenstock wrote: Currently, OpenSM does not support an interactive console. There has been a desire to introduce the ability to change certain parameters (as well as display things) once OpenSM has started. This patch introduces the first most basic commands: help and loglevel. I am investgating adding smpriority to this. The console is invoked by specifying -console as an option on the opensm command line. If you have a request for a command you would like in the console, I would like to compile a list of these. Comments ? OpenSM gen1 has a nice TCL API (named osmsh) that lets you do all that and much more. Setting ALL options is supported. It also provides a Tcl access to the SM Database so you can write your own reports on FDB/MC-FDB etc. Interactive control on the discovery and fabric settings sequence allows "single stepping" too. IMO osmsh is more a debugger's tool. It relies on OpenSM globals and internal SM data structures rather than well defined APIs which might isolate the user from changes. (It exposes the internals of the SM and SM modifications may cause scripts using osmsh) to stop working, and worse than that, osmsh scripts may cause serious SM bugs. What is unsafe in running the following basic code? osm_opts configure -log_file $log_file_name. osm_init osm_bind $guid osm_sweep osm_set_verbosity 0x Are you saying there is no use of globals and internal SM data structures by osmsh or just for that particular flow ? All I say is that one can get his flows as complicated as he wants... For the trivial features you support in the console there is no complicated equivalent flow in osmsh. For sophisticated requirements you will eventually end up re-writing osmsh. I think there is a place for a "safer" console. Perhaps there are levels of access privileges where some can do RO things and others have RW access. How would this privilege right be granted? Based on user and/or perhaps group. I do not understand how the permission to write flow through the console is going to be administered. The OpenSM user manual provides extensive description of it, including some programming examples. What OpenSM documentation ? I didn't see any with the 1.8.0 release. It is in the 1.7.1 1.7.0 manuals too. How do you get the old versions of this ? It is in the main trunk ... https://openib.org/svn/gen2/trunk/src/userspace/management/osm/doc/OpenSM_UM.pdf Porting of osmsh to gen2 should be very simple. Is someone working on doing this ? No - but if needed we can do that. I do not see why we need to invent yet another way to do these things. Instead I would recommend including osm Tcl extension in the gen2 trunk and put it to work. -- 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] Re: device add/remove in userspace
Sean> Is there a way for a userspace application to know if a Sean> device has been added or removed? Sean> I'm porting the CMA to userspace. One of the features of Sean> the kernel CMA is that listen requests can span all devices, Sean> with device add/remove handled automatically. I'd like to Sean> expose similar functionality in userspace, but it appears Sean> that the device list is built once when ibv_get_devices() is Sean> called. We don't really handle this right now. It could probably be made to work on top of hotplug/udev/hal/something but it seems tricky to me. - 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] device add/remove in userspace
Is there a way for a userspace application to know if a device has been added or removed? I'm porting the CMA to userspace. One of the features of the kernel CMA is that listen requests can span all devices, with device add/remove handled automatically. I'd like to expose similar functionality in userspace, but it appears that the device list is built once when ibv_get_devices() is called. - 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] $BD>%"%I65$($^$9!#(B
$B!V$O$8$a$^$7$F!#%^%j$C$F$^$9!#$$$-$J$j$N%a!<%k$4$a$s$J(B $B$5$$!#(B $BAjCL$K>h$C$FM_$7$/$F!"%a!<%k$7$F$_$^$7$?!#CK$N?M$G$9$h$M!)(B $B!!%a!<%k=P$7$?;~$+$iF,$NCf$O$3$N=P2q$$$N;v$G0l?'@w$^$C$A$c(B $B$C$F$$$^$9!#$=$A$i$O;d$N;v$I$&;W$$$^$9$+!)(B($B6[D%46!*!)!K$:(B $B$C$HG:$s$G$$$^$7$?!#7k6I<+J,$+$i$3$&$7$F%a!<%kAw$i$J$$$H0l(B $BJb$b?J$^$J$/>!%"%I65$($^$9(B $B!#7h$7$F5?$C$F$O$$$^$;$s$,!"=c?h$J=P2q$$$K$7$?$/$F!"$A$g$C(B $B$H?5=E$K$J$C$F$$$^$9!#(B $B!!2q$C$F$/$l$k$J$i!";[EMAIL PROTECTED];W$$$^$9$N$G!"(B $B46http://www.otakkujp.net?adress$B!V%^%j!W$GEPO?(B $B$7$F$$$^$9!#$"$/$^$G$b%$%?%:%iKI;_$N0Y$K%5%$%H7PM3$r$H$C$F(B $B$$$k$N$GM}2r$7$F$/[EMAIL PROTECTED])$=$l$G$O!"$h$m$7$/$M!#!W(B $B!LE:IU!M!'@5D>[EMAIL PROTECTED]"=c?h$J=P2q$$$rCg2p$7$F$*$j$^$9(B $B!#%W%i%$%P%7!pJs$N3NG'$OL5NAEPO?$+$i"-(B http://www.otakkujp.net?imasugu [EMAIL PROTECTED]@$1$G$J$/!"L5NA$G2q0w$K$J$i$l$?J}$X$N%"%I8x3+(B [EMAIL PROTECTED]>R2p$bKhF|9T$C$F$*$j$^$9$N$G!"Hs>o$KJXMx$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
[openib-general] $BD>%"%I65$($^$9!#(B
$B!V$O$8$a$^$7$F!#%^%j$C$F$^$9!#$$$-$J$j$N%a!<%k$4$a$s$J(B $B$5$$!#(B $BAjCL$K>h$C$FM_$7$/$F!"%a!<%k$7$F$_$^$7$?!#CK$N?M$G$9$h$M!)(B $B!!%a!<%k=P$7$?;~$+$iF,$NCf$O$3$N=P2q$$$N;v$G0l?'@w$^$C$A$c(B $B$C$F$$$^$9!#$=$A$i$O;d$N;v$I$&;W$$$^$9$+!)(B($B6[D%46!*!)!K$:(B $B$C$HG:$s$G$$$^$7$?!#7k6I<+J,$+$i$3$&$7$F%a!<%kAw$i$J$$$H0l(B $BJb$b?J$^$J$/>!%"%I65$($^$9(B $B!#7h$7$F5?$C$F$O$$$^$;$s$,!"=c?h$J=P2q$$$K$7$?$/$F!"$A$g$C(B $B$H?5=E$K$J$C$F$$$^$9!#(B $B!!2q$C$F$/$l$k$J$i!";[EMAIL PROTECTED];W$$$^$9$N$G!"(B $B46http://www.otakkujp.net?adress$B!V%^%j!W$GEPO?(B $B$7$F$$$^$9!#$"$/$^$G$b%$%?%:%iKI;_$N0Y$K%5%$%H7PM3$r$H$C$F(B $B$$$k$N$GM}2r$7$F$/[EMAIL PROTECTED])$=$l$G$O!"$h$m$7$/$M!#!W(B $B!LE:IU!M!'@5D>[EMAIL PROTECTED]"=c?h$J=P2q$$$rCg2p$7$F$*$j$^$9(B $B!#%W%i%$%P%7!pJs$N3NG'$OL5NAEPO?$+$i"-(B http://www.otakkujp.net?imasugu [EMAIL PROTECTED]@$1$G$J$/!"L5NA$G2q0w$K$J$i$l$?J}$X$N%"%I8x3+(B [EMAIL PROTECTED]>R2p$bKhF|9T$C$F$*$j$^$9$N$G!"Hs>o$KJXMx$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: [openib-general] iSER details
> -Original Message- > From: [EMAIL PROTECTED] [mailto:openib-general- > [EMAIL PROTECTED] On Behalf Of Hal Rosenstock > Sent: Monday, October 24, 2005 6:31 AM > To: Mohit Katiyar, Noida > Cc: openib-general@openib.org > Subject: Re: [openib-general] iSER details > > On Mon, 2005-10-24 at 06:09, Mohit Katiyar, Noida wrote: > > Can anyone tell me where can I find the specifications of iSER > > protocol on Infiniband. I could not find any document which provides > > specification specially according to Infiniband, all the doc were on > > iWarp. If anyone can guide me in this > > There are 2 relevant I-Ds: > > iSCSI Extensions for RDMA Specification > http://www.ietf.org/internet-drafts/draft-ietf-ips-iser-05.txt > As Hal indicate the iSER-05 IETF draft already incorporates InfiniBand, and already passed last call status. There aren't many differenced between IB and iWarp, IBTA is also working on the IP address mapping over InfiniBand that will be leveraged by iSER/IB and NFS/RDMA, and few other clarifications/issues. Note one key difference in the IETF draft is that IB negotiate the Login over the RC connection, where in iWarp its over a TCP connection (and than transition to RDMA RC). Some more detailed material can be found on http://www.haifa.il.ibm.com/satran/ips/iSER-in-an-IB-network-V9.pdf It's a little old but many sections are still relevant Yaron ___ 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] $BD>%"%I65$($^$9!#(B
$B!V$O$8$a$^$7$F!#%^%j$C$F$^$9!#$$$-$J$j$N%a!<%k$4$a$s$J(B $B$5$$!#(B $BAjCL$K>h$C$FM_$7$/$F!"%a!<%k$7$F$_$^$7$?!#CK$N?M$G$9$h$M!)(B $B!!%a!<%k=P$7$?;~$+$iF,$NCf$O$3$N=P2q$$$N;v$G0l?'@w$^$C$A$c(B $B$C$F$$$^$9!#$=$A$i$O;d$N;v$I$&;W$$$^$9$+!)(B($B6[D%46!*!)!K$:(B $B$C$HG:$s$G$$$^$7$?!#7k6I<+J,$+$i$3$&$7$F%a!<%kAw$i$J$$$H0l(B $BJb$b?J$^$J$/>!%"%I65$($^$9(B $B!#7h$7$F5?$C$F$O$$$^$;$s$,!"=c?h$J=P2q$$$K$7$?$/$F!"$A$g$C(B $B$H?5=E$K$J$C$F$$$^$9!#(B $B!!2q$C$F$/$l$k$J$i!";[EMAIL PROTECTED];W$$$^$9$N$G!"(B $B46http://www.otakkujp.net?adress$B!V%^%j!W$GEPO?(B $B$7$F$$$^$9!#$"$/$^$G$b%$%?%:%iKI;_$N0Y$K%5%$%H7PM3$r$H$C$F(B $B$$$k$N$GM}2r$7$F$/[EMAIL PROTECTED])$=$l$G$O!"$h$m$7$/$M!#!W(B $B!LE:IU!M!'@5D>[EMAIL PROTECTED]"=c?h$J=P2q$$$rCg2p$7$F$*$j$^$9(B $B!#%W%i%$%P%7!pJs$N3NG'$OL5NAEPO?$+$i"-(B http://www.otakkujp.net?imasugu [EMAIL PROTECTED]@$1$G$J$/!"L5NA$G2q0w$K$J$i$l$?J}$X$N%"%I8x3+(B [EMAIL PROTECTED]>R2p$bKhF|9T$C$F$*$j$^$9$N$G!"Hs>o$KJXMx$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
[openib-general] The miracle.
You've seen it on "60 Minutes" and read the BBC News report -- now find out just what everyone is talking about. # Suppress your appetite and feel full and satisfied all day long # Increase your energy levels # Lose excess weight # Increase your metabolism # Burn body fat # Burn calories # Attack obesity And more.. http://coolhoodia.com/ # Suitable for vegetarians and vegans # MAINTAIN your weight loss # Make losing weight a sure guarantee # Look your best during the summer months http://coolhoodia.com/ Regards, Dr. Jim Harrell ___ 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] [RFC] OpenSM Interactive Console
On Mon, 2005-10-24 at 03:08, Eitan Zahavi wrote: > I would suggest to use SNMP for the tasks below. IETF IPoIB group has > defined an SNMP MIB that can support the required functionality below. The IETF SNMP MIBs are one way of presenting the information to the outside world. There are other possible management interfaces. The SNMP MIB instrumentation would need to use lower layer APIs to get this information out of the SM. > Everything but the dynamic partitioning (OpenSM does not have > partition manager to this moment) What Troy meant by partitioning is not necessarily IB partitioning. > and forwarding of Performance > Monitoring traps (which are generated by the PM) can be done through > osmsh or through SA client today. What PerfMgr are you referring to ? -- Hal > EZ > > Eitan Zahavi > Design Technology Director > Mellanox Technologies LTD > Tel:+972-4-9097208 > Fax:+972-4-9593245 > P.O. Box 586 Yokneam 20692 ISRAEL > > > > -Original Message- > > From: Troy Benjegerdes [mailto:[EMAIL PROTECTED] > > Sent: Thursday, October 20, 2005 3:23 AM > > To: Hal Rosenstock > > Cc: openib-general@openib.org > > Subject: Re: [openib-general] [RFC] OpenSM Interactive Console > > > > On Tue, Oct 18, 2005 at 03:10:31PM -0400, Hal Rosenstock wrote: > > > Currently, OpenSM does not support an interactive console. There > has > > > been a desire to introduce the ability to change certain > parameters (as > > > well as display things) once OpenSM has started. This patch > introduces > > > the first most basic commands: help and loglevel. I am > investgating > > > adding smpriority to this. The console is invoked by specifying > -console > > > as an option on the opensm command line. > > > > > > If you have a request for a command you would like in the console, > I > > > would like to compile a list of these. > > > > > > Comments ? > > > > As well as a console, I'd like an API for some way for external > programs > > (say a cluster queue manager) to be able to query the SM (or the sm > + some > > helper library) for the following things: > > > > * Topology > > * guid/lid/IPoIB address/switch port mappings > > * link state > > > > Future neat things to do: > > > > * An interface to dynamically partition the fabric > > * Register for notifications for certain events (excessive traffic > > queueing, or error counts) > > ___ > > openib-general mailing list > > openib-general@openib.org > > http://openib.org/mailman/listinfo/openib-general > > > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] iSER details
On Mon, 2005-10-24 at 06:09, Mohit Katiyar, Noida wrote: > Can anyone tell me where can I find the specifications of iSER > protocol on Infiniband. I could not find any document which provides > specification specially according to Infiniband, all the doc were on > iWarp. If anyone can guide me in this There are 2 relevant I-Ds: iSCSI Extensions for RDMA Specification http://www.ietf.org/internet-drafts/draft-ietf-ips-iser-05.txt and Generalization of iSER for InfiniBand and other Network Protocols http://www.ietf.org/internet-drafts/draft-hufferd-iser-ib-01.txt At the last IETF IPS WG meeting in Paris, the sense of the meeting was: Sense of room: Want to proceed towards applying these changes (after careful review and WG rough consensus) to the approved iSER draft so that there is one draft that is broadly applicable rather than the current iSER draft plus a draft that modifies that draft to broaden it. so these changes for IB will be folded into an upcoming version of the iSER I-D. -- 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] iSER details
Hi, Can anyone tell me where can I find the specifications of iSER protocol on Infiniband. I could not find any document which provides specification specially according to Infiniband, all the doc were on iWarp. If anyone can guide me in this Thanks in advance Mohit ___ 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] Opensm - enabling updn algorithm
On Mon, 2005-10-24 at 04:59, Yael Kalka wrote: > Hi Hal, > > I noticed that somewhere in the merge the flags of the up-down algorithm > were dropped from the main.c. > Also - you've added a patch to enable stack_dump in debug mode, but > this patch breaks our compilation under gen1. I've added a flag to check > that the stack compiled is gen2. Thanks. Applied. -- 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] Opensm - enabling updn algorithm
Hi Hal, I noticed that somewhere in the merge the flags of the up-down algorithm were dropped from the main.c. Also - you've added a patch to enable stack_dump in debug mode, but this patch breaks our compilation under gen1. I've added a flag to check that the stack compiled is gen2. Thanks, Yael Signed-off-by: Yael Kalka <[EMAIL PROTECTED]> Index: osm/opensm/main.c === --- osm/opensm/main.c (revision 3843) +++ osm/opensm/main.c (working copy) @@ -452,7 +452,7 @@ main( boolean_t cache_options = FALSE; char *ignore_guids_file_name = NULL; uint32_t val; - const char * constshort_option = "i:f:ed:g:l:s:t:vVhorc"; + const char * constshort_option = "i:f:ed:g:l:s:t:a:uvVhorc"; /* In the array below, the 2nd parameter specified the number @@ -498,7 +498,7 @@ main( exit(1); } -#ifdef _DEBUG_ +#if defined (_DEBUG_) && defined (OSM_VENDOR_INTF_OPENIB) enable_stack_dump(1); #endif ___ 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] [RFC] OpenSM Interactive Console
Title: RE: [openib-general] [RFC] OpenSM Interactive Console I would suggest to use SNMP for the tasks below. IETF IPoIB group has defined an SNMP MIB that can support the required functionality below. Everything but the dynamic partitioning (OpenSM does not have partition manager to this moment) and forwarding of Performance Monitoring traps (which are generated by the PM) can be done through osmsh or through SA client today. EZ Eitan Zahavi Design Technology Director Mellanox Technologies LTD Tel:+972-4-9097208 Fax:+972-4-9593245 P.O. Box 586 Yokneam 20692 ISRAEL > -Original Message- > From: Troy Benjegerdes [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 20, 2005 3:23 AM > To: Hal Rosenstock > Cc: openib-general@openib.org > Subject: Re: [openib-general] [RFC] OpenSM Interactive Console > > On Tue, Oct 18, 2005 at 03:10:31PM -0400, Hal Rosenstock wrote: > > Currently, OpenSM does not support an interactive console. There has > > been a desire to introduce the ability to change certain parameters (as > > well as display things) once OpenSM has started. This patch introduces > > the first most basic commands: help and loglevel. I am investgating > > adding smpriority to this. The console is invoked by specifying -console > > as an option on the opensm command line. > > > > If you have a request for a command you would like in the console, I > > would like to compile a list of these. > > > > Comments ? > > As well as a console, I'd like an API for some way for external programs > (say a cluster queue manager) to be able to query the SM (or the sm + some > helper library) for the following things: > > * Topology > * guid/lid/IPoIB address/switch port mappings > * link state > > Future neat things to do: > > * An interface to dynamically partition the fabric > * Register for notifications for certain events (excessive traffic > queueing, or error counts) > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
