On Mon, 12 Oct 1998, Matti Aarnio wrote:
> When can I have the fixed 3c59x.c ?
> Could it be worth pushing to Linus too ?
The next version will be out tomorrow, with this low-memory change, media
selection support for the new 3c900B-combo, and some changes for the latest
CardBus adapters.
> > An advantage to copying with the Alpha is that the Tulip must have
> > word-aligned receive buffers. With 14 byte Ethernet headers, the IP headers
> > are always misaligned. The Linux protocol code doesn't (didn't) have
> > get_unaligned() calls for disassembling packets, so uncopied packets cause
> > alignment traps. When copying packets (or with a better chip) you can do
> > skb_reserve(skb,2) to align the IP header.
>
> I puzzled this a bit, and then pulled 21143HRM (Hardware Reference
> Manual) from Intel's site.
>
> The chip supports having two buffers per ring descriptor entry,
> but there the rule of 'buffer size must be multiple of 4 bytes'
> does seem to block a possibly interesting way to split the frame
> into two parts with nice alignments... ("Copy the first 14 octets
> into buffer 1, then continue into buffer2 for the rest. Create the
> buffer1 to be 16 bytes before buffer2, and copy the initial 14
> bytes into proper alignment after the reception.")
>
> Of course the manual does not say, what will happen in this case
> the receive buffer1 size is 14, would the chip just store 14 real
> input bytes, and two nonsense ones into the buffer area, or would
> it completely refuse to store the bytes, or would it store 16 bytes,
> and then continue with buffer2 ?
I thought of this a long time ago, and tried it out. The Tulip rounds both
the addresses and buffer sizes down. The chips doesn't do byte steering
from the Rx FIFO, so the bytes always end up in the same place.
The Tulip driver also supports handles six chips from three other vendors.
They don't document their behavior and I haven't tested them, but I suspect
it's identical or less flexible. For instance the two Lite-On chips
apparently only work correctly in ring mode, not linked descriptor mode.
Donald Becker [EMAIL PROTECTED]
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
