Re: [openib-general] the rping test doesn't exit gracefuly
I think that's the expected output... On Sun, 2006-03-19 at 17:14 +0200, Dotan Barak wrote: > Hi sean. > > I tried to execute the test rping, but i'm having a problem. > there are error messages at the end of the test but the return value of the > executable is 0. > is this is the expected behaviour of the test? > > here is the output of both of the sides (with the command lines that i used): > > server: > --- > # ./rping -s -V -v -p 12345 -C 10 > server ping data: rdma-ping-0: > ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr > server ping data: rdma-ping-1: > BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs > server ping data: rdma-ping-2: > CDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst > server ping data: rdma-ping-3: > DEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu > server ping data: rdma-ping-4: > EFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv > server ping data: rdma-ping-5: > FGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvw > server ping data: rdma-ping-6: > GHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwx > server ping data: rdma-ping-7: > HIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxy > server ping data: rdma-ping-8: > IJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz > server ping data: rdma-ping-9: > JKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyzA > DISCONNECT EVENT... > wait for RDMA_READ_ADV state 9 > cq completion failed status 5 > # echo $? > 0 > > client: > --- > # ./rping -V -v -c -C 10 -a 11.4.8.31 -p 12345 > ping data: rdma-ping-0: ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr > ping data: rdma-ping-1: BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs > ping data: rdma-ping-2: CDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst > ping data: rdma-ping-3: DEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu > ping data: rdma-ping-4: EFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv > ping data: rdma-ping-5: FGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvw > ping data: rdma-ping-6: GHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwx > ping data: rdma-ping-7: HIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxy > ping data: rdma-ping-8: IJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz > ping data: rdma-ping-9: JKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyzA > cq completion failed status 5 > DISCONNECT EVENT... > # echo $? > 0 > > > Thanx > Dotan > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general 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] amso1100 userspace driver
On Sun, 2006-03-19 at 14:01 -0500, Pete Wyckoff wrote: > Perhaps I'm being dense, but I can't seem to find the > device-specific userspace driver for amso1100 in the SVN tree. > Does one exist? I'm looking for something that implements > openib_driver_init() and all the ibv_context_ops for amso1100. > There's drivers for mthca, ipath, cxgb3, ehca, but no amso1100? > > Thanks, > There is no userspace support yet for the Ammasso driver... > -- Pete > ___ > 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] [PATCH] diags/smpquery: support for querying SL2VL and VLArbitration tables
Hello,
There is support for querying SL2VLMapping and VLArbitration tables -
'sl2vl' and 'vlarb' operations are added to smpquery.
Sasha.
Support for SL2VLMapping and VLArbitration tables querying.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
diags/src/smpquery.c | 133 +-
1 files changed, 119 insertions(+), 14 deletions(-)
diff --git a/diags/src/smpquery.c b/diags/src/smpquery.c
index 3ce3e9a..6f8d0c9 100644
--- a/diags/src/smpquery.c
+++ b/diags/src/smpquery.c
@@ -53,6 +53,7 @@
#defineDEBUG if (verbose>1) IBWARN
#define IBERROR(fmt, args...) iberror(__FUNCTION__, fmt, ## args)
+
static int dest_type = IB_DEST_LID;
static int verbose;
@@ -61,16 +62,21 @@ typedef char *(op_fn_t)(ib_portid_t *des
typedef struct match_rec {
char *name;
op_fn_t *fn;
+ unsigned opt_portnum;
} match_rec_t;
-static op_fn_t node_desc, node_info, port_info, switch_info, pkey_table;
-static match_rec_t match_tbl[] = {
+static op_fn_t node_desc, node_info, port_info, switch_info, pkey_table,
+ sl2vl_table, vlarb_table;
+
+static const match_rec_t match_tbl[] = {
{ "nodeinfo", node_info },
{ "nodedesc", node_desc },
- { "portinfo", port_info },
+ { "portinfo", port_info , 1 },
{ "switchinfo", switch_info },
- { "pkeys", pkey_table },
+ { "pkeys", pkey_table , 1 },
+ { "sl2vl", sl2vl_table , 1 },
+ { "vlarb", vlarb_table , 1 },
{0}
};
@@ -214,22 +220,122 @@ pkey_table(ib_portid_t *dest, char **arg
return 0;
}
-op_fn_t *
-match_op(char *name)
+static char *sl2vl_dump_table_entry(ib_portid_t *dest, int in, int out)
{
- match_rec_t *r;
+ char buf[2048];
+ char data[IB_SMP_DATA_SIZE];
+ int portnum = (in << 8) | out;
+
+ if (!smp_query(data, dest, IB_ATTR_SLVL_TABLE, portnum, 0))
+ return "smp query failed";
+ mad_dump_sltovl(buf, sizeof buf, data, sizeof data);
+ printf("ports: in %2d, out %2d: ", in, out);
+ printf("%s", buf);
+ return 0;
+}
+
+static char *
+sl2vl_table(ib_portid_t *dest, char **argv, int argc)
+{
+ char data[IB_SMP_DATA_SIZE];
+ int type, num_ports, portnum = 0;
+ int i;
+ char *ret;
+
+ if (argc > 0)
+ portnum = strtol(argv[0], 0, 0);
+
+ if (!smp_query(data, dest, IB_ATTR_NODE_INFO, 0, 0))
+ return "node info query failed";
+
+ mad_decode_field(data, IB_NODE_TYPE_F, &type);
+ mad_decode_field(data, IB_NODE_NPORTS_F, &num_ports);
+ if (portnum > num_ports)
+ return "invalid port number";
+
+ printf("# SL2VL table: %s\n", portid2str(dest));
+ printf("# SL: |");
+ for (i = 0 ; i < 16 ; i++)
+ printf("%2d|", i);
+ printf("\n");
+
+ if (type != IB_NODE_SWITCH)
+ return sl2vl_dump_table_entry(dest, 0, 0);
+
+ for (i = 0 ; i <= num_ports ; i++) {
+ ret = sl2vl_dump_table_entry(dest, i, portnum);
+ if (ret)
+ return ret;
+ }
+ return 0;
+}
+
+static char *vlarb_dump_table_entry(ib_portid_t *dest, int portnum, int offset)
+{
+ char buf[2048];
+ char data[IB_SMP_DATA_SIZE];
+ if (!smp_query(data, dest, IB_ATTR_VL_ARBITRATION,
+ (offset << 16) | portnum, 0))
+ return "smp query failed";
+ mad_dump_vlarbitration(buf, sizeof(buf), data, sizeof(data));
+ printf("%s", buf);
+ return 0;
+}
+
+static char *vlarb_dump_table(ib_portid_t *dest, int portnum,
+ char *name, int offset, char *data, int size_field)
+{
+ int size;
+ char *ret;
+ mad_decode_field(data,size_field, &size);
+ printf("# %s priority VL Arbitratoin Table:", name);
+ if ( (ret = vlarb_dump_table_entry(dest, portnum, offset)) ||
+ (size > 32 &&
+ (ret = vlarb_dump_table_entry(dest, portnum, offset + 1))) )
+ return ret;
+ return 0;
+}
+
+static char *
+vlarb_table(ib_portid_t *dest, char **argv, int argc)
+{
+ char data[IB_SMP_DATA_SIZE];
+ int portnum = 0;
+ char *ret;
+
+ if (argc > 0)
+ portnum = strtol(argv[0], 0, 0);
+
+ if (!smp_query(data, dest, IB_ATTR_PORT_INFO, portnum, 0))
+ return "node info query failed";
+
+ printf("# VLArbitration tables: %s port %d\n",
+ portid2str(dest), portnum);
+ if ( (ret = vlarb_dump_table(dest, portnum, "Low", 1,
+ data, IB_PORT_VL_ARBITRATION_LOW_CAP_F)) ||
+ (ret = vlarb_dump_table(dest, portnum, "High", 3,
+ data, IB_PORT_VL_ARBITRATION_HIGH_CAP_F)) )
+ return ret;
+
+ return 0;
+}
+
+static op_fn_t *
+match_op(char *name)
+{
+ const match_rec_t *r;
for (r = match_tbl; r->n
[openib-general] [PATCH] libibmad: mad_dump_sltovl() output simplification
Hello,
There is simplification of mad_dump_sltovl() output (and function). This
is helpful when multiple tables are queried for gracefull results
printing.
Sasha.
This simplifies mad_dump_sltovl() output and makes it possible to dump
multiple SL2VL tables.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
libibmad/src/dump.c | 18 --
1 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/libibmad/src/dump.c b/libibmad/src/dump.c
index 7bfd92c..9389ce1 100644
--- a/libibmad/src/dump.c
+++ b/libibmad/src/dump.c
@@ -647,24 +647,14 @@ void
mad_dump_sltovl(char *buf, int bufsz, void *val, int valsz)
{
ib_slvl_table_t* p_slvl_tbl = val;
- char buf_line1[1024];
- char buf_line2[1024];
uint8_t vl;
- int i;
-
- buf_line1[0] = 0;
- buf_line2[0] = 0;
-
- for (i = 0; i < 16; i++)
- sprintf(buf_line1, "%s%-4u|", buf_line1, i);
-
+ int i, n = 0;
+ n = snprintf(buf, bufsz, "|");
for (i = 0; i < 16; i++) {
ib_slvl_get_i(p_slvl_tbl, i, &vl);
- sprintf(buf_line2, "%s0x%-2X|", buf_line2, vl);
-
+ n += snprintf(buf + n, bufsz - n, "%2u|", vl);
}
-
- snprintf(buf, bufsz, "\nSL: |%s\nVL: |%s\n", buf_line1, buf_line2);
+ snprintf(buf + n, bufsz - n, "\n");
}
void
___
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] krping minor fixes
This patch fixes some little issues in krping.
-- Pete
Add some comments into the source explaining how to get krping to
do its business. The use of /bin/echo rather than the bash builtin
avoids killing the shell in some error exit cases.
Return an error if the route doesn't resolve to avoid an oops on
the client when it can't connect to a server, and make the error
say more clearly that something failed.
Setting size=65536 (RPING_BUFSIZE) seems to work just fine. Or
fix the printk error to report RPING_BUFSIZE-1 too.
Getopt taken from mount code isn't really mounting anything.
Signed-off-by: Pete Wyckoff <[EMAIL PROTECTED]>
Index: gen2/branches/iwarp/src/linux-kernel/infiniband/ulp/krping/krping.c
===
--- gen2/branches/iwarp/src/linux-kernel/infiniband/ulp/krping/krping.c
(revision 5878)
+++ gen2/branches/iwarp/src/linux-kernel/infiniband/ulp/krping/krping.c
(working copy)
@@ -97,6 +97,12 @@
static struct proc_dir_entry *krping_proc;
/*
+ * Invoke like this, one on each side, using the server's address on
+ * the RDMA device (iw%d):
+ *
+ * /bin/echo server,port=,addr=192.168.69.142,validate > /proc/krping
+ * /bin/echo client,port=,addr=192.168.69.142,validate > /proc/krping
+ *
* krping "ping/pong" loop:
* client sends source rkey/addr/len
* server receives source rkey/add/len
@@ -884,9 +890,9 @@
wait_event_interruptible(cb->sem, cb->state >= ROUTE_RESOLVED);
if (cb->state != ROUTE_RESOLVED) {
printk(KERN_ERR PFX
- "waiting for addr/route resolution state %d\n",
+ "addr/route resolution did not resolve: state %d\n",
cb->state);
- return ret;
+ return -EINTR;
}
DEBUG_LOG("rdma_resolve_addr - rdma_resolve_route successful\n");
@@ -978,7 +984,7 @@
case 'S':
cb->size = optint;
if ((cb->size < 1) ||
- (cb->size > (RPING_BUFSIZE - 1))) {
+ (cb->size > RPING_BUFSIZE)) {
printk(KERN_ERR PFX "Invalid size %d "
"(valid range is 1 to %d)\n",
cb->size, RPING_BUFSIZE);
Index: gen2/branches/iwarp/src/linux-kernel/infiniband/ulp/krping/getopt.c
===
--- gen2/branches/iwarp/src/linux-kernel/infiniband/ulp/krping/getopt.c
(revision 5878)
+++ gen2/branches/iwarp/src/linux-kernel/infiniband/ulp/krping/getopt.c
(working copy)
@@ -70,6 +70,6 @@
return -EINVAL;
}
}
- printk(KERN_INFO "%s: Unrecognized mount option %s\n", caller, token);
+ printk(KERN_INFO "%s: Unrecognized option %s\n", caller, token);
return -EOPNOTSUPP;
}
___
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] amso1100 userspace driver
Perhaps I'm being dense, but I can't seem to find the device-specific userspace driver for amso1100 in the SVN tree. Does one exist? I'm looking for something that implements openib_driver_init() and all the ibv_context_ops for amso1100. There's drivers for mthca, ipath, cxgb3, ehca, but no amso1100? Thanks, -- Pete ___ 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] vendor: identify rmpp mads
Hi Hal, Please check-in the change in osm_vendor_mlx_svc.h I have tested it for IB_MCLASS_SUBN_ADM As far as I know BIS, DevAdm and the vendor classes range are not part of the management, so they are not needed in this patch (but should be added to Kernel file mad.c I sent you - if it's not there, I looked on the file mad.c in my machine, and I am not sure it is updated) Thanks! Ofer -Original Message- From: Hal Rosenstock [mailto:[EMAIL PROTECTED] Sent: Friday, March 17, 2006 2:07 AM To: Ofer Gigi Cc: OPENIB Subject: Re: [PATCH] vendor: identify rmpp mads Hi Ofer, On Thu, 2006-03-16 at 12:14, Ofer Gigi wrote: > Hi Hal, > > RMPP mad can only sent in 4 kinds of mad: > 1. IB_MCLASS_SUBN_ADM > 2. IB_MCLASS_DEV_MGMT > 3. BIS > 4. DevAdm There are more than these. There is also the vendor class 2 range as well. > If the packet is not 1 or 2 - the mad is not checked and returned in advance as not a > rmpp packet. > Since 3,4 are not management classes (see 13.4.4 page 720 in the spec) I don't know > whether they are defined as constants or not - so I didn't handle them. 3 and 4 are management classes defined in the IBA 1.2 annexes (and do support RMPP). > Thanks > > Ofer G. > > Signed-off-by: Ofer Gigi <[EMAIL PROTECTED]> > > Index: osm_vendor_mlx_svc.h > === > --- osm_vendor_mlx_svc.h(revision 5836) > +++ osm_vendor_mlx_svc.h(working copy) > @@ -116,6 +116,9 @@ osmv_mad_is_rmpp(IN const ib_mad_t *p_ma > CL_ASSERT(NULL != p_mad); > > rmpp_flags = ((ib_rmpp_mad_t*)p_mad)->rmpp_flags; > +/* HACK - JUST SA and DevMgt for now - need to add BIS and DevAdm*/ > +if ( (p_mad->mgmt_class != CL_NTOH16(IB_MCLASS_SUBN_ADM)) && > +(p_mad->mgmt_class != CL_NTOH16(IB_MCLASS_DEV_MGMT)) ) return(0); > return (0 != (rmpp_flags & IB_RMPP_FLAG_ACTIVE)); > } Given the above comments, what do you want me to do with this ? Also, I have no way of testing this. Should I just check it in ? -- 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] mthca FMR correctness (and memory windows)
> From: Talpey, Thomas > Sent: Sunday, March 19, 2006 5:36 PM > > I'm implementing FMR memory registration mode in the NFS/RDMA > client, and I've got it mostly working. However as I > understand it, mthca's existing fmr's do not guarantee that > the r_key is completely invalidated when the ib_unmap_fmr() > returns. This makes using them rather problematic, to say the least. When ib_unmap_fmr() is done, you can be sure that the old FMR is inaccessible. That's why this call blocks... > > Now, I notice that ib_unmap_fmr() is a blocking operation (at > least, the kernel whines about semaphores being waited in > interrupt context, when I experimented with that). > > Does this mean mthca's ib_unmap_fmr() is waiting for the > invalidation now, or plans to in the future? It is indeed waiting for true invalidation. But Tom, I think that you should be looking at rdma/ib_fmr_pool.h for a better API to use for FMRs. This way you can allocate a pool and remap FMRs each time you need one. You can look for examples in ulp/sdp directory. > > Is there a plan to make fmr's compliant with verbs 1.2? In the future... And it will probably be a different API, such an API that can go through a WQE->CQE. > > Final question is memory windows. The code is there in the > NFS/RDMA client, but all it gets is ENOSYS from ib_bind_mw(). > (Yes, I know memory windows may not perform well on mthca. > However, they're correct and hopefully faster than ib_reg_phys_mr()). FMR's the fastest. MWs are supported by the mthca HW. To my knowledge there was no demand for MWs so far and that's why the code to handle them hasn't been implemented in mthca. > > What is the plan to implement mthca memory windows? > > Thanks, > Tom. ___ 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] rdma_cm README file is inconsistent with the source code
Hi sean. 1) In the source code of the rdma_cm (cma.c) i saw that the library tries to open the file: "/dev/infiniband/rdma_cm". 2) I saw the following lines in the README file: To create the appropriate character device file automatically with udev, a rule like KERNEL="ucma", NAME="infiniband/%k", MODE="0666" can be used. This will create the device node named /dev/infiniband/ucma which file is the updated one? thanks Dotan ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Re: [PATCH 1 of 3] core: static rate encoding changesupport
On Thursday 16 March 2006 19:17, Bryan O'Sullivan wrote:
> On Thu, 2006-03-16 at 18:58 +0200, Michael S. Tsirkin wrote:
> > > BTW, have you looked at ehca or ipath? Do they need their static rate
> > > handling fixed up?
> >
> > Not sure, I think they do.
>
> Came a bit late to this discussion, sorry. If you make core changes
> that require driver changes to work with them, it's probably a good idea
> to file bugs against those drivers in Bugzilla so that the ehca and
> ipath owners know something is up that they'll need to fix.
>
This encoding change DOES demand changes to the provider code.
I note that both ehca and ipath take the static rate field as the IPD value.
(ehca copies the static rate value in the ah attr struct to an "ipd" field,
ipath copies the entire ah attribute structure as-is).
The new encoding will require ehca and ipath to translate the new encoding to
an IPD value at the provider layer (from the encoding as given in the URLs
above -- essentially the encoding described in the PathRecord rate field
(Table 205 on page 901, section 15.2.5.6 of IB Spec).
Such translation is currently done by ULPs! (not good).
For example, in IPoIB:
ipoib_multicast.c, procedure ipoib_mcast_join_task() :
(tracking current rate)
if (!ib_query_port(priv->ca, priv->port, &attr)) {
priv->local_lid = attr.lid;
priv->local_rate = attr.active_speed *
ib_width_enum_to_int(attr.active_width);
} else
and ipoib_main.c, procedure path_rec_completion :
(computing IPD from current rate and desired rate)
int path_rate = ib_sa_rate_enum_to_int(pathrec->rate);
if (path_rate > 0 && priv->local_rate > path_rate)
av.static_rate = (priv->local_rate - 1) / path_rate;
The proper place for this translation is at the provider layer (ULPs should
NOT be involved in IPD calculations).
The changes to ehca and ipath should be very minor, but must be done
(For full discussion, see the links below)
http://openib.org/pipermail/openib-general/2006-March/017452.html
http://openib.org/pipermail/openib-general/2006-March/017453.html
http://openib.org/pipermail/openib-general/2006-March/017454.html
Definition of new encoding:
http://openib.org/pipermail/openib-general/2006-March/017999.html
(and see thread starting at this point)
ULP (ipoib) changes for new encoding:
http://openib.org/pipermail/openib-general/2006-March/018000.html
Finally, changes submitted for Mellanox provider layer:
http://openib.org/pipermail/openib-general/2006-March/018001.html
- Jack
___
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] libibverbs/examples/asyncwatch.c: Added a print of the event name in string format
Added a print of the event name in string format.
Signed-off-by: Dotan Barak <[EMAIL PROTECTED]>
Index: latest/src/userspace/libibverbs/examples/asyncwatch.c
===
--- latest.orig/src/userspace/libibverbs/examples/asyncwatch.c 2006-03-19
12:03:02.0 +0200
+++ latest/src/userspace/libibverbs/examples/asyncwatch.c 2006-03-19
17:36:14.0 +0200
@@ -42,6 +42,38 @@
#include
+static const char *event_name_str(enum ibv_event_type event_type)
+{
+ switch (event_type) {
+ case IBV_EVENT_DEVICE_FATAL:
+ return "IBV_EVENT_DEVICE_FATAL";
+ case IBV_EVENT_PORT_ACTIVE:
+ return "IBV_EVENT_PORT_ACTIVE";
+ case IBV_EVENT_PORT_ERR:
+ return "IBV_EVENT_PORT_ERR";
+ case IBV_EVENT_LID_CHANGE:
+ return "IBV_EVENT_LID_CHANGE";
+ case IBV_EVENT_PKEY_CHANGE:
+ return "IBV_EVENT_PKEY_CHANGE";
+ case IBV_EVENT_SM_CHANGE:
+ return "IBV_EVENT_SM_CHANGE";
+
+ case IBV_EVENT_CQ_ERR:
+ case IBV_EVENT_QP_FATAL:
+ case IBV_EVENT_QP_REQ_ERR:
+ case IBV_EVENT_QP_ACCESS_ERR:
+ case IBV_EVENT_COMM_EST:
+ case IBV_EVENT_SQ_DRAINED:
+ case IBV_EVENT_PATH_MIG:
+ case IBV_EVENT_PATH_MIG_ERR:
+ case IBV_EVENT_SRQ_ERR:
+ case IBV_EVENT_SRQ_LIMIT_REACHED:
+ case IBV_EVENT_QP_LAST_WQE_REACHED:
+ default:
+ return "unexpected";
+ }
+}
+
int main(int argc, char *argv[])
{
struct ibv_device **dev_list;
@@ -73,9 +105,9 @@ int main(int argc, char *argv[])
if (ibv_get_async_event(context, &event))
return 1;
- printf(" event_type %d, port %d\n", event.event_type,
- event.element.port_num);
-
+ printf(" event_type %s (%d), port %d\n",
+ event_name_str(event.event_type),
+ event.event_type, event.element.port_num);
ibv_ack_async_event(&event);
}
___
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] mthca FMR correctness (and memory windows)
I'm implementing FMR memory registration mode in the NFS/RDMA client, and I've got it mostly working. However as I understand it, mthca's existing fmr's do not guarantee that the r_key is completely invalidated when the ib_unmap_fmr() returns. This makes using them rather problematic, to say the least. Now, I notice that ib_unmap_fmr() is a blocking operation (at least, the kernel whines about semaphores being waited in interrupt context, when I experimented with that). Does this mean mthca's ib_unmap_fmr() is waiting for the invalidation now, or plans to in the future? Second comment is that the existing fmr api is (IMO) very inconsistent. Why does ib_map_phys_fmr() take an array of u64 physaddrs and not struct page *'s? And the unmap api mysteriously takes a struct list *, not any object returned by ib_alloc_fmr() or ib_map_phys_fmr(). Is there a plan to make fmr's compliant with verbs 1.2? Final question is memory windows. The code is there in the NFS/RDMA client, but all it gets is ENOSYS from ib_bind_mw(). (Yes, I know memory windows may not perform well on mthca. However, they're correct and hopefully faster than ib_reg_phys_mr()). What is the plan to implement mthca memory windows? Thanks, Tom. ___ 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] mthca: add a check to modify_qp that sgid_index and path_mtu are valid
Added a check that the parameters sgid_index and path_mtu are valid,
since they might come from userspace.
Signed-off-by: Dotan Barak <[EMAIL PROTECTED]>
Index: latest/drivers/infiniband/hw/mthca/mthca_qp.c
===
--- latest.orig/drivers/infiniband/hw/mthca/mthca_qp.c 2006-03-19
16:25:48.0 +0200
+++ latest/drivers/infiniband/hw/mthca/mthca_qp.c 2006-03-19
16:54:05.0 +0200
@@ -481,13 +481,20 @@
return err;
}
-static void mthca_path_set(struct ib_ah_attr *ah, struct mthca_qp_path *path)
+static int mthca_path_set(struct mthca_dev *dev, struct ib_ah_attr *ah,
+ struct mthca_qp_path *path)
{
path->g_mylmc = ah->src_path_bits & 0x7f;
path->rlid= cpu_to_be16(ah->dlid);
path->static_rate = !!ah->static_rate;
if (ah->ah_flags & IB_AH_GRH) {
+ if (ah->grh.sgid_index >= dev->limits.gid_table_len) {
+ mthca_dbg(dev, "sgid_index (%u) too large. max is %d\n",
+ ah->grh.sgid_index,
dev->limits.gid_table_len-1);
+ return -1;
+ }
+
path->g_mylmc |= 1 << 7;
path->mgid_index = ah->grh.sgid_index;
path->hop_limit = ah->grh.hop_limit;
@@ -498,6 +505,8 @@
memcpy(path->rgid, ah->grh.dgid.raw, 16);
} else
path->sl_tclass_flowlabel = cpu_to_be32(ah->sl << 28);
+
+ return 0;
}
int mthca_modify_qp(struct ib_qp *ibqp, struct ib_qp_attr *attr, int attr_mask)
@@ -590,8 +599,14 @@
if (qp->transport == MLX || qp->transport == UD)
qp_context->mtu_msgmax = (IB_MTU_2048 << 5) | 11;
- else if (attr_mask & IB_QP_PATH_MTU)
+ else if (attr_mask & IB_QP_PATH_MTU) {
+ if (attr->path_mtu < IB_MTU_256 || attr->path_mtu >
IB_MTU_2048) {
+ mthca_dbg(dev, "path MTU (%u) is invalid\n",
+ attr->path_mtu);
+ return -EINVAL;
+ }
qp_context->mtu_msgmax = (attr->path_mtu << 5) | 31;
+ }
if (mthca_is_memfree(dev)) {
if (qp->rq.max)
@@ -640,7 +655,9 @@
}
if (attr_mask & IB_QP_AV) {
- mthca_path_set(&attr->ah_attr, &qp_context->pri_path);
+ if (mthca_path_set(dev, &attr->ah_attr, &qp_context->pri_path))
+ return -EINVAL;
+
qp_param->opt_param_mask |=
cpu_to_be32(MTHCA_QP_OPTPAR_PRIMARY_ADDR_PATH);
}
@@ -662,7 +679,9 @@
return -EINVAL;
}
- mthca_path_set(&attr->alt_ah_attr, &qp_context->alt_path);
+ if (mthca_path_set(dev, &attr->alt_ah_attr,
&qp_context->alt_path))
+ return -EINVAL;
+
qp_context->alt_path.port_pkey |=
cpu_to_be32(attr->alt_pkey_index |
attr->alt_port_num << 24);
qp_context->alt_path.ackto = attr->alt_timeout << 3;
___
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 rping test doesn't exit gracefuly
Hi sean. I tried to execute the test rping, but i'm having a problem. there are error messages at the end of the test but the return value of the executable is 0. is this is the expected behaviour of the test? here is the output of both of the sides (with the command lines that i used): server: --- # ./rping -s -V -v -p 12345 -C 10 server ping data: rdma-ping-0: ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr server ping data: rdma-ping-1: BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs server ping data: rdma-ping-2: CDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst server ping data: rdma-ping-3: DEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu server ping data: rdma-ping-4: EFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv server ping data: rdma-ping-5: FGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvw server ping data: rdma-ping-6: GHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwx server ping data: rdma-ping-7: HIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxy server ping data: rdma-ping-8: IJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz server ping data: rdma-ping-9: JKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyzA DISCONNECT EVENT... wait for RDMA_READ_ADV state 9 cq completion failed status 5 # echo $? 0 client: --- # ./rping -V -v -c -C 10 -a 11.4.8.31 -p 12345 ping data: rdma-ping-0: ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr ping data: rdma-ping-1: BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs ping data: rdma-ping-2: CDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst ping data: rdma-ping-3: DEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstu ping data: rdma-ping-4: EFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuv ping data: rdma-ping-5: FGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvw ping data: rdma-ping-6: GHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwx ping data: rdma-ping-7: HIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxy ping data: rdma-ping-8: IJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz ping data: rdma-ping-9: JKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyzA cq completion failed status 5 DISCONNECT EVENT... # echo $? 0 Thanx Dotan ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] IPoIB network interface "RUNNING" status with the cable disconnected - fix
Sorry, the same message, but with a subject.
Hello,
the patch fixes a problem with the network interface "RUNNING"
status.
The problem was that the status stayed "RUNNING" with the cable
disconnected,
both for ib0 network interface and a vlan (partition) child device
(like ib0.f1f1)
The patch causes the network interface device to be flushed when
cable is disconnected.
This patch requires also my previous patch to be applied (ipoib_ib.c
- wrong pointer memory access bug fix), see below.
Signed-off-by: Leonid Arsh <[EMAIL PROTECTED]>
Index: infiniband/ulp/ipoib/ipoib_verbs.c
===
--- infiniband/ulp/ipoib/ipoib_verbs.c (revision 8499)
+++ infiniband/ulp/ipoib/ipoib_verbs.c (working copy)
@@ -251,10 +251,11 @@
struct ipoib_dev_priv *priv =
container_of(handler, struct ipoib_dev_priv,
event_handler);
- if (record->event == IB_EVENT_PORT_ACTIVE ||
+if (record->event == IB_EVENT_PORT_ERR||
+record->event == IB_EVENT_PORT_ACTIVE ||
record->event == IB_EVENT_LID_CHANGE ||
record->event == IB_EVENT_SM_CHANGE) {
- ipoib_dbg(priv, "Port active event\n");
+ ipoib_dbg(priv, "Port state change event\n");
schedule_work(&priv->flush_task);
}
}
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Leonid Arsh
Sent: Sunday, March 19, 2006 4:03 PM
To: openib-general@openib.org
Subject: [openib-general] [PATCH] ipoib_ib.c - wrong pointer memory
accessbug
Hello,
Trying to understand the problem with "RUNNING" network interface
status when a cable is disconnected, I found an error in
ipoib_ib_dev_flush() function.
Although this patch doesn't fix the "RUNNING" status problem yet, it
fixes a serious wrong pointer memory access bug.
Signed-off-by: Leonid Arsh <[EMAIL PROTECTED]>
Index: infiniband/ulp/ipoib/ipoib_ib.c
===
--- infiniband/ulp/ipoib/ipoib_ib.c (revision 8499)
+++ infiniband/ulp/ipoib/ipoib_ib.c (working copy)
@@ -603,7 +603,7 @@
/* Flush any child interfaces too */
list_for_each_entry(cpriv, &priv->child_intfs, list)
- ipoib_ib_dev_flush(&cpriv->dev);
+ ipoib_ib_dev_flush(cpriv->dev);
mutex_unlock(&priv->vlan_mutex);
}
___
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] [PATCH]
Hello,
the patch fixes a problem with the network interface "RUNNING"
status.
The problem was that the status stayed "RUNNING" with the cable
disconnected,
both for ib0 network interface and a vlan (partition) child device
(like ib0.f1f1)
The patch causes the network interface device to be flushed when
cable is disconnected.
This patch requires also my previous patch to be applied (ipoib_ib.c
- wrong pointer memory access bug fix), see below.
Signed-off-by: Leonid Arsh <[EMAIL PROTECTED]>
Index: infiniband/ulp/ipoib/ipoib_verbs.c
===
--- infiniband/ulp/ipoib/ipoib_verbs.c (revision 8499)
+++ infiniband/ulp/ipoib/ipoib_verbs.c (working copy)
@@ -251,10 +251,11 @@
struct ipoib_dev_priv *priv =
container_of(handler, struct ipoib_dev_priv,
event_handler);
- if (record->event == IB_EVENT_PORT_ACTIVE ||
+if (record->event == IB_EVENT_PORT_ERR||
+record->event == IB_EVENT_PORT_ACTIVE ||
record->event == IB_EVENT_LID_CHANGE ||
record->event == IB_EVENT_SM_CHANGE) {
- ipoib_dbg(priv, "Port active event\n");
+ ipoib_dbg(priv, "Port state change event\n");
schedule_work(&priv->flush_task);
}
}
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Leonid Arsh
Sent: Sunday, March 19, 2006 4:03 PM
To: openib-general@openib.org
Subject: [openib-general] [PATCH] ipoib_ib.c - wrong pointer memory
accessbug
Hello,
Trying to understand the problem with "RUNNING" network interface
status when a cable is disconnected, I found an error in
ipoib_ib_dev_flush() function.
Although this patch doesn't fix the "RUNNING" status problem yet, it
fixes a serious wrong pointer memory access bug.
Signed-off-by: Leonid Arsh <[EMAIL PROTECTED]>
Index: infiniband/ulp/ipoib/ipoib_ib.c
===
--- infiniband/ulp/ipoib/ipoib_ib.c (revision 8499)
+++ infiniband/ulp/ipoib/ipoib_ib.c (working copy)
@@ -603,7 +603,7 @@
/* Flush any child interfaces too */
list_for_each_entry(cpriv, &priv->child_intfs, list)
- ipoib_ib_dev_flush(&cpriv->dev);
+ ipoib_ib_dev_flush(cpriv->dev);
mutex_unlock(&priv->vlan_mutex);
}
___
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] Aide Orphélin !!
Pablo Adjas ABIDJAN COTE D'IVOIRE Cher , Je suis Monsieur Pablo Adjas le seul fils de 'ancien chef PAUL Adjas de la SIERA LEONNE. La source de votre contact me donne le courage et la confiance de me confier à vous. Je vous écris avec une confidence absolue premièrement pour demander votre assistance pour transférer notre liquidité de 25 000 000 de dollar qui actuellement se trouve dans le coffre fort d'une compagnie de sécurité ici en Abidjan dans votre compte personnel jusqu'à notre arrivée dans votre pays. SOURCEDE L'ARGENT Mon défunt père, chef PAUL Adjas, le patron des extracteur d'or et de diamant en Sierra Leone (S.L.M.C) Freetown. Concernant mon père, cet argent est le résultat de l'or et le diamant extraient des mines Sierra Léonaise avant le début de la guerre civil entre les forces rebelles et les forces de maintien de la paix de l'ECOMOG qui a détruit mon pays après le coup de force qui a chassé du pouvoir,le président démocratiquement élu AHMED TEJAN KABBAH. Mon père avait déjà mis en place un plan pour nous évacuer (ma famille) ma mère, ma petite sour et moi même sur Abidjan en Cote d'ivoire avec nos effets personnels et la boite contenant l'argent par le biais des forces d'évacuation des nations unies. Mon père nous a demandé de déposer la boite dans une compagnie privée de sécurité jusqu'à ce qu'il nous rejoigne après la guerre. Pendant la guerre dans mon pays, et avec pour conséquence le pillage des propriétés publiques et du gouvernement par les forces rebelles, la coopération des mines sierra léonaise étaient l'une des cibles pillées et détruites. Mon père et plusieurs autres haut fonctionnaires ont été attaqués et tués par les rebelles en novembre 2000 pour leur relation avec le gouvernement civil d'AHMED TEJAN KABBAH. Suite à la mort de mon père, et avec les nouvelles de mon oncle à propos de son accident d'avion en janvier, nos espoirs de survie étaient complètement noyés. Cette mort prématurée de mon père et de mon oncle a provoqué un arrêt cardiaque chez ma mère et d'autres complications qui ont provoqués sa mort plus tard dans un hôpital et après on a eu à dépenser une importante somme d'argent pour elle. Actuellement ma sœur et moi même sommes seuls dans ce pays étrange, souffrant et sans aucun soutien . sans aucune relations, nous sommes actuellement comme des réfugiés et des orphelins. Notre seul espoir actuellement est en vous et en la boite qu'on déposé dans la compagnie de sécurité. A cet effet, je sollicite humblement votre assistance dans le sens suivant : 1- m'aider à faire sortir la boite de la compagnie de sécurité comme CO- bénéficiaire pour transférer cet argent en votre nom dans votre propre compte dans votre pays pour un investissement lucratif .avec vous comme principal acteur. 2- Le plus important c'est que la compagnie de sécurité ne connaît pas le contenu exact de la boite parce qu'on l'a déclaré comme richesses familiales. 3- Tous les documents relatifs au dépôts sont dans mon coffre a la maison. 4- Pour votre assistance, je vous céderai 20% de cet argent pour vos efforts et votre assistance. 5- Enfin je vous prie de garder cette transaction strictement confidentiel. Merci et que Dieu vous bénisse pour votre assistance à notre égard. Très sincèrement Pablo Adjas contact me [EMAIL PROTECTED] Web Sitesi Sahibi Olmanın Tam Zamanı: Mynet Proservis Basit Paket: 25 YTL / Yıl Web Sitesi Sahibi Olmanın Tam Zamanı: Mynet Proservis Basit Paket: 25 YTL / Yıl ___ 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] ipoib_ib.c - wrong pointer memory access bug
Hello, Trying to understand the problem with "RUNNING" network interface status when a cable is disconnected, I found an error in ipoib_ib_dev_flush() function. Although this patch doesn't fix the "RUNNING" status problem yet, it fixes a serious wrong pointer memory access bug. Signed-off-by: Leonid Arsh <[EMAIL PROTECTED]> Index: infiniband/ulp/ipoib/ipoib_ib.c === --- infiniband/ulp/ipoib/ipoib_ib.c (revision 8499) +++ infiniband/ulp/ipoib/ipoib_ib.c (working copy) @@ -603,7 +603,7 @@ /* Flush any child interfaces too */ list_for_each_entry(cpriv, &priv->child_intfs, list) - ipoib_ib_dev_flush(&cpriv->dev); + ipoib_ib_dev_flush(cpriv->dev); mutex_unlock(&priv->vlan_mutex); } ___ 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 - fix sm_key check in osm_sa_mcmember_record.c
Hi Hal,
We noticed that when sending MCMemberRecord query, there is a check if
the requestor is trusted (if not then PortGid, join_state and
proxy_join are returned as zero). But, currently the trusted check is
done on the sm_key in the response mad, which is set to zero
(according to C15-0.1.5), instead of checking the sm_key in the
request mad.
The following patch fixes this issue, and also removes a comment out
of place.
Thanks,
Yael
Signed-off-by: Yael Kalka <[EMAIL PROTECTED]>
Index: opensm/osm_sa_mcmember_record.c
===
--- opensm/osm_sa_mcmember_record.c (revision 5882)
+++ opensm/osm_sa_mcmember_record.c (working copy)
@@ -1952,13 +1952,6 @@ __osm_sa_mcm_by_comp_mask_cb(
if (! osm_physp_has_pkey( p_rcv->p_log, p_mgrp->mcmember_rec.pkey,
p_req_physp ))
goto Exit;
- /*
- * o15-0.1.16: If SA supports UD multicast, then if it receives a
- * SubnAdmGetTable() of MCMemberRecord with the MCMemberRecord:PortGID
- * wildcarded, then SA shall return a single MCMemberRecord for each
- * multicast group that matches the query operation.
- */
-
/* so did we got the PortGUID mask */
if (IB_MCR_COMPMASK_PORT_GID & comp_mask)
{
@@ -2219,7 +2212,7 @@ osm_mcmr_query_mgrp(IN osm_mcmr_recv_t*
the mad is valid. Meaning - is either zero or equal to the local
sm_key.
*/
- if (p_resp_sa_mad->sm_key == 0)
+ if (p_rcvd_mad->sm_key == 0)
trusted_req = FALSE;
for ( i = 0; i < pre_trim_num_rec; i++ )
___
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] modify QP from reset->reset or reset->error fails in mthca
According to the IB spec: QP state can be modified from any state to reset QP state can be modified from any state to error Modify QP from reset to reset or from reset to error fail in Mellanox HCAs. Here if the error message from the /var/log/messages: + kernel: ib_mthca :05:00.0: modify QP 0->0 returned status 0a. i guess that the problem is that the HCA don't know that this QP is in use until the QP is in the init state. roland: how do you think the mthca driver should behave in those scenarios? Dotan ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [Bug 22] IBED RC2 Installation fails
http://openib.org/bugzilla/show_bug.cgi?id=22 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2006-03-19 02:05 --- Please attach /tmp/IBED.*.log files after failure. Note: openibd is a part of kernel-ib RPM. Check that ipoib and kernel-ib packages selected while installing IBED. --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ 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] mthca - query qp
On Sunday 19 March 2006 11:31, Michael S. Tsirkin wrote: > I think even QP state is already reported to user by means of completion > with error and asynchronous event (and I think same can be said for path > migration state). > The same CANNOT be said for static rate. - Jack ___ 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] mthca - query qp
Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > Subject: Re: [PATCH] mthca - query qp > > OK, I at least applied the error flow part of this patch, since that's > clearly something we want. > > I need to think about how to handle the other attributes. Probably > anything that just copies values from the struct ib_qp passed in to > the function should at least be in the generic ib_query_qp function, > since there's no good reason for every low-level driver to duplicate it. > > However I'm wondering whether we even have the right interface for > query QP at all. I think even QP state is already reported to user by means of completion with error and asynchronous event (and I think same can be said for path migration state). I conclude that ib_query_qp is mostly useful for debug. However, speaking from experience, things you need the most during debug: number of end to end credits (debug performance problems), work requests executed (debug data/debug problems) are actually not part of query qp verb. > The only thing that the consumer couldn't have saved > off for themselves is the QP state, Formally speaking, we also have the send/receive PSN which the users couldn't have saved off for themselves. > so maybe the right interface is > just an ib_query_qp_state() function that gives back the QP's current state. I don't thinj anyone actually uses query qp, so we probably even can kill it off altogether. If the point is to make debugging possible/easier, what I think we are missing is an interface (in debugfs?) that given QP number, will get us the QP state in hardware format, with all the detail. This could be implemented as a separate module. -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies ___ 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] mthca - query qp
On Thu, 2006-03-16 at 14:38 -0800, Roland Dreier wrote: > I need to think about how to handle the other attributes. Probably > anything that just copies values from the struct ib_qp passed in to > the function should at least be in the generic ib_query_qp function, > since there's no good reason for every low-level driver to duplicate it. > Probably this is how it should be done > However I'm wondering whether we even have the right interface for > query QP at all. The only thing that the consumer couldn't have saved > off for themselves is the QP state, so maybe the right interface is > just an ib_query_qp_state() function that gives back the QP's current state. > I think we should pass to the consumer all the info in a centralized way through a standard query_qp verb. ___ 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: Re: [PATCH] mthca - query qp
Quoting r. Jack Morgenstein <[EMAIL PROTECTED]>: > Subject: Re: Re: [PATCH] mthca - query qp > > On Friday 17 March 2006 00:38, Roland Dreier wrote: > > > > However I'm wondering whether we even have the right interface for > > query QP at all. The only thing that the consumer couldn't have saved > > off for themselves is the QP state, so maybe the right interface is > > just an ib_query_qp_state() function that gives back the QP's current > > state. > > > > The static rate is another value that may be changed by the HCA. Furthermore, > the HCA may set a static rate lower than that requested by the caller. The > only way to know the actual, operative static rate is via ib_query_qp. I don't think that's the intended result of the ib_query_qp. The spec says: Primary Address vector, for RC & UC transports only, containing: . Maximum Static Rate. -- Michael S. Tsirkin Staff Engineer, Mellanox Technologies ___ 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] mthca - query qp
> > However I'm wondering whether we even have the right interface for > > query QP at all. The only thing that the consumer couldn't > have saved > > off for themselves is the QP state, so maybe the right interface is > > just an ib_query_qp_state() function that gives back the > QP's current > > state. > > > > The static rate is another value that may be changed by the > HCA. Furthermore, the HCA may set a static rate lower than > that requested by the caller. The > only way to know the actual, operative static rate is via ib_query_qp. > > Jack The HCA changes the path_mig_state, so it is also needed. Dotan ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Re: [PATCH] mthca - query qp
On Friday 17 March 2006 00:38, Roland Dreier wrote: > > However I'm wondering whether we even have the right interface for > query QP at all. The only thing that the consumer couldn't have saved > off for themselves is the QP state, so maybe the right interface is > just an ib_query_qp_state() function that gives back the QP's current > state. > The static rate is another value that may be changed by the HCA. Furthermore, the HCA may set a static rate lower than that requested by the caller. The only way to know the actual, operative static rate is via ib_query_qp. Jack ___ 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 - recognize port change not as duplicated guids
Hi Hal,
This is a patch to solve the issue of port move during heavy sweep
being recognized as duplicated guids.
If the SM sees what seems to be duplicated guids, but it also received
an indication for immediatly forcing another heavy sweep (for example,
as a result of receiving trap 128) - then it shouldn't issue a
duplicated guids error (and exit), but just ignore and continue.
This means that only if the SM recognizes such a duplication in a
stable subnet it'll issue the error and exit.
Thanks,
Yael
Signed-off-by: Yael Kalka <[EMAIL PROTECTED]>
Index: opensm/osm_node_info_rcv.c
===
--- opensm/osm_node_info_rcv.c (revision 5882)
+++ opensm/osm_node_info_rcv.c (working copy)
@@ -129,12 +129,17 @@ __osm_ni_rcv_set_links(
}
else
{
- if( osm_node_has_any_link( p_node, port_num ) )
+ if( osm_node_has_any_link( p_node, port_num ) &&
+ p_rcv->p_subn->force_immediate_heavy_sweep == FALSE )
{
/*
Uh oh...
This means that we found 2 nodes with the same guid,
or a 12x link with lane reversal that is not configured
correctly.
+ If the force_immediate_heavy_sweep == TRUE, then this might be a
case
+ of port being moved (causing trap 128), and thus re-discovered.
+ In this case - just continue. There will be another heavy sweep
+ immediatly after, when the subnet is stable again.
*/
char line[BUF_SIZE];
char dr_new_path[BUF_SIZE];
___
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
