----- Original Message -----
>Date: Sat, 25 Jul 2009 00:34:13 -0700
>From: "Garrett D'Amore" <[email protected]>
>Subject: Re: [driver-discuss] Tx strategy for packets with many fragments
>To: Masa Murayama <[email protected]>
>Cc: [email protected]
>
>
>Masa Murayama wrote:
>> ----- Original Message -----
>>
>>> Date: Fri, 24 Jul 2009 22:05:37 -0700 (PDT)
>>> From: Somnath kotur <[email protected]>
>>> To: "Garrett D'Amore" <[email protected]>
>>> Cc: [email protected]
>>> 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 i
t 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 D
MA-
>> 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
You are right. If mmu page size is 4k byte, a msgpullup'ed 64k byte LSO
packet will be consist of 17 (= 64k/4k + 1) fragments in physical
memory space.
But in my experience, 17 is enough small for common gigabit nics. :-)
They can handle 17 fragments. So we don't need to prepare physically
continuous tx buffers for LSO. we can also control maximum fragment
number by notifying maximum size of LSO packet in m_getcapab.
It is very simple solution, I think.
-masa
>> -masa
>>
>>
>>> ?
>>> I am using Solaris 10x86 Update 6 05/08
>>> ?
>>> Thanks
>>> Som
>>>
>>>
>>>
>>> _______________________________________________
>>> driver-discuss mailing list
>>> [email protected]
>>> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>>>
>>
>> _______________________________________________
>> driver-discuss mailing list
>> [email protected]
>> http://mail.opensolaris.org/mailman/listinfo/driver-discuss
>>
>
_______________________________________________
driver-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
