On Mon, 11 Jul 2016, Ted Unangst wrote: > Stefan Fritsch wrote: > > On Mon, 11 Jul 2016, Reyk Floeter wrote: > > > The intentional 4GB limit is for forwarding: what if you forward mbufs > > > from a 64bit-capable interface to another one that doesn't support 64bit > > > DMA? And even if you would only enable it if all interfaces are > > > 64bit-capable, what if you plug in a 32bit USB/hotplug interface? We did > > > not want to support bounce buffers in OpenBSD. > > > > Yes, I have understood that. My mail was more about non-mbuf DMA: Does it > > make sense to allow 64bit DMA in other cases while keeping the 4GB > > limitation for mbufs? > > every kind of device can be attached via usb now. for the code that supports > flipping, like bufcache, this is still tricky to handle dynamic limit changes. > what happens to buffers marked DMA that suddenly aren't?
I guess the flipping would have to be done just before the device driver is called, but after it is clear which device driver will be called. Not sure if that is feasible or worth the effort. That's what I wanted to find out with my mail ;) BTW, for usb devices, it probably depends on the host controller if 64bit dma is possible or not. I guess most xhci controllers will be able to do it. > That said, I'm not 100% convinced the fear of bounce buffers is justified. If > a USB device requires bouncing, it's already pretty slow. What are we > optimizing for again? True for spinning disks or usb storage sticks. But an SSD attached via USB 3.x is not slow. > Or something could be done to bring iommu to life. The problem is that there are many systems that dont' have any. Or for openbsd in VMs, it may be expensive for the host system to emulate the iommu. Cheers, Stefan
