Masa Murayama wrote:
----- Original Message -----
Date: Fri, 24 Jul 2009 22:05:37 -0700 (PDT)
From: Somnath kotur <so...@yahoo.com>
To: "Garrett D'Amore" <gdam...@sun.com>
Cc: driver-discuss@opensolaris.org
Subject: [driver-discuss] Tx strategy for packets with many fragments
Hi All,
????????? I'm currently involved in writing driver for my 10G NIC H/W?. My ha
rdware seems to be facing a problem whenever i try with LSO enabled ( all it n
eeds is the Tx MSS ) and the packet has? more fragments than the no: of TX des
criptors that my card can handle (32)? at one time .
My current strategy in such a scenario is to ddi_dma_mem_alloc? a virtual buf
fer in my driver for the packet size?,do an ddi_dma_addr_bind for this VA? and
then copy the contents of the packet to this virtual buffer which is now DMA-
ready as well before handing it off to the card. Now,?for some reason this doe
sn't seem to work in the case of these large packets that come in LSO path.Now
while i am not sure what the H/W problem is, my question really is ..
a) Is this a good/workable strategy?
b) Are there any better alternatives ?
Somnath kotur,
I think you can reduce the number of fragments to the reasonable number
by msgpullup(), which reallocates a fragmented packet to a virtually
continuous packet.
I have written some ethernet drivers for gigabit nics which have LSO
capabiliy, and this is what I do to send packets with many fragments.
This will pull up the messages, for sure. But it doesn't help with
packets that are spread across multiple physical pages. (Even a pull up
will spread across multiple pages.)
- Garrett
-masa
?
I am using Solaris 10x86 Update 6 05/08
?
Thanks
Som
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss