Hello, Michael Kelly, le mer. 26 août 2026 20:53:54 +0100, a ecrit: > On 22/08/2026 08:38, Michael Kelly wrote: > > I'm considering whether it would be appropriate to implement within rump > > a similar bounce buffer capability as is found in x86. I've only looked > > briefly at this code and in general it is arch independent except for > > clearly arch specific functionality relating to the the memory sync > > requirements of DMA and user buffers. There is however arch specific > > code for rumpkern so possibly having arch specific variants of > > bus_dmamap_sync within rump might be feasible. > > I've prototyped this successfully such that Hurd boots using Qemu i440fx > machine type and 6G RAM without the patch that has currently been deployed. > This has several advantages: > > 1) Using q35 machine reverts to the previous performance without using > bounce buffers at all. > > 2) Using i440fx uses a bounce buffer only where the physical memory address > requires it. The bounce buffer is retained by the IDE channel DMA map > meaning it does not need reallocation per request. > > All I've done, really, is to duplicate the relevant parts from the x86 DMA > implementation which is mostly architecture independent. > > If this is deemed the best solution, what is the way forward for integration > ? I'm assuming that it would be preferred to see if I can get this > functionality merged to the upstream rumpkernel sources but I think that > might take quite a long time. They might not be happy with the idea let > alone the implementation. There's quite a bit of work to transform the > prototype into something that they might consider. For example, there are > functions that I've not revised (bus_dmamap_load_mbuf and > bus_dmamap_load_uio) that Hurd does not use but NetBSD might. > > Would you want an interim patch to replace the existing one or just leave > things alone for now ?
If you have a working patch we can use it to get the performance benefit while discussion with upstream happens, yes. Thanks, Samuel
