Milton Miller wrote:
While this will help the problem with the cache-incoherent DMA systems
not running, it guarantees the hardware will stop every <ring-size>
packets and wait for the cpu to respond to an interrupt. It would seem
that this will lead to packet drops.
Well, in NAPI mode, we the CPU may poll its way to the last buffer
without having to go through an interrupt cycle. You are right that
buffers would probably get dropped between the time the hardware hit the
S-bit and the CPU caught up.
[download manual from site in source file]
In fact 6.4.3.4 says 82557 will start dropping frames immediately.
Looking at the descriptions around page 101:
(1) The link pointer, S, and EL is read when hw starts recieving the frame.
(2) Its pretty clear EL overrides S from the order of the descriptions
in the text.
My testing confirms this.
(3) 6.4.3.3.1 #4 looks intresting -- That is a RFD with size 0 skips
frame fill and goes to the next packet.
How about putting a zero length descriptor in consistent memory to
suspend the rx unit before the last real frame? In other words fr0 ->
fr1 ... frN-2 -> frN-1 -> WaitHere0 -> FrN. We could then have 2 such
frames, and when we refill modify FrN to the new chain, with the
WaitHere1 as its next-to-last, do the syncs, then clear the S bit on
WaitHere0. When the rx passes WaitHere0 we can reclaim it for the next
use (might want a slightly larger pool, basically need RxRingSize /
RxRingFillBatch such frames.
Hmm...I will take a look at this. My test worked over the weekend by
the way. A patch will be coming.
-Ack
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
