On Tue, Aug 04, 2015 at 11:41:16PM -0700, David Dillow wrote: > On Tue, 2015-08-04 at 12:09 -0600, Jason Gunthorpe wrote: > > On Mon, Aug 03, 2015 at 11:33:51AM -0700, Bart Van Assche wrote: > > > >Bart, do you know what hardware this workaround is for? > > > > > > I hope the HW vendors can comment on this. Sorry but I'm not sure which > > > HCA > > > models and/or firmware versions do not support FMR mapping with a non-zero > > > offset. > > > > Perhaps David can remember why he added this: > > > > commit 8f26c9ff9cd0317ad867bce972f69e0c6c2cbe3c > > It's originally from commit 559ce8f150d7d031c79c4d79173860f1bdfe3ce4, > and the list's attempts at code archaeology failed us: > http://article.gmane.org/gmane.linux.drivers.rdma/7149
Okay.. So over time we went from a clear target specific bug described 9 years ago in 559ce through chinese whispers to a general unspecific fear of non-zero offset FMR? But nobody has described FMR failure in this way in the past 9 years with any specificity? My random guesses would be broken mthca firmware at the start of the FMR feature (long since fixed) or a wonky target that is now 10 years obsolete.. If it was an HCA bug, I strongly have to think it is fixed now. We use FMR all over the place and SRP is the only area I've noticed this restriction.. If it is a target bug, then FRWR should trigger it as wel, so we are already about to revert that workaround. I'm inclined to drop this entirely.. What do you think Bart? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
