Ian,
An iSER target is basically an iSCSI
target with an add-on of an iSER transport
As you may know Voltaire contributed the
iSER Initiator and also has a full Target implementation that was tested with
it
There are few Target solutions that are
possible:
There is at least one
Hello,
Included patch adds O_ASYNC support for uverbs event handling.
Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
Index: trunk/src/linux-kernel/infiniband/core/uverbs_main.c
===
---
On Tue, 2005-07-05 at 11:22, Eitan Zahavi wrote:
Hi Hal,
In INSTALL, it states:
Software Dependencies
=
IBMgtSim depends on: tcl8.3/8.4, OpenSM 1.7.0 and ibdm 1.0
What are the specific dependencies on OpenSM 1.7.0 ?
[EZ] Actually it should say 1.7.0 and
I
would like to clarify the comment on SRP. There are companies presently
shipping and demonstrating SRP native IB storage. For
example:
Engenio (formerly LSI)
Raytheon
Data Direct
Mellanox
SRP
was designed for highly optimized storage access across an RDMA capable
transport, and
Hello！
We plan to run lustre on InfiniBand. But now lustre does not support IB.
I know noting about the IB stack. So I think the IB Upper Layer Protocol(SDP,
DAP) could be used to transport data for lustre.
But there are too many ULPs over IB. I know little about them. As far
as I
Title: RE: Some IBMgtSim Questions and Nits
Did either of these formats change at 1.7.0 (from 1.6.1) ? (You also
mentioned osm.fdbs somewhere else; did that format change ?)
[EZ] Not sure about that. I have to lookup the old code tree.
Also there are a number of files in this
Title: RE: IBDM - IB DataModel build issues fixed - full version
Why does the TOPSYSTEM need to be identified ? Is it just a way of
not
having it as the first file in the system definition ?
[EZ] Actually the definition is required to be declare before use ...
Can you elaborate a
The quick answer here is none of SDP, iSER/SRP or uDAPL for different
reasons on each case
kDAPL is the kernel API that is designed to handle a kernel application
such as NFS, Lustre or the like. See:
http://www.datcollaborative.org/kdapl.html
There is are already implementations of
Quoting ?? [EMAIL PROTECTED]:
Subject: how to choose appropriate ULPs for application
We plan to run lustre on InfiniBand. But now lustre does not support IB.
If it currently works on top of sockets, SDP is the fastest way
to get it running on InfiniBand, with good performance.
You
Thank you very much!
I'll read the materials that you supply.
I have not described my plan clearly. I don't konw how to run lustre
on IB. Neither do I konw the lustre running in kernel space or user
space. Now the lustre NAL does not supports IB vapi. If I use IPoIB,
it works. But it doen
I would also recommend studying DAFS, and in particular
the differences between DAFS and NFS over RDMA.
NFS over RDMA leaves most of the existing file system
logic intact and basically optimizes the exchange of
individual messages over RDMA.
Using SDP would be a somewhat similar strategy,
with
The IB spec says A GID is a valid 128-bit IPv6 address (per RFC 2373)
with additional properties / restrictions defined within IBA to
facilitate efficient discovery, communication, and routing., so I don't
think it needs to say much more. [Perhaps the IB specification should
refer to the more
Hi Eitan and Hal,
On Tue, Jul 05, 2005 at 02:23:57PM +0300, Eitan Zahavi wrote:
Hi Ber,
Thanks.
I have used an ex script to fix the following typos on all the code tree's I
own.
In the future - it is much better from my perspective to simply get the list
of words I need to check for.
I hope you
I looked further into the whole gen1 source tree.
There is no consumer of this useraccess_cm API
(ioctl). Are there any consumers of this API's. Is it
supported ?
Thanks,
Vish
--- viswanath krishnamurthy [EMAIL PROTECTED] wrote:
Is there a sample code (examples) to use the gen1
stack user
At 06:14 AM 7/6/2005, Rimmer, Todd wrote:
I would like to clarify the
comment on SRP. There are companies presently shipping and
demonstrating SRP native IB storage. For example:
Engenio (formerly
LSI)
Raytheon
Data Direct
Mellanox
SRP was designed for
highly optimized storage access
Eliminating the DAT_RETURN detail information is a strange
choice, but certainly within the realm of options available
to any implementation. No DAPL consumer should rely on the
more detailed information. It is strange because it may
encourage people to code from uDAPL in order to get more
Thanks for adding this. A few questions:
+static int ib_uverbs_event_async (int fd, struct file *filp, int on)
+{
+ int ret;
+ struct ib_uverbs_event_file *file = filp-private_data;
+
+ if (!file)
+ return -EBADFD;
Can this function ever be called on a
This looks good. Go ahead and check it in when the userspace side is
ready.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit
This looks good as well. Go ahead and check it in.
- 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
The current sdp_conn_put/sdp_conn_hold implementation
seems to be subject to the following race condition:
- thread A calls sdp_conn_put, atomic dec and test returns 0
- thread B looks up the connection and calls sdp_conn_get,
incrementing the reference count back to 1
- thread A now goes on to
Protect sdp_conn_put by dev_root_s.sock_lock.
Add sdp_conn_put_light for when we know its not the last reference.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index: ulp/sdp/sdp_conn.c
===
--- ulp/sdp/sdp_conn.c (revision
Use sdp_conn_put_light in cases when we know there is another
reference on the connection.
Rule: sdp_conn_put should never be called on a locked connection:
since its safe to sdp_conn_unlock, this is not the last reference.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Index:
On Wed, 2005-07-06 at 13:47, Roland Dreier wrote:
This looks good as well. Go ahead and check it in.
Thanks. Applied.
-- Hal
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe,
On Wed, 2005-07-06 at 13:46, Roland Dreier wrote:
This looks good. Go ahead and check it in when the userspace side is
ready.
Thanks. Applied.
WARNING:
Note that this is another flag day (ABI_VERSION change for libibumad so
OpenSM and diagnostics need updating and rebulding.
r2814 is the
On Tue, 2005-07-05 at 03:24, Michael S. Tsirkin wrote:
Hal, Shahar, could you please move the following files
outside the src directory?
./trunk/src/userspace/management/osm/doc/OpenSM_RN.pdf
./trunk/src/userspace/management/osm/doc/OpenSM_UM.pdf
These are not sources, so they dont belong
MAD RMPP: Minor build changes
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Index: mad_rmpp.h
===
--- mad_rmpp.h (revision 2815)
+++ mad_rmpp.h (working copy)
@@ -33,10 +33,8 @@
*/
#ifndef __MAD_RMPP_H__
-#define
How does this patch look?
Do you have a test program you're using to check SIGIO-based event
handling? If so can you post it?
Thanks,
Roland
--- infiniband/core/uverbs.h(revision 2815)
+++ infiniband/core/uverbs.h(working copy)
@@ -62,6 +62,7 @@ struct ib_uverbs_event_file {
Quoting r. Hal Rosenstock [EMAIL PROTECTED]:
Subject: Re: documentation under src dir
On Tue, 2005-07-05 at 03:24, Michael S. Tsirkin wrote:
Hal, Shahar, could you please move the following files
outside the src directory?
./trunk/src/userspace/management/osm/doc/OpenSM_RN.pdf
Roland and Michael,
* On Jul,4 Roland Dreier[EMAIL PROTECTED] wrote :
Sayantan I am facing a compile problem with the following error:
Sayantan drivers/infiniband/core/uverbs_main.c: In function
Sayantan `ib_uverbs_add_one':
Sayantan
On Wed, 2005-07-06 at 19:46, Sayantan Sur wrote:
Thanks for the information. I was able to compile the kernel components
against 2.6.12. On installing the entire OpenIB stack, I am getting an
error like this:
[EMAIL PROTECTED]:~] ibstat
CA 'mthca0'
CA type: MT23108
Number
30 matches
Mail list logo
