14 messages in org.freebsd.freebsd-stableRe: Strangeness with 4.0-S| From | Sent On | Attachments |
|---|---|---|
| Chris Wasser | Jun 25, 2000 8:08 am | |
| Doug White | Jun 26, 2000 9:12 am | |
| Uwe Laverenz | Jun 27, 2000 12:05 am | |
| laurens van alphen (craxx) | Jun 27, 2000 12:44 am | |
| Uwe Laverenz | Jun 27, 2000 2:47 am | |
| Bill Paul | Jun 30, 2000 11:53 am | |
| Alan Edmonds | Jun 30, 2000 12:28 pm | |
| Stephen McKay | Jul 3, 2000 12:49 am | |
| Stefan Esser | Jul 4, 2000 5:01 am | |
| Stephen McKay | Jul 4, 2000 7:10 am | |
| Stefan Esser | Jul 8, 2000 1:13 pm | |
| Stephen McKay | Jul 9, 2000 3:51 am | |
| Chad R. Larson | Jul 9, 2000 1:46 pm | |
| Stefan Esser | Jul 10, 2000 10:39 am |
| Subject: | Re: Strangeness with 4.0-S | |
|---|---|---|
| From: | Stefan Esser (se...@freebsd.org) | |
| Date: | Jul 10, 2000 10:39:55 am | |
| List: | org.freebsd.freebsd-stable | |
On 2000-07-09 20:52 +1000, Stephen McKay <mck...@thehub.com.au> wrote:
On Saturday, 8th July 2000, Stefan Esser wrote:
Oh, there are renegotiations after each overrun ??? They should not be required at all. The Ethernet chip probably supports writing a new prefetch limit into the register while fully active ... I have looked at a number of Ethernet controller data sheets. There never was a warning that the chip must be quiescent when the "early send" limit is modified.
The code at the point that an underrun is detected is:
printf("dc%d: TX underrun -- ", sc->dc_unit); if (DC_IS_DAVICOM(sc) || DC_IS_INTEL(sc)) dc_init(sc);
After that, it sets the new threshold, or store and forward mode. That conditional (which resets the DE-500 style cards I own), looks deliberate since it is so specific. Either that, or Bill was being conservative. When I get a chance, I will experiment with removing it.
Well, the DE Driver (DEC 21x4x) has (relevant lines marked ***):
if (csr & TULIP_STS_ABNRMLINTR) { u_int32_t tmp = csr & sc->tulip_intrmask & ~(TULIP_STS_NORMALINTR|TULIP_STS_ABNRMLINTR); *** if (csr & TULIP_STS_TXUNDERFLOW) { *** if ((sc->tulip_cmdmode & TULIP_CMD_THRESHOLDCTL) != TULIP_CMD_THRSHLD160) { *** sc->tulip_cmdmode += TULIP_CMD_THRSHLD96; *** sc->tulip_flags |= TULIP_NEWTXTHRESH; } else if (sc->tulip_features & TULIP_HAVE_STOREFWD) { sc->tulip_cmdmode |= TULIP_CMD_STOREFWD; sc->tulip_flags |= TULIP_NEWTXTHRESH; } } if (sc->tulip_flags & TULIP_NOMESSAGES) { sc->tulip_statusbits |= tmp; } else { tulip_print_abnormal_interrupt(sc, tmp); sc->tulip_flags |= TULIP_NOMESSAGES; } *** TULIP_CSR_WRITE(sc, csr_command, sc->tulip_cmdmode);
and later:
if (sc->tulip_flags & TULIP_NEEDRESET) { tulip_reset(sc); tulip_init(sc); }
But since TULIP_NEEDRESET has not been set in tulip_cmdmode, no chip reset is performed. I did not know, that the DC driver is different, but the specific test on Davicom and Intel chips seems to indicate, that Bill Paul knows what he is doing ... ;-)
I agree, that for chips that need to be completely re-initialized, the default might be store-and-forward ...
Well, I'd rather have the driver changed to not require a re-negotiation of the transmission parameters.
I haven't read the data sheet yet (downloading now). Then we should know what limitations we have to live with.
There are so many DEC 21x4x clones, all slightly different, and it seems that at least a few need the chip reset.
It hides the problem very well for me. I really can't see the tiniest of performance loss with store and forward. Maybe it's something that only shows up on benchmarks.
Guess it will show up if you measure latencies (or your application is doing lots of RPCs). But as soon as there is a cheap 100baseT switch in the path to the destination, there will be store-and-forward at work ;-)
Regards, STefan
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message