On Wed, Jun 10, 2015 at 10:39:49AM -0400, Hal Rosenstock wrote: > On 6/10/2015 10:22 AM, Wan, Kaike wrote: > > > > > >> -----Original Message----- > >> From: Hal Rosenstock [mailto:h...@dev.mellanox.co.il] > >> Sent: Wednesday, June 10, 2015 9:37 AM > >> > >>> > >>> 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 ? >
This series does not attempt to optimize the kernel needing to know that a PR has been updated. There are existing mechanisms for that. In the future it would be nice to have more local support for such updates but I don't think this patch precludes that in any way. Right now we are just taking the first step by making the actual query more efficient. 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
