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). _______________________________________________ networking-discuss mailing list [email protected]
