Netdev List
 help / color / mirror / Atom feed
* [PATCH v2 0/2][RFC] iWARP Core Support
@ 2006-06-07 20:06 Steve Wise
  2006-06-07 20:06 ` [PATCH v2 1/2] iWARP Connection Manager Steve Wise
  2006-06-07 20:06 ` [PATCH v2 2/2] iWARP Core Changes Steve Wise
  0 siblings, 2 replies; 11+ messages in thread
From: Steve Wise @ 2006-06-07 20:06 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.

I believe I've addressed all the round 1 review comments.  Details of
the changes are tracked in each patch comment.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread
* RE: [openib-general] [PATCH v2 1/2] iWARP Connection Manager.
@ 2006-06-14 18:06 Caitlin Bestler
  0 siblings, 0 replies; 11+ messages in thread
From: Caitlin Bestler @ 2006-06-14 18:06 UTC (permalink / raw)
  To: Steve Wise, Sean Hefty
  Cc: Andrew Morton, netdev, rdreier, linux-kernel, openib-general

netdev-owner@vger.kernel.org wrote:
> On Tue, 2006-06-13 at 16:46 -0500, Steve Wise wrote:
>> On Tue, 2006-06-13 at 14:36 -0700, Sean Hefty wrote:
>>>>> Er...no. It will lose this event. Depending on the event...the
>>>>> carnage varies. We'll take a look at this.
>>>>> 
>>>> 
>>>> This behavior is consistent with the Infiniband CM (see
>>>> drivers/infiniband/core/cm.c function cm_recv_handler()).  But I
>>>> think we should at least log an error because a lost event will
>>>> usually stall the rdma connection.
>>> 
>>> I believe that there's a difference here.  For the Infiniband CM, an
>>> allocation error behaves the same as if the received MAD were lost
>>> or dropped.  Since MADs are unreliable anyway, it's not so much that
>>> an IB CM event gets lost, as it doesn't ever occur.  A remote CM
>>> should retry the send, which hopefully allows the
> connection to make forward progress.
>>> 
>> 
>> hmm.  Ok.  I see.  I misunderstood the code in cm_recv_handler().
>> 
>> Tom and I have been talking about what we can do to not drop the
>> event. Stay tuned.
> 
> Here's a simple solution that solves the problem:
> 
> For any given cm_id, there are a finite (and small) number of
> outstanding CM events that can be posted.  So we just
> pre-allocate them when the cm_id is created and keep them on
> a free list hanging off of the cm_id struct.  Then the event
> handler function will pull from this free list.
> 
> The only case where there is any non-finite issue is on the
> passive listening cm_id.  Each incoming connection request
> will consume a work struct.  So based on client connects, we
> could run out of work structs.
> However, the CMA has the concept of a backlog, which is
> defined as the max number of pending unaccepted connection
> requests.  So we allocate these work structs based on that
> number (or a computation based on that number), and if we run
> out, we simply drop the incoming connection request due to
> backlog overflow (I suggest we log the drop event too).
> When a MPA connection request is dropped, the (IETF
> conforming) MPA client will eventually time out the
> connection and the consumer can retry.
> 
> Comments?
> 

If the IWCM cannot accept a Connection Request event from
the driver then *someone* should generate a non-peer reject
MPA Response frame. Since the IWCM does not have the resources
to relay the event, it probably does not have the resources
to generate the MPA Response frame either. So simply returning
an "I'm Busy" error and expecting the driver to handle it
makes sense to me.


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

end of thread, other threads:[~2006-06-14 18:08 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-07 20:06 [PATCH v2 0/2][RFC] iWARP Core Support Steve Wise
2006-06-07 20:06 ` [PATCH v2 1/2] iWARP Connection Manager Steve Wise
2006-06-08  7:54   ` Andrew Morton
2006-06-12 15:54     ` Tom Tucker
2006-06-13 20:34       ` Steve Wise
2006-06-13 21:36         ` [openib-general] " Sean Hefty
2006-06-13 21:46           ` Steve Wise
2006-06-14 16:11             ` Steve Wise
2006-06-07 20:06 ` [PATCH v2 2/2] iWARP Core Changes Steve Wise
2006-06-07 22:13   ` Tom Tucker
  -- strict thread matches above, loose matches on Subject: below --
2006-06-14 18:06 [openib-general] [PATCH v2 1/2] iWARP Connection Manager Caitlin Bestler

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