Re: [PATCH v3] [RFC] rdma/cm: support option to allow manually setting IB path

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Wed, Oct 28, 2009 at 12:37:39PM -0700, Sean Hefty wrote:
> >But, I still think this API should return EINVAL if the cm_id is in
> >AF_INET/AF_INET6 mode. That is to say, this API only works with the
> >AF_IB idea we have been discussing.
> >
> >I suggest this because using this API really does override the
> >capabilities of the AF_INET/6 in unexpected ways, as the discussion
> >drifted through it seemed like at least bonding, routing
> >and ND operations would/could be overridden.
> >
> >If so then I'd say it should be part of an AF_IB patch.
> >
> >Sean, what are your thoughts on applying it to AF_INET/6?
> 
> Even without any other kernel changes, this patch enables us to solve the
> biggest scaling problem that we've measured, so I want to allow it regardless of
> what the original addressing was.  Whether a path record comes from the SA, a
> local cache, some wonky multicast protocol, or is made up is really independent
> from how the GIDs were discovered.

OK, that makes sense.

I have no problem with this if there is a way for the kernel to choose
the DGID and pass it to user space to do path resolution to feed back
PRs through the new API - at least it is then possible to use the new
API in a way that is consistent with the IP stack.

ie this API when applied to AF_INET does not short-circuit ND. You
have to use AF_IB to remove the ND.

Does that seem consistent with what you are thinking? Does a DGID
returning API already exist? Seems simple to add if not..

Jason
--
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