Jason King wrote:
On Mon, Jun 1, 2009 at 1:55 PM, Pradeep <[email protected]> wrote:
Hi,
There are so many features need to implemented in
the gldv3 driver . I dont know whether you are
implementing them in your driver are not . Let me
list out them
1. If you are ddi_mem functions for memory allocations
use ddi_bind functions for rx buffers , instead of
freeing and re-allocating them .
2. There is tx chaining of mblks .
3. Avoid using bcopy/bzero
simple rx path should be
-post buffers logic
use ddi_mem and desballoc
as soon as u receive rx completion send down using mac_rx
and when free_rtn of desballoc is called re-use this buffer
-Tx side
bind the mblk to buffer (use ddi_bind functions)
4.Hardware checksum offload feature
Let me know if you need any help
This brings up some questions I've been meaning to ask for a while
(I've changed the subject since it's more general in nature).
I've heard there are issues with doing 'loan up' (i.e. desballoc +
free_rtn) -- there are no guarantees that the buffer will ever be
returned. What determines when an mblk passing up the stack is
free'ed?
Also, I've notice that some OSes create a pool of pre-mapped buffers
that the upper stacks can then use. In the context of Opensolaris,
this would be akin to creating a pool of dma mapped mblk's, and then
the upper layers when needing an mblk, grab one from the pool to use
it, eliminating the overhead of a bcopy as well as the mapping
overhead. Are there any plans to provide similar functionality? I
know it cannot work in all circumstances (as it requires knowing which
link to use at the time of mblk allocation), though it seems like in a
number of common situations (such as already established TCP
connections or such), that it might be a win (though I don't have the
testing facilities to be able to say how much).
Hi Jason,
I've been working on the buffer management on the rx side, consolidating
the dma rx buffer pool of all the GLD instances (port/ring). The driver
can simply ask for a number of buffer from the framework and use it,
pass it up to the stack. It's the framework's responsibility to recycle
the buffer returned. So everything is transparent to the drivers.
Another prominent advantage of doing so is that the buffer can be shared
among instances. New Intel 10G NICs have 128 rings. The existing way of
allocating buffer for each ring is a big waste of memory.
I already have a prototype for e1000g and ixgbe. But I need some more
time to conduct experiments and refine it. Then I will handle it out for
reviews. The code to be integrated may be applied to ixgbe only, then
applies to other NIC drivers.
Regards,
Miles Xu
Solaris NIC Team
_______________________________________________
networking-discuss mailing list
[email protected]
