On Thu, Mar 29, 2018 at 10:29:18PM +0000, Hefty, Sean wrote: > A single API with a refresh flag makes sense to me. I'll try to > remember more details, but I've been struggling so far. I think > Roland was wanting to remove the caches at one point, but I don't > remember the reason. I remember Roland bringing that up once too, but clearly with roce we are going in the other direction. If there was some 'latest data issue' here then it could only have been a race between the time the HCA updates the GID table from a SMP and processing some kind of packet. For instance processing a patch record or sending a packet in close proximity to a SMP that changes the GID table. But we already have problems there, say, if some SMP MADs get lost or delayed relative to a PR response depending on the update, so at best cached or not cached is just shuffling around the time window of an existing race. Assuming devices are timely in their updates to the cache. In general though - the architecture where the IB driver changes the HW GID table async to the Linux static is pretty much bonkers, we can't implement things like that without creating races. So, I'm inclined to go ahead with this and hope we either don't create real problems or we can address them using the forcoming gid entry ref count patches and some light IB driver rework around the HW GID table. 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
