[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5530B7D0.602@profitbricks.com>
Date: Fri, 17 Apr 2015 09:35:44 +0200
From: Michael Wang <yun.wang@...fitbricks.com>
To: Roland Dreier <roland@...nel.org>,
Jason Gunthorpe <jgunthorpe@...idianresearch.com>
CC: "Hefty, Sean" <sean.hefty@...el.com>,
"Weiny, Ira" <ira.weiny@...el.com>,
Hal Rosenstock <hal.rosenstock@...il.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Tom Tucker <tom@...ngridcomputing.com>,
Steve Wise <swise@...ngridcomputing.com>,
Hoang-Nam Nguyen <hnguyen@...ibm.com>,
Christoph Raisch <raisch@...ibm.com>,
infinipath <infinipath@...el.com>, Eli Cohen <eli@...lanox.com>,
"Latif, Faisal" <faisal.latif@...el.com>,
Jack Morgenstein <jackm@....mellanox.co.il>,
Or Gerlitz <ogerlitz@...lanox.com>,
Haggai Eran <haggaie@...lanox.com>,
Tom Talpey <tom@...pey.com>, Doug Ledford <dledford@...hat.com>
Subject: Re: [PATCH v3 07/28] IB/Verbs: Reform IB-ulp ipoib
Hi, Roland
Thanks for the comment :-)
On 04/16/2015 07:02 PM, Roland Dreier wrote:
> On Thu, Apr 16, 2015 at 9:44 AM, Jason Gunthorpe
> <jgunthorpe@...idianresearch.com> wrote:
>>> We can give client->add() callback a return value and make
>>> ib_register_device() return -ENOMEM when it failed, just wondering
>>> why we don't do this at first, any special reason?
>
>> 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?
Agree, the idea is correct that one client's initialization failure should not
influence the whole device, as long as the rest client can keep the device
working (but how to estimate that...).
While just ignore the failure seems really strange...
Regards,
Michael Wang
>
> - R.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists