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

[David Acker <dacker@roinet.com>]

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