From owner-freebsd-hackers Mon Jul 16 12:37:40 2001 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id CA38A37B403; Mon, 16 Jul 2001 12:37:36 -0700 (PDT) Subject: Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3 In-Reply-To: <200107161829.LAA23310@smtpout.mac.com> from Josh Osborne at "Jul 16, 2001 02:28:55 pm" To: stripes@mac.com (Josh Osborne) Date: Mon, 16 Jul 2001 12:37:36 -0700 (PDT) Cc: hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20010716193736.CA38A37B403@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > On Monday, July 16, 2001, at 12:57 PM, Bill Paul wrote: > [...] > > The chip has some nifty features though: hardware VLAN tag insertion > > and removal, TCP/IP checksum offload on receive and transmit, 2048-bit > > multicast hash filter, and 4 pattern match buffers for use with WOL. > > What is WOL? Wake on LAN. > > The transmit checksum offload has to be turned off if you use jumbo > > frames larger than about 8K, because the chip only has an 8K transmit > > FIFO. There is also support for interrupt moderation. > > Does it automatically not checksum packets >8K, or does A Bad Thing > happen if you fail to turn it off first? It does a Bad Thing (tm). In my testing, trying to send a frame larger than 8170 bytes puts the transmitter to sleep. Normally, the chip acknowledges transmit commands with three interrupt indications: TX DMA done (packet was transfered to the chip), TX done (packet made it to the wire), TX idle (TX queue empty, waiting for more packets). If you have transmit checksums enabled and send a frame larger than 8170 bytes, you get the TX DMA done interrupt, but nothing else. The transmitter stops responding after that, and eventually a watchdog timeout is triggered which resets the NIC. The driver disables TX checksum offloading if you set the MTU above a certain threshold. I think at that point, the performance gain from using jumbo frames is greater than that of using TX checksum offload anyway (for sustained transfers anyway). For the record, the chip allows TX checksum offload on a global or per-packet basis. I use the per-packet method, and simply don't set the "I want TX checksums computed" bits in the TX DMA descriptors once the MTU is set above the threshold (I also clear the if_hwassist flags so the OS will go back to computing the checksums itself). -Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message