Milton Miller wrote:
On May 23, 2007, at 4:32 PM, David Acker wrote:
Milton Miller wrote:
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.
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
-
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
