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? Thanks Som ----- Original Message ---- From: Somnath kotur <[email protected]> To: Masa Murayama <[email protected]>; Garrett D'Amore <[email protected]> Cc: [email protected] 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 <[email protected]> To: Garrett D'Amore <[email protected]> Cc: [email protected] 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" <[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 _______________________________________________ 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
