Netdev List
 help / color / mirror / Atom feed
* RE: [openib-general] Re: [PATCH 1/2] iWARP Connection Manager.
@ 2006-06-01 22:28 Caitlin Bestler
  2006-06-02 13:57 ` Steve Wise
  0 siblings, 1 reply; 4+ messages in thread
From: Caitlin Bestler @ 2006-06-01 22:28 UTC (permalink / raw)
  To: Tom Tucker, Sean Hefty
  Cc: Steve Wise, netdev, rdreier, linux-kernel, openib-general


>> 
>> There's a difference between trying to handle the user calling
>> disconnect/destroy at the same time a call to accept/connect is
>> active, versus the user calling disconnect/destroy after
>> accept/connect have returned.  In the latter case, I think you're
>> fine.  In the first case, this is allowing a user to call
> destroy at the same time that they're calling accept/connect.
>> Additionally, there's no guarantee that the F_CONNECT_WAIT flag has
>> been set by accept/connect by the time disconnect/destroy tests it.
> 
> The problem is that we can't synchronously cancel an
> outstanding connect request. Once we've asked the adapter to
> connect, we can't tell him to stop, we have to wait for it to
> fail. During the time period between when we ask to connect
> and the adapter says yeah-or-nay, the user hits ctrl-C. This
> is the case where disconnect and/or destroy gets called and
> we have to block it waiting for the outstanding connect
> request to complete.
> 
> One alternative to this approach is to do the kfree of the
> cm_id in the deref logic. This was the original design and
> leaves the object around to handle the completion of the
> connect and still allows the app to clean up and go away
> without all this waitin' around. When the adapter finally
> finishes and releases it's reference, the object is kfree'd.
> 
> Hope this helps.
> 
Why couldn't you synchronously put the cm_id in a state of
"pending delete" and do the actual delete when the RNIC
provides a response to the request? There could even be
an optional method to see if the device is capable of
cancelling the request. I know it can't yank a SYN back
from the wire, but it could refrain from retransmitting.

^ permalink raw reply	[flat|nested] 4+ messages in thread
* [PATCH 0/2][RFC] iWARP Core Support
@ 2006-05-31 18:26 Steve Wise
  2006-05-31 18:26 ` [PATCH 1/2] iWARP Connection Manager Steve Wise
  0 siblings, 1 reply; 4+ messages in thread
From: Steve Wise @ 2006-05-31 18:26 UTC (permalink / raw)
  To: rdreier, mshefty; +Cc: linux-kernel, netdev, openib-general


This patchset defines the modifications to the Linux infiniband subsystem
to support iWARP devices.  We're submitting it for review now with the
goal for inclusion in the 2.6.19 kernel.  This code has gone through
several reviews in the openib-general list.  Now we are submitting it
for external review by the linux community.

This StGIT patchset is cloned from Roland Dreier's infiniband.git
for-2.6.18 branch.  The patchset consists of 2 patches:

        1 - New iWARP CM implementation.  
        2 - Core changes to support iWARP.

Signed-off-by: Tom Tucker <tom@opengridcomputing.com>
Signed-off-by: Steve Wise <swise@opengridcomputing.com>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2006-06-02 13:57 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-01 22:28 [openib-general] Re: [PATCH 1/2] iWARP Connection Manager Caitlin Bestler
2006-06-02 13:57 ` Steve Wise
  -- strict thread matches above, loose matches on Subject: below --
2006-05-31 18:26 [PATCH 0/2][RFC] iWARP Core Support Steve Wise
2006-05-31 18:26 ` [PATCH 1/2] iWARP Connection Manager Steve Wise
2006-05-31 22:22   ` Sean Hefty
2006-06-01 17:00     ` Steve Wise
2006-06-01 21:09       ` Sean Hefty
2006-06-01 22:21         ` [openib-general] " Tom Tucker
2006-06-01 17:11     ` Tom Tucker

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox