> >>>>> A SA cache is undeniably critical for fabric scalability and > >>>>> performance. > >>>>> In user space, the ibacm application provides a good example of > >>>>> pathrecord cache for address and route resolution. With the recent > >>>>> implementation of the provider architecture, ibacm offers more > >>>> extensibility as a SA cache. > >>>>> In kernel, ipoib implements its own small cache for pathrecords, > >>>>> which is however not available for general use. Furthermore, the > >>>>> implementation of a SA cache in user space offers better > >>>>> flexibility, larger capacity, and more robustness for the system. > >>>>> > >>>>> In this patch series, a mechanism is implemented to allow ib_sa to > >>>>> send pathrecord query to a user application (eg ibacm) through netlink. > >>>> > >>>> While this appears to address the current upstream use model for > >>>> ACM with it's multicast overlay backend where PRs are static, it > >>>> does not appear to address PR changes. > >>>> Should aging/revalidation of PRs be supported ? If so, would this > >>>> make PRs similar at "high" level to IP neighbor cache in kernel ? > >>> > >>> Even for the default provider acmp, PRs will time out and the length > >>> of > >> timeout is configurable. For other providers (eg ibssa), the PR > >> change could be managed correctly and promptly, and this capability > >> is beyond ibacm core itself. > >> > >> That deals with the update of PR in user space (ACM). Doesn't kernel > >> need some way of knowing PR was updated ? > > > > Maybe. If a kernel client is interested in PR changes, it can register > > for notification > > Wouldn't the notification mechanism be via netlink ? What would the > granularity be for the registrations and notifications ?
Not necessarily. AFAIK, SA notification is not currently supported in kernel. One could register notification through netlink, as long as the user space application (eg: ibacm) supports it. But this would be a new feature, as Sean pointed out in previous e-mail. Kaike -- 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
