[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1345659074.2709.80.camel@bwh-desktop.uk.solarflarecom.com>
Date: Wed, 22 Aug 2012 19:11:14 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: "H. Peter Anvin" <hpa@...or.com>,
David Laight <David.Laight@...lab.com>,
Benjamin LaHaise <bcrl@...ck.org>,
David Miller <davem@...emloft.net>, <tglx@...utronix.de>,
<mingo@...hat.com>, <netdev@...r.kernel.org>,
<linux-net-drivers@...arflare.com>, <x86@...nel.org>
Subject: Re: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations
On Wed, 2012-08-22 at 10:54 -0700, Linus Torvalds wrote:
> On Wed, Aug 22, 2012 at 10:27 AM, Ben Hutchings
> <bhutchings@...arflare.com> wrote:
> >
> > If this is right, how can it be safe to use readq/writeq at all?
>
> Pray.
>
> Or don't care about ordering: use hardware that is well-designed and
> doesn't have crap interfaces that are fragile.
Well the whole point of having the two 32-bit generic implementations is
that hardware may care about the order! How can it be right that a
64-bit implementation assumes it doesn't?
> If you care about ordering, you need to do them as two separate
> accesses, and have a fence in between. Which, quite frankly, sounds
> like the right model for you *anyway*, since then you could use
> write-combining memory and you might even go faster, despite an
> explicit fence and thus a minimum of 2 transactions.
Yes, which unfortunately is no better than we have at the moment.
> Seriously. If you care that deeply about the ordering of the bytes you
> write out, MAKE THAT ORDERING VERY EXPLICIT IN THE SOURCE CODE. Don't
> say "oh, with this hack, I win 100ns". You need to ask yourself: what
> do you care about more? Going really fast on some machine that you can
> test, or being safe?
I have to care quite a lot about both. :-) But yes, safety first.
> With PCIe, it's *probably* fine to just say "we expect 64-bit accesses
> to make it through unmolested".
I have to hope so.
> The 128-bit case I really don't know about. It probably works too. But
> while I'd call the 64-bit case almost certain (in the absence of truly
> crap hardware), the 128-bit case I have a hard time judging how
> certain it is going to be.
Right, I think it's been made pretty clear that it's going to be
dependent on more than just architecture.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
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
Powered by blists - more mailing lists