From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ted H. Kim" Subject: Re: [PATCH] ib/cm: Change reject message type when destroying cm_id Date: Mon, 18 May 2015 14:27:51 -0700 Message-ID: <555A5957.7080508@oracle.com> References: <1431632941-3430-1-git-send-email-sean.hefty@intel.com> <1431708034.29187.14.camel@redhat.com> <1828884A29C6694DAF28B7E6B8A82373A8FDBF8D@ORSMSX109.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1828884A29C6694DAF28B7E6B8A82373A8FDBF8D-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Doug Ledford Cc: "Hefty, Sean" , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-rdma@vger.kernel.org On 05/15/15 10:06 AM, Hefty, Sean wrote: >> Did you intend to add an ISSUE B: section to the commit message? > > The issue is listed as the missing comm id. Though, thinking about it > again, the issue may have been a missing node GUID. I can't recall now. > Maybe Ted does. Imagine the case of the Linux active side sending REQ with it's CM communication id. When it gets the REP back, the other side's communication ID will be received and internal CM state updated. So any REJ from this point on can send both communication IDs. Now imagine a slightly different case. The active side sends the REQ, and the passive side responds with MRA. At this point the CM should update the state with the second communication ID coming in the MRA. But it does not do so. This is "ISSUE B". This is will require a different fix from the patch in question to add the communication ID updating when getting an MRA. So as a side effect, a REJ issued at this point by the active side has only its own communication ID. The problem with only one communication ID REJs is that they are all generated by remote systems from the one being sent the REJ and therefore might not be unique. The way that TIMEOUT REJ addresses this is to have a GUID in the ARI to make it unique. But other REJ codes don't have this. -ted > The IB spec is goofy here in that it only allows a CM REQ, once sent, > to timeout. It doesn't define an 'abort' case. The spec also treats > the connection is being in a single 'REP wait' state, regardless of > whether an MRA has been received or not. This change results in > the 'I got an MRA but I'm waiting for a REP' to be handled the > same as 'I'm waiting for a REP', at least for the destruction case. -- Ted H. Kim, PhD Sun/Oracle America ted.h.kim-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org 5750 Hannum Drive, #200 +1 310-258-7536 Culver City, CA 90230 -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html