On Sat, Jul 28, 2012 at 8:50 PM, Clemens Ladisch <clemens@xxxxxxxxxx> wrote: > Alexey Filin wrote: >> On Fri, Jul 27, 2012 at 5:04 PM, Peter Stuge <peter@xxxxxxxx> wrote: >>> If you require consumer interfaces and you want neither USB nor >>> Ethernet then I guess there is only FireWire left to choose from. >> >> "The FireWire host interface supports DMA and memory-mapped devices" > > This is the interface between the host controller and its driver. > > The interesting thing about FireWire would be RDMA, but allowing the > device to read/write the PC's memory doesn't help you much because there > is no indication when it did so, so you'd need additional transactions > to tell your driver about this. Is IO operation of memory-mapped device guaranteed to be synchronous? > > With a 3.2 GHz CPU and under ideal conditions (using queued posted > quadlet writes), I can get about 120000 FireWire packets per second. > With such small packets, the bottleneck is the CPU because of the packet > queueing overhead. What you need is some protocol that does not use > packets. It is impossible, modern system bus (PCIe) uses serial links and a packet protocol (PCI Express 2.0 Base Specification Revision 0.9, 1.5. PCI Express Layering Overview): "PCI Express uses packets to communicate information between components. Packets are formed in the Transaction and Data Link Layers to carry the information from the transmitting component to the receiving component." Unfortunately spec doesn't define latencies. PCI Express 2.0 spec, 2.8. Completion Timeout Mechanism: "In any split transaction protocol, there is a risk associated with the failure of a Requester to receive an expected Completion. To allow Requesters to attempt recovery from this situation in a standard manner, the Completion Timeout mechanism is defined. This mechanism is intended to be activated only when there is no reasonable expectation that the Completion will be returned, and should never occur under normal operating conditions. Note that the values specified here do not reflect expected service latencies, and must not be used to estimate typical response times." PCI Express 2.0 spec, Table 7-24: Device Control 2 Register: "Completion Timeout Value - In device Functions that support Completion Timeout programmability, this field allows system software to modify the Completion Timeout value. This field is applicable to Root Ports, Endpoints that issue Requests on their own behalf, and PCI Express to PCI/PCI-X Bridges that take ownership of Requests issued on PCI Express....Default range: 50 μs to 50 ms" the same in PCI EXPRESS BASE SPECIFICATION, REV. 3.0 (Table 7-25: Device Control 2 Register) Some info about request ordering (PCI Express System Architecture, ch 8, Transaction ordering, Introduction): "...As with other protocols, PCI Express imposes ordering rules on transactions moving through the fabric at the same time. The reasons for the ordering rules include: * Ensuring that the completion of transactions is deterministic and in the sequence intended by the programmer. * Avoiding deadlocks conditions. * Maintaining compatibility with ordering already used on legacy buses (e.g., PCI, PCI-X, and AGP). * Maximize performance and throughput by minimizing read latencies and managing read/write ordering." Sequential order of request execution (Alan wrote about it) seems to be the cornerstone of existing buses. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
