Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755029AbbDPRVc (ORCPT <rfc822;w@1wt.eu>);
	Thu, 16 Apr 2015 13:21:32 -0400
Received: from mga02.intel.com ([134.134.136.20]:22337 "EHLO mga02.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751355AbbDPRVV (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 16 Apr 2015 13:21:21 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.11,589,1422950400"; 
   d="scan'208";a="481848218"
From: "Hefty, Sean" <sean.hefty@intel.com>
To: Roland Dreier <roland@kernel.org>,
        Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
CC: Michael Wang <yun.wang@profitbricks.com>,
        "Weiny, Ira" <ira.weiny@intel.com>,
        Hal Rosenstock <hal.rosenstock@gmail.com>,
        "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Tom Tucker <tom@opengridcomputing.com>,
        Steve Wise <swise@opengridcomputing.com>,
        Hoang-Nam Nguyen <hnguyen@de.ibm.com>,
        Christoph Raisch <raisch@de.ibm.com>,
        infinipath <infinipath@intel.com>, Eli Cohen <eli@mellanox.com>,
        "Latif, Faisal" <faisal.latif@intel.com>,
        Jack Morgenstein <jackm@dev.mellanox.co.il>,
        Or Gerlitz <ogerlitz@mellanox.com>, Haggai Eran <haggaie@mellanox.com>,
        Tom Talpey <tom@talpey.com>, Doug Ledford <dledford@redhat.com>
Subject: RE: [PATCH v3 07/28] IB/Verbs: Reform IB-ulp ipoib
Thread-Topic: [PATCH v3 07/28] IB/Verbs: Reform IB-ulp ipoib
Thread-Index: AQHQdeT2sFttzbzDr0mwYqlrDkZAnp1LyTCAgAAFUYCAAARbAIABMlqAgAA0SYCAAAUDgIAABHAA//+LcBCAAHrdgIAA5C0AgAIlTACAAAUoAP//jpHw
Date: Thu, 16 Apr 2015 17:21:18 +0000
Message-ID: <1828884A29C6694DAF28B7E6B8A82373A8FC24E3@ORSMSX109.amr.corp.intel.com>
References: <20150413192701.GA19112@obsidianresearch.com>
 <20150413194602.GA21467@phlsvsds.ph.intel.com>
 <20150413200138.GC19112@obsidianresearch.com>
 <20150414141806.GA7354@phlsvsds.ph.intel.com>
 <20150414172514.GB7682@obsidianresearch.com>
 <20150414174311.GA28111@phlsvsds.ph.intel.com>
 <20150414175904.GB13896@obsidianresearch.com>
 <1828884A29C6694DAF28B7E6B8A82373A8FC127C@ORSMSX109.amr.corp.intel.com>
 <20150414182137.GD7682@obsidianresearch.com>
 <552E1A1A.4090704@profitbricks.com>
 <20150416164418.GC22946@obsidianresearch.com>
 <CAG4TOxPMaRAR_B69J1_SHaHh8YMW2Unx786t2FbrA8g=05BAgA@mail.gmail.com>
In-Reply-To: <CAG4TOxPMaRAR_B69J1_SHaHh8YMW2Unx786t2FbrA8g=05BAgA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.22.254.139]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by nfs id t3GHLY6e023148
Content-Length: 731
Lines: 12

> > No idea, but having ib_register_device fail and unwind if a client
> > fails to attach makes sense to me.
> 
> It seems a bit unfriendly to fail an entire device if one ULP has a
> problem.  Let's say you have a system whose main network connection is
> IPoIB.  Would you want that connection to come up even if, say, the
> NFS/RDMA server fails to find the memory registration type it likes?

What's missing is some way for the device to indicate which modules are actually necessary for it to run.  Without having something like that, I agree with Roland.

- Sean 
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?