On Wed, Sep 16, 2020 at 09:00:09AM +1000, Benjamin Herrenschmidt wrote: > On Tue, 2020-09-15 at 11:18 +0100, Lorenzo Pieralisi wrote: > > To sum it up: > > > > (1) RDMA drivers need a new mapping function/attribute to define their > > message push model. Actually the message model is not necessarily related > > to write combining a la x86, so we should probably come up with a better > > and consistent naming. Enabling this patchset may trigger performance > > regressions on mellanox drivers on arm64 - this ought to be addressed. > > I doubt it. Besides Mellanox will probably enable WC already through > the other code path (the use of this accessor is only one of the path > that enables the driver to do WC). > > I don't think we need to solve the RDMA semantics issue that urgently > TBH, and it's definitely an orthogonal issue to that at hand. > > > (2) User-space/passthrough drivers rely on VFIO for BAR mappings. Since > > it looks relevant, WC message model semantics should be introduced > > there, somehow. > > Yes. I will ping some folks on the VFIO patch to see if we can get the ball rolling there again. > > > (3) Given the above, the sysfs interface can be enabled. I still don't > > see the advantages (other than saying it is there for other arches, ie > > what can you really do with the sysfs mappings - see Jason's VFIO/DMA > > query) but we can do it. Still, I am not happy about the possible > > mellanox regressions - that should be tested/verified before this > > patch is merged IMHO. Do we really need it for v5.10 ? > > I don't think there's a significant risk of regression, but then I also > dont' have a way to test :-) I'm going to re-submit this patch to Catalin and Will with an updated commit message capturing the context from this discussion (and cc everyone involved). As for the whole device GRE / new naming context-- I'll have to defer to Lorenzo on suggested next steps on this front. Thanks, Clint
