[+Jason] On Tue, Sep 08, 2020 at 09:33:42AM +1000, Benjamin Herrenschmidt wrote: > On Thu, 2020-09-03 at 12:08 +0100, Lorenzo Pieralisi wrote: > > > It's been what other architectures have been doing for mroe than a > > > decade without significant issues... I don't think you should worry > > > too > > > much about this. > > > > Minus what I wrote above, I agree with you. I'd still be able to > > understand what this patch changes in the mellanox driver HW > > handling though - not sure what they expect from > > arch_can_pci_mmap_wc() > > returning 1. > > I don't know enough to get into the finer details but looking a bit it > seems when this is set, they allow extra ioctls to create buffers > mapped with pgprot_writecombine(). > > I suppose this means faster MMIO backet buffers for small packets (ie, > non-DMA use case). > > Also note that mlx5_ib_test_wc() only uses arch_can_pci_mmap_wc() for a > non-ROCE ethernet port on a PF... For anyting else, it just seems to > actually try to do it and see what happens :-) > > Leon: Can you clarify the use of arch_can_pci_mmap_wc() in mlx5 and > whether you see an issue with enabling this on arm64 ? Hi Jason, I was wondering if you could help us with this question, we are trying to understand what enabling arch_can_pci_mmap_wc() on arm64 would cause in mellanox drivers wrt mappings and whether there is an expected behaviour behind them, in particular whether there is an implicit reliance on x86 write-combine arch/interconnect details. Thanks, Lorenzo
