From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sean Hefty" Subject: RE: [openib-general] [PATCH v2 1/2] iWARP Connection Manager. Date: Tue, 13 Jun 2006 14:36:46 -0700 Message-ID: <000001c68f31$78910fe0$24268686@amr.corp.intel.com> References: <1150230871.17394.68.camel@stevo-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "Andrew Morton" , , , , Return-path: Received: from mga03.intel.com ([143.182.124.21]:16154 "EHLO azsmga101-1.ch.intel.com") by vger.kernel.org with ESMTP id S932330AbWFMVgz (ORCPT ); Tue, 13 Jun 2006 17:36:55 -0400 To: "'Steve Wise'" , "Tom Tucker" In-Reply-To: <1150230871.17394.68.camel@stevo-desktop> Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org >> 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. - Sean