Re: [PATCH] e100 rx: or s and el bits

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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/