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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4654B2E4.9010308@roinet.com>
Date:	Wed, 23 May 2007 17:32:20 -0400
From:	David Acker <dacker@...net.com>
To:	Milton Miller <miltonm@....com>
CC:	Jeff Garzik <jgarzik@...ox.com>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	e1000-devel@...ts.sourceforge.net,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	John Ronciak <john.ronciak@...el.com>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	netdev@...r.kernel.org, Scott Feldman <sfeldma@...ox.com>
Subject: Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and
 el bits)

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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html