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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
