brian.xu wrote:
I think besides allocating the dma handle, you can also put the
ddi_dma_mem_alloc() and ddi_dma_addr_bind_handle() in the constructor of
the cache. For different MTU size, separate caches are created, just
like what allocb() does(with different mblk size). What is more, for
your new xesballoc(), besides the virtual address, the dma cookie for
the whole buffer should also be passed, so for ip forwarding, when this
packet is needed to send on the other NIC, and if the dma attribute for
the 2 NICs are compatible(I think in most of the situation, it is the
case), then no dma bind/unbind on the new NIC is required.
That could indeed be done. Feel free to extend xesballoc(), assuming the
code ever gets integrated.
This idea is also applicable for the tx side. and I have also a
prototype based on this idea, which almost eliminate the overhead of dma
bind/unbind.
Detaily, I create a pseudo device with a default dma attribute.(the dma
attr are also driver properties, so that user can modify them). then
when a mblk is allocated, in the dblk_constructor(), the whole dblk is
dma bound to the pseudo device, and the dma cookies for the dblk are
kept in the mp->b_datap. when the mblk is transmiting on the NIC, if the
dma attr of the NIC is compatible to the pseudo device, then a dma
bind/unbind fast path is hit. there are two cases here:
Is this useful in practise, bearing in mind that the top of the stack
doing the allocation is not necessarily aware of the NIC that the packet
will eventually be forwarded to?
1.For sparc and x86 with iommu or x86 without iommu but the cookies for
the whole dblk is 1, then the cookie.dmac_laddress for the mblk is the
cookie_laddress for the dblk plus the offset of mp->b_rptr to the
mp->b_datap->db_base, and cookie.dmac_size is MBLKL(mp).
2.For x86 without iommu and the cookies for the dblk is more than 1, a
new ddi_dma_mblk_get_next_cookie() is required to caculate the cookie
for the mblk according to the cookie info for the dblk. since in this
case, the cookie info for the whole dblk has already been available, so
the overhead is quite cheap to get the cookie for the mblk.
If the dma attr are not compatible, we just do like how the current dma
bind/unbind is done.
So, you take an extra bind/unbind hit if the NIC's DMA engine imposes a
restriction that the stack's idealized parameters did not forsee? Sounds
like it could be a problem.
Paul
--
===================================
Paul Durrant
http://www.linkedin.com/in/pdurrant
===================================
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
