Date: Tue, 22 Jan 2002 03:03:57 +0100 From: Marko Zec <zec@tel.fer.hr> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: freebsd-stable@freebsd.org Subject: Re: if_fxp.c typo? Message-ID: <3C4CC88D.64BDDFD7@tel.fer.hr> References: <86y9kzqjlr.wl@keiichi01.osaka.iij.ad.jp> <7mn10ebxbp.wl@waterblue.imgsrc.co.jp> <3C4CA33C.BAD0F33B@tel.fer.hr> <20020121180148.U59128@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C4CC88D.64BDDFD7>