From owner-freebsd-stable Mon Jan 21 18: 4:34 2002 Delivered-To: freebsd-stable@freebsd.org Received: from inje.iskon.hr (inje.iskon.hr [213.191.128.16]) by hub.freebsd.org (Postfix) with ESMTP id F296637B404 for ; Mon, 21 Jan 2002 18:04:28 -0800 (PST) Received: from tel.fer.hr (zg07-232.dialin.iskon.hr [213.191.150.233]) by mail.iskon.hr (8.11.4/8.11.4/Iskon 8.11.3-1) with ESMTP id g0M24HE15393; Tue, 22 Jan 2002 03:04:17 +0100 (MET) Message-ID: <3C4CC88D.64BDDFD7@tel.fer.hr> Date: Tue, 22 Jan 2002 03:03:57 +0100 From: Marko Zec X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lemon Cc: freebsd-stable@freebsd.org Subject: Re: if_fxp.c typo? References: <86y9kzqjlr.wl@keiichi01.osaka.iij.ad.jp> <7mn10ebxbp.wl@waterblue.imgsrc.co.jp> <3C4CA33C.BAD0F33B@tel.fer.hr> <20020121180148.U59128@prism.flugsvamp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Jonathan Lemon wrote: > The multicast filter problem has already been resolved in r1.126 of > the driver, by reloading the multicast filters on initialization. Mea culpa, didn't follow the code development in detail recently. Nice. > The value for bundle_max is explicitly allowed to go to 0xffff, from > the Intel rcvbundl.h documentations: > > * .... If you do not want to put > * a limit on the bundle size, set this value to xFFFF. This is not a very wise thing to do - wouldn't it be better to generate an interrupt before all of the receive buffers get filled up? If that happens, the card will go in RNR state, so we will loose at least some packets in that case, and waste another couple of slow CPU-to-PCI cycles for restarting the receiver. > The value for int_range is also correct, again from the Intel code: > > * .... The current default is either x600 or x800; > * experiments show that the value probably should stay within the > * range of x200 - x1000. > > There is an internal multiplier of 1.5 for the values, so a range of > 300 - 3000 translates into 0x1C2 - 0x1194, with a default value of 0x5DC, > which is "close enough". Did you try to measure TCP throughput between two nodes that use small TCP window sizes (16K or less), with int_delay set to 1000 usec or more? On 3000 usec, TCP throughput drops in average from more than 10,5 Mbyte/s to only around 5. With all due respect to Intel's recommended and "probably" nice value ranges, int_delay set to more than 1 msec is an instant guarantee for throughput degradation, on all nodes that don't use large window TCP extensions. On the other hand, not allowing int_delay to be set lower than 300 usec is another nonsense - if Intel didn't put such restriction in it's own drivers (the values you refer to are only recommendations), why do we need to do it? Marko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message