Andrew Gallatin wrote:
Paul Durrant wrote:
Andrew Gallatin wrote:
Isn't the overhead to map/unmap the buffer fairly high? Why don't
you keep the buffer mapped?
That was what I was getting at. If the pool is shared amongst drivers
then the buffer has to be unmapped before being recycled (in case
it's allocated by a different driver) thus blowing away most of the
advantage of loanup.
Perhaps you'd want to setup buffer pools based on things
like which IOMMU the device is behind, and DMA constraints.
That way the vast majority of installs which use either a
single instance of a single device, or multiple instances
of the same type of device, would be able to share a pool.
I'm just speculating..
In my design, the term "pool" represents the buffer pool with the same
attributes (alignment, buffer size...). That is, the buffer in the same
pool is identical in terms of the driver instances' usage. Each driver
instance(interface or ring) needs to acquire a " buffer handler" to get
buffer. The framework actually create a sub-pool. The instance gets the
buffer from the sub-pool directly. The stack returns the buffer to the
sub-pool directly. So one piece of buffer won't be returned to the
sub-pool other than the one that assigns the buffer. My previous design
is to unmap the buffer only when it's scheduled out from the sub-pool to
the pool.
Miles Xu
Drew
_______________________________________________
networking-discuss mailing list
[email protected]
