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

[Sean Hefty]

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.

- Sean

--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Jason Gunthorpe]

On Wed, Oct 28, 2009 at 02:41:15PM -0700, Sean Hefty wrote:
 Does a DGID returning API already exist?
 
 yes - query_route returns the following information: SGID, DGID, pkey, source
 address, destination address, and path records (max of 2).  Not all of the
 information is valid, depending on the state of the rdma cm id.  The librdmacm
 already invokes this after rdma_resolve_addr completes.

Great, I didn't realize that was there. No further comments from me then

Reviewed-By: Jason Gunthorpe jguntho...@obsidianresearch.com

Jason
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html