> From: Hal Rosenstock [mailto:[email protected]] > Sent: Thursday, June 11, 2015 8:24 AM > To: Weiny, Ira > Cc: Jason Gunthorpe; Wan, Kaike; [email protected]; Fleck, John > Subject: Re: [PATCH v4 4/4] IB/sa: Route SA pathrecord query through netlink > > 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, [email protected] wrote: > >>>>> From: Kaike Wan <[email protected]> > >>>>> > >>>>> 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 the kernel client can query SA for mulitcast PRs, why can't ibacm (even backed by acmp)? Is there any code there that prevents a mgid being used as the destination? > > If user space PR capabilities (unicast, multicast, both) is supported, it > affects > the API. How? If we can query SA for multicast PRs without joining the multicast groups, what additional changes in netlink API do we need to support both? >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. > -- 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
