Subject: Re: Hardware questions
To: Peter Eisch <peter@boku.net>
From: David Laight <David.Laight@btinternet.com>
List: port-sparc
Date: 11/26/2001 22:52:00
> le0 at ledma0 slot 15 offset 0xc00000 level 6: address 08:00:20:1c:90:50
> le0: 8 receive buffers, 2 transmit buffers
> lebuffer0 at sbus0 slot 2 offset 0x40000: 128K memory
> le1 at lebuffer0 slot 2 offset 0x60000 level 4 (ipl 7): address
> 08:00:20:1c:90:50
> le1: 64 receive buffers, 16 transmit buffers
> 
> Which one is on my SS20 motherboard, the 8/2 rx/tx nic or the 64/16 rx/tx
> nic?
> 
> Now, if you would have cited the sparc64 hardware I would have kept quiet.

Ok - now I've not seen an sbus ethernet card with onboard memory....

However I would also never run an ethernet card with as few an 8 rx buffers.
Asking for trouble....

I always used 128 buffers of 512 bytes arranged as 64k contiguous memory.
A rx frame will be 1-3 buffers, but can be copied out into a correctly
sized streams message in one go (except when it wraps bottom to top).
This lets you receive a burst of 128 packets or 64kb of data without
taking an interrupt.

The tx space was 32kb - but filled in rotation, with a max of 128 pending
tx frames (data aligned into next 32 byte chunk with a guess to align
the copy of the userdata).

Never seen that run out of rx buffers.

Careful aligning of the data copies (probably) beats any attempt to tx/rx
from/to 'user' buffers.  Especially when you have to allow for the
pathological fragmented buffers.

It also stops lots of 1500 (maybe 2k) buffers being sat at the stream head
containing 1 byte of data each on a rlogin session.
(I know netBSD doesn't have a stream network stack...)

    David