Could you please stop that comitte crap?
James, what do you think about doing an s/DAT/RDMA/ and s/dat/rdma/
on the code so we can stop this endless mess? In the end it won't
look like dat anyway, and the sooner why make that absolutely clear
that less idiocy like this is going to happen.
sa_query: Add service record support
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Index: include/ib_sa.h
===
--- include/ib_sa.h (revision 2757)
+++ include/ib_sa.h (working copy)
@@ -1,5 +1,6 @@
/*
* Copyright (c)
Am Dienstag, den 28.06.2005, 15:32 -0700 schrieb Libor Michalek:
On Tue, Jun 28, 2005 at 09:15:21AM +0200, Arne Redlich wrote:
Am Montag, den 27.06.2005, 11:35 -0700 schrieb Libor Michalek:
On Wed, Jun 22, 2005 at 10:39:43AM +0200, Arne Redlich wrote:
Hi,
I'm trying to use SDP
Taking an interface because it has a user base, and then
ignoring that user base is just plain idiotic.
If you want to design your own RDMA interface do so.
But changing DAT to meet your whims rather than
actual code requirements makes no sense. If you
can't come up with something that remains
On Wed, 2005-06-29 at 20:19 -0700, Caitlin Bestler wrote:
Source compatability for an existing Provider is *not* maintained by
OpenIB
kDAPL because there are fields *missing* from the Provider Info. That
*will*
result in a compilation error.
I have no problem with there being a header file
On Thu, Jun 30, 2005 at 08:38:45AM -0700, Caitlin Bestler wrote:
actual code requirements makes no sense. If you
can't come up with something that remains acceptable
to the broader community of DAT users then you should
refrain from using the dat_ symbols and their already
established
That is the primary distinction between an IA Address and an IP Address.
An IA Address meets all of the *local* characteristics of an IP Address,
but does not necessarily meet the *global* characteristics of an IP Address
(namely it might not have been assigned by IANA).
But there is nothing that
On Thu, Jun 30, 2005 at 08:40:12AM -0700, Tom Duffy wrote:
I have no problem with there being a header file with allows for source
compatibility. This header would be maintained by OpenIB, but never
included in upstream. I think James has a start of such a header called
kdat.h. It needs a
And please everyone stop Cc'ing the subscribers only yahoogroups thing,
the bounce message is totally anoying.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit
That is a reasonable migration plan, as long as rebuild
is the only step required after fetching and placing the
kdat.h file.
-Original Message-
From: Tom Duffy [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 8:40 AM
To: Caitlin Bestler
Cc: [EMAIL PROTECTED];
Hello,
Comments inline.
James Lentini wrote:
I'd like to summarize the discussion we've been having around
addressing and start a new email thread with a more appropriate title.
First off, here is there requirement we are trying to satisfy:
kDAPL consumers use an Internet Protocol (IP)
This is a quick outline of the changes required to
make ib_verbs.h transport neutral. Some of the changes
were actually required anyway to fully support IB 1.2.
Most verbs are nominally unchanged. The differences are
in the exact data formats and in some semantic details.
These changes will
This is a list of structural differences in between OpenIB's
gen2 verbs and RNIC-PI that will remain even after gen2 is made
transport neutral.
After these distinctions are understood, a decision should be made as to
whether the differences represent different objectives and should be
merely
Shirley I did netperf test over Mellanox 23108 4X HCA against
Shirley r2720, after a while the HCA stopped to accept packets.
Shirley I am pretty sure it's a bug in driver not IPoIB. rmmod
Shirley ib_ipoib didn't help, after removing ib_mthca, and
Shirley restarted, the driver
On Thu, Jun 30, 2005 at 08:52:54AM -0700, Caitlin Bestler wrote:
structs:
typically struct ib_xyz is transformed as follows:
struct ib_xyz {
/* Only IB specific fields remain */
/* In some cases fields have been split, because
* iWARP allows
Shirley It could be a firmware problem. I used 3.3.2 firmware,
Shirley the sender side had this problem. The receiver side was
Shirley OK. Anyway after back to 3.2.0 firmware, it's OK now.
Hmm, if firmware makes a difference then it is either a firmware bug
or a very subtle timing
Christoph wrote,
On Thu, Jun 30, 2005 at 08:38:45AM -0700, Caitlin Bestler wrote:
actual code requirements makes no sense. If you
can't come up with something that remains acceptable
to the broader community of DAT users then you should
refrain from using the dat_ symbols and their already
-Original Message-
From: Christoph Hellwig [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 9:03 AM
To: Caitlin Bestler
Cc: openib-general; [EMAIL PROTECTED]
Subject: Re: [openib-general] Making gen2 transport neutral
On Thu, Jun 30, 2005 at 08:52:54AM -0700, Caitlin
Christoph Even better make the methods implementing them optional
Christoph and let the upper layer return EOPNOTSUPP when it's not
Christoph implemeneted.
That's what the current drivers/infiniband code does, except we use
ENOSYS. However I have no objection to changing to
Libor Michalek wrote:
Assume that the userspace 'struct ib_cm_event' contains the cm_id as
well as a new 'u64 context' which is inherited from the cm_id, and is
set at the time of the cm_id creation. This is what I'm assuming that
Arlin would like to see.
In the case of two threads
On Thu, Jun 30, 2005 at 09:09:47AM -0700, Caitlin Bestler wrote:
If there's a citation in coding standards somewhere that
makes this a closed issue please cite it. That would close
the discussion quickly.
It's far too highlevel for the coding standards documents we have.
Maybe I'll find time
Robert I think that your suggestion to s/DAT/RDMA makes sense,
Robert since this code is quickly becoming the RDMA transport
Robert independent interface for Linux, rather than trying to
Robert RNIC-PI unionize the IB core layer to make it support both
Robert IB and iWarp.
I
On Thu, Jun 30, 2005 at 09:18:20AM -0700, Roland Dreier wrote:
Robert I think that your suggestion to s/DAT/RDMA makes sense,
Robert since this code is quickly becoming the RDMA transport
Robert independent interface for Linux, rather than trying to
Robert RNIC-PI unionize the
Hal Rosenstock wrote:
mad_rmpp: Fix non first segment copying in ib_coalesce_recv_mad
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Thanks! Committed.
- Sean
___
openib-general mailing list
openib-general@openib.org
Christoph Well, the plan was to take the parts of the DAT API
Christoph that make sense and put them into that generic RDMA
Christoph layer. DAT advocates claimed there were such useful
Christoph higherlevel abstractions, but the more I look at the
Christoph dat/dat-provider
user_mad: Add receive side RMPP support
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Index: user_mad.c
===
--- user_mad.c (revision 2757)
+++ user_mad.c (working copy)
@@ -176,7 +176,7 @@
if (mad_recv_wc-wc-status !=
-Original Message-
This is a quick outline of the changes required to make ib_verbs.h
transport neutral. Some of the changes were actually
required anyway to
fully support IB 1.2.
Same comment on the following structure, it is not an RDMA
transport independent structure,
Hal Rosenstock wrote:
- if (count sizeof (struct ib_user_mad) + 256) /* until RMPP supported */
+ if (count sizeof (struct ib_user_mad) + 256)
return -EINVAL;
Does it make more sense to use sizeof(struct ib_mad) rather than 256?
- Sean
You still must deal with connection management and many error
conditions in a transport neutral fashion.
Typo: transport *dependent* fashion.
___
openib-general mailing list
openib-general@openib.org
Roland wrote,
I disagree. It doesn't make sense to me for us to add an abstraction
layer on top of another abstraction layer -- let's just fix the first
abstraction layer.
If we follow the approach of changing the name of DAT to RDMA and then
putting it in the kernel, we end up with a stack that
On Thu, 2005-06-30 at 12:34, Sean Hefty wrote:
Hal Rosenstock wrote:
- if (count sizeof (struct ib_user_mad) + 256) /* until RMPP supported
*/
+ if (count sizeof (struct ib_user_mad) + 256)
return -EINVAL;
Does it make more sense to use sizeof(struct ib_mad) rather
At 10:39 PM 6/29/2005, Bill Strahm wrote:
--
Message: 2
Date: Wed, 29 Jun 2005 09:00:37 -0700
From: Roland Dreier [EMAIL PROTECTED]
Subject: Re: [openib-general] IP addressing on InfiniBand networks
To: Caitlin Bestler [EMAIL PROTECTED]
Cc: Lentini, James [EMAIL
Christoph wrote,
Well, the plan was to take the parts of the DAT API that make sense
and put them into that generic RDMA layer. DAT advocates claimed there
were such useful higherlevel abstractions, but the more I look at
the dat/dat-provider codebase I doubt there's a lot of them.
One example
user_mad: Add receive side RMPP support
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Index: user_mad.c
===
--- user_mad.c (revision 2760)
+++ user_mad.c (working copy)
@@ -176,7 +176,7 @@
if (mad_recv_wc-wc-status !=
We have to keep in mind that DAT was designed for a broader
purpose than what is proposed for RDMA verbs. It was designed
to support transport *and* OS neutral applications that could
be migrated easily in a number of ways: transport, form OS to
OS, from user to kernel, etc.
So in some ways DAT
Caitlin Bestler wrote:
We have to keep in mind that DAT was designed for a broader
purpose than what is proposed for RDMA verbs. It was designed
to support transport *and* OS neutral applications that could
be migrated easily in a number of ways: transport, form OS to
OS, from user to kernel,
Sean Hefty wrote:
Caitlin Bestler wrote:
We have to keep in mind that DAT was designed for a broader
purpose than what is proposed for RDMA verbs. It was designed
to support transport *and* OS neutral applications that could
be migrated easily in a number of ways: transport, form OS to
OS,
On 6/30/05, Bob Woodruff [EMAIL PROTECTED] wrote:
Catlin wrote,
application - DAT Layer --- RDMA Verbs
model-specific code
\ ^
\ /
Michael Being the person who led the addressing definition for
Michael IB, I can state quite clearly that GID are NOT IPv6
Michael addresses. They were intentionally defined to have a
Michael similar look-n-feel since they were derived in large part
Michael from Future I/O
Carlin wrote,
True.
My assumption is that each transport would have its
own CM module with similar, but not identical APIs.
An application wants to go direct it could do the
if/else ifs on its own.
If the application will have to have if/else for some functions,
then it already has to be
It was pointed out to me that comparing tx_tail and tx_head directly
is not safe, since they're unsigned ints that will eventually wrap.
Therefore we need to take their difference as signed ints and check that.
Does this look right? Did I miss any other spots?
- R.
Index:
On Wed, 29 Jun 2005, Roland Dreier wrote:
James - IB services (both kernel and user space) will be configured using
James IP addresses. By IB services, I'm referring to protocols that are
James layered directly on top of the InfiniBand protocols (e.g. SDP,
James NFS-RDMA, iSER,
Looking at the code, I have to say that I don't like the strategy of
returning the actual length of the MAD but not copying anything if the
MAD is too big. It seems error prone to return a length bigger than
the user passed in to read(), and it doesn't feel right either.
I understand and agree
On Thu, 30 Jun 2005, Tom Duffy wrote:
On Wed, 2005-06-29 at 20:19 -0700, Caitlin Bestler wrote:
Source compatability for an existing Provider is *not* maintained
by OpenIB kDAPL because there are fields *missing* from the
Provider Info. That *will* result in a compilation error.
I have no
On Thu, Jun 30, 2005 at 09:13:28AM -0700, Sean Hefty wrote:
Libor Michalek wrote:
Assume that the userspace 'struct ib_cm_event' contains the cm_id as
well as a new 'u64 context' which is inherited from the cm_id, and is
set at the time of the cm_id creation. This is what I'm assuming
This patch changes sdp to use Linux native lists for the listen conn
list.
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
===
---
The following patch moves verification of the cm_id state higher up
in the CM function calls. This fixes an issue trying to allocate a
message for a cm_id that may be in an invalid state, which could
result in a crash.
This problem was first reported by Hal a while ago, but was recently
hit by
Roland Dreier wrote:
I understand and agree with the sentiment of not wanting to add
another ioctl() to get the length. Instead, how about returning a
ib_user_mad_hdr with a status of ENOSPC and putting the actual length
somewhere. I'm not sure if it's better to change the ABI and add a
length
On Thu, 2005-06-30 at 14:45, Roland Dreier wrote:
Looking at the code, I have to say that I don't like the strategy of
returning the actual length of the MAD but not copying anything if the
MAD is too big. It seems error prone to return a length bigger than
the user passed in to read(), and
From: Sean Hefty [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 2:32 PM
Roland Dreier wrote:
I understand and agree with the sentiment of not wanting to add
another ioctl() to get the length. Instead, how about returning a
ib_user_mad_hdr with a status of ENOSPC and putting
On Thu, 2005-06-30 at 17:32, Sean Hefty wrote:
Roland Dreier wrote:
I understand and agree with the sentiment of not wanting to add
another ioctl() to get the length. Instead, how about returning a
ib_user_mad_hdr with a status of ENOSPC and putting the actual length
somewhere. I'm not
Fab Tillier wrote:
Why not just expect the user to read a MAD until the read returns zero?
I'm thinking something like this:
read( offset = 0, len = 256 )
read( offset 256, len = value determined by first read? )
So a read at offset 0 would block waiting for the next MAD, but a read with a
From: Sean Hefty [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 30, 2005 2:46 PM
Fab Tillier wrote:
Why not just expect the user to read a MAD until the read returns zero?
I'm thinking something like this:
read( offset = 0, len = 256 )
read( offset 256, len = value determined by
Fab Tillier wrote:
The user would need to know how large of a buffer to allocate for the read.
If the user needs to allocate two buffers, then they either need to be
able to process data the spans multiple buffers, or a second data copy is
required. There's also an issue if the user is using
#0 stack_dump () at src/stack.c:72
72 if (!__builtin_frame_address(2))
(gdb) bt
#0 stack_dump () at src/stack.c:72
#1 0x2acbd1a6 in handler (x=11) at src/stack.c:151
#2 signal handler called
#3 __osm_sm_mad_ctrl_send_err_cb (bind_context=0x550dd8, p_madw=0x567820)
at
This patch changes sdp to use Linux native lists for the listen conn
list. The first version had a bug where if the listen list was empty,
the lookup would return a bogus conn.
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: linux-2.6.12-openib/drivers/infiniband/ulp/sdp/sdp_conn.c
On Thu, 30 Jun 2005, Caitlin Bestler wrote:
snip
os_data / Identification of Consumer Objects
gen2 provides minimal support for identification of RDMA
resources using consumer supplied handles. A user-supplied
context is available in callbacks, but not in work
Hal,
Would you mind versioning your patches? That way I don't think you are
just resending the same email.
Thanks,
-tduffy
signature.asc
Description: This is a digitally signed message part
___
openib-general mailing list
openib-general@openib.org
kfree() already checks for NULL. No need to do it twice.
Signed-off-by: Tom Duffy [EMAIL PROTECTED]
Index: linux-kernel/dat-provider/dapl_cookie.c
===
--- linux-kernel/dat-provider/dapl_cookie.c (revision 2761)
+++
The following patch converts the RMPP code to use the MAD layer APIs for
allocating send MAD data buffers when sending ACKs.
Signed-off-by: Sean Hefty [EMAIL PROTECTED]
Index: mad_rmpp.c
===
--- mad_rmpp.c (revision 2760)
+++
On Tue, Jun 28, 2005 at 11:18:57PM +0300, Michael S. Tsirkin wrote:
Libor, here's a stub at solving an old problem.
Most of the patch is passing sdp_opt to iocb complete and cancel functions.
I didnt yet test it, and I wont have the time today,
but maybe you could tell me whether I'm going
Libor Michalek wrote:
The listen id is in the req rcvd event. (event-param.req_rcvd.listen_id)
Do you mean that it is not being set correctly?
Ok, I didn't look deep enough. It is set correctly and the polling seems
to be working.
The uDAPL code is now connecting properly but I am having
Sean Hefty wrote:
The following patch moves verification of the cm_id state higher up
in the CM function calls. This fixes an issue trying to allocate a
message for a cm_id that may be in an invalid state, which could
result in a crash.
This problem was first reported by Hal a while ago, but
63 matches
Mail list logo
