From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH] ucc_geth: Rework the TX logic. Date: Mon, 30 Mar 2009 14:32:23 -0500 Message-ID: <49D11E47.8080106@freescale.com> References: <1238089445-28396-1-git-send-email-Joakim.Tjernlund@transmode.se> <2a27d3730903270245k6e8633eehfb5cd3fcebd36240@mail.gmail.com> <49CCD3E8.9040007@freescale.com> <49D0FFBB.7000009@freescale.com> <49D1052D.2050609@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Li Yang , linuxppc-dev@ozlabs.org, netdev@vger.kernel.org, pku.leo@gmail.com To: Joakim Tjernlund Return-path: Received: from az33egw02.freescale.net ([192.88.158.103]:43468 "EHLO az33egw02.freescale.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758685AbZC3TdH (ORCPT ); Mon, 30 Mar 2009 15:33:07 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: 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