The present disclosure relates generally to data communications, and more specifically, to accessing registers in a highly integrated computer network.

BACKGROUND

Server computers are continuously managed to enable access to shared switches and other traffic routing resources. For example, contention for routing resources may exist when server computers are housed within racks for space and connectivity considerations, such as in a blade server computer arrangement. The server computers may experience transmission bottlenecks and delays when forwarding data frames through centralized switches, such as shared top of rack switches.

To illustrate, FIG. 1 shows a conventional blade server computer system 100. The system 100 includes a plurality of server computers 106-125 housed within racks 102, 104 and arranged into chassis 138, 140, 142, and 144. An illustrative server computer 106 may include a half-width information technology element (ITE) blade server computer.

Data frame communications between the server computers 106-125 housed within different chassis 138, 140, 142, 144 or racks 102, 104 may be referred to as east- west connectivity. For example, the server computer 1 1 1 of a first chassis 140 may forward a data frame to the server computer 106 of another chassis 138 via a path 164. The path 164 includes a chassis switch 154 and a top of rack switch (TOR) 158. The chassis switch 154 and the top of rack switch 158 route the data frame based upon a media access control (MAC) address.

When the server computer 1 1 1 of the rack 102 forwards a data frame to the server computer 123 of the rack 104, the data frame travels through paths 166 and 168. The paths 166 and 168 include the top of rack switch 158, an end of rack switch (EOR) 162, and a top of rack switch 160. The top of rack switch 158 is again used when the server computer 111 attempts north-south connectivity (i.e., internal to external data frame communication) through paths 166 and 170. Because the data frames in the above examples are all routed through the top of rack switches 158, 160, a potential bottleneck scenario can result. Increasing the number of switches and associated connections to accommodate additional traffic may present configuration and management challenges, as well as increase hardware costs and latency. It is therefore desirable to increase the efficiency with which switches may forward data frames between server computers. BRIEF SUMMARY

In a particular embodiment, an apparatus is disclosed that includes a plurality of distributed bridge elements in communication with a plurality of server computers. Each distributed bridge element may be configured to access a register in response to receiving a data frame that includes a register access request. A controlling bridge may be configured to control the plurality of distributed bridge elements and to generate and communicate the data frame to at least one of the plurality of bridge elements.

In another embodiment, a method of performing a register access includes receiving a data frame at a bridge element of a plurality of bridge elements in communication with a plurality of server computers. The data frame may include a register access request and may be forwarded from a controlling bridge in communication with the plurality of bridge elements. A register may be accessed and execution of the register access request may be initiated in response to receiving the data frame.

In another embodiment, a program product for accessing a register may include a computer readable storage medium having computer readable program code embodied therewith. The computer readable program code may include program instructions resident at a bridge element of a plurality of bridge elements in communication with a plurality of server computers. The program instructions may be configured to receive from a controlling bridge a data frame that includes a register access request, to access a register, and to initiate execution of the register access request in response to receiving the data frame. At least one of the embodiments may facilitate efficient programming of registers in a highly integrated environment. The controlling bridge may provide trusted (e.g., known and secure) firmware used to control access considerations, such as security, routing, and availability in a consistent manner. The controlling bridge may be configured to access registers of local and remote bridge elements, as well as other hardware nodes, such as adapters and partitions. The automated register accesses may reduce potential bottlenecks and facilitate efficient processing. Fiber Channel over Ethernet may be supported, and an embodiment of a system may be scalable to include hundreds or more server computers with direct connectivity.

Features that characterize embodiments are set forth in the claims annexed hereto and forming a further part hereof. However, for a better understanding of the embodiments, and of the advantages and objectives attained through its use, reference should be made to the Drawings and to the accompanying descriptive matter in which there are described exemplary embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a prior art computing system that includes racks of blade server computers;

FIG. 2 is a block diagram of an embodiment of a networked computing system configured to allow direct communication between server computers housed within different racks and chassis of blade server computers;

FIG. 3 is a diagram of a particular embodiment of a system configured to remotely access registers using distributed bridge elements and one or more controlling bridges;

FIG. 4 is a diagram of another particular embodiment of a system configured to conduct register access operations using a plurality of distributed bridge elements and one or more controlling bridges; FIG. 5 is a flow diagram of a particular embodiment of a method of using a controlling bridge to program registers of distributed bridge elements and other target nodes; and

FIG. 6 is a flow diagram of a particular embodiment of a method to detect and respond to register access errors.

DETAILED DESCRIPTION

Firmware of a controlling bridge may control register load and store operations involving multiple, interconnected bridge elements. The controlling bridge may be directly coupled to a local bridge element via a Peripheral Component Interconnect Express (PCIe) and may communicate with the bridge elements using data frames that include register access requests. In a particular embodiment, the system may include a main register ring that uses a token protocol to access registers. An initiating bridge element making a register access request may wait for a token on the main register ring. The token may be used so that only the one bridge element having control of the token may access a target node at a time. When the token becomes available, the register access request may be placed on the main register ring for delivery to the target node. The register access address may be addressed to the bridge element or other target node. The target node may execute the register access request and communicate a response to the initiating bridge element. The initiating bridge element may then return the token to the main register ring.

To prevent conflicting register access operations from multiple controlling bridges, the controlling bridges may select a bridge element to be a bridge element control port. The bridge element control port may be used when accessing registers other than bridge element registers. Bridge element registers may be accessed directly via their respective bridge element to allow parallel access to separate sets of bridge element registers. A bridge element may access its register without a token received from the main register ring. The bridge element may hold off external accesses from the main register ring until all register access requests of the data frame have been completed. When accessing a register, the controlling bridge may use a firmware based semaphore mechanism. The semaphore mechanism may prevent other controlling bridges from accessing the register at the same time. Each bridge element may include multiple registers for controlling bridges to use as semaphore registers.

Multiple register access requests, or operations, may be included within a single data frame. Illustrative register access operations may include a register load and a register store, as well as a sequential register load and a sequential register store. Other register access operations may include get, check and release functions of a semaphore control operation. Additional examples of register access operations may include AND/OR operations, as well as a compare and swap operation.

A data frame conveying a register access request may additionally include a sequence number field. According to a particular embodiment, a controlling bridge may insert a four byte sequence number in the sequence number field when sending a data frame and associated register access request. The sequence number field may be unchanged by a receiving bridge element that uses the sequence number to update a history queue. The bridge element may return the data frame and sequence number to the controlling bridge. The controlling bridge may use the sequence number of the returned frame to confirm the delivery or to detect a loss of a data frame.

The bridge element that executes the register access request may maintain one or more history queues. An illustrative history queue may include a first-in, first-out (FIFO) memory. The history queue may include entries storing sequence numbers and counts of successfully completed operations (e.g., load and store operations) associated with given data frames. The controlling bridge may read the entries of the history queue to determine if a data frame has been lost. For example, a controlling bridge may access a history queue of a bridge element when a data frame having an expected sequence number is not received at the controlling bridge. The controlling bridge may determine by reading the history queue if the data frame having the sequence number was received by the bridge element. If the data frame was never received, the controlling bridge may resend the data frame. If an entry in the history queue indicates that the data frame was received at the bridge element, then the controlling bridge may read the count of successfully completed operations. The count of successfully completed operations may be used to determine whether an error was encountered while processing a register access request. According to a particular embodiment, the bridge element may maintain multiple history queues (e.g., one history queue for each controlling bridge that may control the bridge element).

The controlling bridge may also maintain a history queue, which may also be a FIFO. The entries of the history queue may include status information. For example, the controlling bridge may set status information of an entry associated with a first register access request to "pending" prior to sending a data frame with the register access request. The status information may be updated to reflect details regarding an error. Entries associated with other register access requests may read "pending" until the first register access is successful. Illustrative status information may include: pending, completed, not completed with a lock conflict, and error (e.g., access timeout, frame too short or too long).

Turning particularly to the drawings, FIG. 2 shows an illustrative embodiment of a highly integrated system 200 configured to forward data frames that include register accesses using a distributed virtual bridge 260. The distributed virtual bridge 260 may extend across server computers 206-225, chassis 246, 248, 250, 252, and racks 202, 204 to provide data link layer (i.e., Layer 3) switching between bridge elements. The bridge elements may provide a frame-based, Ethernet-like interface. The interface may facilitate lossless, point-to-point, in- order frame delivery between server computers 206-225 of different racks 202, 204 or chassis 246, 248, 250, 252 (i.e., east-west connectivity) with reduced redundancy and latency.

The system 200 further includes an end-of-rack switch 262 and input/output (I/O) server ITEs 259, 261 that enable north-south connectivity. The I/O server ITEs 259, 261 may enable uplink connectivity to the external Ethernet network (or other network) for the server computers 206-225 housed within the racks 202, 204.

An arrow 264 of FIG. 2 represents direct east-west connectivity and the flow of data frames between server computers located in different racks 202, 204 of the system 200 (e.g., without using a top of rack or chassis switch). An arrow 262 represents direct east-west connectivity across different chassis 246, 248 of the rack 202.

The system 200 of FIG. 2 may enable direct connectivity between server computers of different racks or chassis. To accommodate the relatively high level of system integration, data frames generated by firmware in communication with server computers may include register access request. The uniform, automated register access processes may streamline register operations and associated processing time.

FIG. 3 illustrates a particular embodiment of a highly integrated system 300 configured to conduct register access operations using a plurality of distributed bridge elements and one or more controlling bridges. FIG. 3 generally shows a computer system 300 configured to forward data frames using a distributed virtual bridge 308. The distributed virtual bridge 308 may selectively forward data frames having access register requests to distributed bridge elements and other target nodes.

The distributed virtual bridge 308 may be similar to the distributed virtual bridge 260 of FIG. 2. The system 300 includes a first server computer 302 and a second server computer 304 that are both coupled to an I/O blade device 306 via the distributed virtual bridge 308. The server computers 302, 304 and the I/O blade device 306 may be housed within separate chassis and racks.

The distributed virtual bridge 308 may be coupled to multiple adapters 310, 312, 314, 316, 318, 320, 322, and 324. The adapters 310, 312, 314, 316, 318, 320, 322, and 324 may be located within or may be coupled to the server computers 302, 304. The distributed virtual bridge 308 may use multiple access points, or bridge elements 326, 328, 330, and 332-340 to couple to the server computers 302, 304. For example, a microchip that includes the bridge elements 326, 328, 330, and 332 may be cabled or otherwise coupled to a port of the server computer 302 that includes the adapter 310. As explained herein, the distributed virtual bridge 308 may functionally supplant chassis switches and top of rack switches with a frame-based network fabric that functions in a similar fashion to an Ethernet network. One or more transport layer modules 382, 384, 386, and 388 coupled to the bridge elements 326, 328, 330, and 332 may provide a frame-based, Ethernet-like interface to one or more integrated switch routers 342. The transport layer module 382 may be configured to deconstruct a transmission of data frames so that packet information may be evenly distributed across links to a local rack interconnect 390. The data frames may not be serialized upon leaving the transport layer module 382. A receiving transport layer module 323 may serialize the data frames to achieve reliable, in-order delivery. If the receiving transport layer module 323 determines that data frame information is missing, the transport layer module 323 may initiate a process to recover the missing data. The translation process may be accomplished in hardware, which may provide a larger bandwidth and faster processing than software applications. The transport layer modules 382, 384, 386, and 388, the integrated switch router 342, and the local rack interconnect network 390 may combine to include an underlying lossless, point-to-point communication network (i.e., an integrated switch router network) between the server computers 302, 304 and the I/O blade device 306.

The bridge elements 326, 328, 330, and 332 may function as data link layer (i.e., Layer 2) bridge forwarders within the distributed virtual bridge 308. In particular embodiments, the bridge elements 326, 328, 330, and 332 may comprise a switch, or router device. The bridge elements 326, 328, 330, and 332 may include learned (e.g., received and stored) cached address data used to forward data frames throughout the distributed virtual bridge 308. The learned address data may correspond to one or both of a destination address and a source address associated with a data frame.

When the bridge element 326 does not include address data pertinent to a source or destination address of a received data frame, the bridge element 326 may query a controlling bridge 348 for the address data. The controlling bridge 348 may include a global forwarding table 311 that includes stored address data. The stored address data may be continuously updated by the bridge elements 326, 328, 330, and 332. For example, a bridge element 326 may send an update message to the controlling bridge 348 in response to learning an updated or new MAC address. A corresponding MAC address in the global forwarding table 311 may be subsequently updated. Conversely, the address data of the global forwarding table 31 1 may be used to update the bridge elements 326, 328, 330, and 332. For example, the controlling bridge 348 may respond to a query from the bridge element 326 with requested address data. The bridge element 326 may cache the received address data for future use.

The first server computer 302 may comprise a blade server computer, such as the server computer 202 shown in FIG. 2. The first server computer 302 may include one or more virtual machines (VMs) 350, 352, 354, 356, 358, and 360. A virtual machine may include a software implementation of a computer and may execute programs in a manner similar to a physical machine.

FIG. 3 shows an illustrative hypervisor 362 that is coupled to both the virtual machine 350 and the virtual machine 352. The hypervisor 362 may include platform virtualization software that allows multiple operating systems to run concurrently on the first server computer 302. The hypervisor 362 may include a hypervisor virtual bridge 364 that allows direct communication between the virtual machines 350, 352 without traversal of an external network. In one embodiment, the hypervisor virtual bridge 364 may register address information with the controlling bridge 348.

The server computer 302 may include at least one processor 303 coupled to a memory 305. The processor 303 may represent one or more processors (e.g., microprocessors), and the memory 305 may represent random access memory (RAM) devices comprising the main storage of the server computer 302, as well as supplemental levels of memory, e.g., cache memories, non-volatile or backup memories (e.g., programmable or flash memories), readonly memories, etc. In addition, the memory 305 may be considered to include memory storage physically located in the server computer 302 or on another server computer 304 coupled to the server computer 302 via the distributed virtual bridge 308.

The first server computer 302 may operate under the control of an operating system (OS) 307 and may execute or otherwise rely upon various computer software applications, components, programs, objects, modules, and data structures, such as the virtual machines 350, 352, 354, 356, 358, and 360. Moreover, various applications, components, programs, objects, modules, etc. may also execute on one or more processors in another device coupled to the server computer 302 (e.g., in a distributed computing environment, where computing processes may be allocated to multiple server computers).

The first server computer 302 may include the adapters 310, 312, 314, and 316, such as converged network adapters. A converged network adapter may include a single root I/O virtualization (SR-IOV) adapter, such as a Peripheral Component Interconnect Express (PCIe) adapter that supports Converged Enhanced Ethernet (CEE). The adapters 310, 312, 314, and 316 may be used to implement a Fiber Channel over Ethernet (FCoE) protocol. Each adapter 310, 312, 314, and 316 may be coupled to one or more of the virtual machines 350, 352, 354, 356, 358, and 360. The adapters 310, 312, 314, and 316 may facilitate shared access of the virtual machines 350, 352, 354, 356, 358, and 360. While the adapters 310, 312, 314, and 316 are shown in FIG. 3 as being included within the server computer 302, adapters of another embodiment may include physically distinct devices that are separate from the server computers 302, 304.

Each adapter 310, 312, 314, and 316 may include a converged adapter virtual bridge 366, 368, 370, and 372. The converged adapter virtual bridges 366, 368, 370, and 372 may facilitate sharing of the adapters 310, 312, 314, and 316 by coordinating access by the virtual machines 350, 352, 354, 356, 358, and 360. Each converged adapter virtual bridge 366, 368, 370, and 372 may recognize data flows included within its domain. A recognized domain address may be routed directly, without processing or storage outside of the domain of the particular converged adapter virtual bridge 366, 368, 370, and 372. Each adapter 310, 312, 314, and 316 may include one or more CEE transmit ports that couple to one of the bridge elements 326, 328, 330, and 332. In another embodiment, bridge elements may be co- located with the adapters, and coupling between adapters and the bridge elements may not be Ethernet connections.

The bridge elements 326, 328, 330, and 332 may be configured to forward data frames throughout the distributed virtual bridge 308. The bridge elements 326, 328, 330, and 332 may thus function as access points for the distributed virtual bridge 308 by translating between Ethernet and the integrated switch router 342. The bridge elements 326, 328, 330, and 332 may not include buffers and may support CEE at boundaries of the distributed virtual bridge 308. In another embodiment, the bridge elements 326, 328, 330, and 332 may include buffers. Each bridge element 326, 328, 330, and 332 of the distributed virtual bridge 308 may include a forwarding cache 374, 376, 378, and 380. A forwarding cache 374, 376, 378, and 380 may include a lookup table that stores address data used to forward data frames that are received by the bridge elements 326, 328, 330, and 332. For example, the bridge element 326 may compare address data associated with a received data frame to the address data stored within the forwarding cache 374.

Illustrative address data may include routing information, such as a routing key included within header data of the data frame. The routing key may include at least one of a virtual local area network (VLAN) tag and a logical network identifier, as well as a MAC address. The MAC address may be generated and assigned by a Fiber Channel Forwarder (FCF) 313, as set by an administrator or computing system. The Fiber Channel Forwarder 313, or FCoE switch, may facilitate connectivity between FCoE initiators and Fiber Channel fabrics. To illustrate, an FCoE data frame sent from the first virtual machine 358 and intended for a second virtual machine 363 may be addressed to the Fiber Channel Forwarder 313 in accordance with the FCoE standard. According to standard routing procedures, the Fiber

Channel Forwarder 313 may receive and readdress the FCoE data frame for forwarding to the virtual machine 363.

The Media Access Control (MAC) address of the Fiber Channel Forwarder 313 may have been learned by the first server computer 302 during a discovery phase, when the Fiber

Channel Forwarder 313 establishes communications with networked devices. During the discovery phase, the second server computer 304 may respond to broadcast queries from the first server computer 302. The Fiber Channel Forwarder 313 may discover the second server computer 304 from the query responses. After the discovery phase, a login phase may be initiated. A MAC address of the server computer 304 may be reassigned by the Fiber

Channel Forwarder 313. The reassigned MAC address may be used for subsequent routing and communications between the server computers 302, 304. The Fiber Channel Forwarder 313 may facilitate storage of MAC addresses assigned to the server computers 302, 304.

A VLAN tag may indicate an assigned VLAN, which may be used to segregate traffic and to allow more than one uplink. There may be multiple VLANs on an uplink. Conventionally, each VLAN may use only one uplink port. That is, only one physical uplink port at a given time may be used to forward a data frame associated with a particular VLAN. Through the use of logical networks, a VLAN may use multiple physical ports to forward traffic while maintaining traffic segregation. Link aggregation may be used to bundle several physical links to act as one uplink with higher bandwidth.

A logical network may include a logically specified network portion of the distributed virtual bridge 308. Multiple logical networks may be included within a single bridge element. As such, a logical network may provide an additional layer of traffic separation. When so configured, logical networks may allow different customers to use the same VLAN tag. The VLANs of each customer may remain segregated by virtue of the different logical networks.

The forwarding caches 374, 376, 378, and 380 of the distributed virtual bridge 308 may have a format similar to the global forwarding table 311 of the controlling bridge 348. The forwarding caches 374, 376, 378, and 380 may have smaller memory capacities than the global forwarding table 311. The forwarding caches 374, 376, 378, and 380 may further be updated with address data learned from data frames that flow through the bridge elements 326, 328, 330, and 332.

The address data may additionally be updated with address data received from the global forwarding table 311. Invalid or changed address data that is updated within one or more of the forwarding caches 374, 376, 378, and 380 of the bridge elements 326, 328, 330, and 332 may be communicated to the global forwarding table 311 of the controlling bridge 348. For example, the bridge element 326 may learn a new MAC address of a newly added device that is configured to receive from or send data to the distributed virtual bridge 308. The bridge element 326 may verify that a source MAC address included within a received data frame is allowed at a port by checking a list stored within a memory. The bridge element 326 may send a registration message to the controlling bridge 348 to update the global forwarding table 311 with the verified MAC address. The bridge element 326 may further store the MAC address within the forwarding cache 374. In another example, the bridge element 326 may identify a MAC address that is infrequently used. This infrequently used MAC address may be removed from the forwarding cache 374 to make storage room available for other MAC addresses. The bridge element 326 may send an update message to the controlling bridge 348 to have the MAC address removed from the global forwarding table 311.

Address data stored within the global forwarding table 311 may be communicated to one or more forwarding caches 374, 376, 378, and 380 of the distributed virtual bridge 308. For example, the bridge element 326 may receive a data frame that includes a destination MAC address that is not stored within the forwarding cache 374. To obtain information for forwarding the data frame, the bridge element 326 may send a query to a bridge element 339 configured to access the controlling bridge 348. The bridge element 339 may search the global forwarding table 311 for address data associated with the destination MAC address. If the address data is found, the bridge element 339 may forward the MAC address through the distributed virtual bridge 308 to the querying bridge element 326. The bridge element

326 may store the MAC address as address data within the forwarding cache 374. As with the global forwarding table 311, the address data included within the forwarding caches 374, 376, 378, and 380 of the distributed virtual bridge 308 may include both internal address information, as well as addresses that are external to the system 300.

Each of the bridge elements 326, 328, 330, and 332 may be connected to one or more of the transport layer modules 382, 384, 386, and 388. The transport layer modules 382, 384, 386, and 388 may include buffering used for attachment to the integrated switch router 342. The transport layer modules 382, 384, 386, and 388 may further provide a frame-based, Ethernet- like interface to the integrated switch router 342. The transport layer modules 382, 384, 386, and 388 may each include a shared buffer used to transmit frames across the integrated switch router 342. Additional buffers of the transport layer modules 382, 384, 386, and 388 may be used to receive data frames from the integrated switch router 342. The buffers may be divided into different virtual lanes. Virtual lanes may include logically separated paths for data frame traffic flowing between a bridge element and a transport layer module. For example, there may be four virtual lanes between the bridge element 326 and the transport layer module 382. The transport layer modules 382, 384, 386, and 388 may include logic to recover from faulty microchips and links between a source and a destination. The transport layer modules 382, 384, 386, and 388 may maintain a strict ordering of packets within a particular virtual lane regardless of each data frame's path through the local rack interconnect network 390 and the computer system 300.

The integrated switch router 342 may communicate with the transport layer modules 382, 384, 386, and 388 and may facilitate routing and packet delivery to and from the local rack interconnect network 390. The local rack interconnect network 390 may include links to the bridge elements 326, 328, 330, and 332 located within the same chassis and rack, as well as links to the bridge elements 334-340 in different chassis and racks. The local rack interconnect network 390 may include point-to-point connections, or pipes, between the bridge elements 326, 328, 330, 332, and 333-340 of the distributed virtual bridge 308 with no frame loss and with in-order frame delivery.

The second server computer 304 may include a server computer similar to the first server computer 302 and may be similar to the server computer 302 of FIG. 3. As such, the second server computer 304 may be located within a different chassis and rack than the first server computer 302. Similar to the first server computer 302, the second server computer 304 may include a processor 399 coupled to a memory 397 and to an operating system 395. The processor 399 may include a controlling bridge (CB) 394, a global forwarding table (GFT) 396, and a Fiber Channel Forwarder (FCF) 398. The second server computer 304 may further include virtual machines 355, 357, 359, 361, 363, and 365. A hypervisor 367 may be coupled to the virtual machines 357, 359. The hypervisor 367 may include a hypervisor virtual bridge 371 that allows direct communication between the virtual machines 357, 359. A hypervisor virtual bridge 373 of a hypervisor 369 coupled to the virtual machines 361, 363 may facilitate direct communication between the virtual machines 361, 363. For example, the hypervisor virtual bridges 371, 373 may register address data with the controlling bridge 348.

The second server computer 304 may also include one or more adapters 318, 320, 322, and 324, such as converged CEE network adapters. Each adapter 318, 320, 322, and 324 may be coupled to one or more of the virtual machines 355, 357, 359, 361, 363, and 365. The adapters 318, 320, 322, and 324 may each include a converged adapter virtual bridge 375, 377, 379, and 381. The converged adapter virtual bridges 375, 377, 379, and 381 may facilitate sharing of the adapters 318, 320, 322, and 324 by coordinating virtual machine access. The adapters 318, 320, 322, and 324 may each couple to one or more of the bridge elements 334, 336, 338, and 340 of the distributed virtual bridge 308. Each adapter 318, 320, 322, and 324 may include one or more CEE transmit ports that couple to one of the bridge elements 334, 336, 338, or 340.

Each bridge element 334, 336, 338, and 340 may include a forwarding cache 383, 385, 387, and 389 that includes address data used to forward data frames that are received by the bridge elements 334, 336, 338, and 340. The bridge elements 334, 336, 338, and 340 may each be connected to one or more transport layer modules 315, 317, 319, and 321. The transport layer modules 315, 317, 319, and 321 may include buffering used for the attachment to the integrated switch router 346. The transport layer modules 315, 317, 319, and 321 may further provide a frame-based, Ethernet-like interface to the integrated switch router 346 and may maintain packet ordering. A portion of the distributed virtual bridge 308 shown in FIG. 3 as located above the local rack interconnect network 390 and as associated with the server computers 302, 304 may be referred to as a north portion. The bridge elements 326, 328, 330, 332, 334, 336, 338, and 340 may be coupled to the adapters 310, 312, 314, 316, 318, 320, 322, and 324. The I/O blade device 306 may be the I/O server computer 259 of FIG. 2. As such, the I/O blade device 306 may allow uplink connectivity to an external Ethernet network 392 via an integrated switch router 301 that is coupled to transport layer modules 323, 325, 327, 329, and 331.

The transport layer modules 323, 325, 327, 329, and 331 may each couple to a bridge element 333, 335, 337, and 339. The bridge elements 333, 335, 337, and 339 may each include a forwarding cache 341, 343, 345, and 347. The I/O blade device 306 may be categorized as being included within a south portion of the distributed virtual bridge 308 because the bridge elements 333, 335, 337, and 339 may be coupled to an uplink to the Ethernet 392.

The I/O blade device 306 may include a memory 309, an operating system 391, and a processor 353 that includes the controlling bridge 348. The bridge element 339 may be coupled to the processor 353 via an Ethernet link connection 351. The transport layer module 331 may be coupled to a PCIe bus 344 that is coupled via a PCIe link connection 349 to the processor 353 and the controlling bridge 348. The PCIe bus 344 may also be coupled to a PCIe slot 393.

The controlling bridge 348 may communicate with the bridge elements 326, 328, 330, and 332-340 and other controlling bridges (not shown) of the computer system 300. The controlling bridge 348 may include firmware executing on the processor 353 that manages the bridge elements 326, 328, 330, and 332-340. For example, the controlling bridge 348 may be configured to divide a workload between the bridge elements 326, 328, 330, and 332-340, as well as perform synchronization procedures and failover operations.

The controlling bridges 348, 394 may be configured to interface with and program the bridge elements 326, 328, 330, 332-340. More particularly, the controlling bridge 320 may be configured to generate and send a data frame to one or more of the bridge elements 326, 328, 330, 332-340. The data frames may include register access requests used by the bridge elements 326, 328, 330, 332-340 to access registers. The controlling bridge 348 may include the Fiber Channel Forwarder 313. FCoE may offer the capability to transport fiber channel payloads on top of an Ethernet network. The Fiber Channel Forwarder 313 may execute the Fiber Channel Initialization Protocol to discover and initialize FCoE capable entities connected to an Ethernet cloud. The Fiber Channel Forwarder 313 may further include firmware that encapsulates and de-encapsulates Fiber Channel data frames (e.g., FCoE formatted data frames). In at least one embodiment, the Fiber Channel Forwarder 313 may translate between Ethernet and Fiber Channel protocols.

The controlling bridge 348 may additionally include the global forwarding table 311. The global forwarding table 311 may include address data (e.g., MAC addresses) that is registered and maintained through communication and cooperation with the bridge elements 326, 328, 330, and 332-340, and in some cases, the hypervisors 362, 367, and 369.

In one example, the global forwarding table 311 may maintain MAC addresses that have been learned by a bridge element 326. The bridge element 326 may register the address data with the controlling bridge 348. The controlling bridge 348 may update the global forwarding table 311 by adding the address data to the global forwarding table 311.

Similarly, the bridge element 326 may cause the controlling bridge 348 to update the global forwarding table 311 by sending an update message to the controlling bridge 348. The update message may cause the controlling bridge 348 to delete a MAC address that has been aged out by the bridge element 326. A MAC address may further be deleted when the bridge element 326 has detected that the address data is no longer valid.

In another example, the hypervisor virtual bridge 364 may register MAC addresses or other address data with the controlling bridge 348. The global forwarding table 311 may include address data associated with addresses that are included within the system 300, as well as addresses that are external to the system 300.

FIG. 3 thus shows an embodiment of a system 300 that includes a distributed virtual bridge 308 configured for lossless, point-to-point, in-order data frame delivery. The system 300 may support Fiber channel over Ethernet (FCoE) and may be scalable to include hundreds or more server computers. The controlling bridges 348, 394 may be configured to interface with and program registers of the bridge elements 326, 328, 330, 332-340 and the adapters 366, 368, 370, 372, 375, 377, 379, 381 to reduce administrator workloads. The automated register accesses may reduce potential bottlenecks and facilitate efficient processing. FIG. 4 illustrates another particular embodiment of a system 400 configured to conduct register access operations using a plurality of distributed bridge elements 402, 404, 406, 408 and one or more controlling bridges 438. The controlling bridge(s) 438 may be connected by an Ethernet NIC directly or indirectly through a Local Rack Interconnect, such as the Local Rack Interconnect Network 390 of FIG. 3. A main register ring 446 may include a communications path that uses a register ring protocol to connect nodes on a microchip. For example, the main register ring 446 may be coupled to the bridge elements 402, 404, 406, 408, a partition 410, an integrated switch router 412, and a transport layer module 414.

The bridge elements 402, 404, 406, 408 may include low latency, high speed switches that are similar to the bridge elements 326, 328, 330, and 332-340 of FIG. 3. The partition 410 may include a defined storage area that includes registers 431. The integrated switch router 412 may include registers 423 and may be similar to the integrated switch routers 342, 346 of FIG. 3. The transport layer module 414 may include registers 436 and may be similar to the transport layer modules 315, 317, 319, 321, 323, 325, 327, 329, 331, 382, 384, 386, 388 of FIG. 3.

On the main register ring 446, some of the nodes may be both initiators and targets with regard to register access requests. For example, the bridge elements 402, 404, 406, 408 may be configured to both initiate and receive a register access request. Other nodes, such as the partition 410, the integrated switch router 412, and the transport layer module 414, may only receive register access requests.

When making a register access request to another bridge element 402, 406, 408, the bridge element 404 may wait for a token on the main register ring 446. Once the token is received, the bridge element 404 may place the register access request on the main register ring 446.

The receiving, or target, bridge element 406 to which the register access request is addressed may execute the register access request and communicate a response to the bridge element 404. The bridge element 404 may then return the token to the main register ring 446. To prevent conflicting register access operations from multiple controlling bridges, the controlling bridge 438 may select a bridge element 406 to be a bridge element control port. The bridge element control port may be used when accessing the registers 423, 431, 436 other than bridge element registers 403, 413, 416, 430.

Each bridge element 402, 404, 406, 408 may directly access its own local registers 403, 413, 416, 430 to facilitate parallel access by the controlling bridge 438. The access may occur without a token received from the main register ring 446. A bridge element 404 may delay operations from the main register ring 446 until the register access requests have been completed.

The bridge element 402 may comprise a local bridge element coupled to the controlling bridge 438. The bridge element 402 may be similar to the bridge element 339 of FIG. 3. The bridge element 402 may include the registers 416, a history queue 418, and a remote control module 424. The history queue 418 may include FIFO entries that include sequence numbers 420. The sequence numbers 420 may correspond to data frames having register access requests. An operations count 422 may correspond to a number of successfully completed register access requests associated with a data frame. While only one history queue 418 is shown as being included in the bridge element 402, an embodiment of another bridge element may include multiple history queues (e.g., a history queue for each controlling bridge that may control the bridge element). The remote control module 424 may be configured to execute the register access requests, as well as to update the sequence numbers 420 and the operations count 422. The remote control module 424 may be configured to update operand fields of the data frame with request status information and to route data frames throughout the system 400.

The controlling bridge 438 may be directly coupled to the bridge element 402 via an Ethernet NIC or may be remotely coupled via a Local Rack Interconnect to communicate with the bridge elements 402, 404, 406, 408 using data frames that include register access requests. The controlling bridge 438 may use a semaphore mechanism to prevent other controlling bridges (not shown) from accessing a register 403, 413, 416, 423, 430, 431, 436 at the same time. The controlling bridge 438 may include a FIFO history queue 440 comprising sequence numbers 442 and operation counts 444. The sequence numbers 442 may be associated with respective data frames and their associated register access requests. The sequence numbers 442 may be unique. The operation counts 444 may be compared to operation counts 409, 419, 422, 428 stored in the bridge elements 402, 404, 406, 408 to determine a status of a register access request.

The controlling bridge 438 may additionally include status information 450 that is associated with register access requests. For example, the controlling bridge 438 may access the status information 450 to set an entry associated with a first register access request to "pending."

The status information 450 may be set prior to sending a data frame along with the register access request. When an error is detected, the status information 450 may be updated to reflect details of the detected error. Entries associated with other register access request may be pending until the first register access request has been successfully completed.

Illustrative status information may include: pending, completed, not completed with lock conflict, and error (e.g., access timeout, frame too short, and frame too long).

The controlling bridge 438 may insert a four byte sequence number within a field of a data frame. The sequence number field may be unchanged by a receiving bridge element 404 that uses the sequence number field to update the sequence numbers 407. The bridge element 404 may return the data frame and associated sequence number to the controlling bridge 438. The controlling bridge 438 may check the sequence number of the returned data frame against the stored sequence numbers 442 to confirm delivery or to detect a loss of a data frame.

The controlling bridge 438 may access the history queue 415 when a data frame having an expected sequence number is not received at the controlling bridge 438 from the bridge element 406. The controlling bridge 438 may determine by reading the history queue 415 if the data frame having the sequence number was received by the bridge element 406. If the data frame was never received, the controlling bridge 438 may resend the data frame to the bridge element 406. If an entry in the history queue 415 indicates that the data frame was received at the bridge element 406, then the controlling bridge 438 may read the operations count 419 or the number of successfully completed operations. The operations count 419 may be used to determine whether an error was encountered while processing a register access request of the data frame at the bridge element 406.

A successfully completed operation may include a completed semaphore access. Each register access (i.e., a load or a store operation) of a set of sequential register accesses may be counted as a successfully completed operation. A register access that completes in error may not be counted as a successfully completed operation. A register access that includes a read on the main register ring 446 followed by a write to the main register ring 446 may be counted as a single successfully completed operation.

To prevent conflicting register access operations from multiple controlling bridges, the controlling bridge 438 may select a bridge element of the bridge elements 402, 404, 406, 408 to be a bridge element control port. The designated bridge element control port may be used when accessing registers other than bridge element registers. For instance, when a data frame is addressed to a non-bridge element (e.g., the partition 410, the integrated switch router 412, or the transport layer module 414), a bridge element 408 designated by the controlling bridge 438 as the bridge element control port may receive and route the data frame to the non-bridge element target node. The controlling bridge 448 may send data frames directly to the bridge elements 402, 404, 406, 408 (i.e., without use of a designated bridge element control port). For example, when the bridge element 406 is the target of the data frame (and included register access request), the remote control module 421 of the bridge element 406 may receive the data frame.

The bridge elements 404, 406, 408 may comprise north bridge elements, such as the north bridge element 326 of FIG. 3. The bridge element 404 may include registers 403, a history queue 405, and a remote control module 411. The history queue 405 may include FIFO entries that include sequence numbers 407. The sequence numbers 407 may correspond to data frames having register access requests. An operations count 409 may correspond to a number of successfully completed register access requests associated with a data frame. The remote control module 411 may be configured to execute the register access requests, as well as to update the sequence numbers 407, the operations count 409, and the operand fields of the data frame.

The bridge element 406 may include the registers 413, the history queue 415, and a remote control module 421. The history queue 415 may include FIFO entries that include sequence numbers 417. The sequence numbers 417 may correspond to data frames having register access requests. An operations count 419 may correspond to a number of successfully completed register access requests associated with a data frame. The remote control module 421 may be configured to execute the register access requests, as well as to update the sequence numbers 417, the operations count 419, and the operand fields of the data frame.

The bridge element 408 may include the registers 430, a history queue 426, and a remote control module 429. The history queue 426 may include FIFO entries that include sequence numbers 427. The sequence numbers 427 may correspond to data frames having register access requests. An operations count 428 may correspond to a number of successfully completed register access requests associated with a data frame. The remote control module 429 may be configured to execute the register access requests, as well as to update the sequence numbers 427, the operations count 428, and the operand fields of the data frame.

FIG. 4 thus shows an embodiment of a system 400 configured to enable a controlling bridge 438 to initiate register access requests using distributed bridge elements 402, 404, 406, and 408. The controlling bridge 438 may provide trusted (e.g., known and secure) firmware used to control access considerations, such as security, routing, and availability. The controlling bridge 438 may be configured to access registers of local and remote bridge elements 402, 404, 406, 408, as well as other hardware nodes 410, 412, 414. The automated register accesses may reduce potential bottlenecks and facilitate efficient processing.

FIG. 5 is a flow diagram of an embodiment of a method 500 of using a controlling bridge to program registers of distributed bridge elements and other target nodes. In a particular embodiment, the method 500 may be performed by a controlling bridge and bridge elements, such as the controlling bridge 438 and bridge elements 402, 404, 406, 408 of FIG. 4. At 502, a header of a data frame may be created. For example, the controlling bridge 438 of FIG. 4 may create a header that includes a destination address of a target bridge element 406 or other node. The header may also include a source address, such as a MAC address of the controlling bridge 438 or of a network interface card (NIC) coupled to the controlling bridge 438. The header may further include a VLAN tag and an Ethertype.

A payload of the data frame may be created, at 504. For instance, the controlling bridge 438 of FIG. 4 may generate a payload that includes a register access request(s), a sequence number, and a load/store protocol. At 506, the data frame may be en-queued. For example, the controlling bridge 438 of FIG. 4 may prepare the data frame for transmission at the NIC coupled to the controlling bridge 438. A cyclic redundancy check (CRC) or other checksum may be included within the data frame, at 508. For example, the NIC of the controlling bridge 438 of FIG. 4 may append a CRC to the data frame.

At 510, the data frame may be sent to a local bridge element. For instance, the controlling bridge 438 of FIG. 4 may send the data frame to the bridge element 402. The data frame routing information may be determined, at 512. For example, the bridge element 402 of FIG. 4 may determine a routing path of the data frame based upon the header. The bridge element 402 may further en-queue the data frame for delivery to a receiving bridge element 406 via the integrated switch router 412 and the transport layer module 414. The data frame may be sent to a remote control module of the receiving bridge element, at 514. For instance, when the bridge element 406 is the target of the data frame, the remote control module 421 of the bridge element 406 of FIG. 4 may receive the data frame. When the data frame is alternatively addressed to a non-bridge element (e.g., the partition 410 of FIG. 4), a bridge element 408 designated by the controlling bridge 438 to route data frames to non- bridge elements may receive the data frame.

At 516, the header may be examined, and the sequence number associated with the data frame may be stored. For instance, the remote control module 421 of FIG. 4 may evaluate the header of the received data frame. The remote control module 421 may further store the sequence number 417 associated with the data frame in the history queue 415. The register access request, or operation, may be performed, at 518. For instance, the bridge element 406 of FIG. 4 may perform a register access request on the registers 413. When the bridge element 408 has been designated as a bridge element control port and the partition 410 is a target node, the bridge element 408 may wait for a token to be available from the main register ring 446. The token may be used so that only the one bridge element having control of the token may access the target node at a time. When a token becomes available, the register access request may be placed on the main register ring 446 for delivery to the partition 410.

A count of successfully completed operations may be performed, at 520. For example, the bridge element 406 may determine a number of successfully completed register access requests to be stored as the operations count 419. A result of one or more of the operations may be overlain in the data frame, at 522. For instance, the remote control module 421 may evaluate the outcome of each register access request, or operation. When an error is detected for a register access request, the remote control module 421 may insert an error status update into an operand field of the data frame associated with the register access request. The error status update may notify the controlling bridge 438 of the erroneous attempt so that a corrective action may be initiated.

Operations may continue to be performed until no more operations associated with the frame are detected, at 524. In a particular embodiment, the remote control module 421 of FIG. 4 may detect a consecutive string of four zeros to programmatically signal an end of the register access requests of a data frame.

The number of the successfully completed operations may be stored, at 526. For example, the remote control module 421 of FIG. 4 may store the number of successfully completed operations (e.g., load and store operations) associated with a given data frame in the operations count 419. The number of successfully completed operations may be used to determine whether an error was encountered while processing a register access request.

The data frame may be en-queued, at 528. For instance, the remote control module 421 of FIG. 4 may prepare the data frame for return to the controlling bridge 438 via the transport layer module 414. The remote control module 421 may additionally append an updated CRC. Accordingly, the data frame may be routed to the local bridge element, at 530. For instance, the transport layer module 414 may route the data frame via the integrated switch router 412 to the bridge element 402, and ultimately, to the controlling bridge 438. The controlling bridge 438 may receive and store the returned data frame.

FIG. 5 thus shows a method 500 of routing a data frame having a register access request through a network of distributed bridge elements. The controlling bridge 438 may initiate register access requests to facilitate greater accuracy and scalability. The main register ring 446 may be used, along with tokens and semaphores, to streamline remote and local register accesses.

FIG. 6 is a flowchart of a particular method 600 of detecting and responding to register access errors. The method 600 may be performed by a controlling bridge in communication with a plurality of bridge elements, such as the controlling bridge 438 and bridge elements 402, 404, 406, 408 of FIG. 4. Turning particularly to the flowchart, a history queue may be maintained, at 602. For example, the controlling bridge 438 of FIG. 4 may continuously update the history queue 440. The history queue 440 may include the sequence numbers 442 and the operation counts 444. As described herein, the sequence numbers 442 may be non- identical and otherwise uniquely associated with respective data frames and their associated register access requests. The operation counts 444 may include a number of successfully completed register access requests. The operation counts may be compared to operation counts 409, 419, 422, 428 stored in the bridge elements 402, 404, 406, 408 to determine a status of a register access request.

At 604, a data frame may be received from a target node at the controlling bridge. For instance, the controlling bridge 438 of FIG. 4 may receive a data frame returned from the bridge element 406. The data frame may have been previously sent to the bridge element 406 to perform one or more register accesses on the registers 413.

The controlling bridge may check the history queue, at 606. For example, the controlling bridge 438 of FIG. 4 may evaluate the sequence numbers 417 of the history queue 415 to compare to a sequence number of the received frame. At 608, the controlling bridge may determine if the received data frame is the expected frame. For instance, the controlling bridge 438 of FIG. 4 may compare the sequence numbers 442 of the history queue 440 to the sequence number of the received frame. An expected sequence number of the data frame may be a next sequentially numbered (e.g., in- order) sequence number. The sequence numbers 442 may be used to determine the sequence number that should be received with a returned data frame.

The controlling bridge may pass, or approve, the data frame when the received data frame is determined to be the expected data frame, at 610. When the returned data frame is alternatively not the expected data frame, a data frame may have been lost during

transmission. The controlling bridge may generate and send a data frame to the history queue of the bridge element from which the returned data frame was sent, at 612. For example, the controlling bridge 438 of FIG. 4 may determine that the returned data frame has a sequence number that does not match the expected, in-order sequence number indicated by the history queue 440. In response, the controlling bridge 438 may generate a data frame to be sent to the bridge element 406. The data frame may be used to read the history queue 415 of the bridge element 406. More particularly, data frame may be processed by the bridge element 406 to include the sequence numbers 417 and the operations count 419 associated with the originally transmitted data frame. The transmission to the target node of data frames having new register access requests may be suspended.

At 614, the returned data frame may be received. For instance, the controlling bridge 438 of FIG. 4 may receive the data frame from the bridge element 406. The returned data frame may include information copied from the history queue 415.

The controlling bridge may determine if the missing sequence number was processed at the target node, at 616. For example, the controlling bridge 438 of FIG. 4 may read the returned data frame to determine if the missing sequence number was processed and recorded at the bridge element 406. If the missing sequence number was not processed, then the original data frame having the register access request may be resent, at 618. The controlling bridge may then await confirmation of the delivery of the data frame, at 604. When the controlling bridge alternatively determines that the missing sequence number was processed at the target node, then the controlling bridge may determine if the number of successful operations recorded in the returned data frame equals the number of operations in the original data frame, at 620. For instance, the controlling bridge 438 of FIG. 4 may read the data copied from the operations count 419 into the returned data frame. The controlling bridge 438 may compare the copied data to the number of register access requests included in the original data frame and stored in the operation counts 444.

When the number of successful operations recorded in the returned data frame does not equal the number of operations in the original data frame, all or a portion of the original data frame may be resent, at 618. The controlling bridge may then wait for confirmation of the delivery of the data frame, at 604. When the number of successful operations recorded in the returned data frame alternatively equals the number of operations in the original data frame, data frame transmission to the target node may resume, at 622.

FIG. 6 thus shows a method 600 of detecting and recovering from an unsuccessful register access request. The method 600 may detect whether a data frame was lost or a register access request was otherwise unsuccessfully completed. Corrective action may be automatically initiated in response to a detected error. For example, the data frame having the register access request may be resent. Aspects of the method 600 may thus facilitate efficient and accurate register accesses.

Particular embodiments described herein may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a particular embodiment, the disclosed methods are implemented in software that is embedded in processor readable medium and executed by a processor, which includes but is not limited to firmware, resident software, microcode, etc.

Further, embodiments of the present disclosure, such as the one or more embodiments may take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable medium can be any apparatus that can tangibly embody a computer program and that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

In various embodiments, the medium can include an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk - read only memory (CD-ROM), compact disk-read/write (CD-R/W) and digital versatile disk (DVD).

A data processing system suitable for storing and/or executing program code may include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories that provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the data processing system either directly or through intervening I/O controllers. Network adapters may also be coupled to the data processing system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the currently available types of network adapters.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the disclosed embodiments. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the scope of the disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope possible consistent with the principles and features as defined by the following claims.