Re: [ewg] Re: [PATCH]IPOIB/CM fix for bug# 906 -OFED-1.3
Eli, can you add the upstream change-log description (commit 727f89d27d623f87a637c1868dc8b6af7103fa19) such that this patch instance in ofed will be documented? Or Sure, I updated the changelog. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: Please pull latest libehca
-Original Message- From: Stefan Roscher [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 19, 2008 12:33 PM To: Vladimir Sokolovsky; ewg@lists.openfabrics.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Please pull latest libehca Please pull the following branch for libehca. git://git.openfabrics.org/~/scm/libehca.git branch: ofed_1_3 changes: * move libehca version to 1.2 * add update ChangeLog Thanks Stefan, Done Regards, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Please pull latest libehca
Please pull the following branch for libehca. git://git.openfabrics.org/~/scm/libehca.git branch: ofed_1_3 changes: * move libehca version to 1.2 * add update ChangeLog Thanks Stefan, ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [PATCH]IPOIB/CM fix for bug# 906 -OFED-1.3
Roland Dreier wrote: OK, applied, although that link points to an HTML-mangled version of the patch, and I also had to figure out why we needed that change and write the patch description myself. Eli, can you add the upstream change-log description (commit 727f89d27d623f87a637c1868dc8b6af7103fa19) such that this patch instance in ofed will be documented? Or ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Please sned me pathces to release notes for OFED 1.3
On Mon, 2008-02-18 at 15:53 +0200, Tziporet Koren wrote: Hi, If you got this mail in the To section it means you own a document in OFED and you have not yet updated it for OFED 1.3. Please send me patches against: git://git.openfabrics.org/~tziporet/docs.git ofed_1_3 diff --git a/ipoib_release_notes.txt b/ipoib_release_notes.txt index bce03d3..9c897e6 100644 --- a/ipoib_release_notes.txt +++ b/ipoib_release_notes.txt @@ -12,6 +12,7 @@ Table of Contents 3. Known Issues 4. DHCP Support of IPoIB 5. High Availability (HA) Service +6. Switching between CM and UD mode === 1. Overview @@ -30,6 +31,8 @@ At load time this can be done by inserting the following line in /etc/modprobe.conf: options ib_ipoib debug_level=integer number +0 shuts debug messages off and a none zero value will turn them on. + At runtime the value can be controlled by writing the following to sysfs: echo integer number /sys/module/ib_ipoib/parameters/debug_level @@ -40,8 +43,37 @@ Note that on some older kernels (like the one supplied with Redhat AS 4.0), the path for inspecting the debug level is different and is as follows: /sys/module/ib_ipoib/debug_level +This version adds support for CM mode for HCAs which do not support Infiniband +Shared Receive Qeueus (SRQ). The detection is done automatically at run time. In +this case, the driver uses RC connections between the peers for transferring IPOIB +traffic. + +Even if the HCA does support SRQ, the administrator can force the driver to not +use SRQs. This can be done by setting the module parameter set_nonsrq. + +This version of ofed introduces improvements to IPOIB by cutting the CPU +overhead in handling both send and receive packets. This will improve operation +in different modes of operation but the change is mostly noticeable for small +UDP message were message rate has increased. + +Support for interrupt moderation was introduced. This is done for HCAs which +support this feature (like Mellanox's mlx4). Controlling moderation params is +done through the ethtool interface. + +ethtool -c ib0 +will display the parameters for ib0. Two kinds of parameters are supported: +rx-usecs, tx_usecs and rx-frames, tx_frames - value for rx and tx are identical. +To change a value you need to do: +ethtool -C ib0 rx-usecs new val +This will change both rx_usecs and tx_usecs for ib0. + +The semantics of the parameters is this: an EQE will be pushed to the event queue +if any of the conditions have been met - *-usecs have elapsed or *-frames were +received since the last time an EQE was generated. Using this helps reduce +interrupt rate generated by the device. + === -3. Known Issues +3. Know Issues === 1. If a host has multiple interfaces, each belonging to a different IP subnet, yet they use the same InfiniBand switch, the host may build an incorrect ARP @@ -149,3 +181,15 @@ The HA service may also be activated manually, via the following command: --with-multicastsupport applications that are using multicast -v verbose output +=== +5. Switching between CM and UD mode +=== + +1. The mode of operation can be set by an entry in the file +/etc/infiniband/openib.conf: +SET_IPOIB_CM=yes = CM mode is enabled +SET_IPOIB_CM=no = UD mode is enabled + +2. The mode of operation can be changed in runtime by writing to a sysfs file: +echo datagram /sys/class/net/ib0/mode sets the mode of ib0 to UD +echo connected /sys/class/net/ib0/mode sets the mode ib0 to CM ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Re: [PATCH]IPOIB/CM fix for bug# 906 -OFED-1.3
On Monday 18 February 2008 23:49:30 Roland Dreier wrote: Here is the link to the patch sent previously: http://lists.openfabrics.org/pipermail/general/2008-February/046463.html OK, applied, although that link points to an HTML-mangled version of the patch, and I also had to figure out why we needed that change and write the patch description myself. Hi Roland, here is the link to my description of this problem. Maybe it will help. http://lists.openfabrics.org/pipermail/ewg/2008-February/005905.html regards Stefan ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Long time, no talk
Hello! I am bored today. I am nice girl that would like to chat with you. Email me at [EMAIL PROTECTED] only, because I am using my friend's email to write this. You will see some of my private pics. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: Please sned me pathces to release notes for OFED 1.3
Olaf Kirch wrote:
Hi Tziporet,
On Monday 18 February 2008 14:53, Tziporet Koren wrote:
rds_release_notes.txt - Olaf
RDS_README.txt - Olaf
I'm attaching a patch for RDS_README, which replaces it with
a newer copy of the manpage. The manpage will also go into
rds-tools, I hope.
Olaf
You forgot the attachment, but Vlad gave it to me from the man page
What about update for the release notes?
I attach them here for your convenience
Tziporet
Open Fabrics Enterprise Distribution (OFED)
RDS in OFED 1.3 Release Notes
February 2008
===
Table of Contents
===
1. Overview
2. Supported Platforms
3. Installation Configuration
4. New Features
5. Bug fixes and Enhancements since OFED 1.2
===
1. Overview
===
RDS socket API. It provides reliable, in-order datagram delivery between
sockets over a variety of transports.
For details see RDS.README.txt.
Also available at:
http://oss.oracle.com/projects/rds/dist/documentation/rds.7.txt
===
2. supported platforms
===
RHEL4.0 Update 3,4,5
RHEL5.0
SLES 10
===
3. Installation Configuration
===
To install RDS select rds in OFED's manual installation or put 'rds=y' in the
ofed.conf for unattended installation.
To load RDS module upon boot edit file '/etc/infiniband/openib.conf' as
follows:
# Load RDS module
RDS_LOAD=yes
===
4. New Features
===
RDS socket send buffers are now per socket, not per flow, and the new receive
buffer value is per socket. So we should use the core stack sndbuf and rcvbuf
values instead of offering a separate interface.
Use the following script to change the default and max socket buffer sysctls
to a 1 MB:
#!/bin/bash
nr=$((1 * 1024 * 1024))
sys=/proc/sys/net/core
for f in {r,w}mem_{default,max}; do
echo $nr $sys/$f
done
===
5. Bug fixes and Enhancements since OFED 1.2
===
1. rds_poll() always returns POLLOUT. If you try to send and get
EWOULDBLOCK because the remote receiver is congested then you don't get
to wait for POLLOUT to be raised before sending again -- it's always
raised. This is worked around by implementing some kind of exponential
back-off while retrying the send. This can be done by increasing the
timeout given to poll(). At each poll() timeout expiry the send is
tried again.
This idea of waking poll() waiters on congestion notification hopes to
cut down on the latency between when the send could succeed and when the
poll() timeout hits and the send is retried. If we receive a congestion
bitmap update from the remote node we wake poll() waiters, giving them a
chance to retry their send.
2. Set max send and receive scatter/gather list size to 2 in the QP attributes.
The second sge used for RDS header.
3. Added rs_poll_flag to rds_socket structure to indicate the back pressure
status and send space availability.
rds_poll set POLLIN in case of released back pressure, send space became
available and if there are messages in the receive queue.
set POLLOUT if send buffer is available
4. Added MODULE_VERSION.
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED teleconference today
Friendly reminder: the OFED teleconference is today (Tuesday, 19 February, 2008). Next few teleconferences: - All are at noon US eastern / 9am US Pacific / 7pm Israel 1. Tuesday, Feb 19, code 210020028 2. Monday, Feb 25, code 210020028 Dial-in information: US/Canada: +1.866.432.9903 India: +91.80.4103.3979 Israel: +972.9.892.7026 Others: http://cisco.com/en/US/about/doing_business/conferencing/ -- Jeff Squyres Cisco Systems ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Please sned me pathces to release notes for OFED 1.3
Please ignore this - I used the wrong branch. I will post a new patch. On Tue, 2008-02-19 at 14:47 +0200, Eli Cohen wrote: On Mon, 2008-02-18 at 15:53 +0200, Tziporet Koren wrote: Hi, If you got this mail in the To section it means you own a document in OFED and you have not yet updated it for OFED 1.3. Please send me patches against: git://git.openfabrics.org/~tziporet/docs.git ofed_1_3 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] update perftest README
Update README Signed-off-by: Oren Meron [EMAIL PROTECTED] --- a/README +++ b/README @@ -1,37 +1,52 @@ -This directory includes gen2 uverbs micro-benchmarks. +Open Fabrics Enterprise Distribution (OFED) +Performance Tests README for OFED 1.2 + + February 2008 -The tests are intended as: - 1) simple, efficient usage examples. - Please see the COPYING file if you intend to copy it literally. - 2) a useful benchmark - e.g. for HW or SW tuning and/or functional testing. - Please post results/observations to the openib-general mailing - list. See http://openib.org/mailman/listinfo/openib-general - and http://www.openib.org Contact Us link for contact details. +=== +Table of Contents +=== +1. Overview +2. Notes on Testing Methodology +3. Test Descriptions +4. Running Tests -Testing methodology +=== +1. Overview +=== +This is a collection of tests written over uverbs intended for use as a +performance micro-benchmark. As an example, the tests can be used for +HW or SW tuning and/or functional testing. -- uses CPU cycle counter to get time stamps without context switch. - Some CPU architectures do NOT have such capability. e.g. Intel 80486 - or older PPC. +Please post results/observations to the openib-general mailing list. +See Contact Us at http://openib.org/mailman/listinfo/openib-general and +http://www.openib.org. -- measures round-trip time but reports half of that as one-way latency. - ie. May not be sufficiently accurate for asymmetrical configurations. + +=== +2. Notes on Testing Methodology +=== +- The benchmark used the CPU cycle counter to get time stamps without context + switch. Some CPU architectures (e.g., Intel's 80486 or older PPC) do NOT + have such capability. + +- The benchmark measures round-trip time but reports half of that as one-way + latency. This means that it may not be sufficiently accurate for asymmetrical + configurations. - Min/Median/Max result is reported. The median (vs average) is less sensitive to extreme scores. - Typically the Max value is the first value measured. + Typically, the Max value is the first value measured. -- larger samples only marginally help. The default (1000) is pretty good. +- Larger samples help marginally only. The default (1000) is pretty good. Note that an array of cycles_t (typically unsigned long) is allocated once to collect samples and again to store the difference between them. - Really big sample sizes (e.g. 1 million) might expose other problems + Really big sample sizes (e.g., 1 million) might expose other problems with the program. -- -H option will dump the histogram for additional statistical analysis. +- The -H option will dump the histogram for additional statistical analysis. See xgraph, ygraph, r-base (http://www.r-project.org/), pspp, or other statistical math programs. @@ -39,79 +54,68 @@ Architectures tested: i686, x86_64, ia64 -Test Descriptions -- +=== +4. Test Descriptions +=== -rdma_lat.c - latency test with RDMA write transactions -rdma_bw.c - streaming BW test with RDMA write transactions +rdma_lat.c latency test with RDMA write transactions +rdma_bw.c streaming BW test with RDMA write transactions The following tests are mainly useful for HW/SW benchmarking. They are not intended as actual usage examples. -- - -send_lat.c - latency test with send transactions -send_bw.c - BW test with send transactions -write_lat.c - latency test with RDMA write transactions -write_bw.c - BW test with RDMA write transactions -read_lat.c - latency test with RDMA read transactions -read_bw.c - BW test with RDMA read transactions - -Test's executable name starts with the general prefix ib_ (e.g. ib_write_lat). -Build Tests +send_lat.c latency test with send transactions +send_bw.c BW test with send transactions +write_lat.clatency test with RDMA write transactions +write_bw.c BW test with RDMA write transactions +read_lat.c latency test with RDMA read transactions +read_bw.c BW test with RDMA read transactions -make to build all tests +The executable name of each test starts with the general prefix ib_, +e.g., ib_write_lat.
[ewg] Re: [ofa-general] Re: [PATCH] IPOIB/CM Increase retry counts for OFED-1.3
The send completion errors indicates the packet hasn't been sent out to the wire. It seems the retries you have added induced a little bit delay for the packet to be sent out successfully, which might indicates some flow control or other issues in the device transport layer? Actually for RC a send completion error can occur if an ACK is not received for the message. It would be useful to know what the status of the first failed send it though. Do you have any suggestions on how to debug this problem? How can we hack the mthca/ipoib code to narrow down the root cause of the problem? From the behavior it looks like the local resource temp unavailable, but it could be something else. I definitely think we want to understand what the problem is. For example does it go away if you increase the RNR retry count but not the ACK timeout retry count? When the problem occurs is the receive SRQ empty (or is it only happening with ehca's non-SRQ IPoIB/cm)? - R. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] ibstatus - small script change
Hal Rosenstock wrote: On Tue, 2008-02-12 at 16:33 -0800, Jeremy Brown wrote: The ibstatus script, in infiniband-diags, doesn't tolerate a missing device very well. This small fix makes the output a bit more useful. Not sure this was seen. Proper email list for patch is general rather than ewg. Maintainer is Sasha Khapyorsky [EMAIL PROTECTED] Is tis needed for RC5? Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED Feb 19 - meeting summary on RC5 readiness
OFED Feb 19 - meeting summary on RC5 readiness: 1. Status update: Intel - OK; Qlogic - may have some IPoIB issue; still work on Intel MPI issue Voltaire - OK; Have some bonding issues but no showstoppers Neteffect - OK; have PPC issue but its not a showstopper Mellanox - OK; update XRC structure; see one IPoIB issue under investigation IBM - OK; MPI issue is minor (some error flow) 2. Bugs review (blocker critical only) 905 blo RHEL [EMAIL PROTECTED] scale-up issue with rdma_cm, requests rejected when excee... Should be fixed (need the patch from Sean) 910 cri All [EMAIL PROTECTED] dat_psp_create_any (v1 and v2) fails on OFED 1.3 rdma_cm,... Fixed 874 cri Othe[EMAIL PROTECTED] Intel MPI (IMB test) hangs intermittently on the qlogic HCA On work - will not stop the release 895 cri Othe[EMAIL PROTECTED] kernel panic while running multiple test on sdp Hard to reproduce - will not stop the release 919 cri SLES[EMAIL PROTECTED] IMB testcase over openmpi fails with segmentation fault Minor issue (error flow) 917 cri SLES[EMAIL PROTECTED] ipath build error on ppc64 Fixed 3. Agreed on dates for RC5 and GA - RC5 Feb-21 - GA a week after RC5 (Feb-28) Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] [PATCH] [OFED 1.3 docs] librdmacm: update release notes for OFED 1.3
Signed-off-by: Sean Hefty [EMAIL PROTECTED] --- rdma_cm_release_notes.txt | 154 + 1 files changed, 86 insertions(+), 68 deletions(-) diff --git a/rdma_cm_release_notes.txt b/rdma_cm_release_notes.txt index 24a07af..8060205 100644 --- a/rdma_cm_release_notes.txt +++ b/rdma_cm_release_notes.txt @@ -1,68 +1,86 @@ -Open Fabrics Enterprise Distribution (OFED) - RDMA CM in OFED 1.3 Release Notes - - February 2008 - - -=== -Table of Contents -=== -1. Overview -2. New Features -3. Known Issues - -=== -1. Overview -=== -The RDMA CM is a communication manager used to setup reliable, connected -and unreliable datagram data transfers. It provides an RDMA transport -neutral interface for establishing connections. The API is based on sockets, -but adapted for queue pair (QP) based semantics: communication must be -over a specific RDMA device, and data transfers are message based. - -The RDMA CM only provides the communication management (connection setup / -teardown) portion of an RDMA API. It works in conjunction with the verbs -API for data transfers. - -=== -2. New Features -=== -The RDMA CM now supports connected, datagram, and multicast data transfers. - -When used over Infiniband, the RDMA CM will make use of a local path record -cache, if it is enabled. On large fabrics, use of the local cache can greatly -reduce connection time. Use of a cache is not necessary for iWarp. - -Man pages have been created to describe the various interfaces and test -programs available. For a full list, users should refer to the rdma_cm.7 man -page. - -=== -3. Known Issues -=== -The RDMA CM relies on the operating system's network configuration tables to -map IP addresses to RDMA devices. Incorrectly configured network -configurations can result in the RDMA CM being unable to locate the correct -RDMA device. Currently, the RDMA CM only supports IPv4 addressing. - -All RDMA interfaces must provide a way to map IP addresses to an RDMA device. -For Infiniband, this is done using IPoIB, and requires correctly configured -IPoIB device interfaces sharing the same multicast domain. For details on -configuring IPoIB, refer to ipoib_release_notes.txt. For RDMA devices to -communicate, they must support the same underlying network and data link -layers. - -If you experience problems using the RDMA CM, you may want to check the -following: - - * Verify that you have IP connectivity over the RDMA devices. For example, - ping between iWarp or IPoIB devices. - - * Ensure that IP network addresses assigned to RDMA devices do not - overlap with IP network addresses assigned to standard Ethernet devices. - - * For multicast issues, either bind directly to a specific RDMA device, or - configure the IP routing tables to route multicast traffic over an RDMA - device's IP address. - - +Open Fabrics Enterprise Distribution (OFED) + RDMA CM in OFED 1.3 Release Notes + + February 2008 + + +=== +Table of Contents +=== +1. Overview +2. New Features +3. Known Issues + +=== +1. Overview +=== +The RDMA CM is a communication manager used to setup reliable, connected +and unreliable datagram data transfers. It provides an RDMA transport +neutral interface for establishing connections. The API is based on sockets, +but adapted for queue pair (QP) based semantics: communication must be +over a specific RDMA device, and data transfers are message based. + + +The RDMA CM only provides the communication management (connection setup / +teardown) portion of an RDMA API. It works in conjunction with the verbs +API for data transfers. + +=== +2. New Features +=== +for OFED 1.3: +Added support for valgrind checks. + +Added quality of service support. Quality of service (QoS) is
[ewg] [PATCH][ofed 1.3 docs] uDAPL release notes updated for OFED 1.3
Signed-off by: Arlin Davis [EMAIL PROTECTED] --- diff --git a/uDAPL_release_notes.txt b/uDAPL_release_notes.txt index 33b684a..84c20d7 100644 --- a/uDAPL_release_notes.txt +++ b/uDAPL_release_notes.txt @@ -1,15 +1,102 @@ - Release Notes for - Gamma 3.3 and OFED 1.3 DAPL Release + OFED 1.3 DAPL Release February 2008 -DAPL GAMMA 3.3/OFED 1.3 RELEASE NOTES +OFED 1.3 RELEASE NOTES This release of the DAPL reference implementation is timed to coincide with OFED release 1.3 of the Open Fabrics (www.openfabrics.org) software stack. + +NEW SINCE OFED 1.2 + +* New Features + 1. Add v2.0 library support for new 2.0 API Specification + 2. Separate v1.2 library release to co-exist with v2.0 libraries. + 3. New dat.conf with both 1.2 and 2.0 support + 4. New v2.0 dtestx utilities to test IB extensions + +* Bug Fixes + + v1.2 and v2.0 + - uDAT: static/dynamic registry parsing fixes + - uDAPL: provider fixes for dat_psp_create_any + - dtest/dapltest: change default provider names to sync with dat.conf + - openib_cma: issues with destroy_cm_id and init/resp exchange + - dapltest: use gettimeofday instead of get_cycles for better portability + - dapltest: endian issue with mem_handle, mem_address + - dapltest fix to include inet_ntoa definitions + - fix build problems on 32-bit and 64-bit PowerPC + - cleanup packaging + + v2.0 + - set default config options to match spec file, --enable-debug --enable-ext-type=ib + - use unique devel target names, libdat2.so, /usr/include/dat2 + - dtestx fix memory leak, freeaddrinfo after getaddrinfo + - Fix for IB extended DTO cookie deallocation on inbound rdma_Write_immed + - WinOF: Update OFED code base to include WinOF changes, work from same code base + - WinOF: add DAT_API definition, __stdcall for windows, nothing for linux + - dtest: add dat_evd_query to check correct size + - openib_cma: add macro to convert SID to PORT + - dtest: endian support for exchanging RMR info + - openib_cma: lower default settings, inline and RDMA init/resp + - openib_cma: missing ia_query for max_iov_segments_per_rdma_write + + v1.2 + - openib_cma: turn down dbg noise level on rejects + - dtest: typo in memset + + +BUILD: v1 and v2 uDAPL source install/build instructions (redhat example): + +# cd to distribution SRPMS directory + cd /tmp/OFED-1.3/SRPMS +rpm -i dapl-1.2*.rpm +rpm -i dapl-2.0*.rpm +cd /usr/src/redhat/SOURCES +tar zxf dapl-1.2*.tgz +tar zxf dapl-2.0*.tgz + + # NON_DEBUG build example for x86_64, using OFED targets + + ./configure --prefix /usr --sysconf=/etc --libdir /usr/lib64 +LDFLAGS=-L/usr/lib64 CPPFLAGS=-I/usr/include + + # build and install + + make + make install + + # DEBUG build example for x86_64, using OFED targets + + ./configure --enable-debug --prefix /usr --sysconf=/etc --libdir /usr/lib64 +LDFLAGS=-L/usr/lib64 CPPFLAGS=-I/usr/include + + # build and install + + make + make install + + # DEBUG messages: set environment variable DAPL_DBG_TYPE, default + mapping is 0x0003 + + DAPL_DBG_TYPE_ERR = 0x0001, + DAPL_DBG_TYPE_WARN = 0x0002, + DAPL_DBG_TYPE_EVD = 0x0004, + DAPL_DBG_TYPE_CM= 0x0008, + DAPL_DBG_TYPE_EP= 0x0010, + DAPL_DBG_TYPE_UTIL = 0x0020, + DAPL_DBG_TYPE_CALLBACK = 0x0040, + DAPL_DBG_TYPE_DTO_COMP_ERR= 0x0080, + DAPL_DBG_TYPE_API = 0x0100, + DAPL_DBG_TYPE_RTN = 0x0200, + DAPL_DBG_TYPE_EXCEPTION = 0x0400, + DAPL_DBG_TYPE_SRQ = 0x0800, + DAPL_DBG_TYPE_CNTR = 0x1000 + + NEW SINCE Gamma 3.2 and OFED 1.1 * New Features ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] ibstatus - small script change
On Tue, 2008-02-19 at 10:02 -0800, Hal Rosenstock wrote: On Tue, 2008-02-12 at 16:33 -0800, Jeremy Brown wrote: The ibstatus script, in infiniband-diags, doesn't tolerate a missing device very well. This small fix makes the output a bit more useful. Not sure this was seen. Proper email list for patch is general rather than ewg. Maintainer is Sasha Khapyorsky [EMAIL PROTECTED] Thanks! I couldn't find a maintainer anywhere, so I just took the most recent entry in the changelog. ...and Tziporet asks, in another e-mail: Is this needed for RC5? It certainly isn't critical; just a nice-to-have change that I'm making internally here at QLogic and figured I'd send upstream. Jeremy ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] ibstatus - small script change
On Tue, 2008-02-19 at 14:39 -0800, Jeremy Brown wrote: On Tue, 2008-02-19 at 10:02 -0800, Hal Rosenstock wrote: On Tue, 2008-02-12 at 16:33 -0800, Jeremy Brown wrote: The ibstatus script, in infiniband-diags, doesn't tolerate a missing device very well. This small fix makes the output a bit more useful. Not sure this was seen. Proper email list for patch is general rather than ewg. Maintainer is Sasha Khapyorsky [EMAIL PROTECTED] Thanks! I couldn't find a maintainer anywhere, so I just took the most recent entry in the changelog. ...and Tziporet asks, in another e-mail: Is this needed for RC5? It certainly isn't critical; just a nice-to-have change that I'm making internally here at QLogic and figured I'd send upstream. BTW, what's the use case: Just ibstatus with an ipath HCA ? -- Hal Jeremy ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
