Erik Nordmark wrote:
Darren Reed wrote:
In thinking about experimenting with Solaris networking, I was
pondering how I could experiment with using different types of
buffer allocation schemes behind STREAMS.
If you want to experiment (as opposed to make it into product quality)
then one way would be to overload the pri argument to allocb and
friends to mean "the buffer pool".
The "pri" is an integer, but allocb() doesn't use its value today.
This would require some way for the different providers of buffer
pools to register and get back a "handle" that would fit in an
integer, and then a way to pass that handle to all the places where
the relevant allocb() etc calls would be made.
If we're going to add a new function to call for creating a handle then
we may as well bring in a new buffer allocation function as well, rather
than try to squeeze something in the allocb.
My original dreams were that because dtrace can show who's calling what,
we could determine it all too and do fancy things without any API
changes, but I admit that it wasn't very realistic.
Of couse this would allow base (in esballoc/desballoc) to be
ignored.
I don't understand why you'd want to change that part.
Maybe I'd rather have the driver DMA the packet into memory that is
wired in differently on a NUMA machine, compared to where the NIC is
located. Or maybe I want to DMA the data directly into memory that has
been reserved for another purpose. Or...
Although a NIC can DMA packets into its own buffer, the NIC's buffers
are much more limited in size than the host's (in general.) The driver
puts the packet (with desballoc) into a buffer that is best for it and
that may not necessarily be best for where the packet is going to end up.
Kais Belgaied wrote:
Erik Nordmark wrote On 04/24/06 14:57,:
Darren Reed wrote:
The parameters into the buffer allocation would ideally be:
- size of buffer
- priority
- driver name and instance wanting it (hard/impossible?)
Having an "int alloc_register(name, instance, max_memory_to_use)"
function that returns the handle would allow for this.
another way, have that driver use esballoc() with buffers coming out
of its
owned/managed kmem_cache: that is with constructor function filling
in whatever extra
info your driver deems useful.
So you would specify a dblk constructor (to be called when allocating a
buffer) as another parameter to the alloc_register or similar function?
If so, then at a minimum, we'd need to allow both the constructor and
destructor to be specified. I think that would work nicely.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
