Re: [PATCH v3 07/28] IB/Verbs: Reform IB-ulp ipoib

[Jason Gunthorpe]

On Thu, Apr 16, 2015 at 10:02:46AM -0700, Roland Dreier wrote:
> On Thu, Apr 16, 2015 at 9:44 AM, Jason Gunthorpe
> <jgunthorpe@xxxxxxxxxxxxxxxxxxxx> 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?

That is true, but we also never test any of the cases where one
expected ULP fails to load but another one needs it. Like IPoIB needs
sa_query, for instance.

I'm not saying ULPs should error for soft reasons, like your NFS
example, this unwind would be for OOM, or other 'impossible' class
errors.

That said, the driver core does not fail a bus driver register if a
client probe fails (we could copy this), but it also doesn't just
silently eat the error code either.

What about ib_register_client? If any add's fail should it unwind and
fail upwards?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/