On 3/21/06, Andrew Gallatin <[EMAIL PROTECTED]> wrote: > > I personally *hate* having to pre-allocate receive buffers and loan > them to the stack. If I allocate too few, then my driver has to copy > to dynamically allocated buffers, impacting peak performance. If I > allocate too many, I may needlessly waste system memory and IOMMU > space when my device is essentially idle. If I want to not waste > resources, I need to come up with my own algorithm to grow and shrink > my usage, which is probably going to look about the same, but have a > different set of bugs from my competitors driver. > > If I had my druthers, there would be a globally shared pool of network > receive buffers under the OS's control, in at least 2 popular sizes > (1518, 9500) and perhaps more (4096, 8192..). These buffers would be > pre-entered into the IOMMU, and a driver would be passed the buffer's > DMA address when it allocates a buffer. These buffers would be > contiguous in DMA space. Since they are pre-allocated and pre-entered > into the IOMMU, allocation should be cheap. And since the system > controls them, it could centerally grow and shrink the pool as needed. > MacOSX does something like this (mbufs are pre-entered into the > IOMMU). This is about only thing that MacOSX/Darwin does right in its > entire network driver API :)
Have you looked at dvma_reserve() and dvma_kaddr_load()? They're reliant on having an IOMMU (and so are sparc only at the moment) but do pretty much what you want, I think. Paul -- Paul Durrant http://www.linkedin.com/in/pdurrant _______________________________________________ networking-discuss mailing list [email protected]
