Skip site navigation (1)Skip section navigation (2)
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>