Jason King wrote:
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).
I think we can extend the interfaces to comply the requirements. It's
even possible with my existing design but it looks tricky since you may
need to acquire two buffer pools for one driver instance.
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).
I remember someone in the networking team takes a CR related with tx
buffer management in driver/net-other category. But I can't remember the
exact synopsis.
Miles Xu
_______________________________________________
networking-discuss mailing list
[email protected]
