[openib-general] Re: [PATCH] ipoib: count dropped multicast patckets
Quoting r. Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: Re: [PATCH] ipoib: count dropped multicast patckets
Quoting r. Michael S. Tsirkin [EMAIL PROTECTED]:
Subject: [PATCH] ipoib: count dropped multicast patckets
Count dropped multicast packets.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
And here's a patch that actually works :).
And here's a verson that really actually works :).
Count dropped multicast packets.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index: openib/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
===
--- openib.orig/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 2006-01-08
22:42:58.0 +0200
+++ openib/drivers/infiniband/ulp/ipoib/ipoib_multicast.c 2006-01-10
10:17:41.0 +0200
@@ -122,8 +122,12 @@ static void ipoib_mcast_free(struct ipoi
if (mcast-ah)
ipoib_put_ah(mcast-ah);
- while (!skb_queue_empty(mcast-pkt_queue))
+ while (!skb_queue_empty(mcast-pkt_queue)) {
+ spin_lock_irqsave(priv-tx_lock, flags);
+ ++priv-stats.tx_dropped;
+ spin_unlock_irqrestore(priv-tx_lock, flags);
dev_kfree_skb_any(skb_dequeue(mcast-pkt_queue));
+ }
kfree(mcast);
}
@@ -299,6 +303,8 @@ ipoib_mcast_sendonly_join_complete(int s
{
struct ipoib_mcast *mcast = mcast_ptr;
struct net_device *dev = mcast-dev;
+ struct ipoib_dev_priv *priv = netdev_priv(dev);
+ unsigned long flags;
if (!status)
ipoib_mcast_join_finish(mcast, mcmember);
@@ -309,8 +315,12 @@ ipoib_mcast_sendonly_join_complete(int s
IPOIB_GID_ARG(mcast-mcmember.mgid),
status);
/* Flush out any queued packets */
- while (!skb_queue_empty(mcast-pkt_queue))
+ while (!skb_queue_empty(mcast-pkt_queue)) {
+ spin_lock_irqsave(priv-tx_lock, flags);
+ ++priv-stats.tx_dropped;
+ spin_unlock_irqrestore(priv-tx_lock, flags);
dev_kfree_skb_any(skb_dequeue(mcast-pkt_queue));
+ }
/* Clear the busy flag so we try again */
clear_bit(IPOIB_MCAST_FLAG_BUSY, mcast-flags);
@@ -686,6 +696,7 @@ void ipoib_mcast_send(struct net_device
if (!mcast) {
ipoib_warn(priv, unable to allocate memory for
multicast structure\n);
+ ++priv-stats.tx_dropped;
dev_kfree_skb_any(skb);
goto out;
}
@@ -699,8 +710,10 @@ void ipoib_mcast_send(struct net_device
if (!mcast-ah) {
if (skb_queue_len(mcast-pkt_queue) IPOIB_MAX_MCAST_QUEUE)
skb_queue_tail(mcast-pkt_queue, skb);
- else
+ else {
+ ++priv-stats.tx_dropped;
dev_kfree_skb_any(skb);
+ }
if (mcast-query)
ipoib_dbg_mcast(priv, no address vector,
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] mthca: eq doorbell coalescing + prevent even queque overrun
Quoting Or Gerlitz [EMAIL PROTECTED]: I am seeing EQ overruns in SDP stress tests: if CQ completion handler arms a CQ, this could generate more EQEs, so that EQ will never get empty and consumer index will never get updated. There's something re CQ arming which i'd like to bring up. I see that the mad, ipoib and srp CQ handlers work as follows: first - arm the CQ, second - poll the CQ in a loop till it is emtpy. What is the reasoning behind this approach? Thats what IB spec says. does it means that completions occurring while the handler is running cause interrupts which could be saved? Handlers are running out of the interrupt context, so an interrupt would have to be generated in the window while CQ is being armed. Profiling I've done on ipoib shows that this is quite unlikely. is there any problem with first empty-ing the CQ and only then arming it? The latter approach is taken by iser code. As far as i understand it can not cause the ib consumer to miss interrupts, am i wrong? On Mellanox hardware you wont miss interrupts in this case if you always poll CQ and then arm it as a result of an interrupt. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] osm: Add TODO light sweep through LID
Hi Hal One TODO we have found is that in order to guarantee traps can be delievered to the SM - it would have been nice if light sweep will use LID routing and not direct routing. This way the LFTs could be verified or else a heavy sweep conducted. This patch only changes the TODO file so we do not forget... (I also fixed a typo: issuesi - issues) Eitan Signed-off-by: Eitan Zahavi [EMAIL PROTECTED] Index: doc/todo === --- doc/todo(revision 4876) +++ doc/todo(working copy) @@ -1,4 +1,4 @@ -# OSM List of todo, open issuesi, and futures: +# OSM List of todo, open issues, and futures: 1 041228 - Handle local events (local lid change, port state change, etc.) 2 041228 - Port fail over to next port upon request @@ -12,6 +12,9 @@ 7 051207 - Add dumping of SA records to supported SA records which do not currently do this (SMInfo, VLArb, SLVL, PKey, LFT) +8 060109 - Use LID routing for light sweep to guarantee trap + delivery path to the SM. + Futures ___ 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] osm: Add TODO light sweep through LID
On Tue, 2006-01-10 at 06:08, Eitan Zahavi wrote: Hi Hal One TODO we have found is that in order to guarantee traps can be delievered to the SM - it would have been nice if light sweep will use LID routing and not direct routing. This way the LFTs could be verified or else a heavy sweep conducted. This patch only changes the TODO file so we do not forget... Thanks. Applied. (I also fixed a typo: issuesi - issues) Eitan ___ 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] bad free() in libibumad
On Mon, 2006-01-09 at 18:40, Hal Rosenstock wrote: Hi Ralph, On Mon, 2006-01-09 at 16:46, Ralph Campbell wrote: Here is a patch to fix the following backtrace: (gdb) bt #0 0x00355642f280 in raise () from /lib64/libc.so.6 #1 0x003556430750 in abort () from /lib64/libc.so.6 #2 0x003556464a7f in __libc_message () from /lib64/libc.so.6 #3 0x00355646a71e in _int_free () from /lib64/libc.so.6 #4 0x00355646ac4e in free () from /lib64/libc.so.6 #5 0x003d98f01568 in get_port (ca_name=Variable ca_name is not available.) at src/umad.c:191 #6 0x003d98f025f5 in umad_get_port ( ca_name=0x7f9d3e70 /sys/class/infiniband/mthca0/ports, portnum=1, port=0x7f9d44f0) at src/umad.c:617 #7 0x003d9910249a in osm_vendor_get_all_port_attr (p_vend=0x658220, p_attr_array=0x7f9d4580, p_num_ports=0x7f9d6a08) at osm_vendor_ibumad.c:624 #8 0x004044e9 in get_port_guid (p_osm=Variable p_osm is not available. ) at main.c:274 Signed-off-by: Ralph Campbell [EMAIL PROTECTED] Index: libibumad/src/umad.c === --- libibumad/src/umad.c(revision 4808) +++ libibumad/src/umad.c(working copy) @@ -188,7 +188,6 @@ return 0; clean: - free(port); return -EIO; } I think there is more to it than this but thanks for pointing this out. Thanks. I applied your better version of this patch. -- 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] [PATCH] mthca: eq doorbell coalescing + prevent even queque overrun
Michael I am seeing EQ overruns in SDP stress tests: if CQ completion Michael handler arms a CQ, this could generate more EQEs, Or I see that the mad, ipoib and srp CQ handlers work as follows: first - Or arm the CQ, second - poll the CQ in a loop till it is emtpy. Or does it means that completions occurring while the handler is running cause Or interrupts which could be saved? Michael Handlers are running out of the interrupt context, so Michael an interrupt would have to be generated in the window while Michael CQ is being armed. Profiling I've done on ipoib shows that Michael this is quite unlikely. Sorry, i dont follow. If you arm the CQ when there is one WC in it and then start polling, and during your polling a second WC is generated by the HCA, wouldn't an interrupt related to the 2nd completion be generated - why the case you are mentioning is the arming window? ___ 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] mthca: eq doorbell coalescing + prevent even queque overrun
Quoting Or Gerlitz [EMAIL PROTECTED]: Sorry, i dont follow. If you arm the CQ when there is one WC in it and then start polling, and during your polling a second WC is generated by the HCA, wouldn't an interrupt related to the 2nd completion be generated - why the case you are mentioning is the arming window? I'm polling in the interrupt handler, so interrupts from the same IRQ are disabled. No? What am I missing? -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] mthca: eq doorbell coalescing + prevent even queque overrun
Michael S. Tsirkin wrote: Sorry, i dont follow. If you arm the CQ when there is one WC in it and then start polling, and during your polling a second WC is generated by the HCA, wouldn't an interrupt related to the 2nd completion be generated - why the case you are mentioning is the arming window? I'm polling in the interrupt handler, so interrupts from the same IRQ are disabled. No? What am I missing? OK, i might be somehow newbee around this (working in hard irq context) land. Does disabling the HCA IRQ means no interrupt would be generated later when the handler is done? i was think it would be just deffered. iSER hard irq CQ handler just does a context jump to soft irq handler (tasklet) so the rule you mention does not apply to it. ___ 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] mthca: eq doorbell coalescing + prevent even queque overrun
Quoting Or Gerlitz [EMAIL PROTECTED]: Subject: Re: [openib-general] [PATCH] mthca: eq doorbell coalescing + prevent even queque overrun Michael S. Tsirkin wrote: Sorry, i dont follow. If you arm the CQ when there is one WC in it and then start polling, and during your polling a second WC is generated by the HCA, wouldn't an interrupt related to the 2nd completion be generated - why the case you are mentioning is the arming window? I'm polling in the interrupt handler, so interrupts from the same IRQ are disabled. No? What am I missing? OK, i might be somehow newbee around this (working in hard irq context) land. Does disabling the HCA IRQ means no interrupt would be generated later when the handler is done? i was think it would be just deffered. AFAIK, you get another interrupt only if hardware continues asserting the interrupt. iSER hard irq CQ handler just does a context jump to soft irq handler (tasklet) so the rule you mention does not apply to it. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH applied] perftest: fix device lookup by name
The following is already applied on trunk.
---
Fix device lookup by name.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index: openib/src/userspace/perftest/rdma_bw.c
===
--- openib.orig/src/userspace/perftest/rdma_bw.c2006-01-10
15:02:10.0 +0200
+++ openib/src/userspace/perftest/rdma_bw.c 2006-01-10 15:15:49.0
+0200
@@ -594,7 +594,7 @@ int main(int argc, char *argv[])
return 1;
}
} else {
- for (ib_dev = *dev_list; ib_dev; ++dev_list)
+ for (; (ib_dev = *dev_list); ++dev_list)
if (!strcmp(ibv_get_device_name(ib_dev), ib_devname))
break;
if (!ib_dev) {
Index: openib/src/userspace/perftest/read_bw.c
===
--- openib.orig/src/userspace/perftest/read_bw.c2006-01-10
15:02:10.0 +0200
+++ openib/src/userspace/perftest/read_bw.c 2006-01-10 15:17:02.0
+0200
@@ -688,7 +688,7 @@ int main(int argc, char *argv[])
return 1;
}
} else {
- for (ib_dev = *dev_list; ib_dev; ++dev_list)
+ for (; (ib_dev = *dev_list); ++dev_list)
if (!strcmp(ibv_get_device_name(ib_dev), ib_devname))
break;
if (!ib_dev) {
Index: openib/src/userspace/perftest/read_lat.c
===
--- openib.orig/src/userspace/perftest/read_lat.c 2006-01-10
15:02:10.0 +0200
+++ openib/src/userspace/perftest/read_lat.c2006-01-10 15:16:16.0
+0200
@@ -124,7 +124,7 @@ static struct ibv_device *pp_find_dev(co
if (!ib_dev)
fprintf(stderr, No IB devices found\n);
} else {
- for (ib_dev = *dev_list; ib_dev; ++dev_list)
+ for (; (ib_dev = *dev_list); ++dev_list)
if (!strcmp(ibv_get_device_name(ib_dev), ib_devname))
break;
if (!ib_dev)
Index: openib/src/userspace/perftest/send_bw.c
===
--- openib.orig/src/userspace/perftest/send_bw.c2006-01-10
15:02:10.0 +0200
+++ openib/src/userspace/perftest/send_bw.c 2006-01-10 15:16:21.0
+0200
@@ -965,7 +965,7 @@ int main(int argc, char *argv[])
return 1;
}
} else {
- for (ib_dev = *dev_list; ib_dev; ++dev_list)
+ for (; (ib_dev = *dev_list); ++dev_list)
if (!strcmp(ibv_get_device_name(ib_dev), ib_devname))
break;
if (!ib_dev) {
Index: openib/src/userspace/perftest/send_lat.c
===
--- openib.orig/src/userspace/perftest/send_lat.c 2006-01-10
15:02:10.0 +0200
+++ openib/src/userspace/perftest/send_lat.c2006-01-10 15:16:30.0
+0200
@@ -132,7 +132,7 @@ static struct ibv_device *pp_find_dev(co
if (!ib_dev)
fprintf(stderr, No IB devices found\n);
} else {
- for (ib_dev = *dev_list; ib_dev; ++dev_list)
+ for (; (ib_dev = *dev_list); ++dev_list)
if (!strcmp(ibv_get_device_name(ib_dev), ib_devname))
break;
if (!ib_dev)
Index: openib/src/userspace/perftest/write_bw.c
===
--- openib.orig/src/userspace/perftest/write_bw.c 2006-01-10
15:02:10.0 +0200
+++ openib/src/userspace/perftest/write_bw.c2006-01-10 15:17:02.0
+0200
@@ -740,7 +740,7 @@ int main(int argc, char *argv[])
return 1;
}
} else {
- for (ib_dev = *dev_list; ib_dev; ++dev_list)
+ for (; (ib_dev = *dev_list); ++dev_list)
if (!strcmp(ibv_get_device_name(ib_dev), ib_devname))
break;
if (!ib_dev) {
Index: openib/src/userspace/perftest/write_lat.c
===
--- openib.orig/src/userspace/perftest/write_lat.c 2006-01-10
15:02:10.0 +0200
+++ openib/src/userspace/perftest/write_lat.c 2006-01-10 15:17:02.0
+0200
@@ -122,7 +122,7 @@ static struct ibv_device *pp_find_dev(co
if (!ib_dev)
fprintf(stderr, No IB devices found\n);
} else {
- for (ib_dev = *dev_list; ib_dev; ++dev_list)
+ for (; (ib_dev = *dev_list); ++dev_list)
if (!strcmp(ibv_get_device_name(ib_dev), ib_devname))
[openib-general] Re: We are ready with a Gen2 version of MVAPICH2
Hi Woody, DK wrote, We plan to upload a stripped down version of this new release to the OpenIB SVN at the following location: https://openib.org/svn/gen2/trunk/src/userspace/mpi/ Sounds good to me. Thanks a lot for your feedback. We are working on putting the new version at the above location. Thanks, DK 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] Error when loading ib_umad
I am using the linux kernel 2.6.14 and the latest IB driver in OpenIB.
Is this caused by SMP?
Any suggestion is appreciated!
Here are the error details:
dell-162:~ # lsmod | grep ib
ib_mthca 120096 0
ib_mad 38820 1 ib_mthca
ib_core 51200 2 ib_mthca,ib_mad
libata 54032 1 ata_piix
dell-162:~ # modprobe ib_umad
Killed
dell-162:~ #
Message from [EMAIL PROTECTED] at Wed Jan 11 06:08:42 2006 ...
dell-162 kernel: Oops: [1] SMP
Message from [EMAIL PROTECTED] at Wed Jan 11 06:08:42 2006 ...
dell-162 kernel: CR2: 0e70010c
dell-162:~# tail /var/log/messages
Jan 11 05:25:13 dell-162 kernel: Unable to handle kernel paging request at 0e70010c RIP:
Jan 11 05:25:13 dell-162 kernel: 80215e41{kref_get+1}
Jan 11 05:25:13 dell-162 kernel: PGD 1316a067 PUD 1f81e067 PMD 0
Jan 11 05:25:13 dell-162 kernel: Oops: [1] SMP
Jan 11 05:25:13 dell-162 kernel: CPU 1
Jan 11 05:25:13 dell-162 kernel: Modules linked in: ib_umad evdev
joydev sg sr_mod floppy thermal processor fan button battery ac
ib_mthca ib_mad ib_core ehci_hcd uhci_hcd ipv6 i2c_i801 i2c_core
hw_random e1000 usbcore dm_mod ext3 jbd ata_piix libata
Jan 11 05:25:13 dell-162 kernel: Pid: 12113, comm: modprobe Not tainted 2.6.14 #1
Jan 11 05:25:13 dell-162 kernel: RIP: 0010:[80215e41] 80215e41{kref_get+1}
Jan 11 05:25:13 dell-162 kernel: RSP: :81001ad53b68 EFLAGS: 00010206
Jan 11 05:25:13 dell-162 kernel: RAX: 810010503aa0 RBX: 0e7000f0 RCX:
Jan 11 05:25:13 dell-162 kernel: RDX: 810010503aa0 RSI: 8039d0db RDI: 0e70010c
Jan 11 05:25:13 dell-162 kernel: RBP: 8039d0d4 R08: 8100017f1d50 R09:
Jan 11 05:25:13 dell-162 kernel: R10: 810013f69300 R11: 0048 R12: 81000bcbc318
Jan 11 05:25:13 dell-162 kernel: R13: fff4 R14: 810013f69300 R15: 0e7000f0
Jan 11 05:25:13 dell-162 kernel: FS: 2ade36e0() GS:804eb880() knlGS:
Jan 11 05:25:13 dell-162 kernel: CS: 0010 DS: ES: CR0: 8005003b
Jan 11 05:25:13 dell-162 kernel: CR2: 0e70010c CR3: 1c6e6000 CR4: 06e0
Jan 11 05:25:13 dell-162 kernel: Process modprobe (pid: 12113, threadinfo 81001ad52000, task 81001aaf5040)
Jan 11 05:25:13 dell-162 kernel: Stack: 0e7000f0 80214f62 810010503ac0 801c5a11
Jan 11 05:25:13 dell-162
kernel: 81001c49c190
81001c49c180 81001c49c180 8100193f1200
Jan 11 05:25:13 dell-162 kernel: 8100193f1200
Jan 11 05:25:13 dell-162 kernel: Call
Trace:80214f62{kobject_get+18}
801c5a11{sysfs_create_link+193}
Jan 11 05:25:13 dell-162
kernel:
8027e524{class_device_add+436}
8027e754{class_device_create+276}
Jan 11 05:25:13 dell-162
kernel:
80199ba8{d_instantiate+136}
8019a8f1{dput+33}
Jan 11 05:25:13 dell-162
kernel:
801c5155{create_dir+405}
8027f396{kobj_map+102}
Jan 11 05:25:13 dell-162
kernel:
8018a590{exact_lock+0}
80189fe0{exact_match+0}
Jan 11 05:25:13 dell-162
kernel:
88189a20{:ib_umad:ib_umad_add_one+432}
881095cc{:ib_core:ib_register_client+124}
Jan 11 05:25:13 dell-162
kernel:
880f9090{:ib_umad:ib_umad_init+144}
80152ae9{sys_init_module+6553}
Jan 11 05:25:13 dell-162
kernel:
880f9000{:ib_umad:ib_umad_init+0}
80217751{__up_write+49}
Jan 11 05:25:13 dell-162 kernel: 8010dc5e{system_call+126}
Jan 11 05:25:13 dell-162 kernel:
Jan 11 05:25:13 dell-162 kernel: Code: 8b 07 48 89 fb 85 c0 75 26 b9 20 00 00 00 48 c7 c2 bb c9 39
Jan 11 05:25:13 dell-162 kernel: RIP 80215e41{kref_get+1} RSP 81001ad53b68
Jan 11 05:25:13 dell-162 kernel: CR2: 0e70010c
Jan 11 05:34:19 dell-162 sshd[12947]: Accepted keyboard-interactive/pam for root from :::192.168.1.61 port 3821 ssh2
-- Ian Jiang[EMAIL PROTECTED]Laboratory of Spatial Information Technology
Division of System ArchitectureInstitute of Computing Technology
Chinese Academy of Sciences
___
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] osm: support for trivial PKey manager
Hi Hal,
Removing redundant error in the log.
If the physical port is not valid, nothing is needed to be the done here.
Thanks
Ofer G.
Signed-off-by: Ofer Gigi [EMAIL PROTECTED]
Index: osm_pkey_mgr.c
===
--- osm_pkey_mgr.c (revision 4867)
+++ osm_pkey_mgr.c (working copy)
@@ -171,7 +171,7 @@ __osm_pkey_mgr_process_physical_port(
{
osm_log( p_mgr-p_log, OSM_LOG_ERROR,
__osm_pkey_mgr_process_physical_port: ERR 0501:
- No empty block entry was found to insert IB_DEFAULT_PKEY
for node
+ No empty entry was found to insert IB_DEFAULT_PKEY for node
0x%016 PRIx64 and port %u\n,
cl_ntoh64( osm_node_get_node_guid( p_node ) ), port_num );
}
@@ -275,15 +275,6 @@ osm_pkey_mgr_process(
result = OSM_SIGNAL_DONE_PENDING;
}
}
- else
- {
-osm_log( p_mgr-p_log, OSM_LOG_ERROR,
- osm_pkey_mgr_process: ERR 0502:
- Invalid physical port for node 0x%016 PRIx64
- port %u\n,
- cl_ntoh64( osm_node_get_node_guid( p_node ) ),
- port_num );
- }
}
}
___
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] Error when loading ib_umad
Are you ignoring compile warnings about class_device_create()? Since 2.6.15 is out, the OpenIB svn does not support 2.6.14 any more, so you may run into problems like this. You will probably need to restore the compatibility hack removed in r4784 by adding something like #include linux/version.h #if LINUX_VERSION_CODE KERNEL_VERSION(2,6,15) #define class_device_create(cls, parent, devt, device, fmt, arg...) \ class_device_create(cls, devt, device, fmt, ## arg) #endif to rdma/ib_verbs.h. - 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: merge rdma_cm and ib_addr upstream
Or Just to make sure, would the __be64 node_guid field of struct
Or ib_device have the exact semantics of the __be64 node_guid
Or field of struct ib_device_attr ? iser uses it from the attr
Or struct and we can sure move to use it from the device struct.
Yes, that's right. Something like the patch below (compile tested
only) is what is required.
- R.
---
Move iSER from getting node_guid via ib_query_device() to using the
node_guid field in struct ib_device, since ib_query_device() will stop
returning the node_guid soon.
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
--- infiniband/ulp/iser/iser_verbs.c(revision 4866)
+++ infiniband/ulp/iser/iser_verbs.c(working copy)
@@ -1,6 +1,6 @@
/*
* Copyright (c) 2004, 2005 Voltaire, Inc. All rights reserved.
- * Copyright (c) 2005 Cisco Systems. All rights reserved.
+ * Copyright (c) 2005, 2006 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
@@ -73,8 +73,6 @@ int iser_create_adaptor_ib_res(struct is
struct ib_device *device = p_iser_adaptor-device;
struct ib_fmr_pool_param params;
- ib_query_device(device, (p_iser_adaptor-device_attr));
-
strcpy(p_iser_adaptor-name, device-name);
iser_dbg(setting device name %s as adatptor name\n, device-name);
@@ -234,23 +232,16 @@ int iser_free_qp_and_id(struct iser_conn
struct iser_adaptor *iser_adaptor_find_by_device(struct rdma_cm_id *cma_id)
{
- struct ib_device_attr *p_device_attr = NULL;
struct list_head *p_list;
struct iser_adaptor *p_adaptor = NULL;
- p_device_attr = kmalloc(sizeof *p_device_attr, GFP_KERNEL);
- if(p_device_attr == NULL)
- goto end;
-
- ib_query_device(cma_id-device, p_device_attr);
-
spin_lock(ig.adaptor_list_lock);
p_list = ig.adaptor_list.next;
while (p_list != ig.adaptor_list) {
p_adaptor = list_entry(p_list, struct iser_adaptor, ig_list);
/* find if there's a match using the device GUID */
- if (p_adaptor-device_attr.node_guid ==
p_device_attr-node_guid)
+ if (p_adaptor-device-node_guid == cma_id-device-node_guid)
break;
}
@@ -268,7 +259,6 @@ struct iser_adaptor *iser_adaptor_find_b
}
end:
spin_unlock(ig.adaptor_list_lock);
- kfree(p_device_attr);
return p_adaptor;
}
--- infiniband/ulp/iser/iser.h (revision 4866)
+++ infiniband/ulp/iser/iser.h (working copy)
@@ -1,6 +1,6 @@
/*
* Copyright (c) 2004, 2005 Voltaire, Inc. All rights reserved.
- * Copyright (c) 2005 Cisco Systems. All rights reserved.
+ * Copyright (c) 2005, 2006 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
@@ -105,7 +105,6 @@ struct iser_adaptor {
struct list_head ig_list; /* entry in ig adaptors list */
struct ib_device *device;
- struct ib_device_attr device_attr;
struct ib_pd *pd;
struct ib_cq *cq;
___
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] osm: support for trivial PKey manager
On Tue, 2006-01-10 at 09:51, Ofer Gigi wrote: Hi Hal, Removing redundant error in the log. If the physical port is not valid, nothing is needed to be the done here. Thanks. Applied. ___ 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: [RFC][PATCH] OpenIB uDAPL extension proposal - sample immed data and atomic api's
Kanevsky, Arkady wrote: comments inline. As mentioned on the con-call, there are two separate items to consider while looking at the proposal. The first is the ability to extend DAT for specific provider value-add and the second is to validate the need for general atomic and immediate data functionality in the basic set of API's for all providers. I included atomics and immediate data as examples since it is specific to one provider (IB), it includes operations that require new ops, events, and event data types, and it also provides a working model to validate the extension model from request to completion events. I would like to concentrate on getting consensus on the extension proposal first if possible. Just try to think of the actual operations as some opaque dat_ext_foobar_op(). The thing that bothers me is that we already have several APIs that are transport specific. While some are possible to implement on other transports the others, like Socket CM, can not. So I view both of your specific extensions as transport specific amd hence prefer to add them as normal APIs not extensions. That would work for me. The secondary goal is that Provider can add extensions without requiring to change to DAT. These fall into 3 categories. 1. New memory types including privilages and protection attributes. We can add extension entry to these structures. We need to check if this is sufficient. Think of shared memory for example. I am assuming no changes to PZ. 2. New DTOs. The main issue is not DTOs but their completions and async errors. This is why Immediate data is better handled by incorporating into DAT spec while atomic can be handled by extensions. That is completion will return extention and Consumer will do the secondary switch on the extension type. Extension should not impact backwards compatibility. We had not looked at errors. But assuming a simple model that async errors break connection and we can return extension error with extensions defining new reason. Again details need to be polished. 3. new connection types or CM models... New connections seems to have little impact on existing API assuming that EP type can be extended. The new connection can even restrict which DTO they can handle. CM model is more problematic. Nice summary. Yes, we need be thorough when flushing out all the requirements for extensions in general. I am not sure how much I can share at this point regarding any other extensions but if we think in general terms we should cover all the necessary requirements. Do you want to update the proposal based on your statements above? I would be happy to work it into a real patch for feasibility and to provide feedback based on future extentability. Arlin, it would be nice to consider some of your other extensions that are not transport specific to see how it will fit before we make the final decision. This should give us idea how extensible DAT extension model is. In general, extension route was intended for RNIC|HCA providers to expose HW capabilities beyond IBTA, iWARP and VIA standards. The standard RDMA functionality is best handle via spec addition. DAT 2.0 does it for FMR, remote and local memory invalidation as well as others. True, but the extension route is not fully defined, documented, nor implemented. This is what I would like to work on getting completed in time for 2.0 if possible. BTW: The existing implementation actually uses dapl_provider-extension to store the hca_ptr but the specification states that it is reserved for the providers private use (8.2.1 in DAPL1.2 spec). This is why I had to defined another extension_func in the patch. I had posted a complete list of changes/addition to DAT 2.0 about a month ago. But we had not discussed yet version change from 1.3 to 2.0 nor how much backwards compatibility spec will provide. 2. What is IMMED_EVENT? is it just immediate data without any payload one? I suggest chnaging the name so it will not use EVENT. Just call it NO_PAYLOAD. Do you want to support 2 different way to delivery immediate data? One in event and one in data payload? Why? I would think that just an event way will do. This was modeled after the immediate data discussions on the DAT reflector based on iWARP requirements. http://groups.yahoo.com/group/dat-discussions/message/3285 I recall it now. I want to consider a few usage cases. 1. Existing app running on the Provider with extensions. Want to make sure we do not require any App changes beyond recompile due to extensions. agree 2. App wants to be modified to use Immediate data. How big impact it has on existing code. For example buffer size allocation and completion handling It really depends on transport capabilities. Our current thinking has two delivery mechanisms for the two transports (event and payload) which is not optimal. If we can come to a consensus on
[openib-general] [PATCH] opensm fails to find HCA if port is down.
If opensm is started with no arguments, the default algorithm
for finding a port to bind to will skip ports which are present
but the link is DOWN. If there is only one port in the system,
no port is selected and opensm tries the default HCA name mthca0
which, if not present, confuses opensm and it exits.
The following patch changes the port selection so that the first
active port is selected, and if none, the first non-disabled port.
Signed-off-by: Ralph Campbell [EMAIL PROTECTED]
Index: umad.c
===
--- umad.c (revision 4900)
+++ umad.c (working copy)
@@ -207,9 +207,9 @@
}
/*
- * if *port 0 checks ca[port] state. Otherwise set *port to
+ * if *port 0, check ca[port] state. Otherwise set *port to
* the first port that is active, and if such is not found, to
- * the first port that is (physically) up. Otherwise return -1;
+ * the first port that is not disabled. Otherwise return -1;
*/
static int
resolve_ca_port(char *ca_name, int *port)
@@ -228,14 +228,14 @@
return 1;
}
- if (*port 0) {/* user wants user gets */
+ if (*port 0) {/* check only the port the user wants */
if (*port ca.numports)
return -1;
if (!ca.ports[*port])
return -1;
if (ca.ports[*port]-state == 4)
return 1;
- if (ca.ports[*port]-phys_state == 5)
+ if (ca.ports[*port]-phys_state != 3)
return 0;
return -1;
}
@@ -244,7 +244,7 @@
DEBUG(checking port %d, i);
if (!ca.ports[i])
continue;
- if (up 0 ca.ports[i]-phys_state == 5)
+ if (up 0 ca.ports[i]-phys_state != 3)
up = *port = i;
if (ca.ports[i]-state == 4) {
active = *port = i;
@@ -278,10 +278,11 @@
return ca_name;
}
- /* find first existing HCA with Active port */
+ /* Get the list of CA names. */
if ((n = umad_get_cas_names((void *)names, UMAD_CA_NAME_LEN)) 0)
return 0;
+ /* Find the first existing CA with an active port. */
for (caidx = 0; caidx n; caidx++) {
TRACE(checking ca '%s', names[caidx]);
--
Ralph Campbell [EMAIL PROTECTED]
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] ipoib: flush workqueue after clearing ADMIN_UP
Flush workqueue after clearing IPOIB_FLAG_ADMIN_UP, to prevent a job running from the workqueue from bringing the device back up. Signed-off-by: Jack Morgenstein [EMAIL PROTECTED] Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] Index: gen2/drivers/infiniband/ulp/ipoib/ipoib_main.c === --- gen2.orig/drivers/infiniband/ulp/ipoib/ipoib_main.c 2006-01-10 10:33:32.101242000 +0200 +++ gen2/drivers/infiniband/ulp/ipoib/ipoib_main.c 2006-01-10 10:43:02.254713000 +0200 @@ -134,6 +134,8 @@ static int ipoib_stop(struct net_device netif_stop_queue(dev); + flush_workqueue(ipoib_workqueue); + ipoib_ib_dev_down(dev, 1); ipoib_ib_dev_stop(dev); -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] ipoib: mcast-ah race
ipoib_mcast_send tests mcast-ah twice. If this value
is changed between these two points, we leak an skb.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index: openib/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
===
--- openib/drivers/infiniband/ulp/ipoib/ipoib_multicast.c (revision 4872)
+++ openib/drivers/infiniband/ulp/ipoib/ipoib_multicast.c (working copy)
@@ -206,6 +206,7 @@ static int ipoib_mcast_join_finish(struc
{
struct net_device *dev = mcast-dev;
struct ipoib_dev_priv *priv = netdev_priv(dev);
+ unsigned long flags;
int ret;
mcast-mcmember = *mcmember;
@@ -262,6 +263,7 @@ static int ipoib_mcast_join_finish(struc
av.static_rate, priv-local_rate,
ib_sa_rate_enum_to_int(mcast-mcmember.rate));
+ spin_lock_irqsave(priv-lock, flags);
mcast-ah = ipoib_create_ah(dev, priv-pd, av);
if (!mcast-ah) {
ipoib_warn(priv, ib_address_create failed\n);
@@ -273,6 +275,7 @@ static int ipoib_mcast_join_finish(struc
be16_to_cpu(mcast-mcmember.mlid),
mcast-mcmember.sl);
}
+ spin_unlock_irqrestore(priv-lock, flags);
}
/* actually send any queued packets */
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] ipoib: tx ring overrun
Dont try to post more send work requests if the TX ring is full.
Setting netif_stop_queue is insufficient: linux can still land
a tx packet on us.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index: openib/drivers/infiniband/ulp/ipoib/ipoib_ib.c
===
--- openib.orig/drivers/infiniband/ulp/ipoib/ipoib_ib.c 2006-01-10
15:38:36.0 +0200
+++ openib/drivers/infiniband/ulp/ipoib/ipoib_ib.c 2006-01-10
18:49:33.0 +0200
@@ -344,6 +344,13 @@ void ipoib_send(struct net_device *dev,
* means we have to make sure everything is properly recorded and
* our state is consistent before we call post_send().
*/
+ if (unlikely(priv-tx_head - priv-tx_tail == IPOIB_TX_RING_SIZE)) {
+ ipoib_dbg(priv, TX ring full, dropping packet\n);
+ ++priv-stats.tx_errors;
+ dev_kfree_skb_any(skb);
+ return;
+ }
+
tx_req = priv-tx_ring[priv-tx_head (IPOIB_TX_RING_SIZE - 1)];
tx_req-skb = skb;
addr = dma_map_single(priv-ca-dma_device, skb-data, skb-len,
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] SA cache design
Sean Hefty wrote: To keep the design as flexible as possible, my plan is to implement the cache in userspace. The interface to the cache would be via MADs. Clients would send their queries to the sa_cache instead of the SA itself. The format of the MADs would be essentially identical to those used to query the SA itself. Response MADs would contain any requested information. If the cache could not satisfy a request, the sa_cache would query the SA, update its cache, then return a reply. What I think I really want is a distributed relational database management system with an SQL interface and triggers that maintains the SA data... (select * from path_rec where sgid=x and dgid=y and pkey=z) But without making any assumptions about the SA, a local cache could still use an RDMS to store and retrieve the data records. Would requiring an RDMS on each system be acceptable? If not, then writing a small, dumb pseudo-database as part of the sa_cache could provide a lot of flexibility. - 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] ipoib: tx ring overrun
On Tue, Jan 10, 2006 at 08:55:15PM +0200, Michael S. Tsirkin wrote:
Dont try to post more send work requests if the TX ring is full.
Setting netif_stop_queue is insufficient: linux can still land
a tx packet on us.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index: openib/drivers/infiniband/ulp/ipoib/ipoib_ib.c
===
--- openib.orig/drivers/infiniband/ulp/ipoib/ipoib_ib.c 2006-01-10
15:38:36.0 +0200
+++ openib/drivers/infiniband/ulp/ipoib/ipoib_ib.c2006-01-10
18:49:33.0 +0200
@@ -344,6 +344,13 @@ void ipoib_send(struct net_device *dev,
* means we have to make sure everything is properly recorded and
* our state is consistent before we call post_send().
*/
+ if (unlikely(priv-tx_head - priv-tx_tail == IPOIB_TX_RING_SIZE)) {
+ ipoib_dbg(priv, TX ring full, dropping packet\n);
+ ++priv-stats.tx_errors;
Could this be tx_dropped?
I'm looking at ifconfig output and assuming tx_dropped is used:
[EMAIL PROTECTED]:~$ /sbin/ifconfig ib0
ib0 Link encap:UNSPEC HWaddr
00-00-04-04-FE-80-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.0.51 Bcast:10.0.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:2044 Metric:1
RX packets:1020109972 errors:0 dropped:0 overruns:0 frame:0
TX packets:1549932074 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:128
RX bytes:160480185298 (149.4 GiB) TX bytes:1854376582766 (1.6 TiB)
grant
+ dev_kfree_skb_any(skb);
+ return;
+ }
+
tx_req = priv-tx_ring[priv-tx_head (IPOIB_TX_RING_SIZE - 1)];
tx_req-skb = skb;
addr = dma_map_single(priv-ca-dma_device, skb-data, skb-len,
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
___
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: SA cache design
Quoting Sean Hefty [EMAIL PROTECTED]: To keep the design as flexible as possible, my plan is to implement the cache in userspace. The interface to the cache would be via MADs. Clients would send their queries to the sa_cache instead of the SA itself. The format of the MADs would be essentially identical to those used to query the SA itself. Response MADs would contain any requested information. If the cache could not satisfy a request, the sa_cache would query the SA, update its cache, then return a reply. Bouncing queries required for e.g. IPoIB or SDP to userspace seems like a deadlock scenario in case userspace is located e.g. on an NFS share. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: SA cache design
Michael S. Tsirkin wrote: To keep the design as flexible as possible, my plan is to implement the cache in userspace. The interface to the cache would be via MADs. Clients would send their queries to the sa_cache instead of the SA itself. The format of the MADs would be essentially identical to those used to query the SA itself. Response MADs would contain any requested information. If the cache could not satisfy a request, the sa_cache would query the SA, update its cache, then return a reply. Bouncing queries required for e.g. IPoIB or SDP to userspace seems like a deadlock scenario in case userspace is located e.g. on an NFS share. The SA itself is implemented in userspace. I don't see any issue here. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: SA cache design
Quoting r. Sean Hefty [EMAIL PROTECTED]: Subject: Re: SA cache design Michael S. Tsirkin wrote: To keep the design as flexible as possible, my plan is to implement the cache in userspace. The interface to the cache would be via MADs. Clients would send their queries to the sa_cache instead of the SA itself. The format of the MADs would be essentially identical to those used to query the SA itself. Response MADs would contain any requested information. If the cache could not satisfy a request, the sa_cache would query the SA, update its cache, then return a reply. Bouncing queries required for e.g. IPoIB or SDP to userspace seems like a deadlock scenario in case userspace is located e.g. on an NFS share. The SA itself is implemented in userspace. I don't see any issue here. - Sean Sure, but its not running on the local (possibly diskless) node. -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] ipoib: tx ring overrun
Quoting Grant Grundler [EMAIL PROTECTED]:
On Tue, Jan 10, 2006 at 08:55:15PM +0200, Michael S. Tsirkin wrote:
Dont try to post more send work requests if the TX ring is full.
Setting netif_stop_queue is insufficient: linux can still land
a tx packet on us.
...
+ if (unlikely(priv-tx_head - priv-tx_tail == IPOIB_TX_RING_SIZE)) {
+ ipoib_dbg(priv, TX ring full, dropping packet\n);
+ ++priv-stats.tx_errors;
Could this be tx_dropped?
I dont know. Roland?
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [git patch review 1/7] IB/mthca: fix page shift calculation in mthca_reg_phys_mr()
For all pages except possibly the last one, the byte beyond the buffer
end must be page aligned. Therefore, when computing the page shift to
use, OR the end addresses of the buffers as well as the start
addresses into the mask we check.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
drivers/infiniband/hw/mthca/mthca_provider.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
6627fa662e86c400284b64c13661fdf6bff05983
diff --git a/drivers/infiniband/hw/mthca/mthca_provider.c
b/drivers/infiniband/hw/mthca/mthca_provider.c
index 4cc7e28..30b67c2 100644
--- a/drivers/infiniband/hw/mthca/mthca_provider.c
+++ b/drivers/infiniband/hw/mthca/mthca_provider.c
@@ -783,24 +783,20 @@ static struct ib_mr *mthca_reg_phys_mr(s
if ((*iova_start ~PAGE_MASK) != (buffer_list[0].addr ~PAGE_MASK))
return ERR_PTR(-EINVAL);
- if (num_phys_buf 1
- ((buffer_list[0].addr + buffer_list[0].size) ~PAGE_MASK))
- return ERR_PTR(-EINVAL);
-
mask = 0;
total_size = 0;
for (i = 0; i num_phys_buf; ++i) {
- if (i != 0 buffer_list[i].addr ~PAGE_MASK)
- return ERR_PTR(-EINVAL);
- if (i != 0 i != num_phys_buf - 1
- (buffer_list[i].size ~PAGE_MASK))
- return ERR_PTR(-EINVAL);
+ if (i != 0)
+ mask |= buffer_list[i].addr;
+ if (i != num_phys_buf - 1)
+ mask |= buffer_list[i].addr + buffer_list[i].size;
total_size += buffer_list[i].size;
- if (i 0)
- mask |= buffer_list[i].addr;
}
+ if (mask ~PAGE_MASK)
+ return ERR_PTR(-EINVAL);
+
/* Find largest page shift we can use to cover buffers */
for (shift = PAGE_SHIFT; shift 31; ++shift)
if (num_phys_buf 1) {
--
1.0.7
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [git patch review 2/7] IB/mthca: prevent event queue overrun
I am seeing EQ overruns in SDP stress tests: if the CQ completion
handler arms a CQ, this could generate more EQEs, so that EQ will
never get empty and consumer index will never get updated.
This is similiar to what we have with command interface:
/*
* cmd_event() may add more commands.
* The card will think the queue has overflowed if
* we don't tell it we've been processing events.
*/
However, for completion events, we *don't* want to update the consumer
index on each event. So, perform EQ doorbell coalescing: allocate EQs
with some spare EQEs, and update once we run out of them.
The value 0x80 was selected to avoid any performance impact.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
drivers/infiniband/hw/mthca/mthca_eq.c | 28 +++-
1 files changed, 15 insertions(+), 13 deletions(-)
92898522e3ee1a0ba54140aad1974d9e868f74ae
diff --git a/drivers/infiniband/hw/mthca/mthca_eq.c
b/drivers/infiniband/hw/mthca/mthca_eq.c
index e8a948f..2eabb27 100644
--- a/drivers/infiniband/hw/mthca/mthca_eq.c
+++ b/drivers/infiniband/hw/mthca/mthca_eq.c
@@ -45,6 +45,7 @@
enum {
MTHCA_NUM_ASYNC_EQE = 0x80,
MTHCA_NUM_CMD_EQE = 0x80,
+ MTHCA_NUM_SPARE_EQE = 0x80,
MTHCA_EQ_ENTRY_SIZE = 0x20
};
@@ -277,11 +278,10 @@ static int mthca_eq_int(struct mthca_dev
{
struct mthca_eqe *eqe;
int disarm_cqn;
- int eqes_found = 0;
+ int eqes_found = 0;
+ int set_ci = 0;
while ((eqe = next_eqe_sw(eq))) {
- int set_ci = 0;
-
/*
* Make sure we read EQ entry contents after we've
* checked the ownership bit.
@@ -345,12 +345,6 @@ static int mthca_eq_int(struct mthca_dev
be16_to_cpu(eqe-event.cmd.token),
eqe-event.cmd.status,
be64_to_cpu(eqe-event.cmd.out_param));
- /*
-* cmd_event() may add more commands.
-* The card will think the queue has overflowed if
-* we don't tell it we've been processing events.
-*/
- set_ci = 1;
break;
case MTHCA_EVENT_TYPE_PORT_CHANGE:
@@ -385,8 +379,16 @@ static int mthca_eq_int(struct mthca_dev
set_eqe_hw(eqe);
++eq-cons_index;
eqes_found = 1;
+ ++set_ci;
- if (unlikely(set_ci)) {
+ /*
+* The HCA will think the queue has overflowed if we
+* don't tell it we've been processing events. We
+* create our EQs with MTHCA_NUM_SPARE_EQE extra
+* entries, so we must update our consumer index at
+* least that often.
+*/
+ if (unlikely(set_ci = MTHCA_NUM_SPARE_EQE)) {
/*
* Conditional on hca_type is OK here because
* this is a rare case, not the fast path.
@@ -862,19 +864,19 @@ int __devinit mthca_init_eq_table(struct
intr = (dev-mthca_flags MTHCA_FLAG_MSI) ?
128 : dev-eq_table.inta_pin;
- err = mthca_create_eq(dev, dev-limits.num_cqs,
+ err = mthca_create_eq(dev, dev-limits.num_cqs + MTHCA_NUM_SPARE_EQE,
(dev-mthca_flags MTHCA_FLAG_MSI_X) ? 128 :
intr,
dev-eq_table.eq[MTHCA_EQ_COMP]);
if (err)
goto err_out_unmap;
- err = mthca_create_eq(dev, MTHCA_NUM_ASYNC_EQE,
+ err = mthca_create_eq(dev, MTHCA_NUM_ASYNC_EQE + MTHCA_NUM_SPARE_EQE,
(dev-mthca_flags MTHCA_FLAG_MSI_X) ? 129 :
intr,
dev-eq_table.eq[MTHCA_EQ_ASYNC]);
if (err)
goto err_out_comp;
- err = mthca_create_eq(dev, MTHCA_NUM_CMD_EQE,
+ err = mthca_create_eq(dev, MTHCA_NUM_CMD_EQE + MTHCA_NUM_SPARE_EQE,
(dev-mthca_flags MTHCA_FLAG_MSI_X) ? 130 :
intr,
dev-eq_table.eq[MTHCA_EQ_CMD]);
if (err)
--
1.0.7
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [git patch review 4/7] IB/mthca: Factor common MAD initialization code
Factor out common code for initializing MAD packets, which is shared
by many query routines in mthca_provider.c, into init_query_mad().
add/remove: 1/0 grow/shrink: 0/4 up/down: 16/-44 (-28)
function old new delta
init_query_mad - 16 +16
mthca_query_port 521 518 -3
mthca_query_pkey 301 294 -7
mthca_query_device 648 641 -7
mthca_query_gid 453 426 -27
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
drivers/infiniband/hw/mthca/mthca_provider.c | 52 +++---
1 files changed, 22 insertions(+), 30 deletions(-)
87635b71b544563f29050a9cecaa12b5d2a3e34a
diff --git a/drivers/infiniband/hw/mthca/mthca_provider.c
b/drivers/infiniband/hw/mthca/mthca_provider.c
index 0ae27fa..4887577 100644
--- a/drivers/infiniband/hw/mthca/mthca_provider.c
+++ b/drivers/infiniband/hw/mthca/mthca_provider.c
@@ -45,6 +45,14 @@
#include mthca_user.h
#include mthca_memfree.h
+static void init_query_mad(struct ib_smp *mad)
+{
+ mad-base_version = 1;
+ mad-mgmt_class= IB_MGMT_CLASS_SUBN_LID_ROUTED;
+ mad-class_version = 1;
+ mad-method= IB_MGMT_METHOD_GET;
+}
+
static int mthca_query_device(struct ib_device *ibdev,
struct ib_device_attr *props)
{
@@ -64,11 +72,8 @@ static int mthca_query_device(struct ib_
props-fw_ver = mdev-fw_ver;
- in_mad-base_version = 1;
- in_mad-mgmt_class = IB_MGMT_CLASS_SUBN_LID_ROUTED;
- in_mad-class_version = 1;
- in_mad-method = IB_MGMT_METHOD_GET;
- in_mad-attr_id= IB_SMP_ATTR_NODE_INFO;
+ init_query_mad(in_mad);
+ in_mad-attr_id = IB_SMP_ATTR_NODE_INFO;
err = mthca_MAD_IFC(mdev, 1, 1,
1, NULL, NULL, in_mad, out_mad,
@@ -134,12 +139,9 @@ static int mthca_query_port(struct ib_de
memset(props, 0, sizeof *props);
- in_mad-base_version = 1;
- in_mad-mgmt_class = IB_MGMT_CLASS_SUBN_LID_ROUTED;
- in_mad-class_version = 1;
- in_mad-method = IB_MGMT_METHOD_GET;
- in_mad-attr_id= IB_SMP_ATTR_PORT_INFO;
- in_mad-attr_mod = cpu_to_be32(port);
+ init_query_mad(in_mad);
+ in_mad-attr_id = IB_SMP_ATTR_PORT_INFO;
+ in_mad-attr_mod = cpu_to_be32(port);
err = mthca_MAD_IFC(to_mdev(ibdev), 1, 1,
port, NULL, NULL, in_mad, out_mad,
@@ -223,12 +225,9 @@ static int mthca_query_pkey(struct ib_de
if (!in_mad || !out_mad)
goto out;
- in_mad-base_version = 1;
- in_mad-mgmt_class = IB_MGMT_CLASS_SUBN_LID_ROUTED;
- in_mad-class_version = 1;
- in_mad-method = IB_MGMT_METHOD_GET;
- in_mad-attr_id= IB_SMP_ATTR_PKEY_TABLE;
- in_mad-attr_mod = cpu_to_be32(index / 32);
+ init_query_mad(in_mad);
+ in_mad-attr_id = IB_SMP_ATTR_PKEY_TABLE;
+ in_mad-attr_mod = cpu_to_be32(index / 32);
err = mthca_MAD_IFC(to_mdev(ibdev), 1, 1,
port, NULL, NULL, in_mad, out_mad,
@@ -261,12 +260,9 @@ static int mthca_query_gid(struct ib_dev
if (!in_mad || !out_mad)
goto out;
- in_mad-base_version = 1;
- in_mad-mgmt_class = IB_MGMT_CLASS_SUBN_LID_ROUTED;
- in_mad-class_version = 1;
- in_mad-method = IB_MGMT_METHOD_GET;
- in_mad-attr_id= IB_SMP_ATTR_PORT_INFO;
- in_mad-attr_mod = cpu_to_be32(port);
+ init_query_mad(in_mad);
+ in_mad-attr_id = IB_SMP_ATTR_PORT_INFO;
+ in_mad-attr_mod = cpu_to_be32(port);
err = mthca_MAD_IFC(to_mdev(ibdev), 1, 1,
port, NULL, NULL, in_mad, out_mad,
@@ -280,13 +276,9 @@ static int mthca_query_gid(struct ib_dev
memcpy(gid-raw, out_mad-data + 8, 8);
- memset(in_mad, 0, sizeof *in_mad);
- in_mad-base_version = 1;
- in_mad-mgmt_class = IB_MGMT_CLASS_SUBN_LID_ROUTED;
- in_mad-class_version = 1;
- in_mad-method = IB_MGMT_METHOD_GET;
- in_mad-attr_id= IB_SMP_ATTR_GUID_INFO;
- in_mad-attr_mod = cpu_to_be32(index / 8);
+ init_query_mad(in_mad);
+ in_mad-attr_id = IB_SMP_ATTR_GUID_INFO;
+ in_mad-attr_mod = cpu_to_be32(index / 8);
err = mthca_MAD_IFC(to_mdev(ibdev), 1, 1,
port, NULL, NULL, in_mad, out_mad,
--
1.0.7
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit
[openib-general] [git patch review 7/7] IPoIB: Fix address handle refcounting for multicast groups
Multiple ipoib_neigh structures on mcast-neigh_list may point to the
same ah. This means that ipoib_mcast_free() can't just make a list of
ah structs to free, since this might end up trying to add the same ah
to the list more than once. Handle this in ipoib_multicast.c in the
same way as it is handled in ipoib_main.c for struct ipoib_path.
Signed-off-by: Eli Cohen [EMAIL PROTECTED]
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
97460df37ea3335ca11562568932c9f9facfecdb
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 6c6db75..03b2ca6 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -97,8 +97,6 @@ static void ipoib_mcast_free(struct ipoi
struct ipoib_dev_priv *priv = netdev_priv(dev);
struct ipoib_neigh *neigh, *tmp;
unsigned long flags;
- LIST_HEAD(ah_list);
- struct ipoib_ah *ah, *tah;
ipoib_dbg_mcast(netdev_priv(dev),
deleting multicast group IPOIB_GID_FMT \n,
@@ -107,8 +105,14 @@ static void ipoib_mcast_free(struct ipoi
spin_lock_irqsave(priv-lock, flags);
list_for_each_entry_safe(neigh, tmp, mcast-neigh_list, list) {
+ /*
+* It's safe to call ipoib_put_ah() inside priv-lock
+* here, because we know that mcast-ah will always
+* hold one more reference, so ipoib_put_ah() will
+* never do more than decrement the ref count.
+*/
if (neigh-ah)
- list_add_tail(neigh-ah-list, ah_list);
+ ipoib_put_ah(neigh-ah);
*to_ipoib_neigh(neigh-neighbour) = NULL;
neigh-neighbour-ops-destructor = NULL;
kfree(neigh);
@@ -116,9 +120,6 @@ static void ipoib_mcast_free(struct ipoi
spin_unlock_irqrestore(priv-lock, flags);
- list_for_each_entry_safe(ah, tah, ah_list, list)
- ipoib_put_ah(ah);
-
if (mcast-ah)
ipoib_put_ah(mcast-ah);
--
1.0.7
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [git patch review 5/7] IB: Add node_guid to struct ib_device
Add a node_guid field to struct ib_device. It is the responsibility
of the low-level driver to initialize this field before registering a
device with the midlayer. Convert everyone to looking at this field
instead of calling ib_query_device() when all they want is the node
GUID, and remove the node_guid field from struct ib_device_attr.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
drivers/infiniband/core/cm.c | 29 +++
drivers/infiniband/core/sysfs.c | 22 +++---
drivers/infiniband/core/uverbs_cmd.c |2 +
drivers/infiniband/hw/mthca/mthca_provider.c | 40 +-
drivers/infiniband/ulp/srp/ib_srp.c | 23 +++
include/rdma/ib_verbs.h |2 +
6 files changed, 54 insertions(+), 64 deletions(-)
cf311cd49a78f1e431787068cc31d29d06a415e6
diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c
index 3a611fe..c06b181 100644
--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -3163,22 +3163,6 @@ int ib_cm_init_qp_attr(struct ib_cm_id *
}
EXPORT_SYMBOL(ib_cm_init_qp_attr);
-static __be64 cm_get_ca_guid(struct ib_device *device)
-{
- struct ib_device_attr *device_attr;
- __be64 guid;
- int ret;
-
- device_attr = kmalloc(sizeof *device_attr, GFP_KERNEL);
- if (!device_attr)
- return 0;
-
- ret = ib_query_device(device, device_attr);
- guid = ret ? 0 : device_attr-node_guid;
- kfree(device_attr);
- return guid;
-}
-
static void cm_add_one(struct ib_device *device)
{
struct cm_device *cm_dev;
@@ -3200,9 +3184,7 @@ static void cm_add_one(struct ib_device
return;
cm_dev-device = device;
- cm_dev-ca_guid = cm_get_ca_guid(device);
- if (!cm_dev-ca_guid)
- goto error1;
+ cm_dev-ca_guid = device-node_guid;
set_bit(IB_MGMT_METHOD_SEND, reg_req.method_mask);
for (i = 1; i = device-phys_port_cnt; i++) {
@@ -3217,11 +3199,11 @@ static void cm_add_one(struct ib_device
cm_recv_handler,
port);
if (IS_ERR(port-mad_agent))
- goto error2;
+ goto error1;
ret = ib_modify_port(device, i, 0, port_modify);
if (ret)
- goto error3;
+ goto error2;
}
ib_set_client_data(device, cm_client, cm_dev);
@@ -3230,9 +3212,9 @@ static void cm_add_one(struct ib_device
write_unlock_irqrestore(cm.device_lock, flags);
return;
-error3:
- ib_unregister_mad_agent(port-mad_agent);
error2:
+ ib_unregister_mad_agent(port-mad_agent);
+error1:
port_modify.set_port_cap_mask = 0;
port_modify.clr_port_cap_mask = IB_PORT_CM_SUP;
while (--i) {
@@ -3240,7 +3222,6 @@ error2:
ib_modify_port(device, port-port_num, 0, port_modify);
ib_unregister_mad_agent(port-mad_agent);
}
-error1:
kfree(cm_dev);
}
diff --git a/drivers/infiniband/core/sysfs.c b/drivers/infiniband/core/sysfs.c
index 1f1743c..5982d68 100644
--- a/drivers/infiniband/core/sysfs.c
+++ b/drivers/infiniband/core/sysfs.c
@@ -445,13 +445,7 @@ static int ib_device_uevent(struct class
return -ENOMEM;
/*
-* It might be nice to pass the node GUID with the event, but
-* right now the only way to get it is to query the device
-* provider, and this can crash during device removal because
-* we are will be running after driver removal has started.
-* We could add a node_guid field to struct ib_device, or we
-* could just let userspace read the node GUID from sysfs when
-* devices are added.
+* It would be nice to pass the node GUID with the event...
*/
envp[i] = NULL;
@@ -623,21 +617,15 @@ static ssize_t show_sys_image_guid(struc
static ssize_t show_node_guid(struct class_device *cdev, char *buf)
{
struct ib_device *dev = container_of(cdev, struct ib_device, class_dev);
- struct ib_device_attr attr;
- ssize_t ret;
if (!ibdev_is_alive(dev))
return -ENODEV;
- ret = ib_query_device(dev, attr);
- if (ret)
- return ret;
-
return sprintf(buf, %04x:%04x:%04x:%04x\n,
- be16_to_cpu(((__be16 *) attr.node_guid)[0]),
- be16_to_cpu(((__be16 *) attr.node_guid)[1]),
- be16_to_cpu(((__be16 *) attr.node_guid)[2]),
- be16_to_cpu(((__be16 *) attr.node_guid)[3]));
+ be16_to_cpu(((__be16 *) dev-node_guid)[0]),
+ be16_to_cpu(((__be16 *) dev-node_guid)[1]),
+
[openib-general] [git patch review 3/7] IB/mthca: kzalloc conversions
Convert kmalloc()/memset(,0,) pairs to kzalloc(). Signed-off-by: Roland Dreier [EMAIL PROTECTED] --- drivers/infiniband/hw/mthca/mthca_provider.c | 12 1 files changed, 4 insertions(+), 8 deletions(-) 105e50a5e8f184af31daffce4d7bfd7771fe213f diff --git a/drivers/infiniband/hw/mthca/mthca_provider.c b/drivers/infiniband/hw/mthca/mthca_provider.c index 30b67c2..0ae27fa 100644 --- a/drivers/infiniband/hw/mthca/mthca_provider.c +++ b/drivers/infiniband/hw/mthca/mthca_provider.c @@ -55,7 +55,7 @@ static int mthca_query_device(struct ib_ u8 status; - in_mad = kmalloc(sizeof *in_mad, GFP_KERNEL); + in_mad = kzalloc(sizeof *in_mad, GFP_KERNEL); out_mad = kmalloc(sizeof *out_mad, GFP_KERNEL); if (!in_mad || !out_mad) goto out; @@ -64,7 +64,6 @@ static int mthca_query_device(struct ib_ props-fw_ver = mdev-fw_ver; - memset(in_mad, 0, sizeof *in_mad); in_mad-base_version = 1; in_mad-mgmt_class = IB_MGMT_CLASS_SUBN_LID_ROUTED; in_mad-class_version = 1; @@ -128,14 +127,13 @@ static int mthca_query_port(struct ib_de int err = -ENOMEM; u8 status; - in_mad = kmalloc(sizeof *in_mad, GFP_KERNEL); + in_mad = kzalloc(sizeof *in_mad, GFP_KERNEL); out_mad = kmalloc(sizeof *out_mad, GFP_KERNEL); if (!in_mad || !out_mad) goto out; memset(props, 0, sizeof *props); - memset(in_mad, 0, sizeof *in_mad); in_mad-base_version = 1; in_mad-mgmt_class = IB_MGMT_CLASS_SUBN_LID_ROUTED; in_mad-class_version = 1; @@ -220,12 +218,11 @@ static int mthca_query_pkey(struct ib_de int err = -ENOMEM; u8 status; - in_mad = kmalloc(sizeof *in_mad, GFP_KERNEL); + in_mad = kzalloc(sizeof *in_mad, GFP_KERNEL); out_mad = kmalloc(sizeof *out_mad, GFP_KERNEL); if (!in_mad || !out_mad) goto out; - memset(in_mad, 0, sizeof *in_mad); in_mad-base_version = 1; in_mad-mgmt_class = IB_MGMT_CLASS_SUBN_LID_ROUTED; in_mad-class_version = 1; @@ -259,12 +256,11 @@ static int mthca_query_gid(struct ib_dev int err = -ENOMEM; u8 status; - in_mad = kmalloc(sizeof *in_mad, GFP_KERNEL); + in_mad = kzalloc(sizeof *in_mad, GFP_KERNEL); out_mad = kmalloc(sizeof *out_mad, GFP_KERNEL); if (!in_mad || !out_mad) goto out; - memset(in_mad, 0, sizeof *in_mad); in_mad-base_version = 1; in_mad-mgmt_class = IB_MGMT_CLASS_SUBN_LID_ROUTED; in_mad-class_version = 1; -- 1.0.7 ___ 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] opensm fails to find HCA if port is down.
Hi Ralph,
On Tue, 2006-01-10 at 13:31, Ralph Campbell wrote:
If opensm is started with no arguments, the default algorithm
for finding a port to bind to will skip ports which are present
but the link is DOWN. If there is only one port in the system,
no port is selected and opensm tries the default HCA name mthca0
which, if not present, confuses opensm and it exits.
The following patch changes the port selection so that the first
active port is selected, and if none, the first non-disabled port.
This is close and headed in the right direction but has one property I'm
not too fond of: when there are no active ports, it does not prefer a
port whose physical state is link up over one in (say) polling (anything
other than link up) so the subnet may not come up when it could in that
case.
-- Hal
Signed-off-by: Ralph Campbell [EMAIL PROTECTED]
Index: umad.c
===
--- umad.c(revision 4900)
+++ umad.c(working copy)
@@ -207,9 +207,9 @@
}
/*
- * if *port 0 checks ca[port] state. Otherwise set *port to
+ * if *port 0, check ca[port] state. Otherwise set *port to
* the first port that is active, and if such is not found, to
- * the first port that is (physically) up. Otherwise return -1;
+ * the first port that is not disabled. Otherwise return -1;
*/
static int
resolve_ca_port(char *ca_name, int *port)
@@ -228,14 +228,14 @@
return 1;
}
- if (*port 0) {/* user wants user gets */
+ if (*port 0) {/* check only the port the user wants */
if (*port ca.numports)
return -1;
if (!ca.ports[*port])
return -1;
if (ca.ports[*port]-state == 4)
return 1;
- if (ca.ports[*port]-phys_state == 5)
+ if (ca.ports[*port]-phys_state != 3)
return 0;
return -1;
}
@@ -244,7 +244,7 @@
DEBUG(checking port %d, i);
if (!ca.ports[i])
continue;
- if (up 0 ca.ports[i]-phys_state == 5)
+ if (up 0 ca.ports[i]-phys_state != 3)
up = *port = i;
if (ca.ports[i]-state == 4) {
active = *port = i;
@@ -278,10 +278,11 @@
return ca_name;
}
- /* find first existing HCA with Active port */
+ /* Get the list of CA names. */
if ((n = umad_get_cas_names((void *)names, UMAD_CA_NAME_LEN)) 0)
return 0;
+ /* Find the first existing CA with an active port. */
for (caidx = 0; caidx n; caidx++) {
TRACE(checking ca '%s', names[caidx]);
___
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] opensm fails to find HCA if port is down.
I understand. Maybe it should be the first active, if none, then the
first UP, and if none, the first !disabled.
Mostly I was trying to get something that picked ipath0 port 1
when it was the only port in the system even if the link
is down.
On Tue, 2006-01-10 at 17:12 -0500, Hal Rosenstock wrote:
Hi Ralph,
On Tue, 2006-01-10 at 13:31, Ralph Campbell wrote:
If opensm is started with no arguments, the default algorithm
for finding a port to bind to will skip ports which are present
but the link is DOWN. If there is only one port in the system,
no port is selected and opensm tries the default HCA name mthca0
which, if not present, confuses opensm and it exits.
The following patch changes the port selection so that the first
active port is selected, and if none, the first non-disabled port.
This is close and headed in the right direction but has one property I'm
not too fond of: when there are no active ports, it does not prefer a
port whose physical state is link up over one in (say) polling (anything
other than link up) so the subnet may not come up when it could in that
case.
-- Hal
Signed-off-by: Ralph Campbell [EMAIL PROTECTED]
Index: umad.c
===
--- umad.c (revision 4900)
+++ umad.c (working copy)
@@ -207,9 +207,9 @@
}
/*
- * if *port 0 checks ca[port] state. Otherwise set *port to
+ * if *port 0, check ca[port] state. Otherwise set *port to
* the first port that is active, and if such is not found, to
- * the first port that is (physically) up. Otherwise return -1;
+ * the first port that is not disabled. Otherwise return -1;
*/
static int
resolve_ca_port(char *ca_name, int *port)
@@ -228,14 +228,14 @@
return 1;
}
- if (*port 0) {/* user wants user gets */
+ if (*port 0) {/* check only the port the user wants */
if (*port ca.numports)
return -1;
if (!ca.ports[*port])
return -1;
if (ca.ports[*port]-state == 4)
return 1;
- if (ca.ports[*port]-phys_state == 5)
+ if (ca.ports[*port]-phys_state != 3)
return 0;
return -1;
}
@@ -244,7 +244,7 @@
DEBUG(checking port %d, i);
if (!ca.ports[i])
continue;
- if (up 0 ca.ports[i]-phys_state == 5)
+ if (up 0 ca.ports[i]-phys_state != 3)
up = *port = i;
if (ca.ports[i]-state == 4) {
active = *port = i;
@@ -278,10 +278,11 @@
return ca_name;
}
- /* find first existing HCA with Active port */
+ /* Get the list of CA names. */
if ((n = umad_get_cas_names((void *)names, UMAD_CA_NAME_LEN)) 0)
return 0;
+ /* Find the first existing CA with an active port. */
for (caidx = 0; caidx n; caidx++) {
TRACE(checking ca '%s', names[caidx]);
--
Ralph Campbell [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] [PATCH] opensm fails to find HCA if port is down.
Hi Ralph, On Tue, 2006-01-10 at 17:47, Ralph Campbell wrote: I understand. Maybe it should be the first active, if none, then the first UP, and if none, the first !disabled. Exactly. I think one more loop (first checking physical state for linkup and then checking for not disabled) will take care of it. I'm working on it now as a patch on your patch which I will post. Mostly I was trying to get something that picked ipath0 port 1 when it was the only port in the system even if the link is down. Understood. -- 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: [PATCH] ipoib: tx ring overrun
Quoting r. Roland Dreier [EMAIL PROTECTED]: Subject: Re: [PATCH] ipoib: tx ring overrun Michael Look here Michael https://openib.org/svn/trunk/contrib/mellanox/patches Michael these are updated outstanding patches OK, cool. Is there any ordering info available about dependencies between the patches? ipoib_flush_wq_2.patch needs to be applied on top of ipoib_flush_wq_1.patch Others are independent of each other. Here's a list of patches with some explanations: Fixes for oopses that we saw in testing: ipoib_up_flag_race.patch ipoib_all_neigh_issues_2.patch ipoib_mcast_send.patch ipoib_mc_list.patch ipoib_flush_wq_1.patch ipoib_flush_wq_2.patch Memory leak that we saw in testing ipoib_multicast_leak.patch Drop counter fix (not sure whether this is from testing or code review) ipoib_multicast_drop_counter.patch Code review: cosmetic ipoib_cosmetics.patch Code review: error handling ipoib_init_qp.patch ipoib_post_receives_err.patch Code review: races ipoib_qprst_protect.patch ipoib_multicast_ah.patch ipoib_multicast_race.patch There's also a patch for libibverbs devinfo_board_id.patch and a patch for core/sysfs.c node_desc_clear.patch -- MST ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] SA cache design
Grant Grundler wrote: We already have several databases for different things: makedb (primarily for NSS) updatedb (fast lookup of local files) mandb (man pages) rpmdb (yes, even on debian boxes) sasldbconverter2 (for SASL - linux securty/login stuff) *db4.3* (Berkeley v4.3 Database - used by apt-get/dpkg, Apache, python, libns-db, postfix, etc) In fact, looks like a debian testing box would be disfunctional without Berkeley Database. Would that work? Thanks for pointing these out. I did find that libdb-4.2 was installed on SuSE and RedHat systems, and a libodbc was on my SuSE system. Libdb-4.2 would help manage some of the SA objects to a file, but is limited in its data storage and retrieval capabilities. If a true relational database couldn't be used, libdb would definitely be useful. - 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] opensm fails to find HCA if port is down.
On Tue, 2006-01-10 at 13:31, Ralph Campbell wrote: If opensm is started with no arguments, the default algorithm for finding a port to bind to will skip ports which are present but the link is DOWN. If there is only one port in the system, no port is selected and opensm tries the default HCA name mthca0 which, if not present, confuses opensm and it exits. The following patch changes the port selection so that the first active port is selected, and if none, the first non-disabled port. Signed-off-by: Ralph Campbell [EMAIL PROTECTED] Thanks. Applied. Subsequent patch to follow shortly. ___ 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] opensm fails to find HCA if port is down.
On Tue, 2006-01-10 at 17:51, Hal Rosenstock wrote:
Hi Ralph,
On Tue, 2006-01-10 at 17:47, Ralph Campbell wrote:
I understand. Maybe it should be the first active, if none, then the
first UP, and if none, the first !disabled.
Exactly. I think one more loop (first checking physical state for linkup
and then checking for not disabled) will take care of it. I'm working on
it now as a patch on your patch which I will post.
In libibumad/umad,c::resolve_ca_port, default algorithm is to prefer
ports which are active, then those whose physical state is link up, and
finally those ports whose physical state is not disabled.
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Index: umad.c
===
--- umad.c (revision 4904)
+++ umad.c (working copy)
@@ -244,7 +244,7 @@ resolve_ca_port(char *ca_name, int *port
DEBUG(checking port %d, i);
if (!ca.ports[i])
continue;
- if (up 0 ca.ports[i]-phys_state != 3)
+ if (up 0 ca.ports[i]-phys_state == 5)
up = *port = i;
if (ca.ports[i]-state == 4) {
active = *port = i;
@@ -253,6 +253,18 @@ resolve_ca_port(char *ca_name, int *port
}
}
+ if (active == -1 up == -1) { /* no active or linkup port found */
+ for (i = 0; i = ca.numports; i++) {
+ DEBUG(checking port %d, i);
+ if (!ca.ports[i])
+ continue;
+ if (ca.ports[i]-phys_state != 3) {
+ up = *port = i;
+ break;
+ }
+ }
+ }
+
release_ca(ca);
if (active = 0)
___
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] SA cache design
On Tue, Jan 10, 2006 at 03:00:46PM -0800, Sean Hefty wrote: I did find that libdb-4.2 was installed on SuSE and RedHat systems, and a libodbc was on my SuSE system. Libdb-4.2 would help manage some of the SA objects to a file, but is limited in its data storage and retrieval capabilities. If a true relational database couldn't be used, libdb would definitely be useful. I forgot to point out postgres: http://www.postgresql.org/about/ Several packages (e.g. postfix, ldap) offer different backends so the admin can decide how sophisticated the data storage and retrieval needs to be. With roughly 150K employees, HP has a rather sophisticated LDAP/postfix setup to manage logins. But I don't need that for the 10 boxes I manage outside the firewall. Same is probably true for SA cache. grant ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [MailServer Notification]To Recipient file blocking settings matched and action taken.
ScanMail for Microsoft Exchange has blocked an attachment. Sender = [EMAIL PROTECTED] Recipient(s) = Openib Subject = [openib-general] CMS FOREX Scanning time = 1/10/2006 4:23:46 PM Action on file blocking: The attachment forex.exe matches the file blocking settings. ScanMail has Quarantined it. The attachment was quarantined to C:\Program Files\Trend\Smex\Alert\forex43c450121.exe_. Warning to Recipient: Action taken by attachment blocking. ___ 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] [MailServer Notification]To Recipient file blocking settings matched and action taken.
ScanMail for Microsoft Exchange has blocked an attachment. Sender = Starkest F. Volcanoes Recipient(s) = Openib Subject = SPAM: [openib-general] CMS FOREX Scanning time = 1/10/2006 7:23:53 PM Action on file blocking: The attachment forex.exe matches the file blocking settings. ScanMail has Quarantined it. The attachment was quarantined to C:\Program Files\Trend\Smex\Alert\forex43c450194.exe_. Warning to Recipient: Action taken by attachment blocking. ___ 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] [MailServer Notification]To Recipient file blocking settings matched and action taken.
ScanMail for Microsoft Exchange has blocked an attachment. Sender = Starkest F. Volcanoes Recipient(s) = Openib Subject = SPAM: [openib-general] CMS FOREX Scanning time = 1/10/2006 7:23:53 PM Action on file blocking: The attachment forex.exe matches the file blocking settings. ScanMail has Quarantined it. The attachment was quarantined to C:\Program Files\Trend\Smex\Alert\forex43c450195.exe_. Warning to Recipient: Action taken by attachment blocking. ___ 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] [MailServer Notification]To Recipient file blocking settings matched and action taken.
ScanMail for Microsoft Exchange has blocked an attachment. Sender = Starkest F. Volcanoes Recipient(s) = Openib Subject = SPAM: [openib-general] CMS FOREX Scanning time = 1/10/2006 7:23:53 PM Action on file blocking: The attachment forex.exe matches the file blocking settings. ScanMail has Quarantined it. The attachment was quarantined to C:\Program Files\Trend\Smex\Alert\forex43c4501a6.exe_. Warning to Recipient: Action taken by attachment blocking. ___ 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] [MailServer Notification]To Recipient file blocking settings matched and action taken.
ScanMail for Microsoft Exchange has blocked an attachment. Sender = Starkest F. Volcanoes Recipient(s) = Openib Subject = SPAM: [openib-general] CMS FOREX Scanning time = 1/10/2006 7:23:54 PM Action on file blocking: The attachment forex.exe matches the file blocking settings. ScanMail has Quarantined it. The attachment was quarantined to C:\Program Files\Trend\Smex\Alert\forex43c4501a7.exe_. Warning to Recipient: Action taken by attachment blocking. ___ 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] SA cache design
Grant Grundler wrote: I forgot to point out postgres: http://www.postgresql.org/about/ This looks like it would work well. The question that I have for users is: Is it acceptable for the cache to make use of a relational database system? The disadvantage is that a RDMS would need to be installed and configured on several, or all systems. (It's not clear to me yet how much of that could be automated.) The advantage is that the cache would gain the benefits of having a database backend - notably support for more complex queries, persistent storage, and indexing to increase query performance. To provide some additional context, path record queries can be fairly complex, involving a number of fields. (All queries today are limited to sgid, dgid, and pkey.) Trying to efficiently retrieve a path record based on a dgid and pkey is non-trivial, and support for queries with additional restrictions or for other SA records complicates this issue. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Re: ib_sdp ERR: IOCB dmesg output
On Sun, Dec 11, 2005 at 09:53:41AM -0800, Grant Grundler wrote: ... I might have spoken too soon...I just started getting ERR output from ib_sdp running netperf TCP_STREAM over SDP on the IA64 rx2600's. I killed and restarted the sdpstream script. It seems to be working. I've not yet seen this type of error running r4344 on a different box. If it's not obvious what's wrong, I can try r4344 on the rx2600's as well. ... ib_sdp ERR: IOCB -1 cancel 0 flag 0340 size 8197:0:8197 ib_sdp ERR: IOCB -1 cancel 0 flag 0340 size 16384:0:16384 ib_sdp ERR: IOCB -1 cancel 0 flag 0340 size 49152:0:49152 I'm still seeing similar errors with 2.6.15 + svn 4800 and have another bit of data. Main problem is impact to performance: http://gsyprf3.external.hp.com/openib/rx2600-r4800/sdpstream.png I've parked the dmesg output here: http://gsyprf3.external.hp.com/openib/rx2600-r4800/sdp-errors After loading the drivers, iteratively running netperf to generate the data points (with LD_PRELOAD), I tried to unload all of IB modules but end up with: gsyprf3:~# lsmod Module Size Used by ib_sdp227136 9 ib_cm 93964 1 ib_sdp ib_sa 25324 1 ib_sdp ib_mad 85952 2 ib_cm,ib_sa ib_core93096 4 ib_sdp,ib_cm,ib_sa,ib_mad I'm not sure who is holding the reference counts to ib_sdp. At this point no netperf processes are running. But some wq still have references (as root, lsof | fgrep sdp): sdp_wq/0 3893 root cwd DIR8,34096 2 / sdp_wq/0 3893 root rtd DIR8,34096 2 / sdp_wq/0 3893 root txt unknown /proc/3893/exe sdp_wq/1 3894 root cwd DIR8,34096 2 / sdp_wq/1 3894 root rtd DIR8,34096 2 / sdp_wq/1 3894 root txt unknown /proc/3894/exe [EMAIL PROTECTED]:~$ ps -ef | grep sdp root 389311 0 Jan08 ?00:00:00 [sdp_wq/0] root 389411 0 Jan08 ?00:00:00 [sdp_wq/1] It's likely the userspace openib libs are out of sync. But I don't expect that's relevant to SDP or IPoIB (kernel drivers). This is in contrast to another box running identical kernel + modules: iowa:~# lsmod Module Size Used by ib_uverbs 93096 0 ib_sdp227136 0 ib_cm 93964 1 ib_sdp ib_ipoib 95992 0 ib_sa 25324 2 ib_sdp,ib_ipoib ib_mthca 275136 0 ib_mad 85952 3 ib_cm,ib_sa,ib_mthca ib_core93096 7 ib_uverbs,ib_sdp,ib_cm,ib_ipoib,ib_sa,ib_mthca,ib_mad iota was the target of netperf on gsyprf3 (ie iowa was running netserver with LD_PRELOAD as well). Given the number of recent bug fixes since 4800, I will update and try again later this week. thanks, grant ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] RE: [Ips] iSER API's
Eddy hi, As you can see, there are no responses. I guess that leaves only the option of reading the header files/code. Dan On 1/10/06, Dan Bar Dov [EMAIL PROTECTED] wrote: Eddy hi, OpenIB maintains a WIKI at https://openib.org/tiki/tiki-index.php However I'm not sure it contains any ib_verbs documentation. I'm CCing the openib mailing list, maybe someone there knows where you can find documentation. Dan From: Eddy Quicksall [mailto:[EMAIL PROTECTED] Sent: Monday, January 09, 2006 10:55 PM To: Dan Bar Dov Subject: Re: [Ips] iSER API's I assume ib_verbs is for Infiniband. Am I correct? Where can I get the ib_verbs API documentation? Eddy - Original Message - From: Dan Bar Dov To: John Hufferd ; Eddy Quicksall ; ips@ietf.org Sent: Sunday, January 08, 2006 8:50 PM Subject: RE: [Ips] iSER API's Indeed on Linux the direction is towards a generic RDMA interface. CMA provides a generic CM abstraction, and the ib_verbs API is planned to extend over iWARP one way or another. The DM was deemed unnecessary, the API between iSCSI SCSI and the underlying iSER enforced redesign of the iSER API to conform with iSCSI and SCSI rather then implement yet another layer between iSER and iSCSI/SCSI (namely DM). Dan From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hufferd Sent: Friday, January 06, 2006 11:18 PM To: Eddy Quicksall; ips@ietf.org Subject: RE: [Ips] iSER API's Eddy, What APIs are you asking about? The SCSI CLASS Driver to the Device Driver (Mini Port Driver) should have the same interfaces for iSER as it is available for iSCSI. If you mean between the Device Driver (Mini Port Driver) and the RNIC, that will probably be the RNIC vendors interface if they have implemented all or part of the iSER or Data Mover in the RNIC itself, or the RNIC vendor's interfaces to their version of the verbs (at least until the OS implements its own RDMA interfaces that implement the RDMA verbs). I believe that, over time, most OSs will have generic RDMA interfaces, which can be use by all certified RNIC hardware, and any application (user space or kernel space); in that case the iSER module will probably interface to that OS's RDMA interfaces. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc [EMAIL PROTECTED] Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eddy Quicksall Sent: Friday, January 06, 2006 11:42 AM To: ips@ietf.org Subject: [Ips] iSER API's Is there any work afoot to design some standard iSER API's? Eddy ___ 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] RE: [Ips] iSER API's
Hi, On Tue, 2006-01-10 at 22:03, Dan Bar Dov wrote: Eddy hi, As you can see, there are no responses. I guess that leaves only the option of reading the header files/code. ib_verbs is not just for InfiniBand. It also (will) accomodate RDMA over ethernet as well. The best documentation is indeed the header file. You can direct specific questions to this list. -- Hal Dan On 1/10/06, Dan Bar Dov [EMAIL PROTECTED] wrote: Eddy hi, OpenIB maintains a WIKI at https://openib.org/tiki/tiki-index.php However I'm not sure it contains any ib_verbs documentation. I'm CCing the openib mailing list, maybe someone there knows where you can find documentation. Dan From: Eddy Quicksall [mailto:[EMAIL PROTECTED] Sent: Monday, January 09, 2006 10:55 PM To: Dan Bar Dov Subject: Re: [Ips] iSER API's I assume ib_verbs is for Infiniband. Am I correct? Where can I get the ib_verbs API documentation? Eddy - Original Message - From: Dan Bar Dov To: John Hufferd ; Eddy Quicksall ; ips@ietf.org Sent: Sunday, January 08, 2006 8:50 PM Subject: RE: [Ips] iSER API's Indeed on Linux the direction is towards a generic RDMA interface. CMA provides a generic CM abstraction, and the ib_verbs API is planned to extend over iWARP one way or another. The DM was deemed unnecessary, the API between iSCSI SCSI and the underlying iSER enforced redesign of the iSER API to conform with iSCSI and SCSI rather then implement yet another layer between iSER and iSCSI/SCSI (namely DM). Dan From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hufferd Sent: Friday, January 06, 2006 11:18 PM To: Eddy Quicksall; ips@ietf.org Subject: RE: [Ips] iSER API's Eddy, What APIs are you asking about? The SCSI CLASS Driver to the Device Driver (Mini Port Driver) should have the same interfaces for iSER as it is available for iSCSI. If you mean between the Device Driver (Mini Port Driver) and the RNIC, that will probably be the RNIC vendors interface if they have implemented all or part of the iSER or Data Mover in the RNIC itself, or the RNIC vendor's interfaces to their version of the verbs (at least until the OS implements its own RDMA interfaces that implement the RDMA verbs). I believe that, over time, most OSs will have generic RDMA interfaces, which can be use by all certified RNIC hardware, and any application (user space or kernel space); in that case the iSER module will probably interface to that OS's RDMA interfaces. . . . John L Hufferd Sr. Executive Director of Technology Brocade Communications Systems, Inc [EMAIL PROTECTED] Office Phone: (408) 333-5244; eFAX: (408) 904-4688 Alt Office Phone: (408) 997-6136; Cell: (408) 627-9606 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eddy Quicksall Sent: Friday, January 06, 2006 11:42 AM To: ips@ietf.org Subject: [Ips] iSER API's Is there any work afoot to design some standard iSER API's? Eddy ___ 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 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: Re[PATCH] Opensm - fix forosm_sa_portinfo_record.c
Hi Hal,
You are correct.
Thanks,
Yael
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Hal Rosenstock
Sent: Monday, January 09, 2006 5:39 PM
To: Yael Kalka
Cc: openib-general@openib.org
Subject: [openib-general] Re: Re[PATCH] Opensm - fix
forosm_sa_portinfo_record.c
Hi Yael,
On Mon, 2006-01-09 at 07:29, Yael Kalka wrote:
Hi Hal,
During some tests we've notices that not all compmask fields are
properly checked and compared in the portInfo record query.
Attached is a patch with the missing checks, and addition of some
set/get relevant functions added to the ib_types.h as well.
Just a couple of minor (nit) comments below.
-- Hal
Thanks,
Yael
Signed-off-by: Yael Kalka [EMAIL PROTECTED]
Index: include/iba/ib_types.h
===
--- include/iba/ib_types.h(revision 4809)
+++ include/iba/ib_types.h(working copy)
@@ -3960,6 +3960,33 @@ ib_port_info_get_vl_cap(
*
* SEE ALSO
*/
+/f* IBA Base: Types/ib_port_info_get_init_type
+* NAME
+*ib_port_info_get_init_type
+*
+* DESCRIPTION
+*Gets the VL Capability of a port.
^
init type
+*
+* SYNOPSIS
+*/
+static inline uint8_t
+ib_port_info_get_init_type(
+ IN const ib_port_info_t* const p_pi)
+{
+ return(p_pi-vl_cap 0x0F);
Should this be:
return (uint8_t) (p_pi-vl_cap 0x0F);
+}
+/*
+* PARAMETERS
+*p_pi
+*[in] Pointer to a PortInfo attribute.
+*
+* RETURN VALUES
+*InitType field
+*
+* NOTES
+*
+* SEE ALSO
+*/
[snip...]
-- 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 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] Opensm - clean exit on ^C
Hi Hal,
In revision 3526 you've added a patch that opensm will not handle SIGINT.
This patch is an addition to that patch. If OpenSM doesn't handle SIGINT,
then none of its threads should handle it either.
Yael
-Original Message-
From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
Sent: Monday, January 09, 2006 4:56 PM
To: Yael Kalka
Cc: openib-general@openib.org; Eitan Zahavi
Subject: Re: Re[PATCH] Opensm - clean exit on ^C
Hi Yael,
On Thu, 2006-01-05 at 07:16, Yael Kalka wrote:
Hi Hal,
I've noticed that sometimes when killing OpenSM using ^C not all
threads are killed.
The reason for that is that there are threads that mask the
signalling, and when removing the ^C handling from OpenSM, these
threads still mask the signalling and stay alive as a result.
The following patch fixes this.
Is there one other piece to this ? Doesn't osm_opensm.c need to be
modified to handle SIGINT for OSM_VENDOR_INTF_OPENIB ? Thanks.
void
osm_reg_sig_handler(
IN osm_opensm_t * const p_osm )
{
__p_osm_to_signal = p_osm;
#ifndef OSM_VENDOR_INTF_OPENIB
cl_reg_sig_hdl( SIGINT, __sig_handler );
#endif
-- Hal
Thanks,
Yael
Signed-off-by: Yael Kalka [EMAIL PROTECTED]
Index: include/complib/cl_signal_osd.h
===
--- include/complib/cl_signal_osd.h (revision 4760)
+++ include/complib/cl_signal_osd.h (working copy)
@@ -148,12 +148,14 @@ cl_sig_mask_sigint(void)
#ifdef __WIN__
/* we do not mask kill */
#else
+#ifndef OSM_VENDOR_INTF_OPENIB
sigset_t sigs;
sigemptyset(sigs);
sigaddset(sigs, SIGINT);
pthread_sigmask(SIG_BLOCK, sigs, NULL);
- #endif
+#endif /* OSM_VENDOR_INTF_OPENIB */
+#endif /* __WIN__ */
}
/*
*/
Index: libvendor/osm_vendor_ibumad.c
===
--- libvendor/osm_vendor_ibumad.c (revision 4760)
+++ libvendor/osm_vendor_ibumad.c (working copy)
@@ -244,10 +244,6 @@ umad_receiver(void *p_ptr)
OSM_LOG_ENTER( p_ur-p_log, umad_receiver );
- sigemptyset(sigs);
- sigaddset(sigs, SIGINT);
- pthread_sigmask(SIG_BLOCK, sigs, NULL);
-
for (;;) {
if (!umad
!(umad = umad_alloc(1, umad_size() + MAD_BLOCK_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
