From owner-freebsd-hackers Fri Mar 19 9:39:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id D7DE714D02 for ; Fri, 19 Mar 1999 09:39:42 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA59302; Fri, 19 Mar 1999 09:39:14 -0800 (PST) (envelope-from dillon) Date: Fri, 19 Mar 1999 09:39:14 -0800 (PST) From: Matthew Dillon Message-Id: <199903191739.JAA59302@apollo.backplane.com> To: Bill Paul Cc: hackers@FreeBSD.ORG Subject: Re: Gigabit ethernet revisited References: <199903191415.JAA03718@skynet.ctr.columbia.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :No, I don't think that's it. I think the DMA isn't going fast enough. :The 'WriteRing' in question is a ring of DMA descriptors inside the :NIC, which the firmware is supposed to be managing. There's also a :DmaReadRing for the transmit side. :.. :> Your current code appears to allocate a sufficient number of buffers, :> but your ti_refill_rx_rings() optimization is suspect... you do not :> call it until you have *COMPLETELY* drained the RX ring of packets. :> What happens if new packets are streaming in faster then you can drain :> them? You will completely exhaust your RX ring before you reallocate :> it's buffers. : :There are a couple of tuning parameters that control when the NIC :will interrupt the host to check the receive ring: ti_rx_coal_ticks and :ti_rx_max_coal_bds. The former is the number of microseconds that can :elapse before the NIC will be forced to interrupt, and the latter is :the number of descriptors to wait to be accumulated before generating :an interrupt. Right now, I set things for 500 microseconds and 64 :buffer descriptors, and in my tests this usually results in buffers :being DMAed in chunks of 16 or so. (I addedm some instrumentation to :check this.) So I don't think the RX ring is getting anywhere near :drained. Hmm. I definitely think there's a bug due to not repopulating buffers from inside your receive interrupt packet processing loop, but it may not be the cause of this bug. If the NIC is unable to complete DMA quickly enough, perhaps the burst parameters can be tweaked. The PC certainly should be able to do DMA writes to memory at the PCI bus speed! Ok, lets see... what about these: Read Max DMA parameter Write Max DMA parameter Minimum DMA parameter PCI Latency Timer / system PCI latency timer At a guess, I think you would want: Read Max DMA parameter 16 Write Max DMA parameter 128 Minimum DMA parameter 128 PCI Latency Timer relatively high for this board ( if you have a per-board choice, you may not ) :write ring, but that ring is already full. In other words, the MAC :part of the NIC is getting the all the frames and wants to get them :into the host, but the DMA is proceeding so slowly that it can't move :them all and has to drop some. : :I'm not discounting the possibility that the receive handler is botching :things somehow, but I don't think the problem is lack of space in the :receive ring. : :-Bill -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message