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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
