I did some research on the first topic. The unified event model was
designed based on user feedback. User's of previous RDMA APIs found
multiple event streams difficult to manage. They wanted the ability to
have a single event stream that maintained ordering guarantees.
DAPL allows users to
I hadn't heard that insmod was being removed from Linux.
In fact the DAPL Plugfest successfully used kernel
daemons and kdapltest to demonstrate DAT interoperability
across multiple vendors: kernel to kernel, kernel to user
and user to user.
These are existing applications already deployed. I
On Thu, Jun 02, 2005 at 05:22:26AM -0700, Caitlin Bestler wrote:
I hadn't heard that insmod was being removed from Linux.
No one claimed that.
In fact the DAPL Plugfest successfully used kernel
daemons and kdapltest to demonstrate DAT interoperability
across multiple vendors: kernel to
On Wed, 1 Jun 2005, Tom Duffy wrote:
On Wed, 2005-06-01 at 12:04 +0200, Christoph Hellwig wrote:
That beeing said, one of the first thing you should get rid of if you
want to be able to take code from kdapl to the generic rdma code is way
it deals with handles. The kdapl code gives up
On Thu, 2005-06-02 at 11:16 -0400, James Lentini wrote:
- in dat.h, create a public structure for each object type:
struct dat_ep {
struct dat_provider *provider;
};
- in the transport provider (dapl.h) have a private structure that
contains the public one:
struct
On Thu, 2 Jun 2005, Tom Duffy wrote:
On Thu, 2005-06-02 at 11:16 -0400, James Lentini wrote:
- in dat.h, create a public structure for each object type:
struct dat_ep {
struct dat_provider *provider;
};
- in the transport provider (dapl.h) have a private structure that
On 6/2/05, Tom Duffy [EMAIL PROTECTED] wrote:
On Thu, 2005-06-02 at 11:16 -0400, James Lentini wrote:
- in dat.h, create a public structure for each object type:
struct dat_ep {
struct dat_provider *provider;
};
- in the transport provider (dapl.h) have a private structure
On Thu, Jun 02, 2005 at 11:16:53AM -0400, James Lentini wrote:
This could be an improvement. We just need to be careful that we don't
expose anything transport specific. Off the top of my head, I can
think of one way to do this:
- in dat.h, create a public structure for each object type:
On Tue, May 31, 2005 at 02:03:06PM -0700, Tom Duffy wrote:
On Sat, 2005-05-28 at 09:13 +0200, Christoph Hellwig wrote:
On Fri, May 27, 2005 at 03:56:58PM -0700, Bob Woodruff wrote:
kDAPL is intended as a kernel-level API
for RDMA enabled fabrics. As it was initially written,
it does
On Wed, Jun 01, 2005 at 09:36:09AM +0200, Christoph Hellwig wrote:
For (1) doing a proper RDMA stack should solve thing, and the discussion
how to do it is already ongoing on this list. Once we have proper RMDA
stack that part of KDAPL isn't needed at all anymore. The second is
more
At 03:36 AM 6/1/2005, Christoph Hellwig wrote:
kDAPL is supposed to serve two needs:
(1) provide an unified API for different RDMA transports
(2) provide various higher level helpers
...
For (1) doing a proper RDMA stack should solve thing, and the discussion
how to do it is already ongoing on
On Wed, 2005-06-01 at 12:04 +0200, Christoph Hellwig wrote:
That beeing said, one of the first thing you should get rid of if you
want to be able to take code from kdapl to the generic rdma code is way
it deals with handles. The kdapl code gives up language type safety
just to add its own
The need for a single unifying event disptaching method was *the*
primary feedback received from VIA user when DAPL started.
That included both kernel and user-mode applications, in fact
one of the primary reasons why the DAT Collaborative was
started was that there was no unrestricted API for VIA
On 6/1/05, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Wed, Jun 01, 2005 at 09:36:09AM +0200, Christoph Hellwig wrote:
For (1) doing a proper RDMA stack should solve thing, and the discussion
how to do it is already ongoing on this list. Once we have proper RMDA
stack that part of KDAPL
On 5/31/05, Libor Michalek [EMAIL PROTECTED] wrote:
Also, I realize it's just an implementation detail, but I've got a
number of issues with ATS.
ATS was a workaround the fact that OS naming systems could
not be relied upon to deal with IPv6 format addresses (i.e. GIDs).
That is an
On Sat, May 28, 2005 at 04:26:43PM -0700, Caitlin Bestler wrote:
...
if so what the best strategy for
achieving it is (try to plan an IB/iWARP merge immediately
or wait until there is an iWARP code base).
If there is no iWARP code base, I fail to see how one can merge.
Having a specification
On Sat, May 28, 2005 at 05:18:39PM -0700, Caitlin Bestler wrote:
Verus..
struct rdma_xyz {
/* common fields */
};
struct rdma_xyz_ib {
struct rdma_xyz common;
/* ib fields */
};
struct rdma_xyz_iwarp {
struct rdma_xyz common;
/* iwarp fields */
};
The
Exactly, the code matters from Linux
community standpoint
and the discussion around the convergence
of common PI is
mute until we have that header file
definition but which will come
out soon.
However, I am quite glad to see the
OpenIB and
OpenRDMA communities in agreement on
common
ULP's and
On Fri, 27 May 2005, Bob Woodruff wrote:
Caitlin wrote,
Both uDAPL and kDAPL were designed for *application* use.
Even kDAPL is more intended for use by a kernel daemon that
is loaded separately from the kernel than for use within
the kernel itself.
kDAPL is intended as a kernel-level API
At 06:47 AM 5/28/2005, Christoph Hellwig wrote:
On Sat, May 28, 2005 at
05:17:54AM -0700, Sukanta ganguly wrote:
That's a pretty bold statement. Linux grew up to be
popular via mass acceptance. Seems like that charter
has changed and a few have control over Linux and its
future. The My way
On Tue, May 31, 2005 at 02:31:19PM -0700, Michael Krause wrote:
...
Not intending
to offend anyone but if there can be no debate without implementation on
what is the right solution, then people might as well just go off and
implement and propose their solution for incorporation into the
I completely agree. I think this thread
was not started to get one of
the projects out of the way of the other.
I would think it was started
to coordinate the development cycles
of two related projects, where
one project is admittedly much more
advanced, just due to the since
years now
On Tue, May 31, 2005 at 02:03:06PM -0700, Tom Duffy wrote:
On Sat, 2005-05-28 at 09:13 +0200, Christoph Hellwig wrote:
On Fri, May 27, 2005 at 03:56:58PM -0700, Bob Woodruff wrote:
kDAPL is intended as a kernel-level API
for RDMA enabled fabrics. As it was initially written,
it does
I've been advocating rdmaconsortium folks submit patches
against openib.org for several reasons:
Probably, you meant openrdma.org opensource project but not
a standards setting body (i.e. RDMA consortium -
http://www.rdmaconsortium.org/home) :)
1) start with a code base that works
2)
On Tue, 2005-05-31 at 16:43 -0700, Venkata Jagana wrote:
AFAICT the openib.org steering group doesn't control the content
of the svn.openib.org source tree. It manages things like web
content,
overall charter, etc
Don't agree. If you have read the email thread on this discussion,
On Tue, May 31, 2005 at 04:43:58PM -0700, Venkata Jagana wrote:
I've been advocating rdmaconsortium folks submit patches
against openib.org for several reasons:
Probably, you meant openrdma.org opensource project but not
a standards setting body (i.e. RDMA consortium -
On Fri, May 27, 2005 at 03:56:58PM -0700, Bob Woodruff wrote:
Caitlin wrote,
Both uDAPL and kDAPL were designed for *application* use.
Even kDAPL is more intended for use by a kernel daemon that
is loaded separately from the kernel than for use within
the kernel itself.
kDAPL is intended
On Fri, May 27, 2005 at 08:04:26PM -0700, Caitlin Bestler wrote:
A commitment that after merger that the API will be transport
neutral is essential. That is, IB HCAs do not have to emulate
iWARP. iWARP HCAs do not have to emulate IB.
You won't get any commitments from us at all.
Is there
--- Christoph Hellwig [EMAIL PROTECTED] wrote:
On Fri, May 27, 2005 at 06:24:46PM -0700, Caitlin
Bestler wrote:
Oh that's a great development plan for me to
propose
to my business people. Let's go write lots of
code,
and *after* we write it the IB people (our
competitors)
have agreed
On Sat, May 28, 2005 at 05:17:54AM -0700, Sukanta ganguly wrote:
That's a pretty bold statement. Linux grew up to be
popular via mass acceptance. Seems like that charter
has changed and a few have control over Linux and its
future. The My way or the highway philosophy has
gotten embedded in
On 5/28/05, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Sat, May 28, 2005 at 05:17:54AM -0700, Sukanta ganguly wrote:
That's a pretty bold statement. Linux grew up to be
popular via mass acceptance. Seems like that charter
has changed and a few have control over Linux and its
future.
On 5/27/05, Bob Woodruff [EMAIL PROTECTED] wrote:
So for every new RDMA device type that comes along, you need to add a new
enum, and unions for device class specific stuff, etc.
Seems rather static and not easily extended. Not
to mention that testing nightmare when the thing has to support
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Woodruff, Robert J
Sent: Thursday, May 26, 2005 5:12 PM
To: Caitlin Bestler
Cc: Venkata Jagana; [EMAIL PROTECTED];
openib-general@openib.org
Subject: [Rdma-developers] RE: [openib-general]
On Fri, 2005-05-27 at 10:07 -0700, Caitlin Bestler wrote:
OpenIB's announced charter was IB specific. There was no
announcement that the intent was to define *all* RDMA
services.
The OpenIB board will be voting, maybe even at the next meeting, whether
to expand OpenIB's charter to include
Caitlin wrote,
Both uDAPL and kDAPL were designed for *application* use.
Even kDAPL is more intended for use by a kernel daemon that
is loaded separately from the kernel than for use within
the kernel itself.
kDAPL is intended as a kernel-level API
for RDMA enabled fabrics. As it was initially
-Original Message-
From: Bob Woodruff [mailto:[EMAIL PROTECTED]
Sent: Friday, May 27, 2005 3:57 PM
To: Caitlin Bestler; Roland Dreier; 'James Lentini';
[EMAIL PROTECTED]
Cc: Venkata Jagana; [EMAIL PROTECTED];
openib-general@openib.org
Subject: RE: [Rdma-developers] Re:
Catlin wrote,
The sourceforge DAPL requires extensive parallel data between
the DAPL layer and the verbs layer, that has a measurable impact
on system performance. RNIC-PI not only avoids requiring either
IB HCAs to pretend to be iWARP RNICs, or iWARP RNICs to pretend
to be IB HCAs, it also
-Original Message-
From: Bob Woodruff [mailto:[EMAIL PROTECTED]
Sent: Friday, May 27, 2005 5:36 PM
To: Caitlin Bestler; Roland Dreier; James Lentini;
[EMAIL PROTECTED]
Cc: Venkata Jagana; [EMAIL PROTECTED];
openib-general@openib.org
Subject: RE: [Rdma-developers] Re:
On Fri, May 27, 2005 at 06:24:46PM -0700, Caitlin Bestler wrote:
Oh that's a great development plan for me to propose
to my business people. Let's go write lots of code,
and *after* we write it the IB people (our competitors)
have agreed to *look* at it (but they're all busy, don't
forget)
-Original Message-
From: Grant Grundler [mailto:[EMAIL PROTECTED]
Sent: Friday, May 27, 2005 7:15 PM
To: Caitlin Bestler
Cc: Bob Woodruff; Roland Dreier; James Lentini;
[EMAIL PROTECTED]; Venkata Jagana;
[EMAIL PROTECTED]; openib-general@openib.org
Subject: Re:
On Fri, May 27, 2005 at 08:04:26PM -0700, Caitlin Bestler wrote:
You will never get a guarantee your code will go into
kernel.org regardless of which path you take.
I've seen three of the lead developers (a) promise to review
any proposed code changes and (b) indicate they are willing
At 09:29 AM 5/26/2005, Talpey, Thomas wrote:
At 11:49 AM 5/26/2005, Bob
Woodruff wrote:
Finally, until there is some consensus about allowing TCP offload in
Linux,
I see no need to start to hack up the InfiniBand stack to support
iWarp.
It is not a requirement that TCP offload be supported in
42 matches
Mail list logo
