EP1190317A2 - Transfert de donnees, synchronisation d'applications et reseau a faible temps d'attente - Google Patents

Transfert de donnees, synchronisation d'applications et reseau a faible temps d'attente

Info

Publication number
EP1190317A2
EP1190317A2 EP00925509A EP00925509A EP1190317A2 EP 1190317 A2 EP1190317 A2 EP 1190317A2 EP 00925509 A EP00925509 A EP 00925509A EP 00925509 A EP00925509 A EP 00925509A EP 1190317 A2 EP1190317 A2 EP 1190317A2
Authority
EP
European Patent Office
Prior art keywords
data
computer
buffer
application
memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00925509A
Other languages
German (de)
English (en)
Inventor
Derek Edward Roberts
Steven Leslie Pope
Glenford Ezra Mapp
Stephen John Hodges
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
AT&T Investments UK LLC
Original Assignee
AT&T Laboratories Cambridge Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by AT&T Laboratories Cambridge Ltd filed Critical AT&T Laboratories Cambridge Ltd
Priority to EP02102568A priority Critical patent/EP1338965A3/fr
Priority to EP02102565A priority patent/EP1302854B1/fr
Priority to EP02102564A priority patent/EP1302853A3/fr
Priority to EP02102567A priority patent/EP1302855A3/fr
Publication of EP1190317A2 publication Critical patent/EP1190317A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/544—Buffers; Shared memory; Pipes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/382—Information transfer, e.g. on bus using universal interface adapter
    • G06F13/387—Information transfer, e.g. on bus using universal interface adapter for adaptation of different data processing systems to different peripheral devices, e.g. protocol converters for incompatible systems, open system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/323—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the physical layer [OSI layer 1]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • This invention in its various aspects, relates to the field of asynchronous networking, and specifically to: a memory mapped network interface; a method of synchronising between a sending application, running on a first computer, and a receiving application, running on a second computer, the computers each having a memory mapped network interface; a communication protocol; and a computer network.
  • This invention also relates to data transfer and to synchronising applications.
  • a traditional network is shown in Fig. 1.
  • CPU Central Processing Unit
  • NIC Network Interface Card
  • DMA Direct Memory Access
  • the NIC 210 takes the data and forms network packets 216, which contain enough information to allow them to be routed across the network 218 to computer system 201.
  • a network packet arrives at the NIC 211, it must be demultiplexed to determine where the data needs to be placed. In traditional networks this must be done by the operating system.
  • the incoming packet therefore generates an interrupt 207, which causes software, a device driver in operating system 209, to run.
  • the device driver examines the header information of each incoming network packet 216 and determines the correct location in memory 205, for data contained within the network packet. The data is transferred into memory using the CPU 203 or DMA hardware (not shown).
  • the driver may then request that operating system 209 reschedule any application process that is blocked waiting for this data to arrive.
  • These networks therefore provide implicit synchronisation between sending and receiving applications and are called synchronous networks.
  • asynchronous networks In asynchronous networks, the final memory location within the receiving computer for received data can be computed by the receiving NIC from the header information of a received network packet. This computation can be done without the aid of the operating system.
  • VISA Virtual Interface Architecture
  • Memory-mapped networks are one example of asynchronous networks.
  • An early computer network using memory mapping is described in US patent No. 4,393,443.
  • a memory-mapped network is shown in Fig. 2.
  • Application 222 running on Computer 220 would like to communicate with application 223 running on Computer 221 using network 224.
  • a portion of the application 222's memory address space is mapped using the computer 220's virtual memory system onto a memory aperture of the NIC 226 as shown by the application's page-tables 228 (these page-tables and their use is well known in the art).
  • a portion of application 223's memory address space is mapped using computer 221's virtual memory system onto a memory aperture of the NIC 229 using the application 223's page-tables 231.
  • Software is usually required to create these mappings, but once they have been made, data transfer to and from a remote machine can be achieved using a CPU read or write instruction to a mapped virtual memory address.
  • NIC 226, determines the address of the destination computer 221 and the address of the remote memory aperture 225 within that computer. Some combination of this address information can be regarded as the network address, which is the target of the write.
  • All the aperture mappings and network address translations are calculated at the time that the connection between the address spaces of computers 220 and 221 is made.
  • the process of address lookups and translations at each stage in the system can be carried out using hardware.
  • NIC 226 After receiving a write, NIC 226 creates network packets using its packetisation engine 230. These packets are forwarded to the destination computer 221. At the destination, the memory aperture addresses of the incoming packets are remapped by the packet handler onto physical memory locations 227. The destination NIC 229 then writes the incoming data to these physical memory locations 227. This physical memory has also been mapped at connection set-up time into the address space of application 223. Hence application 223 is able, using page-tables 231 and the virtual memory system, to access the data using processor read and write operations.
  • SCI Scalable Coherent Interface
  • SCI is an example of an asynchronous network standard, which provides poor facilities for synchronisation at the time of data reception.
  • a network using SCI is disclosed in US Patent No. 5,819,075.
  • Figure 3 shows an example of an SCI- like network, where application 242 on computer 240 would like to communicate with application 243 on computer 241. Let us suppose that application 243 has blocked waiting for the data. Application 242 transmits data using the methods described above. After sending the data, application 242 must then construct a synchronisation packet in local memory, and program the event generator 244, in NIC 246, to send the synchronisation packet 248, to the destination node.
  • the NIC 245 on computer 241 On receiving synchronisation packet 248, the NIC 245 on computer 241, invokes its event handler 247, which generates an interrupt 249 allowing the operating system 248 to determine that application 243 is blocked and should be woken up.
  • This is called out- of-band synchronisation since the synchronisation packet must be treated as a separate and distinct entity and not as part of the data stream.
  • Out-of-band synchronisation greatly reduces the potential of memory-mapped networks to provide high bandwidth and low latency.
  • NIC In other existing asynchronous networks, such as the newly emerging Virtual Interface Architecture (VIA) standard and the forthcoming Next Generation Input/Output (NGIO) standard, some support is provided for synchronisation.
  • VIP Virtual Interface Architecture
  • NGIO Next Generation Input/Output
  • a NIC will raise a hardware interrupt when some data has arrived. However, the interrupt does not identify the recipient of the data, instead only indicates that some data has arrived for some communicating end-point.
  • EP 0 600 683 EP 0 359 137, EP 0 029 800, US 5 768 259, US 5 550 808 and JP 600211559.
  • a first aspect of the invention provides a method of synchronising between a sending application on a first computer and a receiving application on a second computer, each computer having a main memory, and at least one of the computers having an asynchronous network interface, comprising the steps of: providing the asynchronous network interface with a set of rules for directing incoming data to memory locations in the main memory of the second computer; storing in the network interface one or more triggering value(s), each triggering value representing a state of a data transfer between the applications; receiving, at the network interface, a data stream being transferred between the applications; comparing at least part of the data stream received with the stored triggering values; if the compared part of the data stream matches any stored triggering value, indicating that the triggering value has been matched; and storing the data received in the main memory of the second computer at one or more memory location(s) in accordance with the said rules.
  • an asynchronous network interface for use in a host computer having a main memory and connected to a network, the interface comprising: means for storing a set of rules for directing incoming data to memory locations in the main memory of the host computer; a memory for storing one or more triggering value(s), each value representing a state of a data transfer between two or more applications in the computer network; a receiver for receiving a data stream being transferred between two or more applications in the computer network; comparison means for comparing at least part of the data stream received by the network interface with the stored triggering values; and a memory for storing information identifying any matched triggering values.
  • a further aspect of the invention provides a method of passing data between an application on a first computer and remote hardware within a second computer or on a passive backplane, the first computer having a main memory and an asynchronous network interface, the method comprising the steps of: providing the asynchronous network interface with a set of rules for directing incoming data to memory or I/O location(s) of the remote hardware; storing in the network interface one or more triggering value(s), each triggering value representing a state of a data transfer between the application and the hardware; receiving, at the network interface, a data stream being transferred between the application and the hardware; comparing at least part of the data stream received with the stored triggering value(s); indicating that a triggering value has been matched, if any compared part of the data stream matches a triggering value; storing data transmitted in memory or I/O location(s) of the remote hardware in accordance with the said rules; and storing the data received in the main memory of the computer at one or more memory location(s) in accordance with the said
  • a further aspect of the invention provides a method of arranging data transfers from one or more applications on a computer, the computer having a main memory, an asynchronous network interface, and a Direct Memory Access (DMA) engine having a request queue address common to all the applications, comprising the steps of: the application requesting the network interface to store a triggering value corresponding to a property of the data block to be transferred; an application requesting the DMA engine to transfer a block of data; the network interface storing a triggering value corresponding to a property of the data block to be transferred, along with an identification of the application which requested the DMA transfer; the network interface monitoring the data stream being sent by the applications and comparing at least part of the data stream with the triggering value(s) stored in its memory; and if any triggering value matches, indicating that that triggering value has matched.
  • DMA Direct Memory Access
  • a yet further aspect of the invention provides a method of transferring data from a sending application on a first computer to a receiving application on a second computer, each computer having a main memory, and a memory mapped network interface, the method comprising the steps of: creating a buffer in the main memory of the second computer for storing data being transferred as well as data identifying one or more pointer memory location(s); storing at said pointer memory location(s) at least one write pointer and at least one read pointer for indicating those areas of the buffer available for writes and for reads; in dependence on the values of the WRP(s) and RDP(s), the sender application writing to the buffer; updating the value of the WDP(s), after a write has taken place, to update the indication of the areas of the buffer available for reads and writes; in dependence on the values of WRP(s) and RDP(s), the receiver application reading from the buffer; and updating the value of the RDP(s), after a read has taken place, to update the indication of the areas of the buffer available for read
  • Another aspect of the invention provides a computer network comprising two computers, the first computer running a sending application and the second computer running a receiving application, each computer having a main memory and a memory mapped network interface, the main memory of the second computer having: a buffer for storing data being transferred between computers as well as data identifying one or more pointer memory location(s); means for reading at least one write pointer (WRP) and at least one read pointer (RDP) stored at (a) pointer memory location(s), for indicating those areas of the buffer available for writes and those areas available for reads; the network interface of the second computer comprising: a memory mapping; means for reading data from the buffer in accordance with the contents of the WRP(s) and RDP(s); and means for updating the value of the RDP(s), after a read has taken place, to update the indication of the areas of the buffer available for reads and writes.
  • WRP write pointer
  • RDP read pointer
  • a further aspect of the invention provides a method of sending a request from a client application on a first computer to a server application on a second computer, and sending a response from the server application to the client application, both computers having a main memory and a memory mapped network interface, the method comprising the steps of:
  • Another aspect of the invention provides a method of arranging data for transfer as a data burst over a computer network comprising the steps of: providing a header comprising the destination address of a certain data word in the data burst, and a signal at the beginning or end of the data burst for indicating the start or end of the burst, the destination addresses of other words in the data burst being inferrable from the address in the header.
  • a further aspect of the invention provides a method of processing a data burst received over a computer network comprising the steps of: reading a reference address from the header of the data burst, and calculating the addresses of each data word in the burst from the position of that data word in the burst in relation to the position of the data word to which the address in the header corresponds, and from the reference address read from the header.
  • Another aspect of the invention provides a method of interrupting transfer of a data burst over a computer network comprising the steps of: halting transfer of a portion of the data burst which has not yet been transferred, thereby splitting the data burst into two burst sections, one which is transferred, and one waiting to be transferred.
  • a further aspect of the invention provides a method of restarting the transfer of a data burst, after the transfer of that data burst has been interrupted, the method comprising the steps of: calculating a new reference address for the untransferred data burst section from the address contained in the header of the whole data burst, and from the position in the whole data burst of the first data word of the untransferred data burst section in relation to the position of the data word to which the address in the header corresponds; providing a new header for the untransferred data burst section comprising the new reference address; and transmitting the new header along with the untransferred data burst section.
  • the first aspect of the present invention addresses the synchronisation problem for memory mapped network interfaces.
  • the present invention uses a network interface, containing snooping hardware which can be programmed to contain triggering values comprising either addresses, address ranges, or other data which are to be matched. These data are termed 'Tripwires'.
  • the interface monitors the data stream, including address data, passing through the interface for addresses and data which match the Tripwires which have been set.
  • the snooping hardware can generate interrupts or increment event counters, or perform some other application specified action.
  • This snooping hardware is preferably based upon Content Addressable Memory (CAM). References herein to the "data stream” refer to the stream of data words being transferred and to the address data accompanying them.
  • CAM Content Addressable Memory
  • the invention thus provides in-band synchronisation by using synchronisation primitives which are programmable by user level applications, while still delivering high bandwidth and low latency.
  • the programming of the synchronisation primitives can be made by the sending and receiving applications independently of each other and no synchronisation information is required to traverse the network.
  • a number of different interfaces between the network interface and an application can be supported. These interfaces include VIA and the forthcoming Next Generation Input Output (NGIO) standard.
  • NGIO Next Generation Input Output
  • An interface can be chosen to best match an application's requirements, and changed as its requirements change.
  • the network interface of the present invention can support a number of such interfaces simultaneously.
  • the Tripwire facility supports the monitoring of outgoing as well as incoming data streams. These Tripwires can be used to inform a sending application that its DMA send operations have completed or are about to complete.
  • Memory-Mapped network interfaces also have the potential to be used for communication between hardware entities. This is because memory mapped network interfaces are able to pass arbitrary memory bus cycles over the network. As shown in Fig. 4, it is possible to set up a memory aperture 254, in the NIC 252 of Computer 250, which is directly mapped via NIC 259, onto an address region 257 of the I/O bus 253 of passive backplane 251.
  • NIC Network Interface card
  • the interface of the present invention can be programmed to present the same hardware interface as the remote hardware device 255, and so appear at the hardware level in computer 250 to be an instance of the remote hardware device. If the network card 252 were an interface according to the present invention, so programmed, the remote hardware device 255 would appear as physically located within computer 250, in a manner transparent to all software.
  • the hardware device 255 is able to be physically located both at the remote end of a dedicated link, or over a general network. The invention will support both general networking activity and remote hardware communication simultaneously on a single network card.
  • Another aspect of the invention relates to a link-level communication protocol which can be used to support cut-through routing and forwarding. There is no need for an entire packet to arrive at a NIC, or any other network entity supporting the communication protocol, before data transmission can be started on an outgoing link.
  • the invention also allows large bursts of data to be handled effectively without the need for a small physical network packet size such as that employed by an ATM network, it being possible to dynamically stop and restart a burst and regenerate all address information using hardware.
  • FIG. 5 shows two or more computers connected by an embodiment of the present invention, using Network Interface Cards (NICs);
  • NICs Network Interface Cards
  • FIG. 6 shows in detail the various functional blocks comprising the NICs of Figure 5;
  • Figure 7 shows the functional blocks of the NIC loyed within a Field Programmable
  • FPGA Gate Array
  • FIGS 8 and 8e shows the communication protocol used in one embodiment of the invention
  • FIG. 9 shows schematically hardware communication according to an embodiment of the invention.
  • Figure 10 shows schematically a circular buffer abstraction according to one embodiment of the invention
  • Figure 11 shows schematically the system support for discrete message communication using circular buffers
  • Figure 12 shows a client-server interaction according to an embodiment of the invention
  • Figure 13 shows how the system of the present invention can support VIA;
  • Figure 14 shows outgoing stream synchronisation according to an embodiment of the present invention;
  • Figure 15 shows a client-server interaction according to an embodiment of the invention using a hardware data source
  • Figure 16 shows an apparatus for synchronising an end-point application and constituting an embodiment of the invention
  • Figure 17 shows another apparatus for synchronising an end-point application and constituting an embodiment of the invention
  • Figures 18 to 23 show examples of actions which may be performed by the apparatuses of Figures 16 and 17;
  • Figure 24 illustrates the format of a data burst with implied addresses
  • Figure 25 illustrates an interruption in forwarding a burst of the type shown in Figure
  • Figure 26 illustrates forwarding of the rest of the burst
  • FIG. 27 illustrates coalescing of two data bursts
  • Figure 28 illustrates "transparent" communication over a network between an application running on a computer and remote hardware
  • Figure 29 illustrates applications of various tripwires at different locations in a computer.
  • computers 1, 2 use the present invention to exchange data.
  • a plurality of other computers such as 3, may participate in the data exchange if connected via optional network switch 4.
  • Each computer 1, 2 is composed of a microprocessor central processing unit 5,57, memory 6,60, local cache memory 7,57, and system controller 8,58.
  • the system controller 8,58 interacts with its microprocessor 5,57 to allow the microprocessor to exchange data with devices attached to I/O bus 9.
  • Attached to I/O bus 9,59 are standard peripherals, such as a video adapter 10.
  • Also attached to I/O bus 9,59 is one or more network interfaces, in the form of NICS 11,56 which represent an embodiment of this invention.
  • the I/O bus is a standard PCI bus conforming to PCI Local Bus Specification, Rev. 2.1, although any other bus capable of supporting bus master operations can be used with suitable modification of System Controller peripherals, such as video card 10, and the interface to NIC 11,56.
  • each NIC comprises a memory 18, 19, 20 for storing triggering values, a receiver 15 for receiving a data stream, a comparator for comparing part of the data stream with the triggering values and a memory 23 for storing information which will identify matched triggering values.
  • each NIC 56, 11 is composed of a PCI to Local Bus bridge 12, a control Field Programmable Gate Array (FPGA) 13, transmit (Tx) serialiser 14, fibre-optic transceiver 15, receive (Rx) de-serialiser 16, address multiplexer and latch 17, CAM array 18, 19, 20, boot ROMs 21 and 22, static RAM 23, FLASH ROM 24, and clock generator and buffer 25, 26.
  • Figure 6 also shows examples of known chips which could be used for each component, for example boot ROM 21 could be an Altera EPC1 chip.
  • FPGA 13 is comprised of functional blocks 27-62. The working of the blocks will be explained by reference to typical data flows.
  • NIC 11 Operation of NIC 11 begins by computer 1 being started or reset. This operation causes the contents of boot ROM 21 to be loaded into FPGA 13 thereby programming the FPGA and, in turn, causing state machines 28, 37, 40, 43, 45, 46 and 47 to be reset.
  • Clock generator 25 begins running and provides a stable clock for the Tx serialiser 14.
  • Clock buffer/divider 26 provides suitable clocks for the rest of the system.
  • Serialiser 14 and de-serialiser 16 are reset and remain in a reset condition until communication with another node is established and a satisfactory receive clock is regenerated by de- serialiser 16.
  • PCI bridge 12 is also reset and loaded with the contents of boot ROM 22.
  • Bridge 12 can convert (and re-convert at the target end) memory access cycles into I/O cycles and support legacy memory apertures, and as the rest of the NIC supports byte-enabled (byte-wide as well as word-wide) transfers, ROM 22 can be loaded with any PCI configuration space information, and can thus emulate any desired PCI card transparently to microprocessor 5.
  • FLASH control state machine 47 Immediately after reset, FLASH control state machine 47 runs and executes a simple microcode sequence stored in FLASH memory 24. Typically this allows the configuration space of another card such as 69 in Figure 9 to be read, and additional information to be programmed into bridge 12. Programming of the FLASH memory is also handled by state machine 47 in conjunction with bridge 12.
  • Microprocessor 5 writes one or more words to an address location defined by system controller 8 to lie within NIC 1 l's address space.
  • PCI to local bus bridge 12 captures these writes and turns them into local bus protocol (discussed elsewhere in this document). If the writes are within the portion of the address space determined to be within the local control aperture of the NIC by register decode 48, then the writes take place locally to the Content Addressable Memory appropriate register, (CAM), Static RAM (SRAM) or FLASH memory area. Otherwise target state machine 28 claims the cycles and forwards them to protocol encoder 29.
  • CAM Content Addressable Memory appropriate register
  • SRAM Static RAM
  • byte-enable, parity data and control information are added first to an address and then to each word to be transferred in a burst, with a control bit marking the beginning of the burst and possibly also a control bit marking the end of the burst.
  • the control bit marking the beginning of the burst indicates that address data forming the header of the data burst comprises the first "data" word of the burst.
  • Xon/Xoff-style management bits from block 31 are also added here. This protocol, specific to the serialiser 14 and de-serialiser 16 is also discussed elsewhere in this document.
  • Serialiser 14 converts a 23-bit parallel data stream at 62MHz to a 1-bit data stream at approximately 1.5Gbit s; this is converted to an optical signal by transceiver 15 and carried over a fibre-optic link to a corresponding transceiver 15 in NIC 56, part of computer 2. It should be noted that other physical layers and protocols are possible and do not limit the scope of the invention.
  • NIC 56 the reconstructed digital signal is clock-recovered and de-serialised to 62MHz by block 16.
  • Block 32 expands the recovered 23 bits to 46 bits, reversing the action of block 30.
  • Protocol decoder 33 checks that the incoming words have suitable sequences of control bits. If so, it passes address/data streams into command FIFO 34. If the streams have errors, they are passed into error FIFO 35; master state machine 37 is stopped; and an interrupt is raised on microprocessor 57 by block 53. Software is then used to decipher the incoming stream until a correct sequence is found, whereupon state machine 37 is restarted.
  • master state machine 37 When a stream arrives at the head of FIFO 34, master state machine 37 requests access to local bus 55 from arbiter 40. When granted, it passes first the address, then the following data onto local bus 55. Bridge 12 reacts to this address/data stream by requesting access to I/O bus 59 from system controller 58. When granted, it writes the required data into memory 60.
  • Reads of computer 2's memory 60 initiated by computer 1 take place in a similar manner. However, state machine 28 after sending the address word sends no other words, rather it waits for return data. Data is returned because master state machine 37 in NIC 56 reacts to the arrival of a read address by requesting a read of memory 60 via I/O bus 59 and corresponding local bus bridge 12. This data is returned as if it were write data flowing from NIC 56 to NIC 11, but without an initial address. Protocol decoder 33 reacts to this addressless data by routing it to read return FIFO 36, whereupon state machine 28 is released from its wait and the microprocessor 5's read cycle is allowed to complete.
  • remote interrupt generator 54 causes state machine 28 to send a word from NIC 56 to a mailbox register in NIC 1 l's bridge 12. This will have been configured by software to raise an interrupt on microprocessor 5.
  • master state machine 37 uses pipeline delay 38 to anticipate the draining of FIFO 34 and to terminate the data burst on local bus 55. It then uses the CAM address latch/counter 41 to restart the burst when more data arrives in FIFO 34.
  • 'Tripwires' are triggering values, such as addresses, address ranges or other data, that are programmed into the NIC to be matched.
  • the trigging values used as tripwires are addresses.
  • three CAM devices are pipelined to reduce the match cycle time from around 70 nanoseconds to less than 30 nanoseconds.
  • Tripwires takes place by microprocessor 5 writing to PCI bridge 12 via system controller 8 and I/O bus 9.
  • CAM array 18, 19, 20 appears like conventional RAM to microprocessor 5.
  • Address latch 44 passes data to the CAMs unmodified.
  • Address multiplexer 41 is arranged to pass local bus data out on the CAM address bus where it is latched at the moment addresses are valid on the local bus by latch 17.
  • address latch/counter 44 has its data flow direction reversed. So far as microprocessor 5 is concerned, it sees the expected data returned, since the memory arrays in CAMs 18, 19, 20 either contain the same data, or internal flags indicating that particular segments of the memory array have not yet been written and should not participate in match cycles.
  • a burst starts with the address of the first data word followed by an arbitrary number of data words.
  • the address of the data words is implicit and increments from the start address.
  • address latch/counter 44 is loaded with the address of each new data burst, and incremented each time a valid data item is presented on internal local bus 55.
  • CAM control state machine 43 is arranged to enable each CAM 18, 19, 20 in sequence for a compare operation as each new address is output by latch/counter 44.
  • This sequential enabling of the CAMs combined with their latching properties permits the access time for a comparison operation to be reduced by a factor of three (there being three CAMs in this implementation, other implementations being possible) from 70ns to less than 30ns.
  • the CAM op-code for each comparison operation is output from one of the internal registers 49 via address multiplexers 41 and 17. The op-code is actually latched by address multiplexer 17 at the end of a read/write cycle, freeing the CAM address bus to return the index of matched Tripwires after comparison operations.
  • the Tripwire data (i.e. the addresses to be monitored) is written to sequential addresses in the CAM array.
  • the comparison operation (cycle) all valid Tripwires are compared in parallel with the address of the current data, be it inbound or outbound.
  • masking operations may be performed, depending on the type of CAM used, allowing certain bits of the address to be ignored during the comparison. In this way, a Tripwire may actually represent a range of addresses rather than one particular address.
  • the CAM array When the CAM array signals a match found (i.e. a Tripwire has been hit), it returns the address of the Tripwire (its offset in the CAM array) via the CAM address bus to the tripwire FIFO 42. Two courses of action are then possible, depending on how internal registers 49 have been programmed.
  • state machine 45 One course of action is for state machine 45 to request that an interrupt be generated by management logic 53.
  • an interrupt is received by microprocessor 5, and software is run which services the interrupt. Normally this would involve microprocessor 5 reading the Tripwire address from FIFO 42, matching the address with a device-driver table, signalling the appropriate process, marking it runnable and rescheduling.
  • state machine 45 to cause records to be read from SRAM 23 using state machine 46.
  • a record comprises a number of data words; an address and two data words. These words are programmed by the software just before the Tripwire information is stored in the CAM.
  • the address in LATCH 44 is left shifted by two to form an address index for SRAM 23.
  • the first word is then read by state machine 46 and placed on local bus 55 as an address in memory 6.
  • a fetch-and-increment operation is then performed by state machine 45, using the second and third words of the SRAM record to first AND and then OR, or else INCREMENT the data referred to in memory 6.
  • a bit in the first word read by the state machine will indicate which operation it should take. In the case of an INCREMENT, the first data word also indicates the amount to increment by.
  • the device driver While in the case of the interrupt followed by a Tripwire FIFO read, the device driver is presented with a list of endpoints which require attention. This list improves system performance as the device driver is not required to scan a large number of memory locations looking for such endpoints.
  • the device driver Since the device driver is not required to know where the memory locations which have been used for synchronisation are. It is also not required to have any knowledge or take part in the application level communication protocol. All communication protocol processing can be performed by the application and different applications are free to use differing protocols for their own purposes, and one device driver instance may support a number of such applications.
  • the invention addresses this problem by using hardware FIFO 50 to queue DMA requests from applications.
  • Each application wanting to request DMA transfers sets up a descriptor, containing the start address and the length of the data to be transferred, in its local memory and posts the address of the descriptor to the DMA queue, whose address is common to all applications. This can be arranged by mapping a single page containing the physical address of the DMA queue as a write-only page into the address space of all user applications as they are initialised.
  • bridge 12 When the DMA process is complete, bridge 12 notifies state machine 51 of the completion. The state machine then uses data from descriptor block 52 to write back a completion descriptor in memory 6. Optionally, an interrupt can also be raised on microprocessor 5, although a Tripwire may already have been crossed to provide this notification early in order to minimise the delay bringing the relevant application back onto microprocessor 5's run queue. This is shown later in this document.
  • state machine 51 writes a failure code back into the completion field of the descriptor that the application has just attempted to place on the queue.
  • the application does not need to read the status of the NIC in order to safely post a DMA request. All applications can safely share the same hardware posting address, and no time-consuming virtualisation or system device driver process is necessary. Should any operation take longer than a preset number of PCI cycles, timeout logic 61 is activated to terminate the current cycle and return an interrupt through block 53.
  • Another aspect of the invention relates to the protocol which is preferably used by the NIC.
  • This protocol uses an address and some additional bits in its header. This allows the transfer of variable length packets with simple routines for Segmentation and Reassembly (SAR) that are transparent to the sending or receiving codes. This is also done without the need to have an entire packet arrive before segmentation, reassembly or forwarding can occur, allowing the data to be put out on the ongoing link immediately. This enables data to traverse many links without significantly adding to the overall latency.
  • the packets may be fragmented and coalesced on each link, for example between the NIC and a host I/O bus bridge, or between the NIC and another NIC. We term this cut-through routing and forwarding.
  • cut-through forwarding and routing enables small packets to pass through the network without any delays caused by large packets of other streams. While other network physical layers such as ATM also provide the ability to perform cut- through forwarding and routing, they do so at the cost of requiring all packets to be of a fixed small size.
  • FIG 8 shows an example of how this protocol has been implemented using the 23-bit data transfer capability of HP's GLLNK chipset (serialiser 14 and de-serialiser 16).
  • PCI to local bus bridge 12 provides a bus of 32 address/data bits, 4 parity bits and 4 byte- enable bits. It also provides an address valid signal (ADS) which signifies that a burst is beginning, and that the address is present on the address/data bus. The burst continues until a burst last signal (BLAST) is set active, signifying the end of a burst. It provides a read/write signal, and some other control signals that need not be transferred to a remote computer.
  • Figure 8A shows how this protocol is used to transfer an n data word burst 63.
  • the data traffic closely mirrors that used on the PCI bus, but uses fewer signals.
  • the destination address always precedes each data burst. Therefore, the bursts can be of variable size, can be split or coalesced, by generating fresh address words, or by removing address words where applicable.
  • sequential data words are destined for sequentially incrementing addresses.
  • data words having sequentially decrementing addresses might also be used, or any other pattern of addresses may be used so long as it remains easy to calculate. So far as the endpoints are concerned, exactly the same data is transferred to exactly the same locations.
  • packets can be of any size at all, reducing the overhead of sending an address; packets can be split (and addresses regenerated to continue) by network switches to provide quality of service, and receivers need not wait for a complete packet to arrive to begin decoding work.
  • the destination address given in the header may be for the 'nth' data word in the burst, rather than for the first, although using the first data word address is preferred.
  • Figure 8b shows how the protocol of Figure 8a is transcribed onto the G-LINK physical layer.
  • the first word in any packet contains an 18-bit network address.
  • Each word of 63 is split into two words in 64; the lower 16 bits carry high and low addresses or data, corresponding to the address/data bus; the next 4 bits carry either byte enables or parity data.
  • the byte enable field (only 2 bits of which are available, owing to the limitations of G-LINK) is used to carry a 2-bit code indicating read, write or escape packet use. Escape packets are normally used to carry diagnostic or e ⁇ or information between nodes, or as a means of carrying the Xon/Xoff-style protocol when no other data is in transit.
  • the G-LINK nCAV signal corresponds to the ADS signal of 63; nDAV is active throughout the rest of the burst and the combination of nDAV inactive and nCAV inactive signals the end of a burst, or nC AV active indicates the immediate beginning of another burst.
  • Figure 8c shows a read data burst 65; this is the same as a write burst 64, except data bit 16 is set to 0.
  • the data field contains the network address for the read data to be returned to.
  • the data for a read returns 66 it travels like a write burst, but is signified by there only being one nCAV active (signifying the network address) along with the first word.
  • An additional bit, denoted FLAG in Figure 8 is used to cary Xon/Xoff sttyle information when a burst is in progress. It is not necessary therefore to break up a burst in order to send an Escape packet containing the Xon/Xoff information.
  • the FLAG bit also serves as an additional end of packet indicator.
  • 67,68 shows an escape packet; after the network address, this travels with 68 or without 67 a payload as defined by data bit 16 in the first word of the burst.
  • an extra network address word may precede each of these packets.
  • Other physical layer or network layer solutions are possible, without compromise to this patent application, including fibre channel parts (using 8B/10B encoding) and conventional networks such as ATM or even Ethernet.
  • the physical layer only needs to provide some means of identifying data from non-data and the start of one burst from the end of a previous one.
  • a further aspect of the invention relates to the distribution of hardware around a network.
  • One use of a network is to enable one computer to access a hardware device whose location is physically distant.
  • a hardware device whose location is physically distant.
  • the NIC 73 is programmed from Boot ROM 22 to present the same hardware interface as that of the frame-grabber card 69.
  • Computer 72 can be running the standard application program as provided by a third party vendor which is unaware that system has been distributed over a network.
  • All control reads and writes to the frame-grabber 69 are transparently forwarded by the NIC 73, and there is no requirement for an extra process to be placed in the data path to interface between the application running on CPU 74 and the NIC 73.
  • Passive PCI I/O back-plane 71 requires simply a PCI bus clock and arbiter i.e., no processor, memory or cache. These functions can be implemented at very low cost.
  • the I/O buses are conformant to PCI Local Bus Specification 2.1. This PCI standard supports the concept of a bridge between two PCI buses. It is possible to program the NIC 73 to present the same hardware interface as a PCI bridge between Computer 72 and passive back-plane 71.
  • Such programming would enable a plurality of hardware devices to be connected to back-plane 71 and controlled by computer 72 without the requirement for additional interfacing software. Again, it should be clear that the invention will support both general networking activity and this remote hardware communication, simultaneously using a single network card.
  • FIG. 10 shows a system comprising two software processes, applications 102 and 103, on different computers 100, 101.
  • Application 102 is producing some data.
  • Application 103 is awaiting the production of data and then consuming it.
  • the circular buffer 107 is composed of a region of memory on Computer 101 which holds the data and two memory locations - RDP 106 and WRP 109.
  • WRP 109 contains the pointer to the next byte of data to be written into the buffer, while RDP 106 contains the pointer to the last byte of data to be read from the buffer.
  • RDP + 1 modulo wrap-around of the buffer When the circular buffer is empty, then WRP is equal to RDP + 1 modulo wrap-around of the buffer. Similarly, the buffer is full when WRP is equal to RDP - 1.
  • WRP 108 and RDP 111 in the caches of computer 100 and computer 101 respectively. Each computer 100,101 may use the value of WRP and RDP held in its own local cache memory to compute how much data can be written to or read from the buffer at any point in time, without the requirement for communication over the network.
  • the producer sets up a Tripwire 110, which will match on a write to the RDP pointer 106, and the consumer sets up a Tripwire 113, which will match on a write to the WRP pointer 109.
  • consumer application 103 attempts to read data from the circular buffer 107, it first checks to see if the circular buffer is empty. If so, application 103 must wait until the buffer is not empty, determined when WRP 109 has been seen to be incremented. During this waiting period, application 103 may either block, requesting an operating system reschedule, or poll the WRP 109 pointer.
  • producer application 102 decides to write to the circular buffer 107, it may do so while the buffer is not full. After writing some data, application 102 updates its local cached value of WRP 108, and writes the updated value to the memory location 109, in computer 101. When the value of WRP 109, is updated, the Tripwire 113, will match as has been previously described.
  • NIC 115 will raise a hardware interrupt 114.
  • This interrupt causes CPU 118 to run device driver software contained within operating system 118.
  • the device driver will service the interrupt by reading the tripwire FIFO 42 on NIC 115 and determine from the value read, the system identifier for application 103.
  • the device driver can then request that operating system 118, reschedule application 103.
  • the device driver would then indicate that the tripwire 113 should not generate a hardware interrupt until application 103 has been next descheduled and subsequently another Tripwire match has occurred.
  • system identifier for each running application is loaded into internal registers 49, each time the operating system reschedules. This enables the NIC to determine the currently running application, and so make the decision whether or not to raise a hardware interrupt for a particular application given a Tripwire match.
  • application 102 may occur without triggering further hardware interrupts.
  • Application 103 now reads data from the circular buffer 107. It can read data until the buffer becomes empty (detected by comparing the values of RDP and WRP 111,109). After reading, application 102 will update its local value of RDP 111 and finally writes the updated value of RDP to memory location 106 over the network.
  • application 102 and application 103 could be operating on different parts of the circular buffer simultaneously without the need for mutual exclusion mechanisms or Tripwire.
  • the most important properties of the data structure are that the producer and the consumer are able to process data without hindrance from each other and that flow control is explicit within the software abstraction. Data is streamed through the system. The consumer can remove data from the buffer at the same time as the producer is adding more data. There is no danger of buffer over-run, since a producer will never transmit more data than can fit in the buffer.
  • the producer only ever increments WRP 108, 109 and reads RDP 106, and the consumer only ever increments RDP 106, 111, and reads WRP 109.
  • Inconsistencies in the values of WRP and RDP seen by either the producer or consumer either cause the consumer to not process some valid data (when RDP 106 is inconsistent with 111), or the producer to not write some more data (when WRP 109 is inconsistent with 108), until the inconsistency has been resolved. Neither of these occurrences cause incorrect operation or performance degradation so long as they are transient.
  • computer 100 can store the value of the RDP 106 pointer in its processor cache, since the producer application 102 only reads the pointer 106. Any remote writes to the memory location of the RDP pointer 106 will automatically invalidate the copy in the cache causing the new value to be fetched from memory. This process is automatically carried out and managed by the system controller 8.
  • computer 101 keeps a private copy of the RDP pointer 111 in its own cache, there is no need for any remote reads of RDP pointer values during operation of the circular buffer. Similar observations can also be made for the WRP pointer 109 in the memory of computer 101 and the WRP pointer 108 in the cache of computer 100. This feature of the buffer abstraction ensures that high performance and low latency are maintained. Responsive application level flow-control is possible because the cached pointer values can be exposed to the user-level applications 102, 103.
  • a further enhancement to the above arrangement can be used to provide support for applications which would like to exchange data in discrete units.
  • the system maintains a second circular buffer 127, of updated WRP 129 values co ⁇ esponding to buffer 125.
  • This second buffer 127 is used to indicate to a consumer how much data to consume in order that data be consumed in the same discrete units as it were produced.
  • circular buffer 125 contains the data to be exchanged between the applications 122 and 123.
  • the producer, application 122 writes data into buffer 125, updating the pointer WRP 129, as previously described. Once data has been placed in buffer 125, application 122 then writes the new value of the WRP 129 pointer into buffer 127. At the same time it also manipulates the pointer WRP 131. If either of these write operations does not complete then the application level write operation is blocked until some data is read by the consumer application 123.
  • the Tripwire mechanism can be used as previously described, for either application to block on either a full or empty buffer pair.
  • the consumer application 123 is able to read from both buffers 125 and 127, in the process updating the RDP pointers 133, 135 in its local cache and RDP pointers 124,
  • buffer 127 indicates an amount of data, which had been written into buffer 125. This value may be used by application level or library software 123, to consume data from buffer 125 in the same order and by the same discrete amounts as it were produced by application 122.
  • the NIC can also be used to directly support a low latency Request/Response style of communication, as seen in client/server environments such as Common Object Request Broker Architecture (CORBA) and Network File System (NFS) as well as transactional systems such as databases.
  • CORBA Common Object Request Broker Architecture
  • NFS Network File System
  • FIG.12 Such an arrangement is shown in Fig.12, where application 142 on computer 140 acts as a client requesting service from application 143 on computer 141, which acts as a server.
  • the applications interact via memory mappings using two circular buffers 144 and 145, one contained in the main memory of each computer.
  • the circular buffers operate as previously described, and also can be configured to transfer data in discrete units as previously described.
  • Application 142 the client, writes a request 147 directly into the circular buffer 145, via the memory mapped connection(s), and waits for a reply by waiting on data to arrive in circular buffer 144.
  • Most Request/Response systems use a process known as marshalling to construct the request and use an intermediate buffer in memory of the client application to do the marshalling.
  • marshalling is used to construct a response, with an intermediate buffer being required in the memory of the server application.
  • marshalling can take place directly into the circular buffer 145 of the server as shown. No intermediate storage of the request is necessary at either the client or server computers 140, 141.
  • the server application 143 notices the request (possibly using the Tripwire mechanism) and is able to begin unmarshalling the request as soon as it starts to arrive in the buffer 145. It is possible that the server may have started to process the request 149 while the client is still marshalling and transmitting, thus reducing latency in the communication.
  • the server After processing the request, the server writes the reply 146 directly into buffer 144, unblocking application 142 (using the Tripwire mechanism), which then unmarshalls and processes the reply 148. Again, there is no need for intermediate storage, and unmarshalling by the client may be overlapped with marshalling and transmission by the server.
  • a further useful and novel property of a Request Response system built using the present invention is that data may be written into the buffer both from software running on a CPU, or any hardware device contained in the computer system.
  • Fig. 15 shows a Request Response system which is a file serving application.
  • the client application 262 writes a request 267 for some data held on disks controlled by 271.
  • the server application 263 reads 269 and decodes the request from its circular buffer 265 in the manner previously described. It then performs authentication and authorisation on the request according to the particular application.
  • the server application 263 uses a two-part approach to send its reply. Firstly, it writes, into the circular buffer 264, the software generated header part of the reply 266. The server application 263 then requests 273 that the disk controller 271 send the required data part of the reply 272 over the network to circular buffer 264. This request to the disk controller takes the form of a DMA request, with the target address being an address on I/O bus 270 which has been mapped onto circular buffer 264. Note that the correct offset is applied to the address such that reply data 272 from the disk is placed immediately following the header data 266.
  • the server application 263 Before initiating the request 273, the server application 263 can ensure that sufficient space is available in the buffer 264 to accept the reply data. Further, it is not necessary for the server application 263 to await the completion request 273. It is possible for the client application 262 to have set a Tripwire 274 to match once the reply data 272 has been received into buffer 264. This match can be programmed to increment the WRP pointer associated with buffer 264, rather than requiring application 263 to increment the pointer as previously described. If a request fails, then the client application 262 level timeout mechanism would detect and retry the operation. It is also possible for the client application 262 to arrange that reply data 272 be placed in some other data structure, (such as a kernel buffer-cache page), through manipulation of 169 and 167 as described later. This is useful when 264 is not the final destination of the rept data, so preventing a final memory copy operation by the client. Server application 263 would be unaware of this client side optimisation.
  • Fig. 13 shows two applications communicating using VIA.
  • Application 152 sends data to application 153, by first writing the data to be sent into a region of its memory, shown as block 154.
  • Application 152 then builds a transmit descriptor 156, which describes the location of block 154 and the action required by the NIC (in this case data transmission). This descriptor is then placed onto the TxQueue 158, which has been mapped into the user-level address-space of application 152.
  • Application 152 then finally writes to the doorbell register 160 in the NIC 162 to notify the NIC that work has been placed on the TxQueue 158.
  • the NIC 162 can determine, from the value written, the address in physical memory of the activated TxQueue 158.
  • the NIC 152 reads and removes the descriptor 156 from the TxQueue 158, determines from the descriptor 156, the address of data block 154 and invokes a DMA 164 engine to transmit the data contained in block 154.
  • the NIC 162 places the descriptor 156 on a completion queue 166, which is also mapped into the address space of application 152, and optionally generates a hardware interrupt.
  • the application 152 can determine when data has been successfully sent by examining queue 166.
  • application 153 When application 153 is to receive data, it builds a receive descriptor 157 describing where the incoming data should be placed, in this case block 155. Application 153 then places descriptor 157 onto RxQueue 159, which is mapped into its user-level address- space. Application 153 then writes to the doorbell register 161 to indicate that its RXQueue 159 has been activated. It may choose to either poll its completion queue 163, waiting for data to arrive, or block until data has arrived and a hardware interrupt generated.
  • the NIC 165 in computer 151 services the doorbell register 161 write by first removing the descriptor 157 from the RxQueue 159.
  • the NIC 165 locates the physical pages of memory corresponding to block 155 and described by the receive descriptor 157.
  • the VIA standard allows these physical pages to have been previously locked by application 153 (preventing the virtual memory system moving or removing the pages from physical memory).
  • the NIC is also capable of traversing the page-table structures held in physical memory and itself locking the pages.
  • the NIC 165 continues to service the doorbell register write and constructs a Translation Look-aside (TLB) entry 167 located in SRAM 23.
  • TLB Translation Look-aside
  • the TLB translation having been previously set up, occurs with little overhead and the data is written 175 to appropriate memory block 155.
  • a Tripwire 171 will have been a ⁇ anged (when the TLB 167 entry was constructed) to match when the address range co ⁇ esponding to block 155 is written to.
  • This Tripwire match causes the firmware 173 (implemented in state machine 51) to place the receive descriptor 157 onto completion queue 163 to invalidate the TLB mapping 167 and optionally generate an interrupt. If the RxQueue 159 has been loaded with other receive descriptors, then the next descriptor is taken and loaded into the TLB as previously described.
  • the NIC could also respond to Tripwire match 171 by placing an index on Tripwire FIFO 42, which could enable the device driver to identify the active VIA endpoint without searching all completion queues in the system.
  • This method can be extended to provide support for 120 and the forthcoming Next Generation I/O (NGIO) standard.
  • NGIO Next Generation I/O
  • the transmit, receive and completion queues are located on the NIC rather than in the physical memory of the computer, as is currently the case for the VIA standard.
  • FIG. 14 shows a Direct Memory Access (DMA) engine 182 on the NIC 183, which has been programmed in the manner previously described by a number of user-level applications 184. These applications have requested that the NIC 183 transfer their respective data blocks 181 through the NIC 183, local bus 189, fibre-optic transceiver 190 and onto network 200. After each application has placed its data transfer request onto the DMA request queue 185, it blocks, awaiting a re-schedule, initiated by device driver 187.
  • DMA Direct Memory Access
  • Data transferred over the network by the DMA engine 182 traverses local bus 189, and is monitored by the Tripwire unit 186. This takes place in the same manner as for received data, (both transmitted and received data pass through the NIC using the same local bus 55).
  • Each application when programming the DMA engine 182 to transmit a data block, also constructs a Tripwire which is set to match on an address in the data block.
  • the address to match could indicate that all or a certain portion of the data has been transmitted.
  • the device driver 187 can quickly determine which application should be made runnable. By causing a system reschedule, the application can be run on the CPU at the appropriate moment to generate more DMA requests. Because the device driver can execute at the same time that the DMA engine is transferring data, this decision can be made in parallel to data transfer operations. Hence, by the time that a particular application's data transfer requests have been satisfied, the system can ensure that the application be running on the CPU and able to generate more requests.
  • Figure 16 illustrates a generalised apparatus or a ⁇ angement for synchronising an end- point application using a tripwire.
  • An end-point is a final destination for an information stream and is the point at which processing of the information takes place.
  • Examples of end-points include a web, a file, a database server and hardware devices such as a disk or graphics controller.
  • An end-point may be running an operating system and a number of data processing applications and these are refe ⁇ ed to as end-point applications.
  • examples of end-point applications include an operating system or a component thereof, a network protocol stack, and any application-level processing. Arrangements such as network switches and routers do not constitute end-points or end- point applications because their purpose is to ensure that the information is delivered elsewhere.
  • the a ⁇ angement comprises a computer 300 which is optionally connected to other computers 301 and 302 via a network 303.
  • the computer 300 comprises a program memory (illustrated by way of example only as a read only memory (ROM) 305) which contains a program for controlling the computer to synchronise the end-point application in accordance with an address-based event in an information stream on an information pathway 307, such as a bus, within the computer.
  • the information stream may be wholly within the computer, for example from another application performed by the computer 300, or may be from a remote source, such as from the network 303.
  • the bus 307 is connected to a memory 308 in the end-point application 306, which also comprises a code generator 309 and an action generator 310.
  • the code generator 309 supplies codes to a comparator which is illustrated as a content addressable memory (CAM) 311.
  • CAM content addressable memory
  • the CAM 311 has another input connected to the bus 307 and is a ⁇ anged to perform a comparison between each entry in the CAM and the information stream on the bus 307. When a match is found, the CAM sends a signal to the action generator
  • the end-point application 306 sets a tripwire, for example to be triggered when data relating to an end-point address or range of end-point addresses in the memory 308 are present on the bus 307.
  • the code generator 309 supplies a code which is written into the CAM 311 and which comprises the destination memory address of the data or possibly part of this address, such as the most significant bits when a range of addresses is to be monitored. It is also possible to enter a code which represents not only the address or range of addresses but also part or all of one or more items of data which are expected in the information stream.
  • the CAM 311 compares the address of each data burst on the bus 307, and possibly also at least some of the data of each burst, with each code stored in the CAM
  • the action generator 310 then causes the appropriate action to be taken within the end-point application 306. This may be a single action, several actions, or one or more specific actions which are determined not only by the triggering of the tripwire but also by the data within the information stream, for example arriving at the appropriate location or locations in the memory 308.
  • the information stream 307 may be wholly internal to the computer 300 and an example of this is an application-to-application stream of information where both applications are running, for example alternately, on the computer 300.
  • the information stream may be partly or wholly from outside the computer 300, as illustrated by the broken line connection from the bus 307 to the network 303.
  • the information stream may be from a switch fabric, a network, or a plurality of sources.
  • a switch fabric is a device which has a plurality of inputs and outputs and which is capable of forwarding data from each input to the appropriate output according to routing information contained within the data.
  • a switch fabric may alternatively be wholly contained within the computer.
  • the information stream preferably has a data burst a ⁇ angement as described hereinafter and, in the case of a plurality of sources, the data bursts may arrive from any of the sources at any time, which amounts to multiplexing.
  • Figure 17 shows an arrangement which illustrates two possible modifications to the a ⁇ angement shown in Figure 16.
  • the bus 307 is connected to an input/output bus 312 of the end-point application 306 within the computer 300.
  • This represents an example of a hardware end-point for the information stream but other types of hardware end-points are possible, such as active controllers, and may be located "outside" the application 306.
  • An example of an active controller is a disk controller.
  • the a ⁇ angement shown in Figure 17 also differs from that shown in Figure 16 in that the tripwire may be triggered by an address-based event in the information stream on the bus 307 which does not exactly match any of the codes stored in the CAM 311. Instead, the information from the information stream on the bus 307 first passes through a process 313 before being supplied to the CAM for comparison with each of the stored codes.
  • the information stream comprises packets or bursts of data starting with an address, for example corresponding to an address in the memory 308 to which the first item of data after the address in the packet or burst is allocated.
  • Subsequent items of data are to be allocated to consecutive addresses, for example such that each item of data in the burst is to be allocated to the next highest address location after the preceding data item.
  • the address at the start of each burst relates to the first data item and the following data item addresses can be inferred by incrementing the address upon the arrival of the second and each subsequent item of data.
  • the application 306 can cause the code generator 309 to store in the CAM 311 a code which co ⁇ esponds to an implied address in the actual information stream appearing on the bus 307.
  • the process 313 detects the address at the start of each data burst and supplies this to the CAM 311 with the arrival of the first data item. As each subsequent data item of the same burst arrives, the process 313 increments the address and supplies this to the CAM 311. This allows a tripwire to be triggered when, for example a data item having an implied address is present on the bus 307 because the CAM can match the co ⁇ esponding stored code with the address supplied by the process 313.
  • the action generator 310 can cause any one or more of various different actions to be triggered by the tripwire.
  • the resulting action may be determined by which tripwire has been triggered i.e. which code stored in the CAM 311 has been matched. It is also possible for the action to be at least partly determined by the data item which effectively triggered the tripwire. Any action may be targetted at the computer containing the tripwire or at a different computer.
  • Various possible actions are described hereinafter as typical examples and may be performed singly or in any appropriate combination for the specific application and may be targetted at the computer containing the tripwire or at a different computer.
  • Figure 18 illustrates the action generator 310 raising an interrupt request IRQ and supplying this to the interrupt line of a central processing unit (CPU) 320 of the computer 300.
  • Figure 19 illustrates the action generator 310 setting a bit in a bitmap 321, for example in the memory 308.
  • the action generator may raise an interrupt request if an application which requires data corresponding to the tripwire is not currently running but is runnable; for example it has not exhausted its time-slice. Otherwise, for example if the application is awaiting rescheduling, the relevant bit in the bitmap 321 may be set.
  • the operating system may periodically check the bitmap 321 for changes and, as a result of the arrival of the relevant data for an application which is presently not running, may decide to reschedule or wakeup the application.
  • Figure 20 illustrates another type of action which may be performed as a result of detection of the address-based event.
  • a counter 322 for example whose count is stored within the memory 308, is incremented in response to triggering of the tripwire. Incrementing may take place as a result of any tripwire being triggered or only by one or more specific tripwires depending on the specific application.
  • Figure 21 illustrates another action which is such that, when the or the appropriate tripwire is triggered, a predetermined value "N" is written to a location "X" shown at 323 as being in the memory 308 (or being mapped thereto).
  • Figure 22 illustrates another combination of actions which may be used to indicate that an application should be awakened or rescheduled.
  • a tripwire When a tripwire is triggered, an interrupt request is supplied to the CPU 320 and a "runnable bit" for a specific application is set at location 324 in the memory 308.
  • the operating system of the computer 300 responds to the interrupt request by waking up or rescheduling the application whose runnable bit has been set.
  • Figure 23 illustrates an action which modifies entries in the CAM 311 in response to triggering of a tripwire.
  • the code which triggers the tripwire may be deleted if no further tripwires are required for the same address-based event.
  • the code may be modified so as effectively to set a different but related tripwire.
  • a further possibility is to generate a completely new code and supply this to the CAM 311 in order to set a new unrelated tripwire.
  • Figure 24 illustrates the format of a data burst, a sequence of which forms the information stream on the bus 307.
  • the data burst comprises a plurality of items which arrive one after the other in sequence on the bus.
  • the first item is an address A(n) which is or corresponds to the end-point address, for example in the memory 308, for receiving the subsequent data items.
  • This address is the actual address n of the first data item Di of the burst, which immediately follows the address A(n).
  • the subsequent data items D 2 , D 3 ..., D p arrive in sequence and their destination addresses are implied by their position within the burst relative to the first data item DI and its address n.
  • the second data item D has an implied address n + 1
  • the third data item D 3 has an implied address n + 2 and so on.
  • Each data item is written or supplied to the implied address as its destination address.
  • This data burst format may be used to fragment and coalesce bursts as the data stream passes through a forwarding unit 330, such as a network interface card or a switch, of an information pathway.
  • a forwarding unit 330 such as a network interface card or a switch, of an information pathway.
  • the forwarding unit can start to transmit a burst as soon as the first data item has arrived and does not have to wait until the whole data burst has arrived.
  • Figure 25 illustrates an example of this in which an interruption in the data burst occurs.
  • the forwarding unit 330 has already started transmission of the burst and the first r data items 331 together with the burst address have already been forwarded.
  • the remainder 332 of the burst has not yet arrived and the forwarding unit 330 terminates forwarding or transmission of that burst.
  • the forwarding unit 330 When the remainder 332 of the burst starts to arrive, the forwarding unit 330 recalculates the destination address A(r +1) for the remainder of the burst and inserts this in front of the data item D r +i. This is transmitted as a further burst 333 as illustrated in Figure 26.
  • This technique may be used even when the whole burst is available for forwarding by the forwarding unit 330.
  • the forwarding unit 330 may terminate transmission of a particular burst before completion of transmission for reasons of arbitration between a number of competing bursts or for flow control reasons.
  • individual data bursts can be forwarded in tact or can be sent in two or more fragments as necessary or convenient and all such bursts are treated as valid bursts by any subsequent forwarding units.
  • Figure 27 illustrates an alternative situation in which the forwarding unit has an internal buffer 335 which contains first and second bursts 336 and 337.
  • the implied address of the first data item D n + 1 of the second burst 337 immediately follows the implied address of the last data item D n of the first burst 336.
  • the forwarding unit checks for such situations and, when they are found, coalesces the first and second bursts into a coalesced burst 338 as shown in the lower part of Figure 27.
  • the forwarding unit then transmits a single contiguous burst, which saves the overhead of the excess address information (which is deleted from the second burst).
  • Any subsequent forwarding units then treat the coalesced burst 338 as a single burst.
  • the format of the data burst allows such fragmentation or merging of bursts to take place. This in turn allows forwarding units to transmit data as soon as it arrives so as to reduce or minimise latency. Also, bursts of any length or number of data items can be handled which improves the flexibility of transmission of data.
  • Figure 28 illustrates an example of communication between an application, whose address space is shown at 340, and remote hardware 341 via a network 303 such that the network 303 is "transparent" or “invisible” to each of the application and the remote hardware 341.
  • the address space 340 contains mapped configuration data and registers of the remote hardware as indicated at 342. This is mapped onto the system input/output bus 343 to which a network interface card 344 is connected.
  • the network interface card 344 is loaded with configuration and register data co ⁇ esponding to the remote hardware 341. All application requests are forwarded over the network 303 transparently to the remote hardware 341 so that the remote hardware appears as though it is local to the application and the network 303 is invisible.
  • the remote hardware 341 is connected to a passive input/output bus 345 which is provided with a network interface card 346 for interfacing to the network 303.
  • the configuration and registers of the remote hardware are illustrated at 347 and are mapped ultimately to the region 342 of the address space 340 of the application. Again, the network is invisible to the remote hardware 341 and the remote application appears to be local to it.
  • the application sends a request to the remote hardware 341, for example requesting that the remote hardware supply data to be used in or processed by the application, this is written in the space 342 which is mapped to the system input/output bus 343.
  • the network interface card 344 sends read/write requests over the network 303 to the card 346, which supplies these via the passive input/output bus 345 to the remote hardware 341. Viewed from the remote hardware 341, the bus 345 appears equivalent to the bus 343.
  • the remote hardware 341 may supply an interrupt and/or data for the application to the bus 345. Again, the network interface card 346 sends this via the network 303 to the card 344. The network interface card 344 supplies an interrupt request to the computer running the application and writes the data on behalf of the remote hardware to the space 342 in the address space 340 of the application. Thus, to the application, the remote hardware 341 appears to be connected directly to the bus 343.
  • tripwires may be implemented at other points in a system as illustrated by tripwire units 2 to 5 in Figure 29.
  • the system comprises a disk controller 351 connected to an input/output bus 307b and the tripwire unit 2 is implemented as part of the disk controller 351.
  • Such an a ⁇ angement allows tripwire operations to inform applications of any characteristic data transfer to or from the disk controller 351.
  • Such an arrangement is particularly useful where the controller 351 is able to transfer data to and from a non-contiguous memory region corresponding to user-level buffers of an application. This allows data transfer and application level notification to be achieved without requiring hardware interrupts or kernel intervention.
  • the tripwire unit 3 is associated with a system controller 352 connected to a host bus 307a and the input/output bus 307b.
  • a system controller 352 connected to a host bus 307a and the input/output bus 307b.
  • Such an a ⁇ angement allows tripwire operations to inform applications of any characteristic data transfer to or from any device in the computer system.
  • This includes hardware devices, such as the disk controller 351 and the network interface card 350, and, in the case of a system employing several CPUs, enables an application running on one of the CPUs to synchronise on a data transfer to or from an application running on another of the CPUs.
  • a tripwire may be used for synchronisation between applications running on the same CPU. This reduces the need for other mechanisms such as spin locks where both applications are required to operate in lock-step with the data transfer.
  • Tripwire units 4 and 5 are implemented in the CPU 320 or the memory 308. This is generally equivalent to the tripwire unit 3, where all data transfers in the system can be monitored. However, the tripwire unit 4 may monitor data written by an application to cache, which may not appear on the host bus 307a.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Multi Processors (AREA)
  • Communication Control (AREA)
  • Information Transfer Systems (AREA)

Abstract

Cette invention concerne une interface de réseau asynchrone ainsi qu'un procédé de synchronisation entre deux applications tournant sur des ordinateurs distincts. Cette interface de réseau comprend un matériel de surveillance qui peut être programmé de manière à contenir des valeurs de déclenchement comprenant soit des adresses, des éventails d'adresses ou d'autres données devant être mises en correspondance. Ces données sont appelées fils-pièges (trip wires). Une fois programmée, l'interface contrôle le flux de données, y compris les données d'adresse, qui passent par elle afin de déceler des adresses et des données qui correspondent aux fils-pièges établis. En cas de correspondance, le matériel de surveillance peut lancer des interruptions, incrémenter des compteurs d'événements ou effectuer une autre action spécifiée par l'application. Ce matériel de surveillance est de préférence du type mémoire à contenu adressable. Cette invention permet ainsi d'obtenir une synchronisation intrabande en utilisant des primitives de synchronisation qui sont programmables par des applications de niveau utilisateur, ceci tout en offrant une largeur de bande élevée et un faible temps d'attente. La programmation des primitives de synchronisation peut se faire en envoyant et en recevant des applications indépendamment les unes des autres, aucune information de synchronisation ne devant traverser le réseau.
EP00925509A 1999-05-04 2000-05-03 Transfert de donnees, synchronisation d'applications et reseau a faible temps d'attente Withdrawn EP1190317A2 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP02102568A EP1338965A3 (fr) 1999-05-04 2000-05-03 Transfert de données
EP02102565A EP1302854B1 (fr) 1999-05-04 2000-05-03 Transfert de données asynchrone
EP02102564A EP1302853A3 (fr) 1999-05-04 2000-05-03 Transfert de données, synchronisation d'applications et réseau à faible temps d'attente
EP02102567A EP1302855A3 (fr) 1999-05-04 2000-05-03 Méthode pour envoyer une demande de données

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB9910280A GB2349717A (en) 1999-05-04 1999-05-04 Low latency network
GB9910280 1999-05-04
PCT/GB2000/001691 WO2000067131A2 (fr) 1999-05-04 2000-05-03 Transfert de donnees, synchronisation d'applications et reseau a faible temps d'attente

Related Child Applications (4)

Application Number Title Priority Date Filing Date
EP02102568A Division EP1338965A3 (fr) 1999-05-04 2000-05-03 Transfert de données
EP02102567A Division EP1302855A3 (fr) 1999-05-04 2000-05-03 Méthode pour envoyer une demande de données
EP02102564A Division EP1302853A3 (fr) 1999-05-04 2000-05-03 Transfert de données, synchronisation d'applications et réseau à faible temps d'attente
EP02102565A Division EP1302854B1 (fr) 1999-05-04 2000-05-03 Transfert de données asynchrone

Publications (1)

Publication Number Publication Date
EP1190317A2 true EP1190317A2 (fr) 2002-03-27

Family

ID=10852767

Family Applications (5)

Application Number Title Priority Date Filing Date
EP02102567A Withdrawn EP1302855A3 (fr) 1999-05-04 2000-05-03 Méthode pour envoyer une demande de données
EP02102564A Withdrawn EP1302853A3 (fr) 1999-05-04 2000-05-03 Transfert de données, synchronisation d'applications et réseau à faible temps d'attente
EP02102568A Withdrawn EP1338965A3 (fr) 1999-05-04 2000-05-03 Transfert de données
EP02102565A Expired - Lifetime EP1302854B1 (fr) 1999-05-04 2000-05-03 Transfert de données asynchrone
EP00925509A Withdrawn EP1190317A2 (fr) 1999-05-04 2000-05-03 Transfert de donnees, synchronisation d'applications et reseau a faible temps d'attente

Family Applications Before (4)

Application Number Title Priority Date Filing Date
EP02102567A Withdrawn EP1302855A3 (fr) 1999-05-04 2000-05-03 Méthode pour envoyer une demande de données
EP02102564A Withdrawn EP1302853A3 (fr) 1999-05-04 2000-05-03 Transfert de données, synchronisation d'applications et réseau à faible temps d'attente
EP02102568A Withdrawn EP1338965A3 (fr) 1999-05-04 2000-05-03 Transfert de données
EP02102565A Expired - Lifetime EP1302854B1 (fr) 1999-05-04 2000-05-03 Transfert de données asynchrone

Country Status (4)

Country Link
EP (5) EP1302855A3 (fr)
DE (1) DE60038703T2 (fr)
GB (1) GB2349717A (fr)
WO (1) WO2000067131A2 (fr)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8346971B2 (en) 1999-05-04 2013-01-01 At&T Intellectual Property I, Lp Data transfer, synchronising applications, and low latency networks
US7035790B2 (en) 2000-06-02 2006-04-25 Canon Kabushiki Kaisha Speech processing system
US7010483B2 (en) 2000-06-02 2006-03-07 Canon Kabushiki Kaisha Speech processing system
US6954745B2 (en) 2000-06-02 2005-10-11 Canon Kabushiki Kaisha Signal processing system
US7072833B2 (en) 2000-06-02 2006-07-04 Canon Kabushiki Kaisha Speech processing system
US6950845B2 (en) 2000-10-23 2005-09-27 Amdocs (Israel) Ltd. Data collection system and method for reducing latency
GB2372679A (en) * 2001-02-27 2002-08-28 At & T Lab Cambridge Ltd Network Bridge and Network
GB0221464D0 (en) 2002-09-16 2002-10-23 Cambridge Internetworking Ltd Network interface and protocol
ATE385368T1 (de) * 2003-08-29 2008-02-15 Koninkl Philips Electronics Nv Elektronische schaltung mit über ein kommunikationsnetz gekoppelten verarbeitungseinheiten
US6993598B2 (en) 2003-10-09 2006-01-31 International Business Machines Corporation Method and apparatus for efficient sharing of DMA resource
US7136943B2 (en) 2004-03-18 2006-11-14 International Business Machines Corporation Method and apparatus for managing context switches using a context switch history table
GB0421229D0 (en) * 2004-09-23 2004-10-27 Level 5 Networks Ltd Packet formation
JP4451837B2 (ja) 2004-12-10 2010-04-14 富士通株式会社 データ転送装置およびデータ転送方法
US10649775B2 (en) * 2013-07-15 2020-05-12 Texas Instrum Ents Incorporated Converting a stream of data using a lookaside buffer
AU2013245529A1 (en) 2013-10-18 2015-05-07 Cisco Technology, Inc. Network Interface
CN111615673B (zh) * 2018-01-22 2023-09-29 西门子股份公司 一种用于工业控制中的技能匹配的系统
CN111104577B (zh) * 2019-10-31 2023-11-14 北京金堤科技有限公司 数据处理方法、装置、计算机可读存储介质及电子设备
CN113110916B (zh) * 2021-04-22 2023-11-07 深信服科技股份有限公司 一种虚拟机数据读写方法、装置、设备及介质

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5764895A (en) * 1995-01-11 1998-06-09 Sony Corporation Method and apparatus for directing data packets in a local area network device having a plurality of ports interconnected by a high-speed communication bus

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4298959A (en) * 1979-11-23 1981-11-03 United Technologies Corporation Digital information transfer system (DITS) receiver
US4429387A (en) * 1982-02-05 1984-01-31 Siemens Corporation Special character sequence detection circuit arrangement
JPS60211559A (ja) * 1984-04-06 1985-10-23 Nec Corp 共通メモリ制御方式
CA1253971A (fr) * 1986-06-26 1989-05-09 Pierre Goyer Service de synchronisation pour systeme d'exploitation reparti ou systeme similaire
EP0276349B1 (fr) * 1987-01-28 1992-03-25 International Business Machines Corporation Dispositif pour commuter des informations entre des canaux de trafic synchrone et pour commuter des paquets de données asynchrones
US5140679A (en) * 1988-09-14 1992-08-18 National Semiconductor Corporation Universal asynchronous receiver/transmitter
US5179556A (en) * 1991-08-02 1993-01-12 Washington University Bandwidth management and congestion control scheme for multicast ATM networks
EP0600683B1 (fr) * 1992-12-04 2001-10-10 AT&T Corp. Interface pour un réseau de paguets
DE69327448T2 (de) * 1992-12-21 2004-03-04 Sun Microsystems, Inc., Mountain View Verfahren und Vorrichtung für Teilaufgaben in verteiltem Verarbeitungssystem
CA2120792C (fr) * 1993-07-16 2006-05-09 Eisuke Sasaoka Guide de lumiere
JP2793769B2 (ja) * 1994-04-01 1998-09-03 沖電気工業株式会社 ウィンドウ型セル流量監視装置
US5586273A (en) * 1994-08-18 1996-12-17 International Business Machines Corporation HDLC asynchronous to synchronous converter
DE59500154D1 (de) * 1994-11-03 1997-04-30 Alsthom Cge Alcatel Verfahren und Vorrichtung zur Messung charakteristischer Grössen eines Stroms von Datenpaketen fester Länge in einem digitalen Übertragungssystem
US5727154A (en) * 1995-04-28 1998-03-10 Fry; Shawn C. Program synchronization on first and second computers by determining whether information transmitted by first computer is an acceptable or unacceptable input to second computer program
US5758089A (en) * 1995-11-02 1998-05-26 Sun Microsystems, Inc. Method and apparatus for burst transferring ATM packet header and data to a host computer system
US5778175A (en) * 1995-12-22 1998-07-07 Digital Equipment Corporation Method implemented by a computer network adapter for autonomously adjusting a transmit commencement threshold valve upon concurrence of an underflow condition
US5887172A (en) * 1996-01-10 1999-03-23 Sun Microsystems, Inc. Remote procedure call system and method for RPC mechanism independent client and server interfaces interoperable with any of a plurality of remote procedure call backends
DE69712481T2 (de) * 1996-06-28 2002-12-19 T. Eric Hopkins Bilderfassungssystem und verfahren
GB2315638B (en) * 1996-07-19 2000-09-13 Ericsson Telefon Ab L M Synchronisation checking
US5956721A (en) * 1997-09-19 1999-09-21 Microsoft Corporation Method and computer program product for classifying network communication packets processed in a network stack

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5764895A (en) * 1995-01-11 1998-06-09 Sony Corporation Method and apparatus for directing data packets in a local area network device having a plurality of ports interconnected by a high-speed communication bus

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HESS J.R. ET AL: "Implementation and Evaluation of a Prototype Reconfigurable Router", FIELD PROGRAMMABLE CUSTOM COMPUTING MACHINES, 21 April 1999 (1999-04-21), Los Alamitos, pages 44 - 50, XP010359162 *

Also Published As

Publication number Publication date
EP1338965A3 (fr) 2010-01-20
DE60038703D1 (de) 2008-06-05
EP1302854A3 (fr) 2005-12-07
EP1338965A2 (fr) 2003-08-27
EP1302854A2 (fr) 2003-04-16
WO2000067131A3 (fr) 2001-09-13
GB2349717A (en) 2000-11-08
EP1302854B1 (fr) 2008-04-23
WO2000067131A2 (fr) 2000-11-09
GB9910280D0 (en) 1999-06-30
EP1302855A3 (fr) 2007-03-07
EP1302853A2 (fr) 2003-04-16
DE60038703T2 (de) 2009-07-02
EP1302855A2 (fr) 2003-04-16
EP1302853A3 (fr) 2006-08-09

Similar Documents

Publication Publication Date Title
US9769274B2 (en) Data transfer, synchronising applications, and low latency networks
EP1302854B1 (fr) Transfert de données asynchrone
EP1358562B1 (fr) Procede et appareil permettant de commander les flux de donnees entre des systemes informatiques via une memoire
KR100555394B1 (ko) Ｎｇｉｏ/ｉｎｆｉｎｉｂａｎｄ 어플리케이션용 리모트 키검증을 위한 방법 및 메커니즘
US7281030B1 (en) Method of reading a remote memory
US7409468B2 (en) Controlling flow of data between data processing systems via a memory
JP4317365B2 (ja) 周辺デバイスからホスト・コンピュータ・システムに割込みを転送する方法および装置
JPH10505977A (ja) デスクトップ用非同期転送モードアダプター
JPH09325947A (ja) コマンドおよびデータ情報を装置に原子的に転送する方法及び装置
EP2383658B1 (fr) Gestion de profondeur de file d'attente en vue d'une communication entre un hôte et un dispositif peripherique
US6880047B2 (en) Local emulation of data RAM utilizing write-through cache hardware within a CPU module

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20011002

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

17Q First examination report despatched

Effective date: 20020419

RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: AT&T INVESTMENTS UK INC.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20100522