[driver-discuss] what can we do if the rx buffer is not returned quickly enough

[Brian Xu - Sun Microsystems - Beijing China]

On 07/02/09 05:53, Andrew Gallatin wrote:
> Brian Xu - Sun Microsystems - Beijing China wrote:
>> On 06/29/09 11:43, Ted You wrote:
>>> I think the slab allocator may be used for NIC drivers in some extent,
>>> but not in the way you described.
>>>
>>> First, the rx buffer with the MTU size must be a physically contiguous
>>> memory, and it has to meet some other hardware specific requirements 
>>> for
>>> DMA transfer. The current slab allocator cannot do that.
>> anything you did now for the NIC driver RX can be put in the 
>> constructor of your private slab object.
>> that is, the slab allocator can do almost anything that the 
>> desballoc() in NIC driver did.
>
> Is there a guide someplace to using the slab allocator for something
> like this?
the comments in top of the kmem.c is a good description of the slab.
>   Is this something a driver is currently allowed to do?
> Are there any examples?
You can refer to the link Paul Durrant provided:
http://cr.opensolaris.org/~pdurrant/webrev/usr/src/uts/common/io/sfxge/sfxge_rx.c.html

I think besides allocating the dma handle, the ddi_dma_mem_alloc() and 
dma_bindle() can also be put in the constructor as well.

Just as someone pointed out, on sparc, a watermark should be set to 
prevent too many iommu pages from being preserved.

Thanks,
Brian
>
> Thanks,
>
> Drew