netdev - RE: [PATCH 2/3] x86_64: Define 128-bit memory-mapped I/O operations

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]

Date:	Wed, 22 Aug 2012 16:05:03 +0100
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Ben Hutchings" <bhutchings@...arflare.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	"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

> Btw, are we even certain that a 128-bit PCIe write is going to remain
> atomic across a bus (ie over various PCIe bridges etc)? Do you you
> care? Is it just a "one transaction is cheaper than two", and it
> doesn't really have any ordering constraints? If the thing gets split
> into two 64-bit transactions (in whatever order) by a bridge on the
> way, would that be ok?

PCIe transfers are basically hdlc packets containing the address,
command and any associated data. Unless they get bridged
though some strange PCIe<->PCI<->PCIe system they are very
unlikely to get broken up.
Maybe if they are longer than the maximum TLP size for the
target somewhere - but that is probably at least 128 bytes.

The time taken is largely independent of the transfer size.
The systems I've used (ppc accessing an Altera FPGA) have
PCIe cycles types of the order of microseconds.
Even for slow comms it is important to generate long TLP.

	David

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