> From: "Ted Unangst" <t...@tedunangst.com> > Date: Mon, 11 Jul 2016 10:45:19 -0400 > > 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?
Actually, as long as the usb controller implements 64-bit DMA, all these devices should work just fine. It's just that not all USB controllers support this and that our uhci(4), ohci(4) and ehci(4) drivers don't support this. > 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? Right. At some point the vast majority of the amd64 hardware we run on will be 64-bit "clean". The major issue here is that we don't really trust all the legacy drivers to do the proper bus_dmamap_sync() operations that are needed for bounce buffers to work. But perhaps that's an argument to do this sooner than later such that we can fix things while hardware is still around.
