On Tue, 2020-09-15 at 11:18 +0100, Lorenzo Pieralisi wrote: > > It's useful for random things, I've used it quite a bit in a previous > > life for things like in-lab hw testing etc... There's tooling out > > there, esp. in the more 'embedded' side of thing that uses this, I > > don't see a good reason not to provide the same level of functionality. > > > > So Lorenzo, imho, we should merge the patch. > > 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. > (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 :-) Cheers, Ben.
