Message-ID: <4227AEA2.8060007@pobox.com>
Date: Thu, 03 Mar 2005 19:41:06 -0500
From: Jeff Garzik <jgarzik@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
MIME-Version: 1.0
To: Roland Dreier <roland@topspin.com>
CC: akpm@osdl.org, linux-kernel@vger.kernel.org, openib-general@openib.org
Subject: Re: [PATCH][16/26] IB/mthca: mem-free doorbell record writing
References: <2005331520.WW3zbnVIUjZ4q0Ov@topspin.com>	<4227A606.50703@pobox.com> <52vf88ntbo.fsf@topspin.com>
In-Reply-To: <52vf88ntbo.fsf@topspin.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1015
Lines: 27

Roland Dreier wrote:
>     Jeff> Are you concerned about ordering, or write-combining?
> 
> ordering... write combining would be fine.
> 
>     Jeff> I am unaware of a situation where writes are re-ordered into
>     Jeff> a reversed, descending order for no apparent reason.
> 
> Hmm... I've seen ppc64 do some pretty freaky reordering but on the
> other hand that's a 64-bit arch so we don't care in this case.  I
> guess I'd rather keep the barrier there so we don't have the
> possibility of a rare hardware crash when the HCA just happens to read
> the doorbell record in a corrupt state.

Well, we don't just add code to "hope and pray" for an event that nobody 
is sure can even occur...

Does someone have a concrete case where this could happen?  ever?

	Jeff


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/