On Mon, Sep 28, 2015 at 11:36:11AM -0400, Doug Ledford wrote: > > Also broadcast could cause a unecessary reception event on the NICs of > > machines that have no interest in this traffic. > > This is true. However, I'm trying to balance between several competing > issues. You also stated the revamped multicast code was adding latency > and dropped packets into the problem space. Sending over the broadcast > would help with latency. However, I have an alternative idea for that... I think your original idea of broadcast immediately and deferred optimal mlid lookup is the best *functionally* for every case - only when you enter the very edge world of caring about timing does it make any difference. 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. 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
