Somnath kotur wrote:
Pls ignore my second observation regarding the no: of cookies being greater
than max no: of segments specified. My eyes decieved me,sorry for the
inconvenience
If i have indicated to the stack that my h/w is capable of LSO in getcapab, does the stack still do /care about checksum ? If LSO flag is set my H/W will do the checksum anyhow, so is there anything specific i have to do regarding CHKSUM to the stack? .I am currently indicating that i am capable of
HCKSUM_INET_FULL_V4 | HCKSUM_IPHDRCKSUM in my getcapab() entry point . This along with LSO flags and lso max
Should this suffice?
Yes.
- Garrett
Thanks
Som
----- Original Message ----
From: Somnath kotur <so...@yahoo.com>
To: Masa Murayama <khf04...@nifty.ne.jp>; Garrett D'Amore <gdam...@sun.com>
Cc: driver-discuss@opensolaris.org
Sent: Tuesday, July 28, 2009 2:44:53 PM
Subject: Re: [driver-discuss] Tx strategy for packets with many fragments
Hi
I had tried the msgpullup earlier and even that didnt seem to succeed or there was some thing the h/w didnt like. One thing i noticed was that the flags of the 'mp' before pullup and the new mp created after msgpullup are lost , for e.g the HW_LSO flag was not present in the new 'mp' , sensing that might be a problem i sent the orginal mp's flags to the H/W which seemed to result in some other problem which the H/w did not like
The other observation i saw the in the ddi_mem_alloc() / bcopy method was that on an ddi_dma_addr_bind_handle() of the mem_alloc'ed memory the no: of cookies returned were > max no: of segments that i had specified in my tx_dma_attr structure
static ddi_dma_attr_t tx_dma_attr = {
DMA_ATTR_V0, /* version of this structure */
0, /* lowest usable address */
0xffffffffffffffffULL, /* highest usable address */
0x7fffffff, /* maximum DMAable byte count */
0x1000, /* alignment in bytes 4K! */
0xfff, /* burst sizes (any?) */
1, /* minimum transfer */
0xffffffffU, /* maximum transfer */
0xffffffffffffffffULL, /* maximum segment length */
18, /* maximum number of segments */
1, /* granularity */
DDI_DMA_RELAXED_ORDERING, /*flags (reservered) */
};
Isn't that NOT supposed to happen ? Pls see if there is a problem with the
structure i have declared above?
Thanks
Som
----- Original Message ----
From: Masa Murayama <khf04...@nifty.ne.jp>
To: Garrett D'Amore <gdam...@sun.com>
Cc: driver-discuss@opensolaris.org
Sent: Saturday, July 25, 2009 2:54:50 PM
Subject: Re: [driver-discuss] Tx strategy for packets with many fragments
----- Original Message -----
Date: Sat, 25 Jul 2009 00:34:13 -0700
From: "Garrett D'Amore" <gdam...@sun.com>
Subject: Re: [driver-discuss] Tx strategy for packets with many fragments
To: Masa Murayama <khf04...@nifty.ne.jp>
Cc: driver-discuss@opensolaris.org
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 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
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
_______________________________________________
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
