1. Technical Field
The present invention is directed to an improved data processing system. More specifically, the present invention is directed to an apparatus and method for implementing multicast on a system area network channel adapter associated with a logically partitioned (LPAR) data processing system, with no visibility to either the Fabric Manager (Subnet Manager) or other Fabric Participants, that LPAR techniques are being employed.
2. Description of Related Art
InfiniBand (IB), which is a form of System Area Network (SAN), defines a multicast facility that allows a Channel Adapter (CA) to send a packet to a single address and have it delivered to multiple ports. Each multicast group is assigned a unique address, and end-nodes that wish to participate in a multicast group do so via a ‘Join’ process initiated by the candidate participant with the Subnet Manager. The InfiniBand architecture is described in the InfiniBand standard, which is available at http://www.infinibandta.org and also hereby incorporated by reference.
With the InfiniBand architecture, the CA sending the multicast packet may be a Host Channel Adapter (HCA) or a Target Channel Adapter (TCA). A multicast packet is sent to all ports of a collection of ports called a multicast group. These ports may be on the same or different nodes in the SAN. Each multicast group is identified by a unique Local Identifier (LID) and Global Identifier (GID). The LID is an address assigned to a port which is unique within the subnet. The LID is used for directing packets within the subnet. The GID is a 128-bit identifier used to uniquely identify a port on a channel adapter, a port on a router, or a multicast group, across all infiniband subnets. The LID and GID are in the Local Route Header (LRH) and Global Route Header (GRH), respectively, of the IB packet. The LRH is present in all IB packets and is an address used for routing IB packets through switches within a subnet. The GRH is present in IB packets which are either multicast packets, or which are targeted to destinations outside the originator's local subnet and is used as an address for routing the packets when the packets traverse multiple subnets.
An IB management action via a Subnet Management Packet (SMP) is used when a node joins a multicast group, and at that time the LID of the port on the node is linked to the multicast group. A subnet manager then stores this information in the switches of the SAN using SMPs. The subnet manager via SMPs tells the switches the routing information for the various multicast groups, and the switches store that information, so that the switches can route the multicast packets to the correct nodes. When a node is going to send a packet to the multicast group, it uses the multicast LID and GID of the group to which it wants the packet to be delivered. The switches in the subnet detect the multicast LID in the packet's Destination LID (DLID) field and replicates the packet, sending it to the appropriate ports, as previously set up by the subnet manager.
It is the Subnet Manager's job to look at the topology and adjust the multicast forwarding tables of each applicable switch in the fabric such that a member of a multicast group will receive a multicast packet sent to that Multicast Group address.
Within a CA, one or more Queue Pairs (QPs) may be registered to receive a given multicast address. IB allows for the number of QPs within a CA that can be registered for the same address to be only limited by the particular implementation. The registration process is done via the IB verb interface. The verb interface is an abstract description of the functionality of a Host Channel Adapter. An operating system exposes some or all of the verb functionality through its programming interface.
When the CA recognizes a multicast packet, the CA must somehow distribute the packet to all the registered QPs within that CA. This must be done in an efficient manner. How this is done is not specified by the InfiniBand Architecture (IBA).
Commonly-owned co-pending Published U.S. Patent Application No. 2003/003426 of Beukema et al., application Ser. No. 09/925,578, filed Aug. 9, 2001, which is incorporated herein by reference, describes a system for implementing multicast on an Infiniband CA. However, the solution described in the Beukema application does not address the additional complexity associated with a logically-partitioned (LPAR) data processing system.
When implementing LPAR, it is advantageous that each Operating System believes that it has control of a single CA. This is further substantiated by the requirement to maintain transparency to the Subnet Manager and other end-nodes, i.e., neither of these must operate any differently when talking to an LPAR end-node vs. a non-LPAR end-node. In order to achieve this, each LPAR sees a logical CA. The ports on this logical CA are assigned LIDs, just like real ports. In addition, packets coming into the ‘real’ port of a CA effectively see a logical switch. This logical switch has a set of logical Multicast Forwarding Tables that the Subnet manager will set up.
In an LPAR computing environment, a single data processing system is “virtualized” to multiple software partitions, each representing a different instance of an operating system. An LPAR data processing system thus functions as if it were several separate machines, though the “machines” (generally unbeknownst to each other) share a common hardware platform. LPAR systems are well suited for situations in which multiple computing platforms are needed, but the additional expense and inconvenience of installing and maintaining multiple physical hardware platforms is undesirable. In particular, it would be beneficial if a CA for a SAN such as Infiniband could be shared among multiple partitions of an LPAR system.