On 6/10/2015 11:49 AM, Wan, Kaike wrote: >>>>>>> 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.
Such notifications are not necessarily tied to SA event reporting. In fact, Todd made argument at 2014 OFA Devcon that such mechanism is anathema to (exa)scalability. -- Hal > 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
