Donald Becker <[EMAIL PROTECTED]> replies to me:
...
> This "buffer deficit" scheme has another beneficial effect: most new chips
> which implement hardware flow control can only trigger FC packets when
> running out of buffers, not in response to a driver-level request. BTW,
> hardware flow control is unrelated to the misnamed code in the new kernel.
> That new code should be called "randomly drop packets when actually doing
> work".
>
> > Speaking of which, a quick browse shows me that:
> > tulip.c at 2.0.35 has this rx_skbuff[] ring problem.
>
> See above -- it just has a different structure.
Eh ? Ok, I take your word on it.
> > 3c59x.c (up to and including version 0.99G!) driver does blow up if that
> > ring can not be refilled successfully...
>
> The 3c59x.c driver has a related bug: it has a limit check at the end of a
> loop instead of the beginning. (A mistaken optimization on my part.) If
> the receive ring cannot be filled and empties completely, there are
> obviously no packets to receive. But with the limit check at the end of the
> loop, the driver will think that and old, already-processed packet is a new
> one. Disaster occurs.. This same bug exists in the eepro100.c driver.
> (However the current tulip driver *does* have the check in the correct
> place.)
When can I have the fixed 3c59x.c ?
Could it be worth pushing to Linus too ?
...
> > de4x5.c (v0.542) driver will always alloc a new skb at an Alpha, and
> > then copy the data there. If the alloc fails, it is skipped. (No kernel
> > crash from that...) (But this isn't Donald's rx_skbuff[] beasts either..)
>
> That's similar to what my drivers used to do. It's a natural progression
> from the original driver model, which was "copy into a fresh skbuff", to the
> zero-copy "receive directly into an skbuff and refill the slot immediately".
>
> 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 ?
> Donald Becker [EMAIL PROTECTED]
> 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
/Matti Aarnio <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
