On Tue, Jun 2, 2009 at 12:25 AM, Min Miles Xu <[email protected]> wrote: > 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.
A couple of questions... will it work with chips (such as cassini) that can separate out protocol headers into a separate buf? I.e. it may take a 8k buffer, and use it to hold the headers of multiple packets. The idea being that you use desballoc to point to the portion of the buffer holding the header for the packet, an then link it to the portion of another buffer(s) holding the actual data (possibly also usign desballoc). Also what about on the tx side? Any thoughts there? It would need to know early on which interface is being used, though for a number of cases, it seems like that should be possible (just not always). _______________________________________________ networking-discuss mailing list [email protected]
