Quoting r. Sean Hefty [EMAIL PROTECTED]:
Subject: Re: rdma_cm branch
Here's the rdma_establish patch from OFED.
Seems to even still apply to 2.6.19. I expect just replacing the
id-device-node_type test you'll get what you want for upstream.
Thanks - this matches what I have queued in my
Sean Hefty wrote:
Or Gerlitz wrote:
Can you clarify what do you mean (ABI) conflict with OFED releases?
Is an issue with someone wishing to work with OFED user space and IB
code from upstream kernel?
Yes - there could be issues there.
As long as OFED provides kernel IB code you need not
Sean Hefty wrote:
Can you clarify what do you mean (ABI) conflict with OFED releases?
Is an issue with someone wishing to work with OFED user space and IB
code from upstream kernel?
Yes - there could be issues there.
To clarify the major issue: currently when a connection request is
Quoting r. Sean Hefty [EMAIL PROTECTED]:
To clarify the major issue: currently when a connection request is received,
the
connection data specified by the active side through the rdma_conn_param is
NOT
given to the user. This includes the responder_resources and
initiator_depth.
And when getting established event, the connection data specified by the
passive side through the rdma_conn_param provided to rdma_accept is also
not given to the user, is that an issue?
Correct - the connection parameter data disappears into the rdma_cm and is not
directly given to the remote
The ideal fix for this is to include rdma_conn_param as part of the
rdma_cm_event.
BTW, wouldn't it be cleaner to just pass it up in the request event?
Yes - this is what I meant by including it in the rdma_cm_event structure.
However, this breaks every userspace app that's been coded to
On Wed, 2006-10-04 at 10:00 -0700, Sean Hefty wrote:
The ideal fix for this is to include rdma_conn_param as part of the
rdma_cm_event.
BTW, wouldn't it be cleaner to just pass it up in the request event?
Yes - this is what I meant by including it in the rdma_cm_event structure.
Guys, I must be confused. I thought the private data _was_ passed up in
the ESTABLISHED event on the active side. We have tools in the
perftools directory that utilize this. What am I missing here?
When a user calls rdma_connect(), they specific connection parameters (like
responder_resources
On Wed, 2006-10-04 at 10:17 -0700, Sean Hefty wrote:
Guys, I must be confused. I thought the private data _was_ passed up in
the ESTABLISHED event on the active side. We have tools in the
perftools directory that utilize this. What am I missing here?
When a user calls rdma_connect(),
On 10/4/06 12:40 PM, Steve Wise [EMAIL PROTECTED] wrote:
On Wed, 2006-10-04 at 10:17 -0700, Sean Hefty wrote:
Guys, I must be confused. I thought the private data _was_ passed up in
the ESTABLISHED event on the active side. We have tools in the
perftools directory that utilize this.
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Subject: Re: rdma_cm branch
Michael S. Tsirkin wrote:
Quoting r. Sean Hefty [EMAIL PROTECTED]:
1. We need to add rdma_establish() and expose the rdma_conn_param values
as
part of the connection event. I'm working on a patch for the latter.
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Subject: Re: rdma_cm branch
The ideal fix for this is to include rdma_conn_param as part of the
rdma_cm_event.
BTW, wouldn't it be cleaner to just pass it up in the request event?
Yes - this is what I meant by including it in the rdma_cm_event
Here's the rdma_establish patch from OFED.
Seems to even still apply to 2.6.19. I expect just replacing the
id-device-node_type test you'll get what you want for upstream.
Thanks - this matches what I have queued in my local git tree against 2.6.19.
- Sean
Sean Hefty wrote:
Steve Wise wrote:
What is the status of the rdma_cm branch in Roland's infiniband.git
tree? It doesn't have the iwarp stuff in it. I'm wondering if it can
be merged with the 2.6.19 stuff to create a branch that was iwarp + ucma
support? Or is that a dumb idea?
I'm
Quoting r. Sean Hefty [EMAIL PROTECTED]:
1. We need to add rdma_establish() and expose the rdma_conn_param values as
part of the connection event. I'm working on a patch for the latter.
I have both patches as part of OFED.
Should I post them for review?
--
MST
Quoting r. Sean Hefty [EMAIL PROTECTED]:
The cleanest solution from an ABI perspective is to merge multicast support
before the ucma; however, I'm not sure that makes the most sense for merging
upstream. Thoughts?
OTOH ucma is already used so it makes sense to merge that first.
Can not this
Sean Hefty wrote:
I'm currently working on moving the rdma_cm code that's in svn forward to
what's
upstream. (I was just typing a message on this...) My plan is to ask Roland
to
host one, maybe two, branches in the infiniband.git tree. Here are the main
pieces missing from the
Quoting r. Sean Hefty [EMAIL PROTECTED]:
1. We need to add rdma_establish() and expose the rdma_conn_param values as
part of the connection event. I'm working on a patch for the latter.
2. We need a ucma branch. To merge upstream, it makes sense to include item
1
first, but this
Since the ucma will not make it for the 2.6.19 feature merge window, why
not target both the ucma and the cma ud/ud-mulitast support for 2.6.20?
This way you would be doing one big ABI change and would not carry this
HUGE svn/git diff.
As I have mentioned in the other thread, once it
Michael S. Tsirkin wrote:
1. We need to add rdma_establish() and expose the rdma_conn_param values as
part of the connection event. I'm working on a patch for the latter.
2. We need a ucma branch. To merge upstream, it makes sense to include item
1
first, but this leads to a conflict with
Michael S. Tsirkin wrote:
Quoting r. Sean Hefty [EMAIL PROTECTED]:
1. We need to add rdma_establish() and expose the rdma_conn_param values as
part of the connection event. I'm working on a patch for the latter.
I have both patches as part of OFED.
Should I post them for review?
I
Or Gerlitz wrote:
Can you clarify what do you mean (ABI) conflict with OFED releases?
Is an issue with someone wishing to work with OFED user space and IB
code from upstream kernel?
Yes - there could be issues there.
The approach i suggest is: it makes sense to take some care not to
Can you clarify what do you mean (ABI) conflict with OFED releases?
Is an issue with someone wishing to work with OFED user space and IB
code from upstream kernel?
Yes - there could be issues there.
To clarify the major issue: currently when a connection request is received,
the
connection
Quoting r. Sean Hefty [EMAIL PROTECTED]:
Did you
carry the rdma_conn_param patch up to userspace as well?
Yes.
--
MST
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe,
Hey Roland/Sean,
What is the status of the rdma_cm branch in Roland's infiniband.git
tree? It doesn't have the iwarp stuff in it. I'm wondering if it can
be merged with the 2.6.19 stuff to create a branch that was iwarp + ucma
support? Or is that a dumb idea?
Steve.
Steve Hey Roland/Sean, What is the status of the rdma_cm branch
Steve in Roland's infiniband.git tree? It doesn't have the iwarp
Steve stuff in it. I'm wondering if it can be merged with the
Steve 2.6.19 stuff to create a branch that was iwarp + ucma
Steve support? Or is
26 matches
Mail list logo
