netdev - Re: [PATCH] ucc_geth: Rework the TX logic.

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: <49D11E47.8080106@freescale.com>
Date:	Mon, 30 Mar 2009 14:32:23 -0500
From:	Scott Wood <scottwood@...escale.com>
To:	Joakim Tjernlund <Joakim.Tjernlund@...nsmode.se>
CC:	Li Yang <leoli@...escale.com>, linuxppc-dev@...abs.org,
	netdev@...r.kernel.org, pku.leo@...il.com
Subject: Re: [PATCH] ucc_geth: Rework the TX logic.

Joakim Tjernlund wrote:
>> different since descriptors are in MURAM which is ioremap()ed -- though 
>> switching to a cacheable mapping with barriers should be a performance 
>> improvement.
> 
> I always thought that MURAM was very fast. The whole reason to have BDs in
> MURAM is that it is faster than normal RAM, at least that is what I 
> thought.

Yeah, on second thought it probably wouldn't be worth it.  There's also 
the question of under what circumstances the QE's MURAM accesses will be 
cache-coherent.

As for the CPU not reordering guarded+cache inhibited accesses, that 
initially seemed to be true for the new arch stuff (book3e/book3s, but 
not really, see below), but the classic arch documentation only 
guarantees stores to such regions to be in-order (and the 
explicitly-specified operation of eieio on I+G accesses wouldn't make 
much sense if they were already guaranteed to be in-order).

Then I looked at the EREF to see what older book E documents had to say 
on the issue, and it suggests that when the architecture document says 
"out of order", it really means "speculative" (and reading the arch 
doc's definition of "out of order" seems to confirm this -- redefining 
terms is bad, m'kay?).  So it seems that the simple answer is no, 
guarded storage is not guaranteed to be in order, unless the only thing 
that can cause an out-of-order access is speculative execution.

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