From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH] Expire sendonly joins (was Re: [PATCH rdma-rc 0/2] Add mechanism for ipoib neigh state change notifications) Date: Mon, 28 Sep 2015 11:36:46 -0600 Message-ID: <20150928173646.GA1453@obsidianresearch.com> References: <5608282F.1020507@redhat.com> <56095E6B.60509@redhat.com> <20150928171007.GE12415@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Christoph Lameter Cc: Doug Ledford , Or Gerlitz , Or Gerlitz , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-rdma@vger.kernel.org On Mon, Sep 28, 2015 at 12:19:04PM -0500, Christoph Lameter wrote: > > Christoph's needs would probably be better served by giving some API > > to control the mlid cache (ie the neightbour table is already 99% of > > the way there). This would let some userspace component pre-load and > > fix all relevant data and undesired cache activity simply can't add > > jitter. > > Ok so on boot up we preload 3000 multicast groups into the neighbor table? > What impact on IB performance would having such a number of mlid's in the > cache have? What is the cost of a neighbour lookup? Isn't it hashed? So not very much if the hash function/table size work well with the distribution of IPs. The win is any send to any of the 3000 groups is consistent in all cases, no outlier that is slower due to the SA turn around. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html