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:
> I agree with this part of the approach.  I just think we need
> a bit more work on the "what to do when we are ready for
> hardware to not stop" part.
Agreed.

>
> The sync is required to push both cache lines, but there is no
> ordering guarantee.  This probably is why you saw size and el
> set.  Aligning the RFD to a cache line conflicts with aligning
> the payload (IP header and data) to a word boundary, and
> depending on cache line size it may be impossible to do both.
> 
> And it won't fix the hole for coherent dma machines.
Yep.

> It wasn't an issue before because we never set two fields.
Before the driver was setting link and clearing the el-bit on the last 
buffer.  This resulted in badness when hardware saw the el-bit cleared 
but link set to 0.

> 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.

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?
-Ack