On 6/10/2015 5:09 PM, Weiny, Ira wrote: >> On 6/10/2015 3:10 PM, Jason Gunthorpe wrote: >>> On Wed, Jun 10, 2015 at 01:47:36PM -0400, Hal Rosenstock wrote: >>>> On 6/9/2015 10:57 AM, kaike....@intel.com wrote: >>>>> From: Kaike Wan <kaike....@intel.com> >>>>> >>>>> This patch routes a SA pathrecord query to netlink first >>>> >>>> Should only unicast PRs be done in this manner or should API support >>>> enabling for unicast and/or multicast ? >>>> >>>> AFAIK kernel doesn't query multicast PRs now (queries MCMRs) but this >>>> seems like it would help make it future proof and not have to take >>>> timeout on local query unless app supports it. >>> >>> It is a good question. We can clearly extend toward that, using a MGID >>> as the DGID and adding additional nested netlink fields. >>> >>> However, does it make sense? >> >> If it doesn't make sense, then should MGIDs as DGIDs never be requested via >> the PR netlink API ? >> > > Why should we prevent it? What does it hurt?
It's merely an optimization in that round trip to user space is avoided with user space needing to perform some validation/lookup which would fail in case multicast PRs not supported (which is case for ACM with multicast backend). If user space PR capabilities (unicast, multicast, both) is supported, it affects the API. Maybe it's overkill but requires user space to indicate no PR available for multicast DGIDs. I think this is the tradeoff to be made/decided. -- Hal > Ira > -- 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
