Thread (51 messages) 51 messages, 5 authors, 2007-08-27

Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)

From: David Acker <hidden>
Date: 2007-05-24 12:42:59

Milton Miller wrote:
On May 23, 2007, at 4:32 PM, David Acker wrote:
quoted
Milton Miller wrote:
quoted
My current reading of the manual is that the C bit will not be
set on an RFD that is size 0.  It goes on to processes EL and
S, and decides to stop and interrupt RNR or suspend, or just
go to the next packet.
I double checked this with a quick experiment and it appears you are 
correct.

What about if we always did the following:
set the size:
sync();
clear el-bit
sync()

Then if the hardware sees just the size set, the packet completes but 
with the el-bit and we know we need to restart since it completed.
If it sees the size == 0, and the el bit set, it stops and RNR 
interrupts.
I think this is exposed to a hole and a race:  we don't know if the 
hardware
read the RFD before we set the size or after, just that it was before 
the EL
bit was cleared.  If it read it before the size was set, then it will not
set the C bit.  If it reads it after the size is set, it will complete it.
Yep...I too got sidetracked!  My test time got lost to two 2 month old 
twins needing to be fed or else! :-)
For coherent DMA we can always observe the C bit.  But for the 
incoherent DMA
case, our store to clear the EL bit may overwrite the dma from the 
device to
the beginning of the packet, or the write to EOF, F, and size, and/or the
write to C, OK, and status bits to tell us its done.  In the worst case, we
would overwrite the beginning of the data but catch the C bit and even the
actual size, and therefore would receive corrupted data.

We can only detect the hardware went RNR when it does so or decide we 
won the
race when it receives and completes the next frame.
Yes, I agree.
quoted
When we find a buffer that is not completed but has the el-bit set, we 
read the status byte of the status control block to see if the RU is 
in the no resources state.  If it isn't, it means that we found that 
buffer  before the hardware did and thus need to wait for it.  We will 
either find it on the next poll or enable interrupts and get told 
about it by hardware.

What do you think?
I think the second part is good ...
Cool.  That part seemed to work well in my tests.

I will reply to your next mail to discuss your plan so that I get it all 
in one message.
-Ack
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help