CN110574340A - 在高性能计算环境中提供相对于分区成员资格定义的多播组成员资格的系统和方法 - Google Patents

在高性能计算环境中提供相对于分区成员资格定义的多播组成员资格的系统和方法 Download PDF

Info

Publication number
CN110574340A
CN110574340A CN201880028491.7A CN201880028491A CN110574340A CN 110574340 A CN110574340 A CN 110574340A CN 201880028491 A CN201880028491 A CN 201880028491A CN 110574340 A CN110574340 A CN 110574340A
Authority
CN
China
Prior art keywords
subnet
partition
port
multicast group
multicast
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.)
Granted
Application number
CN201880028491.7A
Other languages
English (en)
Other versions
CN110574340B (zh
Inventor
B·D·约翰森
B·博格丹斯基
L·霍雷恩
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.)
Oracle International Corp
Original Assignee
Oracle International Corp
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 Oracle International Corp filed Critical Oracle International Corp
Publication of CN110574340A publication Critical patent/CN110574340A/zh
Application granted granted Critical
Publication of CN110574340B publication Critical patent/CN110574340B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G06F16/2255—Hash tables
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/30—Decision processes by autonomous network management units using voting and bidding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H04L45/021—Ensuring consistency of routing table updates, e.g. by using epoch numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/48—Routing tree calculation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/48—Routing tree calculation
    • H04L45/484—Routing tree calculation using multiple routing trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/15—Interconnection of switching modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/20—Support for services
    • H04L49/201—Multicast operation; Broadcast operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/356—Switches specially adapted for specific applications for storage area networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/356—Switches specially adapted for specific applications for storage area networks
    • H04L49/357—Fibre channel switches
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/35—Switches specially adapted for specific applications
    • H04L49/356—Switches specially adapted for specific applications for storage area networks
    • H04L49/358—Infiniband Switches
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/103—Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5069—Address allocation for group communication, multicast communication or broadcast communication
    • 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/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/622—Layer-2 addresses, e.g. medium access control [MAC] addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/668—Internet protocol [IP] address subnets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/30—Peripheral units, e.g. input or output ports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/70—Virtual switches

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Multi Processors (AREA)

Abstract

用于在高性能计算环境中提供相对于分区成员资格的多播组(MCG)成员资格的系统和方法。根据实施例，通过允许指示本地子网的子网管理器应该将作为相关分区的成员的所有端口设置为特定多播组的成员，SM可以执行更高效的多播路由处理。也可以限制IB客户端与处理加入和离开操作通常所需的子网管理的交互。此外，可以通过创建用于包括添加到多播组的每个分区成员的多播分组的路由的生成树，而不是像常规要求的那样在接收到每个多播组加入请求之后创建生成树来减少子网管理器开销。

Description

在高性能计算环境中提供相对于分区成员资格定义的多播组 成员资格的系统和方法
版权声明
本专利文档公开内容的一部分包含受版权保护的素材。版权拥有者不反对任何人对专利文档或专利公开内容按照在专利商标局的专利文件或记录中出现得那样进行的传真复制，但是除此之外在任何情况下都保留所有版权。
优先权声明和对相关申请的交叉引用
本申请要求于2017年3月24日提交的题为“SYSTEM AND METHOD FOR INFINIBANDFABRIC OPTIMIZATIONS TO MINIMIZE SA ACCESS AND STARTUP FAILOVER TIMES”的美国临时专利申请No.62/476,423；于2017年8月18日提交的题为“SYSTEM AND METHOD TOPROVIDE HOMOGENEOUS FABRIC ATTRIBUTES TO REDUCE THE NEED FOR SA ACCESS IN AHIGH PERFORMANCE COMPUTING ENVIRONMENT”的美国临时专利申请No.62/547,203；于2017年8月18日提交的题为“SYSTEM AND METHOD TO PROVIDE PATH RECORDS DERIVED FROMARP RESPONSES AND PEER-TO-PEER NEGOTIATION ON HOMOGENOUS FABRIC ATTRIBUTE INA HIGH PERFORMANCE COMPUTING ENVIRONMENT”的美国临时专利申请No.62/547,206；于2017年8月18日提交的题为“SYSTEM AND METHOD TO PROVIDE MULTICAST GROUPMEMBERSHIP DEFINED RELATIVE TO PARTITIONMEMBERSHIP IN A HIGH PERFORMANCECOMPUTING ENVIRONMENT”的美国临时专利申请No.62/547,213；于2017年8月18日提交的题为“SYSTEM AND METHOD TO PROVIDE DUAL MULTICAST LID ALLOCATION PERMULTICASTGROUP TO FACILITATE BOTH FULL AND LIMITEDPARTITION MEMBERS IN A HIGHPERFORMANCECOMPUTING ENVIRONMENT”的美国临时专利申请No.62/547,218；于2017年8月18日提交的题为“SYSTEM AND METHOD TO PROVIDE MULTICAST GROUP MLIDDYNAMICDISCOVERY ON RECEIVED MULTICAST MESSAGES FORRELEVANT MGID IN A HIGHPERFORMANCE COMPUTINGENVIRONMENT”的美国临时专利申请No.62/547,223；于2017年8月18日提交的题为“SYSTEM AND METHOD TO PROVIDE DEFAULT MULTICAST LID VALUES PERPARTITION AS ADDITIONAL SMA ATTRIBUTES IN A HIGH PERFORMANCE COMPUTINGENVIRONMENT”的美国临时专利申请No.62/547,225；于2017年8月18日提交的题为“SYSTEMAND METHOD TO PROVIDE EXPLICIT MULTICAST LIDASSIGNMENT FOR PER PARTITIONDEFAULT MULTICASTLIDS DEFINED AS SM POLICY INPUT IN A HIGHPERFORMANCECOMPUTING ENVIRONMENT”的美国临时专利申请No.62/547,255；于2017年8月18日提交的题为“SYSTEM AND METHOD TO PROVIDE DEFAULT MULTICAST GROUP(MCG)FOR ANNOUNCEMENTSAND DISCOVERY AS EXTENDED PORT INFORMATION IN A HIGH PERFORMANCE COMPUTINGENVIRONMENT”的美国临时专利申请No.62/547,258；于2017年8月18日提交的题为“SYSTEMAND METHOD TO PROVIDE DEFAULT MULTICAST PROXY FORSCALABLE FORWARDING OFANNOUNCEMENTS ANDINFORMATION REQUEST INTERCEPTING IN A HIGHPERFORMANCECOMPUTING ENVIRONMENT”的美国临时专利申请No.62/547,259；于2017年8月18日提交的题为“SYSTEM AND METHOD TO USE QUEUE PAIR 1FOR RECEIVING MULTICAST BASEDANNOUNCMENTS IN MULTIPLE PARTITIONS IN A HIGH PERFORMANCE COMPUTINGENVIRONMENT”的美国临时专利申请No.62/547,260；于2017年8月18日提交的题为“SYSTEMAND METHOD TO USE ALL INCOMING MULTICAST PACKETS AS A BASIS FOR GUID TO LIDCACHE CONTENTS IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT”的美国临时专利申请No.62/547,261；以及于2017年8月18日提交的题为“SYSTEM AND METHOD TO PROVIDECOMBINED IB AND IP ADDRESSAND NAME RESOLUTION SCHEMES VIA DEFAULT IBMULTICASTGROUPS IN A HIGH PERFORMANCECOMPUTING ENVIRONMENT”的美国临时专利申请No.62/547,264的优先权权益，这些申请中的每个申请都通过引用并入本文。
本申请涉及以下专利申请，这些申请中的每个申请都通过引用被整体并入本文：与本文档同时提交的题为“SYSTEM AND METHOD TO PROVIDE HOMOGENEOUS FABRICATTRIBUTES TO REDUCE THE NEED FOR SA ACCESS IN A HIGH PERFORMANCE COMPUTINGENVIRONMENT”、申请号为____/____的美国专利申请(代理人案卷号ORACL-05828US1)；与本文档同时提交的题为“SYSTEM AND METHOD TO PROVIDE PATH RECORDS DERIVED FROM ARPRESPONSES AND PEER-TO-PEER NEGOTIATION BASED ON HOMOGENEOUS FABRICATTRIBUTEIN A HIGH PERFORMANCE COMPUTING ENVIRONMENT”、申请号为____/____的美国专利申请(代理人案卷号ORACL-05829US1)；与本文档同时提交的题为“SYSTEM AND METHOD TOPROVIDE DUAL MULTICAST LID ALLOCATION PER MULTICAST GROUP TO FACILITATE BOTHFULL AND LIMITED PARTITION MEMBERS IN A HIGH PERFORMANCE COMPUTINGENVIRONMENT”、申请号为____/____的美国专利申请(代理人案卷号：ORACL-05831US1)；与本文档同时提交的题为“SYSTEM AND METHOD TO PROVIDE MULTICAST GROUP MULTICASTLID DYNAMIC DISCOVERY BASED ON RECEIVED MULTICAST MESSAGES FOR RELEVANTMULTICAST GID IN A HIGH PERFORMANCE COMPUTING ENVIRONMENT”、申请号为____/____的美国专利申请(代理人案卷号：ORACL-05832US1)。
背景技术
随着更大的云计算体系架构的推出，与传统网络和存储相关联的性能和管理瓶颈已成为重要的问题。人们对使用诸如InfiniBand(IB)技术等高性能无损互连作为云计算架构的基础越来越感兴趣。这是本发明的实施例旨在解决的一般领域。
发明内容
用于在高性能计算环境中提供相对于分区成员资格的多播组(MCG)成员资格的系统和方法。用于在高性能计算环境中提供相对于分区成员资格定义的多播组成员资格的示例性方法可以在子网管理器处接收创建多播组的请求，该请求包括指示符并且该指示符指示在子网中定义的分区的每个成员要与多播组相关联。该方法可以由子网管理器确定作为在子网中定义的分区的成员的多个附加端端口。该方法可以由子网管理器将作为分区的成员的多个附加端端口与定义多播组的标识符相关联。该方法可以由子网管理器定义将包括定义多播组的标识符的多播分组传递到与定义多播组的标识符相关联的每个端端口的路由。
附图说明
图1示出了根据实施例的InfiniBand环境的图示。
图2示出了根据实施例的分区集群环境的图示。
图3示出了根据实施例的网络环境中的树形拓扑的图示。
图4示出了根据实施例的示例性共享端口体系架构。
图5示出了根据实施例的示例性vSwitch体系架构。
图6示出了根据实施例的示例性vPort体系架构。
图7示出了根据实施例的具有预填充的LID的示例性vSwitch体系架构。
图8示出了根据实施例的具有动态LID分配的示例性vSwitch体系架构。
图9示出了根据实施例的具有动态LID分配和预填充的LID的具有vSwitch的示例性vSwitch体系架构。
图10示出了根据实施例的示例性多子网InfiniBand架构。
图11示出了根据实施例的在高性能计算环境中的两个子网之间的互连。
图12示出了根据实施例的在高性能计算环境中经由双端口虚拟路由器配置的两个子网之间的互连。
图13示出了根据实施例的用于支持高性能计算环境中的双端口虚拟路由器的方法的流程图。
图14示出了根据实施例的支持多播通信的示例性子网A00。
图15示出了根据实施例的由SM/SA用于管理多播组的示例性SA数据存储库。
图16示出了根据实施例的可以经由子网中的生成树(spanning tree)算法确定的示例性路由。
图17示出了根据实施例的交换机的详细视图。
图18图示了根据实施例的用于向多播组的成员提供多播分组传递的方法的流程图。
图19图示出了根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的系统。
图20图示了根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的系统。
图21图示了根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的系统。
图22图示了根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的系统。
图23图示了根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的方法的流程图。
图24是根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的方法的流程图。
图25图示了根据实施例的用于提供高性能计算环境中的从ARP响应和对同构架构属性的对等(peer-to-peer)协商得出的路径记录的系统。
图26是根据实施例的用于从传入的ARP请求和响应来确定GID和LID的方法的流程图，该ARP请求和响应包括与架构最小值/最大值的相关性。
图27是根据实施例的用于基于新的CM类型消息交换来构造路径信息的方法的流程图，该新的CM类型消息交换包括与架构最小值/最大值的相关性。
图28是根据实施例的用于基于新的CM类型消息交换来构造路径信息的方法的流程图，该新的CM类型消息交换包括与架构最小值/最大值的相关性。
图29图示了根据实施例的用于创建和加入多播组(MCG)的流程图。
图30示出了根据实施例的用于通过端端口响应对MLID的请求(例如，加入MCG的请求)的流程图。
图31示出了根据实施例的可以针对子网中的受限分区成员MLID经由生成树算法确定的示例性多播分组路由。
图32示出了根据实施例的用于配置端端口以与分配给MCG的双MLID一起使用的流程图。
图33图示了根据实施例的用于在高性能计算环境中为每个多播组提供双多播本地标识符(MLID)以促进正式分区成员和受限分区成员的流程图。
图34示出了根据实施例的用于提供高性能计算环境中的相对于分区成员资格定义的多播组成员资格的流程图。
图35图示了根据实施例的用于提供高性能计算环境中的相对于分区成员资格定义的多播组成员资格的方法的流程图。
图36图示了根据实施例的用于提供高性能计算环境中的相对于分区成员资格定义的多播组成员资格的方法的流程图。
图37是根据实施例的用于根据端端口的分区表来更新端端口的默认MLID表的方法的流程图。
图38是根据实施例的用于由IB客户端从支持端端口的默认MLID表中确定默认MLID值的方法的流程图。
图39图示了根据实施例的用于在高性能计算环境中提供每个分区的默认多播本地标识符(MLID)值作为附加子网管理代理(SMA)属性的方法的流程图。
图40图示了根据实施例的用于在高性能计算环境中在接收到的多播消息上为相关MGID(多播全局标识符)提供多播组多播本地标识符(MLID)动态发现的方法的流程图。
图41是根据实施例的用于在高性能计算环境中在接收到的多播消息上为相关的MGID(多播全局标识符)提供多播组多播本地标识符(MLID)动态发现的方法的流程图。
图42是根据实施例的用于在高性能计算环境中在接收到的多播消息上为相关的MGID(多播全局标识符)提供多播组多播本地标识符(MLID)动态发现的方法的流程图。
图43图示了根据实施例的用于维护传出多播分组的特定于分区的MLID以及专用的MCG MLID的记录的流程图。
图44图示了根据实施例的用于提供高性能计算环境中的多播本地标识符的端节点动态发现的方法的流程图。
图45图示了根据实施例的用于为定义为SM策略输入的特定于分区的默认MLID提供明确多播本地标识符(MLID)分配的方法的流程图。
图46图示了根据实施例的用于为定义为SM策略输入的每个分区默认MLID提供明确多播本地标识符(MLID)分配的方法的流程图。
图47图示了根据实施例的两个独立的基于胖树的子网，在子网合并操作之前，每个子网具有为定义为SM策略输入的特定于分区的默认MLID的明确多播本地标识符(MLID)分配。
图48示出了基于单个胖树的子网，该子网在子网合并操作之后具有定义为SM策略输入的特定于分区的默认MLID的明确多播本地标识符(MLID)分配。
图49图示了根据实施例的用于在高性能计算环境中提供用于通告和发现的默认多播组(MCG)作为扩展端口信息的方法的流程图。
图50图示了根据实施例的用于在高性能计算环境中提供用于通告和发现的默认多播组(MCG)作为扩展端口信息的方法的流程图。
图51图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的方法的流程图。
图52图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的系统。
图53图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的系统。
图54图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的系统。
图55图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的方法的流程图。
图56图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的方法的流程图。
图57图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的方法的流程图。
图58图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的方法的流程图。
图59图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的系统。
图60图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的系统。
图61图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的系统。
图62图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的系统。
图63图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的系统。
图64图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的方法的流程图。
图65图示了根据实施例的在高性能计算环境中使用所有传入多播(MC)分组作为全局唯一标识符(GUID)到本地标识符(LID)高速缓存内容的基础的方法的流程图。
图66图示了根据实施例的在高性能计算环境中使用所有传入多播(MC)分组作为全局唯一标识符(GUID)到本地标识符(LID)高速缓存内容的基础的系统。
图67图示了根据实施例的在高性能计算环境中使用所有传入多播(MC)分组作为全局唯一标识符(GUID)到本地标识符(LID)高速缓存内容的基础的系统。
图68图示了根据实施例的在高性能计算环境中使用所有传入多播(MC)分组作为全局唯一标识符(GUID)到本地标识符(LID)高速缓存内容的基础的方法的流程图。
图69图示了根据实施例的在高性能计算环境中经由默认IB多播组提供组合的IB和IP地址以及名称解析方案的方法的流程图。
图70图示了根据实施例的在高性能计算环境中经由默认IB多播组提供组合的IB和IP地址以及名称解析方案的系统。更特别地，该图示出了常规的GUID到LID高速缓存。
图71图示了根据实施例的在高性能计算环境中经由默认IB多播组提供组合的IB和IP地址以及名称解析方案的方法的流程图。
图72图示了根据实施例的在高性能计算环境中经由默认IB多播组提供组合的IB和IP地址以及名称解析方案的方法的流程图。
具体实施方式
在附图的各图中通过示例而非限制的方式图示了本发明，附图中相同的标号指示类似的元素。应当注意的是，在本公开中对“一个”或“一些”实施例的引用不一定是相同的实施例，并且这种引用意味着至少一个。虽然讨论了特定的实现，但是应当理解的是，特定实现仅仅是为了说明性目的而提供。相关领域的技术人员将认识到，在不脱离本发明的范围和精神的情况下，可以使用其它部件和配置。
贯穿附图和具体实施方式可以使用共同的标号来指示相同的元素；因此，如果元素在其它地方进行了描述，那么在图中使用的标号可以或可以不在特定于该图的具体描述中引用。
本文描述了用于在高性能计算环境中提供相对于分区成员资格定义的多播组成员资格的系统和方法。
本发明的以下描述使用InfiniBandTM(IB)网络作为高性能网络的示例。贯穿以下描述，可以参考InfiniBandTM规范(也被不同地称为InfiniBand规范、IB规范或传统IB规范)。这样的参考被理解为是指可在http://www.inifinibandta.org获得的于2015年3月发布的Trade Association Architecture Specification，卷1，版本1.3，其全部内容通过引用并入本文。对于本领域技术人员来说显而易见的是，可以使用其它类型的高性能网络而没有限制。以下描述还使用胖树拓扑作为架构拓扑的示例。对于本领域技术人员来说显而易见的是，可以使用其它类型的架构拓扑而没有限制。
为了满足当前时代(例如，Exascale时代)的云的需求，期望虚拟机能够利用诸如远程直接存储器访问(RDMA)的低开销网络通信范例。RDMA绕过OS堆栈并且直接与硬件通信，因此可以使用像单根I/O虚拟化(SR-IOV)网络适配器这样的直通技术。根据实施例，对于高性能无损互连网络中的适用性可以提供虚拟交换机(vSwitch)SR-IOV体系架构。由于网络重新配置时间对于使实时迁移成为实用选项是至关重要的，因此，除了网络体系架构之外，还可以提供可伸缩的和拓扑无关的动态重新配置机制。
根据实施例，并且除此之外，可以提供使用vSwitch的虚拟化环境的路由策略，并且可以提供用于网络拓扑(例如，胖树拓扑)的高效路由算法。动态重新配置机制可以被进一步微调以使胖树中施加的开销最小化。
根据本发明的实施例，虚拟化可以有益于云计算中的高效资源利用和弹性资源分配。实时迁移使得有可能通过以应用透明的方式在物理服务器之间移动虚拟机(VM)来优化资源使用。因此，虚拟化可以通过实时迁移实现整合、资源的按需供给以及弹性。
InfiniBandTM
InfiniBandTM(IB)是由InfiniBandTM贸易协会开发的开放标准无损网络技术。该技术基于提供高吞吐量和低延迟通信的串行点对点全双工互连，特别针对高性能计算(HPC)应用和数据中心。
InfiniBandTM体系架构(IBA)支持双层拓扑划分。在下层，IB网络被称为子网，其中子网可以包括使用交换机和点对点链路互连的主机集合。在上层，IB架构构成可以使用路由器互连的一个或多个子网。
在子网内，可以使用交换机和点对点链路来连接主机。此外，可以存在主管理实体，子网管理器(SM)，其驻留在子网中的指定设备上。子网管理器负责配置、激活和维护IB子网。另外，子网管理器(SM)可以负责在IB架构中执行路由表计算。这里，例如，IB网络的路由旨在在本地子网中的所有源和目的地对之间进行适当的负载平衡。
SM负责向本地子网提供子网管理(SA)。SA提供对关于本地子网的若干种类型的信息的访问和存储。为了提供SA，子网管理器通常维护可查询的数据库，用于存储与子网相关的信息。通常由SA存储/提供的信息的示例包括端节点在子网中进行操作所需的信息，诸如端节点之间的路径、事件的通知、服务属性等；非算法信息，诸如分区数据、M_Keys等；对其它管理实体可能有用的可选信息，诸如拓扑数据、交换机转发表等。
通过使用管理数据报(MAD)访问、查询或报告由SA提供的数据。MAD是标准化的管理分组，除其它用途外，还允许SM/SA与IB设备之间以及IB设备自身之间的管理操作。
通过子网管理接口，子网管理器与子网管理代理(SMA)交换控制分组，这些控制分组被称为子网管理分组(SMP-它们是MAD的子集)。子网管理代理驻留在每个IB子网设备上。通过使用SMP，子网管理器能够发现架构、配置端节点和交换机，以及从SMA接收通知。
通过子网管理接口，子网管理器与子网管理代理(SMA)交换被称为子网管理分组(SMP)的控制分组。子网管理代理驻留在每个IB子网设备上。通过使用SMP，子网管理器能够发现架构、配置端节点和交换机，并从SMA接收通知。
根据实施例，IB网络中的子网内路由可以基于存储在交换机中的线性转发表(LFT)。LFT由SM根据使用中的路由机制来计算。在子网中，端节点和交换机上的主机通道适配器(HCA)端口使用本地标识符(LID)进行寻址。线性转发表(LFT)中的每个条目包括目的地LID(DLID)和输出端口。表中只支持每LID一个条目。当分组到达交换机时，其输出端口通过在交换机的转发表中查找DLID来确定。路由是确定性的，因为分组在网络中在给定的源-目的地对(LID对)之间采用相同的路径。
一般而言，除了主子网管理器之外的所有其它子网管理器为了容错都在备用模式下起作用。但是，在主子网管理器发生故障的情况下，由备用子网管理器协商新的主子网管理器。主子网管理器还执行子网的周期性扫描，以检测任何拓扑变化并相应地重新配置网络。
在IB子网中，每个端节点可以包含一个或多个主机通道适配器(HCA)。HCA负责生成和发送数据分组，以及接收和处理数据分组。每个主机通道适配器(HCA)可以具有一个或多个端口。HCA的端口用于将HCA和包含HCA的端节点连接到网络架构。例如，HCA的端口可以经由物理介质(诸如电缆(例如，双绞铜线，或光纤，电缆))连接到子网交换机。
通过本地子网管理器(即，HCA连接到的子网的子网管理器)为连接到网络架构的HCA端口分配本地标识符(LID)。LID用于寻址HCA端口。其它子网节点也可以由本地子网管理器分配LID。例如，子网主机和交换机可以由子网管理器分配本地标识符(LID)，并且可以通过其分配的LID进行寻址。LID在子网内是唯一的，并且单个子网可以限制为49151个单播LID。
根据实施例，IB网络中的子网内路由可以基于存储在本地子网交换机中的线性转发表(LFT)。LFT由SM根据使用中的路由机制计算得出。每个数据分组包含识别创建分组的端口的源LID(SLID)和识别分组要被传递到的端口的目的地LID(DLID)。此外，线性转发表(LFT)中的每个条目由DLID和输出端口组成。表中每个LID仅支持一个条目。当分组到达交换机时，其输出端口是通过在交换机的转发表中查找分组的DLID来确定的。然后，分组经由与LFT中分组的DLID对应的交换机端口进行出站转发。路由是确定性的，因为分组在给定的源－目的地对(LID对)之间采用网络中相同的路径。
此外，可以使用本地标识符(LID)来寻址子网内的主机和交换机，并且可以将单个子网限制为49151个单播LID。除了作为在子网内有效的本地地址的LID之外，每个IB设备还可以具有64位全局唯一标识符(GUID)。GUID可以用于形成作为IB层三(L3)地址的全局标识符(GID)。
在网络初始化时，SM可以计算路由表(即，子网内每对节点之间的连接/路由)。此外，每当拓扑改变时，都可以更新路由表，以便确保连接性和最佳性能。在正常操作期间，SM可以执行网络的周期性轻扫描以检查拓扑变化。如果在轻扫描期间发现变化，或者如果SM接收到通过发信号通知网络变化的信息(陷阱)，那么SM可以根据发现的变化来重新配置网络。
例如，当网络拓扑改变时，诸如当链路断开时、当添加设备时或者当链路被去除时，SM可以重新配置网络。重新配置步骤可以包括在网络初始化期间执行的步骤。此外，重新配置可以具有限于其中发生网络变化的子网的局部范围。此外，用路由器对大型架构进行分段可以限制重新配置的范围。
除了作为在子网内有效且唯一的本地地址的LID之外，每个IB设备(例如，HCA或交换机)还可以具有64位全局唯一标识符(GUID)。此外，HCA的每个端口可以具有其自己的GUID。IB设备的GUID可以由设备的供应商分配。可以将IB设备的GUID硬编码到设备中，就像网络接口卡的媒体访问控制(MAC)地址一样。GUID可以用于形成作为IB层三(L3)地址的全局标识符(GID)。
图1中示出了示例InfiniBand架构，其示出了根据实施例的InfiniBand环境100的图示。在图1所示的示例中，节点A-E、101-105使用InfiniBand架构120经由相应的主机通道适配器111-115通信。根据实施例，各种节点(例如，节点A-E、101-105)可以由各种物理设备来表示。根据实施例，各种节点(例如，节点A-E、101-105)可以由诸如虚拟机的各种虚拟设备来表示。
在InfiniBand中分区
根据实施例，IB网络可以支持分区作为安全机制，以提供对共享网络架构的系统的逻辑组的隔离。架构中的节点上的每个HCA端口可以是一个或多个分区的成员。分区成员资格由集中式分区管理器管理，集中式分区管理器可以是SM的一部分。SM可以将每个端口上的分区成员资格信息配置为16位分区键(P_Key)的表。SM还可以用包含与通过这些端口发送或接收数据流量的端节点相关联的P_Key信息的分区实施表来配置交换机和路由器端口。此外，在一般情况下，交换机端口的分区成员资格可以表示与在出口(朝链路)方向经由端口路由的LID间接相关联的所有成员资格的联合。
P_Key可以指定两种类型的分区成员资格之一：受限的(limited)或正式的(full)。P_Key的高阶位用于指定在其P_Key表中具有P_Key的HCA的成员资格类型。值1指示正式成员，而值0指示受限成员。受限分区成员不能接受来自其它受限成员的分组。但是，允许成员资格类型的所有其它组合之间进行通信。
根据实施例，分区是端口的逻辑组，使得组的成员只能与同一逻辑组的其它成员通信。在主机通道适配器(HCA)和交换机处，可以使用分区成员资格信息对分组进行过滤以实施隔离。一旦分组到达传入端口，具有无效分区信息的分组就可以被丢弃。在分区的IB系统中，可以使用分区来创建租户集群。在分区实施就位的情况下，节点不能与属于不同租户集群的其它节点通信。以这种方式，即使存在受损或恶意的租户节点时，系统的安全性也能够得到保证。
根据实施例，对于节点之间的通信，除管理队列对(QP0和QP1)以外，队列对(QP)和端到端上下文(EEC)可以被分配给特定分区。然后，可以将P_Key信息添加到发送的每个IB传输分组。当分组到达HCA端口或交换机时，可以针对由SM配置的表验证其P_Key值。如果找到无效的P_Key值，那么立即丢弃该分组。以这种方式，只有在共享分区的端口之间才允许通信。
图2中示出了IB分区的示例，其中示出了根据实施例的分区的集群环境的图示。在图2所示的示例中，节点A-E、101-105使用InfiniBand架构120经由相应的主机通道适配器111-115通信。节点A-E被布置到分区中，即分区1，130、分区2，140和分区3，150。分区1包括节点A101和节点D104。分区2包括节点A101、节点B 102和节点C103。分区3包括节点C103和节点E105。由于分区的布置，节点D104和节点E105不被允许通信，因为这些节点不共享分区。同时，例如，节点A101和节点C103被允许通信，因为这些节点都是分区2，140的成员。
InfiniBand中的虚拟机
在过去的十年中，虚拟化高性能计算(HPC)环境的前景已得到相当大的提高，因为CPU开销已通过硬件虚拟化支持被实际上消除；存储器开销已通过虚拟化存储器管理单元被显著降低；存储开销已通过使用快速SAN存储装置或分布式网络文件系统被减少；并且网络I/O开销已通过使用比如单根输入/输出虚拟化(SR-IOV)的设备直通技术被减少。现在，云有可能使用高性能互连解决方案来容纳虚拟HPC(vHPC)集群，并提供必要的性能。
但是，当与诸如InfiniBand(IB)的无损网络耦合时，由于在这些解决方案中使用的复杂寻址和路由方案，某些云功能(诸如虚拟机(VM)的实时迁移)仍然是个问题。IB是提供高带宽和低延迟的互连网络技术，因此非常适合HPC和其它通信密集型工作负载。
用于将IB设备连接到VM的传统方法是通过利用具有直接分配的SR-IOV。但是，使用SR-IOV实现分配有IB主机通道适配器(HCA)的VM的实时迁移已被证明是具有挑战性的。每个IB连接的节点具有三个不同的地址：LID、GUID和GID。当发生实时迁移时，这些地址中的一个或多个改变。与迁移中的VM(VM-in-migration)通信的其它节点会丢失连接性。当发生这种情况时，通过向IB子网管理器(SM)发送子网管理(SA)路径记录查询来定位要重新连接到的虚拟机的新地址，可以尝试更新丢失的连接。
IB使用三种不同类型的地址。第一种类型的地址是16位本地标识符(LID)。SM向每个HCA端口和每个交换机分配至少一个唯一的LID。LID用于在子网内路由流量。由于LID为16位长，因此可以做出65536个唯一地址组合，其中只有49151个(0x0001-0xBFFF)可以用作单播地址。因此，可用单播地址的数量限定了IB子网的最大尺寸。第二种类型的地址是由制造商分配给每个设备(例如，HCA和交换机)和每个HCA端口的64位全局唯一标识符(GUID)。SM可以向HCA端口分配附加的子网唯一GUID，其在使用SR-IOV时是有用的。第三种类型的地址是128位全局标识符(GID)。GID是有效的IPv6单播地址，并且向每个HCA端口分配至少一个。GID通过组合由架构管理员分配的全局唯一64位前缀和每个HCA端口的GUID地址形成。
胖树(FTree)拓扑和路由
根据实施例，基于IB的HPC系统中的一些采用胖树拓扑来利用胖树提供的有用特性。由于每个源目的地对之间有多条路径可用，因此这些特性包括完全的二分带宽和固有的容错。胖树背后的最初想法是，当树朝着拓扑的根移动时，在节点之间采用具有更多可用带宽的较胖链路。较胖链路可以帮助避免上层交换机中的拥塞并且维持二分带宽。
图3示出了根据实施例的网络环境中的树形拓扑的图示。如图3所示，一个或多个端节点201-204可以在网络架构200中连接。网络架构200可以基于包括多个叶交换机211-214和多个主干交换机或根交换机231-234的胖树拓扑。此外，网络架构200可以包括一个或多个中间交换机，诸如交换机221-224。
同样如图3所示，端节点201-204中的每一个可以是多宿主节点，即，通过多个端口连接到网络架构200的两个或更多个部分的单个节点。例如，节点201可以包括端口H1和H2，节点202可以包括端口H3和H4，节点203可以包括端口H5和H6，并且节点204可以包括端口H7和H8。
此外，每个交换机可以具有多个交换机端口。例如，根交换机231可以具有交换机端口1-2，根交换机232可以具有交换机端口3-4，根交换机233可以具有交换机端口5-6，并且根交换机234可以具有交换机端口7-8。
根据实施例，胖树路由机制是用于基于IB的胖树拓扑的最流行的路由算法之一。胖树路由机制也在OFED(开放架构企业分发-用于构建和部署基于IB的应用的标准软件栈)子网管理器OpenSM中实现。
胖树路由机制旨在生成在网络架构中跨链路均匀传播最短路径路由的LFT。该机制按索引次序遍历架构并将端节点的目标LID(以及因此对应的路由)分配给每个交换机端口。对于连接到相同叶交换机的端节点，索引次序可以取决于端节点连接到的交换机端口(即端口编号顺序)。对于每个端口，该机制可以维护端口使用计数器，并且可以在每次添加新路由时使用这个端口使用计数器来选择最少使用的端口。
根据实施例，在分区的子网中，不允许不是公共分区的成员的节点通信。在实践中，这意味着由胖树路由算法分配的一些路由不用于用户流量。当胖树路由机制以与它针对其它功能路径所做的相同的方式为那些路由生成LFT时，会出现该问题。由于节点按索引的次序进行路由，因此这种行为会导致链路上的平衡降级。由于路由可以在与分区无关的情况下执行，因此，一般而言，胖树路由的子网提供分区之间较差的隔离。
根据实施例，胖树是可以利用可用网络资源进行伸缩的分层网络拓扑。而且，使用放置在不同级别层次上的商用交换机容易构建胖树。通常可以获得胖树的不同变体，包括k-ary-n-trees、扩展的广义胖树(XGFT)、平行端口广义胖树(PGFT)和现实生活胖树(RLFT)。
k-ary-n-tree是具有kn个端节点和n·kn-1个交换机的n级胖树，每个具有2k个端口。每个交换机在树中具有相同数量的上下连接。XGFT胖树通过允许交换机不同数量的上行连接和下行连接以及在树中每个级别的不同数量的连接来扩展k-ary-n-tree。PGFT定义进一步拓宽了XGFT拓扑，并且允许交换机之间的多个连接。可以使用XGFT和PGFT来定义各种各样的拓扑。但是，为了实践的目的，引入了作为PGFT受限版本的RLFT来定义当今HPC集群中常见的胖树。RLFT在胖树的所有级别使用相同端口计数的交换机。
输入/输出(I/O)虚拟化
根据实施例，I/O虚拟化(IOV)可以通过允许虚拟机(VM)访问底层物理资源来提供I/O的可用性。存储流量和服务器间通信的组合强加了可能淹没单个服务器的I/O资源的增加的负载，从而导致积压和由于处理器在等待数据而导致的空闲处理器。随着I/O请求数量的增加，IOV可以提供可用性；并且可以提高(虚拟化)I/O资源的性能、可伸缩性和灵活性，以匹配现代CPU虚拟化中所看到的性能水平。
根据实施例，IOV是期望的，因为它可以允许共享I/O资源并且提供VM对资源的受保护的访问。IOV将暴露于VM的逻辑设备与其物理实现分离。当前，可以存在不同类型的IOV技术，诸如仿真、半虚拟化、直接分配(DA)和单根I/O虚拟化(SR-IOV)。
根据实施例，一种类型的IOV技术是软件仿真。软件仿真可以允许分离的前端/后端软件体系架构。前端可以是置于VM中、与由管理程序实现的以提供I/O访问的后端通信的设备驱动程序。物理设备共享比高，并且VM的实时迁移可能只需几毫秒的网络停机时间。但是，软件仿真引入了附加的、非期望的计算开销。
根据实施例，另一种类型的IOV技术是直接设备分配。直接设备分配涉及将I/O设备耦合到VM，其中在VM之间没有设备共享。直接分配或设备直通以最小的开销提供接近本地性能。物理设备绕过管理程序并且直接附连到VM。但是，这种直接设备分配的缺点是有限的可伸缩性，因为在虚拟机之间不存在共享—一个物理网卡与一个VM耦合。
根据实施例，单根IOV(SR-IOV)可以允许物理设备通过硬件虚拟化表现为相同设备的多个独立的轻量级实例。这些实例可以被分配给VM作为直通设备，并作为虚拟功能(VF)被访问。管理程序通过唯一的(每设备)、全特征物理功能(PF)访问设备。SR-IOV使纯直接分配的可伸缩性问题变得容易。但是，SR-IOV呈现出的问题是它可能会影响VM迁移。在这些IOV技术中，SR-IOV可以扩展PCI Express(PCIe)规范，其意味着允许从多个VM直接访问单个物理设备，同时维持接近本地性能。因此，SR-IOV可以提供良好的性能和可伸缩性。
SR-IOV允许PCIe设备通过向每个客户分配一个虚拟设备来暴露可以在多个客户之间共享的多个虚拟设备。每个SR-IOV设备具有至少一个物理功能(PF)和一个或多个相关联的虚拟功能(VF)。PF是由虚拟机监视器(VMM)或管理程序控制的正常PCIe功能，而VF是轻量级的PCIe功能。每个VF都具有其自己的基地址(BAR)，并被分配有唯一的请求者ID，其使得I/O存储器管理单元(IOMMU)能够区分来自/去往不同VF的流量。IOMMU还在PF和VF之间应用存储器和中断转换。
但是，令人遗憾的是，直接设备分配技术在其中数据中心优化期望虚拟机的透明实时迁移的情况下对云提供商造成障碍。实时迁移的实质是将VM的存储器内容复制到远程管理程序。然后在源管理程序处暂停VM，并且在目的地处恢复VM的操作。当使用软件仿真方法时，网络接口是虚拟的，因此其内部状态被存储到存储器中并且也被复制。因此，可以使停机时间下降到几毫秒。
但是，当使用诸如SR-IOV的直接设备分配技术时，迁移变得更加困难。在这种情况下，网络接口的完整内部状态不能被复制，因为它与硬件绑定。作为替代，分配给VM的SR-IOV VF被分离，实时迁移将运行，并且新的VF将在目的地处被附连。在InfiniBand和SR-IOV的情况下，该处理会引入在秒的数量级上的停机时间。而且，在SR-IOV共享端口模型中，在迁移之后，VM的地址将改变，从而导致SM中的附加开销并对底层网络架构的性能产生负面影响。
InfiniBand SR-IOV体系架构-共享端口
可以存在不同类型的SR-IOV模型，例如，共享端口模型、虚拟交换机模型和虚拟端口模型。
图4示出了根据实施例的示例性共享端口体系架构。如图所示，主机300(例如，主机通道适配器)可以与管理程序310交互，管理程序310可以将各种虚拟功能330、340、350分配给多个虚拟机。同样，物理功能可以由管理程序310处理。
根据实施例，当使用诸如图4所示的共享端口体系架构时，主机(例如，HCA)在网络中出现为具有单个共享LID和在物理功能320和虚拟功能330、340、350之间的共享队列对(QP)空间的单个端口。但是，每个功能(即，物理功能和虚拟功能)可以具有其自己的GID。
如图4所示，根据实施例，可以将不同的GID分配给虚拟功能和物理功能，并且特殊队列对QP0和QP1(即，用于InfiniBand管理分组的专用队列对)由物理功能拥有。这些QP也被暴露给VF，但是VF不允许使用QP0(从VF到QP0的所有SMP都被丢弃)，并且QP1可以充当由PF拥有的实际QP1的代理。
根据实施例，共享端口体系架构可以允许不受(通过分配给虚拟功能附连到网络的)VM的数量限制的高度可伸缩的数据中心，因为LID空间仅被网络中的物理机器和交换机消耗。
但是，共享端口体系架构的缺点是无法提供透明的实时迁移，从而阻碍了灵活VM放置的可能性。由于每个LID与特定管理程序相关联，并且在驻留在管理程序上的所有VM之间共享，因此迁移的VM(即，迁移到目的地管理程序的虚拟机)必须将其LID改变为目的地管理程序的LID。此外，由于受限的QP0访问，子网管理器不能在VM内部运行。
InfiniBand SR-IOV体系架构模型-虚拟交换机(vSwitch)
图5示出了根据实施例的示例性vSwitch体系架构。如图所示，主机400(例如，主机通道适配器)可以与管理程序410交互，管理程序410可以将各种虚拟功能430、440、450分配给多个虚拟机。同样，物理功能可以由管理程序410处理。虚拟交换机415也可以由管理程序401处理。
根据实施例，在vSwitch体系架构中，每个虚拟功能430、440、450是完整的虚拟主机通道适配器(vHCA)，这意味着分配给VF的VM被分配完整的IB地址集合(例如，GID、GUID、LID)和硬件中的专用QP空间。对于网络的其余部分和SM，HCA 400看起来像经由虚拟交换机415、具有连接到它的附加节点的交换机。管理程序410可以使用PF 420，并且VM(附连到虚拟功能)使用VF。
根据实施例，vSwitch体系架构提供透明的虚拟化。但是，由于每个虚拟功能都被分配唯一的LID，因此可用LID的数量被迅速消耗。同样，在使用许多LID地址(即，每个物理功能和每个虚拟功能都有一个LID地址)的情况下，必须由SM计算更多的通信路径，并且必须将更多的子网管理分组(SMP)发送到交换机，以便更新其LFT。例如，通信路径的计算在大型网络中可能花费几分钟。因为LID空间限于49151个单播LID，并且由于每个VM(经由VF)、物理节点和交换机每个占用一个LID，因此网络中的物理节点和交换机的数量限制了活动VM的数量，反之亦然。
InfiniBand SR-IOV体系架构模型-虚拟端口(vPort)
图6示出了根据实施例的示例性vPort概念。如图所示，主机300(例如，主机通道适配器)可以与管理程序410交互，管理程序410可以将各种虚拟功能330、340、350分配给多个虚拟机。同样，物理功能可以由管理程序310来处理。
根据实施例，vPort概念被松散地定义以便赋予供应商实现的自由(例如，定义不规定实现必须是特定于SRIOV的)，并且vPort的目标是使VM在子网中的处理方式标准化。利用vPort概念，可以定义可在空间和性能域都更可伸缩的类似SR-IOV的共享端口和类似vSwitch的体系架构或两者的组合。vPort支持可选的LID，并且与共享端口不同，即使vPort不使用专用LID，SM也知道子网中可用的所有vPort。
InfiniBand SR-IOV体系架构模型-具有预填充LID的vSwitch
根据实施例，本公开提供了用于提供具有预填充的LID的vSwitch体系架构的系统和方法。
图7示出了根据实施例的具有预填充的LID的示例性vSwitch体系架构。如图所示，多个交换机501-504可以在网络交换环境600(例如，IB子网)内提供在架构(诸如InfiniBand架构)的成员之间的通信。架构可以包括多个硬件设备，诸如主机通道适配器510、520、530。主机通道适配器510、520、530中的每个又可以分别与管理程序511、521和531交互。每个管理程序又可以与其交互的主机通道适配器结合建立多个虚拟功能514、515、516、524、525、526、534、535、536并将它们分配给多个虚拟机。例如，虚拟机1 550可以由管理程序511分配给虚拟功能1 514。管理程序511可以附加地将虚拟机2 551分配给虚拟功能2 515，并且将虚拟机3 552分配给虚拟功能3 516。管理程序531又可以将虚拟机4 553分配给虚拟功能1534。管理程序可以通过主机通道适配器中的每一个上的全特征物理功能513、523、533访问主机通道适配器。
根据实施例，交换机501-504中的每一个可以包括多个端口(未示出)，这些端口用于设置线性转发表以便引导网络交换环境600内的流量。
根据实施例，虚拟交换机512、522和532可以由它们相应的管理程序511、521、531处理。在这样的vSwitch体系架构中，每个虚拟功能是完整的虚拟主机通道适配器(vHCA)，这意味着分配给VF的VM被分配完整的IB地址(例如，GID、GUID、LID)集合和硬件中专用的QP空间。对于网络的其余部分和SM(未示出)，HCA 510、520和530看起来像经由虚拟交换机、具有连接到它们的附加节点的交换机。
根据实施例，本公开提供了用于提供具有预填充的LID的vSwitch体系架构的系统和方法。参考图7，LID被预填充到各种物理功能513、523、533以及虚拟功能514-516、524-526、534-536(甚至那些当前未与活动虚拟机相关联的虚拟功能)。例如，物理功能513用LID1预填充，而虚拟功能1 534用LID 10预填充。当网络被引导时，LID在启用SR-IOVvSwitch的子网中被预填充。即使并非所有的VF都在网络中被VM占用，填充的VF也被分配有LID，如图7所示。
根据实施例，非常类似于物理主机通道适配器可以具有多于一个的端口(为了冗余两个端口是常见的)，虚拟HCA也可以用两个端口表示，并且经由一个、两个或更多个虚拟交换机连接到外部IB子网。
根据实施例，在具有预填充LID的vSwitch体系架构中，每个管理程序可以通过PF为自己消耗一个LID，并为每个附加的VF消耗再多一个LID。在IB子网中的所有管理程序中可用的所有VF的总和给出了允许在子网中运行的VM的最大数量。例如，在子网中每管理程序具有16个虚拟功能的IB子网中，那么每个管理程序在子网中消耗17个LID(16个虚拟功能中的每个虚拟功能一个LID加上用于物理功能的一个LID)。在这种IB子网中，对于单个子网的理论管理程序限制由可用单播LID的数量决定，并且是：2891个(49151个可用LID除以每管理程序17个LID)，并且VM的总数(即，极限)是46256个(2891个管理程序乘以每管理程序16个VF)。(实际上，这些数字实际上较小，因为IB子网中的每个交换机、路由器或专用SM节点也消耗LID)。注意的是，vSwitch不需要占用附加的LID，因为它可以与PF共享LID。
根据实施例，在具有预填充LID的vSwitch体系架构中，网络第一次被引导时，为所有LID计算通信路径。当需要启动新的VM时，系统不必在子网中添加新的LID，否则该动作将导致网络完全重新配置，包括路径重新计算，这是最耗时的部分。作为替代，在管理程序之一中定位用于VM的可用端口(即，可用的虚拟功能)，并且将虚拟机附连到可用的虚拟功能。
根据实施例，具有预填充LID的vSwitch体系架构还允许计算和使用不同路径以到达由同一管理程序托管的不同VM的能力。本质上，这允许这样的子网和网络使用类似LID掩码控制(LMC)的特征向一个物理机器提供替代路径，而不受需要LID必须是连续的LMC的限制约束。当需要迁移VM并将其相关联的LID携带到目的地时，能够自由使用非连续LID尤其有用。
根据实施例，以及以上示出的具有预填充LID的vSwitch体系架构的优点，可以考虑某些注意事项。例如，由于当网络被引导时，LID在启用SR-IOV vSwitch的子网中被预填充，因此初始路径计算(例如，在启动时)会比如果LID没有被预填充所花费的时间更长。
InfiniBand SR-IOV体系架构模型-具有动态LID分配的vSwitch
根据实施例，本公开提供了用于提供具有动态LID分配的vSwitch体系架构的系统和方法。
图8示出了根据实施例的具有动态LID分配的示例性vSwitch体系架构。如图所示，多个交换机501-504可以在网络交换环境700(例如，IB子网)内提供架构(诸如InfiniBand架构)的成员之间的通信。架构可以包括多个硬件设备，诸如主机通道适配器510、520、530。主机通道适配器510、520、530中的每一个又可以分别与管理程序511、521、531交互。每个管理程序又可以与其交互的主机通道适配器结合建立多个虚拟功能514、515、516、524、525、526、534、535、536并将它们分配给多个虚拟机。例如，虚拟机1 550可以由管理程序511分配给虚拟功能1 514。管理程序511可以附加地将虚拟机2 551分配给虚拟功能2 515，并且将虚拟机3 552分配给虚拟功能3 516。管理程序531又可以将虚拟机4 553分配给虚拟功能1534。管理程序可以通过主机通道适配器中的每一个上的全特征物理功能513、523、533访问主机通道适配器。
根据实施例，交换机501-504中的每一个可以包括多个端口(未示出)，这些端口用于设置线性转发表以便引导网络交换环境700内的流量。
根据实施例，虚拟交换机512、522和532可以由它们相应的管理程序511、521、531处理。在这样的vSwitch体系架构中，每个虚拟功能是完整的虚拟主机通道适配器(vHCA)，这意味着分配给VF的VM被分配完整的IB地址(例如，GID、GUID、LID)集合和硬件中专用的QP空间。对于网络的其余部分和SM(未示出)，HCA 510、520和530看起来像经由虚拟交换机、具有连接到它们的附加节点的交换机。
根据实施例，本公开提供了用于提供具有动态LID分配的vSwitch体系架构的系统和方法。参考图8，LID被动态分配给各种物理功能513、523、533，其中物理功能513接收LID1、物理功能523接收LID 2并且物理功能533接收LID 3。与活动虚拟机相关联的那些虚拟功能也可以接收动态分配的LID。例如，由于虚拟机1550是活动的并且与虚拟功能1 514相关联，因此虚拟功能514可以被分配LID 5。同样，虚拟功能2 515、虚拟功能3 516和虚拟功能1534每个与活动虚拟功能相关联。由此，这些虚拟功能被分配LID，其中LID 7被分配给虚拟功能2 515、LID 11被分配给虚拟功能3516、并且LID 9被分配给虚拟功能1 534。与具有预填充LID的vSwitch不同，那些当前未与活动虚拟机相关联的虚拟功能不接收LID分配。
根据实施例，利用动态LID分配，可以显著减少初始的路径计算。当网络第一次被引导并且不存在VM时，那么可以使用相对较少数量的LID用于初始的路径计算和LFT分发。
根据实施例，非常类似于物理主机通道适配器可以具有多于一个的端口(为了冗余两个端口是常见的)，虚拟HCA也可以用两个端口表示，并且经由一个、两个或更多个虚拟交换机连接到外部IB子网。
根据实施例，当在利用具有动态LID分配的vSwitch的系统中创建新的VM时，找到空闲的VM时隙，以便决定在哪个管理程序上引导新添加的VM，并且也找到唯一未使用的单播LID。但是，在网络中没有已知的路径和交换机的LFT用于处理新添加的LID。为了处理新添加的VM而计算一组新的路径在其中每分钟可以引导几个VM的动态环境中是非期望的。在大型IB子网中，计算一组新的路由会花费几分钟，并且这个过程将在每次引导新的VM时必须重复。
有利地，根据实施例，由于管理程序中的所有VF与PF共享相同的上行链路，因此不需要计算一组新的路由。只需要遍历网络中所有物理交换机的LFT、将转发端口从属于管理程序(其中创建VM)的PF的LID条目复制到新添加的LID、并且发送单个SMP以更新特定交换机的对应LFT块。因此，该系统和方法避免了计算一组新的路由的需要。
根据实施例，在具有动态LID分配体系架构的vSwitch中分配的LID不一定是连续的。当将具有预填充LID的vSwitch中的每个管理程序上的VM上分配的LID与具有动态LID分配的vSwitch进行比较时，应当注意的是，在动态LID分配体系架构中分配的LID是非连续的，而被预填充的那些LID本质上是连续的。在vSwitch动态LID分配体系架构中，当创建新的VM时，在VM的整个生命周期中使用下一个可用的LID。相反，在具有预填充LID的vSwitch中，每个VM都继承已经分配给对应VF的LID，并且在没有实时迁移的网络中，连续附连到给定VF的VM获得相同的LID。
根据实施例，具有动态LID分配体系架构的vSwitch可以以一些附加的网络和运行时SM开销为代价，利用预填充LID体系架构模型来解决vSwitch的缺点。每次创建VM时，子网中的物理交换机的LFT用与创建的VM相关联的新添加的LID进行更新。对于这个操作，需要发送每交换机一个子网管理分组(SMP)。因为每个VM正在使用与其主机管理程序相同的路径，因此类似LMC的功能也不可用。但是，对所有管理程序中存在的VF的总量没有限制，并且VF的数量可以超过单播LID限制的数量。当然，如果是这种情况，那么并不是所有VF都允许同时附连到活动VM上，但是，当操作接近单播LID极限时，具有更多的备用管理程序和VF增加了灾难恢复和分段网络优化的灵活性。
InfiniBand SR-IOV体系架构模型-具有动态LID分配和预填充LID的vSwitch
图9示出了根据实施例的具有动态LID分配和预填充LID的具有vSwitch的示例性vSwitch体系架构。如图所示，多个交换机501-504可以在网络交换环境800(例如，IB子网)内提供架构(诸如InfiniBand架构)的成员之间的通信。架构可以包括多个硬件设备，诸如主机通道适配器510、520、530。主机通道适配器510、520、530中的每一个又可以分别与管理程序511、521和531交互。每个管理程序又可以与其交互的主机通道适配器结合建立多个虚拟功能514、515、516、524、525、526、534、535、536并将它们分配给多个虚拟机。例如，虚拟机1 550可以由管理程序511分配给虚拟功能1 514。管理程序511可以附加地将虚拟机2 551分配给虚拟功能2515。管理程序521可以将虚拟机3 552分配给虚拟功能3 526。管理程序531又可以将虚拟机4 553分配给虚拟功能2 535。管理程序可以通过主机通道适配器的每一个上的全特征物理功能513、523、533访问主机通道适配器。
根据实施例，交换机501-504中的每一个可以包括多个端口(未示出)，这些端口用于设置线性转发表以便引导网络交换环境800内的流量。
根据实施例，虚拟交换机512、522和532可以由它们相应的管理程序511、521、531处理。在这样的vSwitch体系架构中，每个虚拟功能是完整的虚拟主机通道适配器(vHCA)，这意味着分配给VF的VM被分配完整的IB地址(例如，GID、GUID、LID)集合和硬件中专用的QP空间。对于网络的其余部分和SM(未示出)，HCA 510、520和530看起来像经由虚拟交换机、具有连接到它们的附加节点的交换机。
根据实施例，本公开提供了用于提供具有动态LID分配和预填充LID的混合vSwitch体系架构的系统和方法。参考图9，管理程序511可以用具有预填充LID体系架构的vSwitch进行布置，而管理程序521可以用具有预填充LID和动态LID分配的vSwitch进行布置。管理程序531可以用具有动态LID分配的vSwitch进行布置。因此，物理功能513和虚拟功能514-516使其LID被预填充(即，即使那些未附连到活动虚拟机的虚拟功能被分配了LID)。物理功能523和虚拟功能1 524可以使其LID被预填充，而虚拟功能2和3、525和526使其LID被动态分配(即，虚拟功能2 525可用于动态LID分配，并且由于虚拟机3 552被附连，因此虚拟功能3 526具有动态分配的LID 11)。最后，与管理程序3 531相关联的功能(物理功能和虚拟功能)可以使其LID被动态分配。这使得虚拟功能1和3、534和536可用于动态LID分配，而虚拟功能2 535由于虚拟机4 553被附连到那里因此具有动态分配的LID 9。
根据诸如图9所示、其中(在任何给定管理程序内独立地或组合地)利用了具有预填充LID的vSwitch和具有动态LID分配的vSwitch两者的实施例，每主机通道适配器的预填充LID的数量可以由架构管理员定义，并且可以在0<＝预填充的VF<＝总VF(每主机通道适配器)的范围内，并且可用于动态LID分配的VF可以通过从VF的总数(每主机通道适配器)减去预填充VF的数量找到。
根据实施例，非常类似于物理主机通道适配器可以具有多于一个的端口(为了冗余两个端口是常见的)，虚拟HCA也可以用两个端口表示，并且经由一个、两个或更多个虚拟交换机连接到外部IB子网。
InfiniBand-子网间通信(架构管理器)
根据实施例，除了在单个子网内提供InfiniBand架构之外，本公开的实施例还可以提供跨越两个或更多个子网的InfiniBand架构。
图10示出了根据实施例的示例性多子网InfiniBand架构。如图所示，在子网A1000内，多个交换机1001-1004可以在子网A1000(例如，IB子网)内提供架构(诸如InfiniBand架构)的成员之间的通信。架构可以包括多个硬件设备，诸如，例如通道适配器1010。主机通道适配器1010又可以与管理程序1011交互。管理程序又可以与其交互的主机通道适配器结合建立多个虚拟功能1014。管理程序可以附加地将虚拟机分配给每个虚拟功能，诸如虚拟机11015被分配给虚拟功能1 1014。管理程序可以通过主机通道适配器中的每一个上的全特征物理功能(诸如物理功能1013)访问其相关联的主机通道适配器。在子网B1040内，多个交换机1021-1024可以在子网B1040(例如，IB子网)内提供架构(诸如InfiniBand架构)的成员之间的通信。架构可以包括多个硬件设备，诸如，例如通道适配器1030。主机通道适配器1030又可以与管理程序1031交互。管理程序又可以与其交互的主机通道适配器建立多个虚拟功能1034。管理程序可以附加地将虚拟机分配给虚拟功能中的每一个，诸如虚拟机21035被分配给虚拟功能2 1034。管理程序可以通过主机通道适配器中的每一个上的全特征物理功能(诸如物理功能1033)访问其相关联的主机通道适配器。应当注意的是，虽然在每个子网(即，子网A和子网B)内仅示出了一个主机通道适配器，但是应该理解的是，每个子网内可以包括多个主机通道适配器及其对应的部件。
根据实施例，主机通道适配器中的每一个可以附加地与虚拟交换机(诸如虚拟交换机1012和虚拟交换机1032)相关联，并且每个HCA可以用不同的体系架构模型来建立，如上所述。虽然图10内的两个子网都被显示为使用具有预填充LID体系架构模型的vSwitch，但这并不意味着暗示所有此类子网配置都可以遵循相似的体系架构模型。
根据实施例，每个子网内的至少一个交换机可以与路由器相关联，诸如子网A1000内的交换机1002与路由器1005相关联，并且子网B1040内的交换机1021与路由器1006相关联。
根据实施例，至少一个设备(例如，交换机、节点等)可以与架构管理器(未示出)相关联。架构管理器可以用于例如发现子网间架构拓扑、创建架构简档(例如，虚拟机架构简档)、构建虚拟机相关的数据库对象，这些数据库对象形成用于构建虚拟机架构简档的基础。此外，架构管理器可以根据哪些子网被允许经由哪些路由器端口使用哪些分区号进行通信来定义合法的子网间连接性。
根据实施例，当始发源(诸如子网A内的虚拟机1)处的流量被寻址到不同子网(诸如子网B内的虚拟机2)中的目的地时，该流量可以被寻址到子网A内的路由器，即，路由器1005，路由器1005然后可以经由它与路由器1006的链路将流量传递到子网B。
虚拟双端口路由器
根据实施例，双端口路由器抽象可以提供一种简单的方式用于使得能够基于除了执行正常的基于LRH的交换之外还具有进行GRH(全局路由报头)到LRH(本地路由报头)转换能力的交换机硬件实现来定义子网到子网的路由器功能。
根据实施例，虚拟双端口路由器可以逻辑地连接在对应交换机端口的外部。这种虚拟双端口路由器可以向标准管理实体(诸如子网管理器)提供符合InfiniBand规范的视图。
根据实施例，双端口路由器模型意味着可以以其中每个子网完全控制分组的转发以及到子网的入口路径中的地址映射并且不影响任一不正确连接的子网内的路由和逻辑连接性的方式连接不同的子网。
根据实施例，在涉及不正确连接的架构的情况下，使用虚拟双端口路由器抽象还可以允许诸如子网管理器和IB诊断软件的管理实体在存在与远程子网的非预期的物理连接性时正确地表现。
图11示出了根据实施例的在高性能计算环境中的两个子网之间的互连。在利用虚拟双端口路由器进行配置之前，子网A1101中的交换机1120可以通过交换机1120的交换机端口1121经由物理连接1110连接到子网B1102中的交换机1130，该连接经由交换机1130的交换机端口1131。在这样的实施例中，每个交换机端口1121和1131即可以充当交换机端口又可以充当路由器端口。
根据实施例，这种配置的问题在于诸如InfiniBand子网中的子网管理器的管理实体不能区分既是交换机端口又是路由器端口的物理端口。在这种情况下，SM可以将交换机端口视为具有连接到该交换机端口的路由器端口。但是，如果交换机端口经由例如物理链路连接到具有另一个子网管理器的另一个子网，则子网管理器可以能够在物理链路上发送发现消息。但是，这样的发现消息不能在另一个子网上被允许。
图12示出了根据实施例的在高性能计算环境中经由双端口虚拟路由器配置的两个子网之间的互连。
根据实施例，在配置之后，可以提供双端口虚拟路由器配置，使得子网管理器看到正确的端节点，从而表明子网管理器负责的子网的端部。
根据实施例，在子网A1201中的交换机1220处，交换机端口可以经由虚拟链路1223连接(即，逻辑上连接)到虚拟路由器1210中的路由器端口1211。虚拟路由器1210(例如，双端口虚拟路由器)(当其在实施例中被示出为在交换机1220的外部时，其逻辑上可以被包含在交换机1220内)还可以包括第二路由器端口：路由器端口II 1212。根据实施例，可以具有两个端部的物理链路1203可以经由路由器端口II 1212和包含在子网B1202中的虚拟路由器1230中的路由器端口II 1232，经由物理链路的第一端将子网A1201经由物理链路的第二端与子网B1202连接。虚拟路由器1230可以附加地包括路由器端口1231，其可以经由虚拟链路1233连接(即，逻辑上连接)到交换机1240上的交换机端口1241。
根据实施例，子网A上的子网管理器(未示出)可以检测虚拟路由器1210上的路由器端口1211，作为子网管理器控制的子网的端点。双端口虚拟路由器抽象可以允许子网A上的子网管理器以通常的方式(例如，如按照InifiniBand规范所定义的方式)处理子网A。在子网管理代理级别，可以提供双端口虚拟路由器抽象，使得SM看到正常的交换机端口，并且然后在SMA级别，抽象出连接到交换机端口的另一个端口，并且这个端口是双端口虚拟路由器上的路由器端口。在本地SM中，可以继续使用常规的架构拓扑(SM将端口视为拓扑中的标准交换机端口)，并且因此SM将路由器端口视为端部端口。物理连接可以在两个交换机端口之间进行，这两个交换机端口也被配置为两个不同子网中的路由器端口。
根据实施例，双端口虚拟路由器还可以解决物理链路可能被错误地连接到相同子网中的某个其它交换机端口或者连接到不旨在提供到另一个子网的连接的交换机端口的问题。因此，本文描述的方法和系统还提供了关于子网外部的内容的表示。
根据实施例，在子网(诸如子网A)内，本地SM确定交换机端口，并且然后确定连接到该交换机端口的路由器端口(例如，经由虚拟链路1223连接到交换机端口1221的路由器端口1211)。由于SM将路由器端口1211视为SM管理的子网的端部，因此SM不能超过这个点(例如，向路由器端口II 1212)发送发现消息和/或管理消息。
根据实施例，上述双端口虚拟路由器提供的益处是双端口虚拟路由器抽象完全由双端口虚拟路由器所属的子网内的管理实体(例如，SM或SMA)管理。通过允许仅在本地侧进行管理，系统不必提供外部独立的管理实体。即，子网到子网连接的每一侧都可以负责配置其自己的双端口虚拟路由器。
根据实施例，在其中被寻址到远程目的地(即，在本地子网外部)的诸如SMP的分组到达未经由如上所述的双端口虚拟路由器配置的本地目标端口的情况下，那么本地端口可以返回指定它不是路由器端口的消息。
本发明的许多特征可以在硬件、软件、固件或其组合中、利用硬件、软件、固件或其组合、或者在硬件、软件、固件或其组合帮助下执行。因此，本发明的特征可以使用(例如，包括一个或多个处理器的)处理系统来实现。
图13示出了根据实施例的用于支持高性能计算环境中的双端口虚拟路由器的方法。在步骤1310处，该方法可以在包括一个或多个微处理器的一个或多个计算机处提供第一子网，第一子网包括：多个交换机，该多个交换机至少包括叶交换机，其中该多个交换机中的每个交换机包括多个交换机端口；多个主机通道适配器，每个主机通道适配器包括至少一个主机通道适配器端口；多个端节点，其中端节点中的每个端节点与多个主机通道适配器中的至少一个主机通道适配器相关联；以及子网管理器，该子网管理器在多个交换机和多个主机通道适配器中的一个上运行。
在步骤1320处，该方法可以将多个交换机中的交换机上的多个交换机端口中的交换机端口配置为路由器端口。
在步骤1330处，该方法可以将配置为路由器端口的交换机端口逻辑地连接到虚拟路由器，该虚拟路由器包括至少两个虚拟路由器端口。
多播通信
多播是将单个分组传递到多个目的地的能力。因此，多播可以简化网络架构的端节点之间的通信并提高其效率。多播是通过使用多播组来实现和管理的。支持多播的每个HCA、交换机或路由器可以参与零个、一个或多个多播组(即，成为其成员)。多播组可以由诸如子网管理器之类的管理实体进行管理。
多播组是端节点的集合，每个端节点接收发送到单个多播地址的多播分组。每个多播组与子网唯一多播LID(本文称为MLID)和全局唯一多播GID(本文称为MGID)相关联。多播组由其MGID定义，该MGID在组的创建时与该多播组相关联。多播组的MGID可以由子网管理器分配，或者它可以在组的创建时被提供给SM。MLID是在创建多播组时由SM指派或分配的。多个MGID可以与单个MLID相关联(即，多个多播组可以共享同一MLID)。但是，给定的MGID不能与同一子网上的多于一个MLID相关联。可以将关于多播组的MLID、MGID和其它详细信息(诸如作为多播组的成员的端口的LID和GID)存储在可由/用于子网管理(SA)访问的数据存储库中。
根据实施例，关于在本地子网中定义的多播组的信息可以被分发给子网中的交换机。每个交换机被配置有路由信息，该路由信息用于将接收到的多播分组的副本转发到一个或多个端口，使得接收到的多播分组的副本被转发到具有包含在多播组中(即，与多播组的MGID相关联)的与接收到的多播分组的MLID/MGID对应的LID的每个HCA端口。在一些情况下，多播分组将被复制并转发到端口，该端口将把副本直接发送到HCA端口，而在其它情况下，副本在到达HCA端口之前将需要被转发到另一个交换机。
SM可以生成单个生成树，该单个生成树包括多播组中应将多播分组传递到的所有端口。然后可以从生成树中得出子网中将要参与多播转发的每个交换机的多播转发表(MFT)。使用单个生成树得出交换机MFT可以确保不会将多播分组的重复副本转发到已处理该多播分组的副本的交换机。
多播分组是在其分组首部的DLID字段中包含MLID的分组。当交换机接收到多播分组时，交换机检查分组首部并提取DLID，以确定其是否与多播组对应。在确定DLID与多播组对应(即，DLID字段包含MLID)后，交换机复制分组并将其发出到与多播组相关联的MFT中指定的每个端口(到达端口除外)，该多播组与多播分组的MLID相关联。
图14示出了根据实施例的支持多播通信的示例性子网1400。子网A包含节点1401-1408。节点1401-1408分别包括HCA 1409-1416。HCA 1409-1416各自分别包括端口—端口1417-1424。端口1417-1424经由链路1425-1432连接到交换机1450-1453。例如，端口1417经由链路1425连接到交换机1450；端口1418经由链路1426连接到交换机1450；端口1419经由链路1427连接到交换机1451；等等。
子网1400包括SM/SA 1460。虽然为简单起见并根据不同的实施例在图15中被描绘为单独的实体，但是应该理解的是，SM/SA 1460可以被部署为交换机1450-1453中的任何一个、节点1401-1408中的任何一个的部件，或者被部署为未示出的另一个IB设备的部件。多播组(MCG)1465由SM/SA 1460定义。MCG 1465用点划线以框图形式绘出。其它端口1417-1419和端口1421-1423也用点划线绘出，以指示它们是MCG 1465的成员。相反，端口1420和1424用实线以框图形式绘出，以指示它们不是MCG 1465的成员。
交换机1450经由链路1440互连至交换机1453，并且经由链路1442互连至交换机1452。同样地，交换机1451经由链路1441互连至交换机1452，并且经由链路1443互连至交换机1453。
根据实施例，如果端口1421在网络上发送包括定义MCG 1465的MGID在内的多播分组，则端口1417-1419以及端口1422和1423中的每一个将由于是MCG 1465的成员而接收由端口1421发送的多播分组的副本。
图15示出了根据实施例的由SM/SA用于管理多播组的示例性SA数据存储库。数据存储库1500在关系数据库图中被描绘为表，因为这样的图显示了相关部件之间的关系。但是，图15旨在说明多播组部件之间的关系以及此类部件之间的关联映射，并非旨在进行限制。允许在相关部件之间进行适当的关联映射的任何合适的数据结构都可以提供实施例。实际上，IB规范未定义SA和任何SA数据存储库的特定实现。
如图15所示，SA数据存储库1500可以包括MCG表1540和LID表1544。MCG表1540可以包括关于在本地子网中定义的MCG的信息，包括本地子网中的每个定义的MCG的MGID和对应的MLID。LID表1544可以包括关于子网中的LID的信息，诸如每个LID被分配给的端口的对应GUID。可以配置关系，使得查询可以返回显示与给定MGID相关联的每个LID(分配给端端口)的数据(即，作为由给定MGID定义的MCG的成员的每个端口)。
例如，并且根据实施例，可以利用映射表将本地子网中的LID映射到与LID相关联的多播组的MGID。继续参考图15，可以在例如映射表MCG_LID 1542中映射MCG和LID数据，其中可以将分配给本地子网中的端端口的LID映射到一个或多个MGID。根据实施例，表1540和1542可以经由关系1550相关，并且表1542和1544可以经由关系1552相关。在有这样的关系的情况下，SM可以经由数据存储库的查询来确定哪些LID与哪些MGID相关联(即，哪些端口是哪些多播组的成员)。
如上所述，为了高效地将每个多播分组的单个副本转发给所有多播组成员，SM可以通过子网拓扑确定单个生成树路由。根据实施例，图16示出了可以经由子网1600中的生成树算法确定的示例性路由。如前所述，多播组(MCG)1665由SM/SA 1660定义。MCG 1665用点划线以框图的形式绘出。其它端口1617-1619和端口1621-1623也用点划线绘出，以指示它们是MCG 1665的成员。在图16中，生成树中包含的用于多播流量的服务交付的链路也用点划线绘出，而从生成树中排除的链路用实线格式绘出。
根据实施例，SM 1660可以确定哪些端端口是MCG 1665的成员。使用确定的端端口，SM 1660可以确定生成树，该生成树确保注入到子网中的多播分组的仅单个副本将被传递到作为MCG 1665的成员的每个端端口。例如，链路1642、1640和1643可以被包括在生成树中，而链路1641不需要被包括在内。包括链路1642、1640和1643可以确保无论哪个端端口把多播分组注入到子网中，该多播分组都只有一个副本将被传递到作为MCG 1665的成员的每个端端口。
例如，如果端口1621将多播分组注入到子网中，则它将由交换机1652接收。然后，交换机1652可以将多播分组的副本转发到生成树中指定的每条链路(在其上接收多播分组的链路除外)。因此，交换机1652可以将接收到的多播分组的副本转发到链路1642和1630(并且排除链路1629，因为该多播分组是在这条链路上接收到的)。在这种情况下，端口1622将经由链路1630接收(仅)它的多播分组的副本，并且交换机1650将经由链路1642接收副本。从这里，交换机1650也可以将从链路1642接收到的多播分组的副本转发到链路1625、1626和1640(并且排除链路1642)。因此，端口1617和1618将分别经由链路1625和1626接收(仅)它们的多播分组的相应副本，并且交换机1653将经由链路1640接收副本。这种模式可以继续，直到所有端端口都经由通过SM确定的生成树路由接收到多播分组的一个且仅一个副本。
根据实施例，一旦SM已经确定用于多播流量的单个生成树路由，SM就可以为作为生成树路由的一部分的每个交换机确定多播转发表(MFT)。图17示出了交换机1750-1753的详细视图，其中包括链路1725-1732和链路1740-43连接到的交换机链路端口。如图17所示，链路1725-1732被分别连接到交换机端口1733-1740。同样地，链路1740-1743一端分别连接到端口1760-1763并且另一端分别连接到交换机端口1764-1767。与先前的图一致，连接到SM 1765(未示出)的生成树路由中包含的链路的交换机端口用点划线绘出，而连接到生成树中排除的链路的端口用实线格式绘出。
在确定交换机的MFT时，SM可以确定给定交换机的连接到生成树路由中所包含的用于传递多播流量的链路的每个端口。作为示例，参考图17，交换机1750的MFT可以包括链路1733、1734、1760和1762，这是因为，为了确保作为MCG 1765的成员的每个端端口都接收到多播分组的副本，接收到的多播分组的副本必须从这些端口中的每个端口(接收链路的端口除外)被转发。关于交换机1751，端口1735和1763将被包含在交换机1751的MFT条目中，而端口1736和1761将被排除在MFT条目之外。MFT通过MLID进行索引，并且特定MFT条目包含与MLID关联的生成树对应的端口向量。
图18图示了根据实施例的用于向多播组的成员提供多播分组传递的方法的流程图。在步骤1810处，子网管理器可以确定作为多播组的成员的每个端端口。在步骤1820处，子网管理器可以确定将把多播分组的副本传递给作为多播组的成员的每个端端口的单个生成树。在步骤1830处，子网管理器可以确定如由生成树所确定的本地子网中将转发多播流量的每个交换机的多播转发表。在步骤1840处，SM可以用为每个相应交换机确定的转发表来更新将转发多播流量的每个交换机。
用于减少SA访问的需求的同构架构属性
InfiniBand(IB)规范定义的子网管理器(SM)和子网管理员(SA)提供了集中式的方式来执行IB子网发现和初始化以及查找和注册服务。
用于IB客户端和SA之间的通信的协议被设计为允许SA和IB客户端都代表最小特征IB端端口实现。因此，根据规范，仅256字节的UD(不可靠的数据报)分组用于实现协议。
根据实施例，子网管理器(SM)可以负责建立/定义通过相应子网的路径。它经由可以例如设置交换机转发表(线性转发表)、LID等的子网管理分组(SMP)来这样做。子网管理员(SA)可以负责使用GMP(通用管理分组)响应路径解析请求。例如，在请求路径记录时，SA可以响应，可以包括本地路由首部(DLID、SLID、SL)、全局首部(DGID、SGID)和其它特性，诸如MTU、速率、等待时间、P_Key...等等。
为了确保通信参数与相关的IB架构和对等节点能力以及相关联的管理策略一致，期望IB客户端从SA获得路径记录，以便既获得相关的L2地址信息(LID)又获得通信参数，诸如最大MTU(最大传输单位)、最大速率和服务级别(SL)。
虽然只要相关对等节点可达并且由相同的主SM/SA实例负责子网，就可以预期由客户端从SA获得的路径记录和其它信息保持不变，但是通常每当新的主SM/SA实例变为活动时，都需要刷新任何高速缓存的信息。
在多播组成员资格的情况下，由于新的SM可能向MLID映射分配新的MGID，因此每当新的主SM/SA活动时，固有地需要(重新)加入任何多播成员资格。
在某些实施例中，在对主SM/SA进行任何改变时，IB客户端有可能高速缓存路径记录和多播组成员资格信息，IB客户端有可能乐观地在主SM/SA的整个改变期间高速缓存路径记录和多播组信息。但是，在多播成员资格的情况下，由于各种竞争条件，可能无法直截了当地选出高速缓存信息不再有效的异常情况。
在基于SRIOV的VM部署中，只要每个此类VM执行与物理服务器类似的SA请求类型(例如，路径记录查询)，SA请求流量的问题就会被放大。即，在虚拟化环境中，每个客户端可以包括单个充当系统中的端节点的虚拟机(即，在非SRIOV环境中充当物理服务器)，这在传统上将需要此类SA请求的情况下会极大地增加经由SA请求到SA的流量。
对于能力较差的SM/SA实现，诸如基于连接到交换机管理接口的低性能处理器模块的实现，即使SA请求负载的适度增加也会导致两个SM以及整个系统的严重开销和降低的转发进度。
对于快速故障转移和恢复至关重要的高可用性(HA)系统，任何延迟都成问题。例如，当以亚秒级故障转移时间为目标时，重要的是，只要节点之间的物理连接没有损失，可操作的计算节点就可以继续正常操作并与其它可操作的节点进行通信，而不会发生任何中断。因此，期望所有节点可以继续将现有地址和路径信息用于单播和多播流量，而无需与SA进行交互，并且只有当由于架构内的链路故障而导致SM需要执行重新路由或重新初始化时，才发生连接的中断。
此外，即使对于基于具有完全成熟的HCA的高端服务器的SM/SA实现，将256字节的MAD(管理数据报)用于SA通信也会严重限制性能和可伸缩性。在这种情况下，即使利用最佳高速缓存和极高的性能用于SA请求处理，向新的主SM重新注册多播成员资格的需求也会意味着不必要地中断由可操作的交换机和链路连接的可操作节点之间的连接。
有两个与优化IB客户端和SM/SA基础设施之间的交互相关的主要目标。对于具有嵌入式(低端)SM/SA实现的交换机的中小型系统，目标是尽量使SM能够尽可能快地发现和初始化子网，而不需要服务SA请求或以其它方式与IB客户端(诸如物理服务器或虚拟机)进行通信(即，超出SMA级别的发现和初始化操作)。对于具有高端SM/SA实现的大型系统，目标是SM/SA应该能够以利用最佳IB通信机制的方式向IB客户端分发相关信息，并且还提供具有分层实现的能力，该分层实现提供了可伸缩性并且防止甚至在非常大的集群域中的大规模多播风暴。
根据实施例，默认情况下，每个IB客户端可以请求SA获取路径记录，该路径记录描述了如何按照允许的速率、MTU、SL、分区、LID等与远程端端口进行通信。
根据实施例，在一些IB架构配置中，参数中没有与远程端口的身份无关的变量。替代地，可以存在可以被所有节点使用的明确定义的公共最大值，或者可以以允许节点对交换和就相关的最大值达成一致的方式构造架构，而无需考虑任何中间架构连接，从而还避免了请求SA来获得此类参数的需要。
根据实施例，可以指定客户端节点应该以上述方式表现。但是，这可能容易出错，并且意味着违反相关前提条件的架构更改可能不会被动态检测到。
根据实施例，可以引入每个端口的SMA级别属性(例如，“同构架构”二进制标志属性)。这样的属性可以允许子网管理器在客户端端口级别动态维护向相关联的客户端指示关于是否可以使用简化方案以及相对于本地端口参数有哪些约束(如果有的话)的信息。使用常规的端口级别事件，也可以异步地向IB客户端通知动态变化。
根据实施例，当工程设计系统(ES)私有架构基于同构HCA和交换能力并且使用规则的胖树拓扑时，那么通常没有必须由SM/SA定义以便确保在正常情况下使用正确的路径参数的路径属性。例如，可以通过本地HCA端口的能力来定义一组支持的数据速率、MTU和SL，并且用于通信的相关分区将通过本地HCA的分区设置来定义。
根据实施例，ES私有架构的该方面可以是用于在相关ES主机节点上使用的主机栈的配置参数。但是，下面是可以独立于任何特殊系统配置使用的更灵活的方案。
根据实施例，当SM确定架构中的所有主机节点以及连接主机节点的交换机和交换机端口都支持相同的能力时，则可以为系统中的各种HCA端口设置指定该条件的特殊SMA标志属性(例如“同构架构”属性标志)。(HCA端口也可以首先包括指示对该属性的支持的能力标志)。
根据实施例，该标志可以附加地被包括作为端口当前被设置为其成员的每个分区的附加属性。
根据实施例，为了提高方案的灵活性，可以将这样的属性扩展为包括所有路径属性(全局或每个分区)的最大值，使得SM然后还可以以这样的方式处理非同构的情况，即，即使不同主机节点的最大能力可能不同，也允许主机节点使用由所有对等方支持的值。以这种方式，主机节点将能够仅基于本地端口信息而无需执行SA查询来确定与远程对等方的身份和地址无关的所有路径信息。
根据实施例，配置参数和/或新的SMA属性的替代方案将是引入新型的SA查询，其中端节点将能够在每个子网或分区的基础上使用每个节点的单个或仅几个SA请求来获得“默认最大路径参数”。尽管如此，在拥有大量节点的情况下，这仍然将是启动时的巨大负担。
根据实施例，可以包括多个附加的SMA/PortInfo属性。
根据实施例，可以支持用于支持“同构架构属性”的端口能力。该属性的默认值为假(false)。可以在链路工作时由支持SMA将其设置为真(true)。当被设置为真时，支持主SM可以更新相关的SMA特性。
根据实施例，可以支持“HomogeneousSubnet”标志。该标志的默认值可以为假。如果本地子网中所有可能从该本地端口可见的端端口都具有相同的路径特性并且所有中间链路支持相同的特性，则该标志可以由支持主SM设置。当被设置为真时，本地IB客户端可以安全地从本地端口特性得出相关的路径特性。
根据实施例，可以支持“SemiHomogeneousSubnet”标志。该标志的默认值可以为假。如果中间链路始终支持与本地端口所支持的值和本地子网内从本地端口可见的任何对等端口所支持的值之间的最小值相同的路径特性，则该标志可以由支持主SM设置。当该标志的值被设置为真时，本地端口可以基于与相关对等端口的直接协商来确定路径特性。
根据实施例，可以支持有效标志(真/假)、MTU(合法MTU值)、速率(合法速率值)的“SubnetGlobalMinimalPathParameters”记录。其可以由支持主SM设置为本地子网中可能从该本地端口可见的任何端端口以及任何中间链路所支持的最小值。当被设置为真时，本地IB客户端可以选择将这些路径特性用于本地子网内的任何通信。
根据实施例，可以支持“HomogeneousFabric”标志：该标志的默认值可以为假。如果所有可能从本地端口可见的端端口具有相同的路径特性并且所有中间链路支持相同的特性，则该标志可以由支持主SM设置。当被设置为真时，本地IB客户端可以安全地从本地端口特性得出所有路径特性。
根据实施例，可以支持“SemiHomogeneousFabric”标志。该标志的默认值可以为假。如果中间链路始终支持与本地端口所支持的值和从本地端口可见的任何对等端口所支持的值之间的最小值相同的路径特性，则该标志可以由支持主SM设置。当被设置为真时，本地IB客户端可以基于与相关对等端口的直接协商来确定路径特性。
根据实施例，可以支持“FabricGlobalMinimalPathParameters”-有效标志(真/假)、MTU(合法MTU值)、速率(合法速率值)的记录。其可以由支持主SM设置为可能从该本地端口可见的任何端端口以及任何中间链路所支持的最小值。当被设置为真时，本地IB客户端可以选择将这些路径特性用于任何通信。
图19图示了根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的系统。
根据实施例，图19示出了简化的InfiniBand架构，其包括多个节点，节点A-节点E，1910-1914，这些节点经由主机通道适配器1920-1924(分别)通过InfiniBand架构1900互连，InfiniBand架构1900包括多个交换机1902，以及子网管理器/子网管理员1901。
根据实施例，子网管理器/子网管理员1901可以确定多个主机(例如，节点A-E)和多个交换机1902支持相同的能力集合。在确定多个主机和多个交换机支持相同的能力集合之后，子网管理器配置SMA标志，诸如标志A(在该图中示出为包含标志A的圆圈)，该标志指示可以为每个主机通道适配器端口设置条件。标志A可以包括一个或多个属性，诸如如上所述的同构架构属性。可以将标志A的默认值设置为假，在确定各个端口支持相同的能力集合后，该默认值可以由SA/SM更改为真。
根据实施例，SA/SM可以确定在IB架构内的不同端口之间以及在HCA端口处相同的能力集合。能力集合可以包括但不限于支持的数据速率集合、MTU(最大传输单位)、支持的链路宽度、支持的链路速度和支持的扩展链路速度。(注意的是，在实施例中，不同链路速度和宽度的组合可以表示相同的数据速率)。因此，从路径信息的角度来看，仅速率是相关的。但是，SM必须将所有速度和宽度的组合进行关联，以确定相关的速率集合)。
根据实施例，标志A可以反映/包括可以被支持的用于支持“同构架构属性”的端口能力。在这种情况下，标志A的默认值为假。可以在链路工作时由支持SMA将其设置为真。当被设置为真时，支持主SM可以更新相关的SMA特性。
根据实施例，标志A可以反映/包括“HomogeneousSubnet”标志。该标志的默认值可以为假。如果本地子网中所有可能从本地端口可见的端端口都具有相同的路径特性(例如，MTU、所支持的数据速率)并且所有中间链路支持相同的特性，则该标志可以由支持主SM设置。当被设置为真时，本地IB客户端可以安全地从本地端口特性中得出相关路径特性，对SA的请求比传统的IB架构要少。
根据实施例，标志A可以反映/包括“SemiHomogeneousSubnet”标志。该标志的默认值可以为假。如果端节点(本地端口和远程端口)之间的中间链路支持与本地端口所支持的值和本地子网内从本地端口可见的任何对等端口所支持的值之间的最小值相同的路径特性，则该标志可以由支持主SM设置。当标记的值被设置为真时，本地端口可以基于与相关远程端口的直接协商来确定路径特性。
根据实施例，标志A可以反映/包括有效标志(真/假)、MTU(合法MTU值)、速率(合法速率值)的“SubnetGlobalMinimalPathParameters”记录。其可以由支持主SM设置为本地子网中可能从该本地端口可见的任何端端口以及任何中间链路所支持的最小值。当被设置为真时，本地IB客户端可以选择将这些路径特性用于本地子网内的任何通信。
根据实施例，标志A可以反映/包括“HomogeneousFabric”标志：该标志的默认值可以为假。如果所有可能从本地端口可见的端端口(包括本地端口子网外部的那些端端口)具有相同的路径特性并且所有中间链路支持相同的特性，则该标志可以由支持主SM设置。当被设置为真时，本地IB客户端可以安全地从本地端口特性得出所有路径特性。
根据实施例，标志A可以反映/包括“SemiHomogeneousFabric”标志。该标志的默认值可以为假。如果中间链路始终支持与本地端口所支持的值和从本地端口可见的任何对等端口所支持的值之间的最小值相同的路径特性，则该标志可以由支持主SM设置。当被设置为真时，本地IB客户端可以基于与相关对等端口的直接协商来确定路径特性。
根据实施例，标志A可以反映/包括“FabricGlobalMinimalPathParameters”标志。该标志可以包括有效标志(真/假)、MTU(合法MTU值)、速率(合法速率值)的记录。其可以由支持主SM设置为可能从该本地端口可见的任何端端口以及任何中间链路所支持的最小值。当被设置为真时，本地IB客户端可以选择将这些路径特性用于任何通信。
图20图示了根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的系统。
更特别地，该图图示了包括多个节点的示例性子网，该多个节点包括节点1 2010、节点2 2020和节点3 2030，其中每个节点都经由主机通道适配器(即，HCA 1 2011、HCA 22021和HCA 3 2031)连接到交换架构。节点经由相应的HCA经由多个交换机(诸如交换机12040和交换机2 2041)互连。
根据实施例，子网的每个成员(HCA和交换机)都可以包含相同的“类型”—这意味着这些子网成员中的每个子网成员上的每个端口支持相同的能力，例如，支持的数据速率、MTU(最大传输单位)、支持的链路宽度、支持的链路速度和支持的扩展链路速度。
图21图示了根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的系统。
更特别地，该图图示了包括多个节点的示例性子网，该多个节点包括节点1 2110、节点2 2120和节点3 2130，其中每个节点都经由主机通道适配器(即，HCA 1 2111、HCA 22121和HCA 3 2131)连接到交换架构。节点经由相应的HCA经由多个交换机(诸如交换机12140和交换机2 2141)互连。
根据实施例，子网的不同成员(HCA和交换机)可以包括不同的“类型”—这意味着相同类型的子网的那些成员支持相同的能力集合，而不同类型的成员不支持相同的能力集合。
例如，该图中的类型A的交换机的主机通道适配器支持第一最大数据速率和第一最大传输单元，并且类型B的主机通道适配器和交换机支持相同的第一最大数据速率，但是支持不同的第二最大传输单位。在这种情况下，如果端节点(本地端口和远程端口)之间的中间链路支持与本地端口所支持的值和本地子网内从本地端口可见的任何对等端口所支持的值之间的最小值相同的路径特性，则标志-“SemiHomogeneousSubnet”标志可以由子网管理器设置。当该标志的值被设置为真时，本地端口可以基于与相关远程端口的直接协商来确定路径特性。
图22图示了根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的系统。
更特别地，该图图示了包括多个节点的示例性子网，该多个节点包括节点1 2210、节点2 2220、节点3 2230、节点4 2215、节点52225和节点6 2235，其中每个节点都经由主机通道适配器(即，HCA 1 2211、HCA 2 2221和HCA 3 2231、HCA 4 2216、HCA 52226和HCA 62236)连接到交换架构。节点经由相应的HCA经由多个交换机(诸如交换机1 2240、交换机22241、交换机3 2242、交换机4 2243、交换机5 2244和交换机6 2245)互连。
根据实施例，交换机可以被布置为多个级别。这里，交换机被步骤为两个级别，其中级别0包括交换机1至4，并且级别1包括交换机5-6。
根据实施例，子网的不同成员(HCA和交换机)可以包括不同的“类型”—这意味着相同类型的子网的那些成员支持相同的能力集合，而不同类型的成员不支持相同的能力集合。例如，“类型B”的交换机和HCA可以具有比“类型A”的交换机和HCA更多的能力(即，能够支持更大的MTU、最大数据速率、链路宽度等等)。
根据实施例，然后，子网管理器可以沿着多条不同的路径前进。
在实施例中，子网管理器可以决定“类型B”的所有交换机和HCA属于单个子网，而属于“类型A”的那些交换机和HCA属于不同的子网。然后，SM可以用HomogenousSubnet标志标记“子网B”中的每个端口，并且同样地标记“子网A”中的每个端口。
在实施例中，子网管理器可以设置“SemiHomogeneousSubnet”标志，因为端节点(本地端口和远程端口)之间的中间链路支持与本地端口所支持的值和本地子网内从本地端口可见的任何对等端口所支持的值之间的最小值相同的路径特性。当该标志的值被设置为真时，本地端口可以基于与相关远程端口的直接协商来确定路径特性。
根据实施例，子网管理器可以设置可以被支持的有效标志(真/假)、MTU(合法MTU值)、速率(合法速率值)的“SubnetGlobalMinimalPathParameters”记录。其可以由支持主SM设置为本地子网中可能从本地端口可见的任何端端口以及任何中间链路所支持的最小值。当被设置为真时，本地IB客户端可以选择将这些路径特性用于本地子网内的任何通信。
图23是根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的方法的流程图。
根据实施例，在步骤2301处，该方法可以开始并执行架构发现。
根据实施例，在步骤2302处，该方法可以确定子网/架构中的所有HCA是否具有相同的最大能力，以及是否所有交换机也至少支持那些能力。
根据实施例，在步骤2303处，该方法可以确定在HCA和交换机两者中是否都支持相同的最大能力。
根据实施例，在步骤2304处，如果在HCA和交换机两者中都支持相同的最大能力，则可以初始化架构并反映所有端节点(至少所有支持这种新属性的端节点)的“同构架构”(或者如果SM仅查看子网的话，则为同构子网属性)。
根据实施例，在步骤2305处，如果不支持相同的最大能力，则该方法可以确定是否所有相同类型的HCA都可以经由支持相同最大能力的交换机与相同类型的所有其它HCA进行通信。
根据实施例，在步骤2306处，该方法可以确定在相同类型的HCA之间是否支持这种相同的最大路径能力。
根据实施例，在步骤2307处，如果在相同类型的HCA之间支持这种相同的最大路径能力，则可以初始化架构并反映所有端节点(至少所有支持这种新属性的端节点)的“半同构架构”。
根据实施例，在步骤2308处，如果在相同类型的HCA之间不支持这种相同的最大路径能力，则可以初始化架构并反映所有端节点(至少所有支持这种新属性的端节点)的“全局最小路径参数”。
图24是根据实施例的用于支持高性能计算环境中的同构架构属性以减少对SA访问的需求的方法的流程图。
在步骤2410处，该方法可以在一个或多个微处理器处提供第一子网，该第一子网包括：多个交换机，一个或多个交换机至少包括叶交换机，其中多个交换机中的每个交换机包括多个交换机端口中的至少一个交换机端口；多个主机通道适配器，其中主机通道适配器中的每个主机通道适配器包括多个主机通道适配器端口中的至少一个主机通道适配器端口，并且其中多个主机通道适配器经由多个交换机互连；以及子网管理器，该子网管理器在多个交换机和多个主机通道适配器中的一个上运行。
在步骤2420处，该方法可以由子网管理器确定多个主机通道适配器端口的集合和多个交换机的集合支持相同的能力集合。
在步骤2430处，该方法可以在所述确定后由子网管理器配置SMA(子网管理代理)标志，该标志指示可以为多个主机通道适配器端口的集合设置条件。
基于同构架构属性从ARP响应和对等协商得出的路径记录
根据实施例，只要特定于IB的身份信息的确定是基于如ARP(地址解析协议)的基于广播的查询机制，那么每当接收到同时包含源GID和源LID的任何IB多播消息，特定于远程端口的IB地址信息就被很好地定义。
根据实施例，该特定于远程端口的信息然后可以与由“同构架构”属性/标志定义的信息组合，以形成该远程端口的完整路径记录。
根据实施例，“同构架构”标志属性本身或附加属性可以用于指定所有源IB地址在它们在建立通信时可以被用作目的地地址的意义上是可逆的。
此外，根据实施例，基于多播的地址解析协议以及基于单播的通信管理协议都可以用于表示特定于端口的路径参数，该参数可以用于增强由“同构架构”属性定义的信息。
根据实施例，除了上面讨论的路径信息之外，由SA路径记录定义的附加信息就GID而言是相关对等端口的身份，并且就LID而言，是子网本地地址。
根据实施例，在基于通用RDMA CM(连接管理器)的连接的情况下，地址解析是基于分区的范围内的IP地址，并且IP地址到GID的映射是经由基于广播的ARP协议定义的。
根据实施例，在单个子网内，只要每个HCA端口具有所分配的单个LID，则对等HCA端口的子网本地目的地LID地址将基于初始ARP请求多播分组以及对应的ARP响应单播分组两者中的源LID地址被很好地定义。
根据实施例，基于用来自上面定义的同构架构/子网标志(或配置参数)的值定义的路径记录参数以及由IPoIB ARP请求和响应定义的GID和SLID信息的组合，通常不另外需要SA请求来获得路径记录或与路径相关的信息。
根据实施例，在多子网架构的情况下，GID信息仍然由IPoIB ARP协议很好地定义。但是，封装IB分组中的SLID信息将不再定义原始发送者，而是定义分组在入口路径中被转发到本地子网的IB-IB路由器端口的LID。-这既适用于原始多播请求又适用于随后的单播响应。
根据实施例，仍然，只要整个子网间路由允许跨子网边界的可逆路径，那么将路由器SLID用作单播流量的DLID仍将提供完整的路径记录信息以及来自同构架构标志的信息。然后，需要在各个连接的子网中的SM之间同步同构架构标志。
根据实施例，可以扩展IPoIB ARP协议(或RDMA CM协议)以包括本地同构架构属性，以便允许对等节点协商并商定会超出“全局”最大值的相互参数值。特别地，这将允许具有不同速度接口的节点的不同“子架构”(例如，基于QDR(四倍数据速率)的子架构与基于EDR(增强数据速率)或HDR(高数据速率)的子架构的组合，其中具有相同较高速度的节点的连接将始终只能通过支持该较高速度的交换机/路由器进行)。
根据实施例，可以定义各种PortInfo属性。
根据实施例，一个这样的属性可以是“AllSubnetLocalChannelAdapterLIDsUsable”标志。该标志可以是真/假标志，默认情况下被设置为假。如果与本地子网内可能从本地端口可见的任何CA(通道适配器)端口相关联的所有LID都表示有效的DLID，则该标志可以由支持主SM设置。当为真时，本地IB客户端可以使用从本地子网中的远程CA端口接收到的任何源LID作为当与远程CA端口通信时的目的地LID。
根据实施例，一个这样的属性可以是“RouterSourceLIDsReversible”标志。该标志可以是真/假标志，默认情况下被设置为假。如果当从远程子网中的端端口转发分组时由本地子网中的路由器端口生成的所有源LID都可以用于到达远程子网中的相关端端口，则该标志可以由支持主SM设置。当为真时，本地IB客户端可以使用从远程子网中的CA端口接收到的任何分组中的源LID作为当与远程CA端口通信时的目的地LID。
根据实施例，可以提供各种新定义的通信管理协议添加。
根据实施例，一种这样的方法可以是“PortAndNodeAttributeRequestMessage”，一种新的通信管理(CM)方法(消息类型)。该消息包含发送端口表示的最大路径参数(速率、MTU等)，以及关于发送端口的附加信息(也可以包括特定于平台的信息)。在发起到LID已知的远程端口的其它通信之前，该方法可以用作SA路径请求的基于对等的替换。与对SA的路径查询一样，只要远程端口仍然可用，就可以跨多个连接高速缓存和重用接收到的信息。
根据实施例，一个这样的方法可以是“PortAndNodeAttributeResponseMessage”，一种新的CM方法(消息类型)。该消息包含响应端口表示的最大路径参数(速率、MTU…等等)，以及关于响应端口的附加信息(也可以包括特定于平台的信息)。与对SA的路径查询一样，只要远程端口仍然可用，就可以跨多个连接高速缓存和重用接收到的信息。
图25图示了用于在高性能计算环境中提供从地址解析协议(ARP)响应和关于同构架构属性的对等协商得出的路径记录的系统。
根据实施例，该图示出了简化的InfiniBand架构，该架构包括多个节点，即节点A-节点E，2510-2514，这些节点(分别)通过包括多个交换机2502的InfiniBand架构2500以及子网管理器2501经由主机通道适配器2520-2524互连。
根据实施例，子网管理器2501可以被配置为确定多个主机(例如，节点A-E)和多个交换机2502支持相同的能力集合。在确定多个主机和多个交换机支持相同的能力集合后，子网管理器配置SMA标志，诸如标志A(在图中示出为包含标志A的圆圈)，该标志指示可以为主机通道适配器端口中的每个主机通道适配器端口设置条件。标志A可以包括一个或多个属性，诸如如上所述的同构架构属性。
在实施例中，可以从远程端口接收分组2530，该分组包括源LID和源GID。组合远程端口地址信息和同构架构属性，可以确定完整的路径记录2535。
根据实施例，在多子网架构的情况下(即，当分组从远程子网到达时)，GID信息仍然由IPID ARP协议很好地定义。但是，封装IB分组中的SLID信息不再由原始发送者定义，而是由分组在入口路径中被转发到本地子网的IB-IB路由器端口的LID定义。这既适用于原始多播请求又适用于后续的单播响应。
根据实施例，仍然，只要整个子网间路由允许跨子网边界的可逆路径，那么将路由器SLID用作单播流量的DLID仍将提供完整的路径记录信息以及来自同构架构标志的信息。然后，需要在各个连接的子网中的SM之间同步同构架构标志。
图26是用于基于同构架构属性从ARP响应和对等协商得出路径记录的方法的流程图。
更特别地，该图示出了根据实施例的用于根据来自远程节点的包括与架构最小值/最大值的相关性的传入ARP请求和响应来确定GID和LID的方法的流程图。
根据实施例，在步骤2601处，该方法可以开始。
根据实施例，在步骤2602处，该方法可以从传入的ARP请求或响应中获得源GID(全局标识符)和源LID(SLID或源本地标识符)。
根据实施例，在步骤2603处，该方法可以确定源GID是否来自本地子网。
如果源GID来自本地子网，则该方法可以在步骤2604处确定本地扩展的端口信息是否指示由本地主SM设置的标志指示与本地子网内可能从本地端口可见的任何CA(通道适配器)端口相关联的所有LID表示有效的DLID(上述“AllSubnetLocalChannelAdapterLIDsUsable”标志)。
根据实施例，如果做出这样的确定，则在步骤2606处，该方法可以记录这样的确定，可以记录接收到的源LID可以用作远程节点的目的地LID。
根据实施例，如果未做出这样的确定，则在步骤2605处，该方法可以记录需要SA访问或其它附加信息来确定远程节点的目的地LID。
根据实施例，如果确定源GID不是来自本地子网，则在步骤2607处，该方法可以确定扩展的PortInfo是否指示RouterSourceLIDsReversible标志为真(或表示当从远程子网中的端端口转发分组时由本地子网中的路由器端口生成的所有源LID都可以用于到达远程子网中的相关端端口的另一个标志)。
根据实施例，如果做出这样的确定，则在步骤2608处，该方法可以记录接收到的源LID可以用作远程节点的目的地LID。
根据实施例，如果没有做出这样的确定，则在步骤2609处，该方法可以记录需要SA访问或其它附加信息来确定远程节点的目的地LID。
图27是用于基于同构架构属性从ARP响应和对等协商中得出路径记录的方法的流程图。
更特别地，该图示出了根据实施例的用于基于包括与架构最小值/最大值的相关性的新的CM类型消息交换来构造路径信息的方法的流程图。
根据实施例，在步骤2701处，该方法可以开始。
根据实施例，在步骤2702处，该方法可以确定本地扩展的PortInfo是否指示同构架构标志被设置为真。
根据实施例，在步骤2703处，如果同构架构标志被设置为真，则该方法可以基于本地PortInfo信息来构造路径信息属性。
根据实施例，在步骤2704处，如果同构架构标志未被设置为真，则该方法可以确定本地扩展PortInfo是否指示SemiHomogenous架构标志被设置为真。
根据实施例，在步骤2705处，如果SemiHomogenous架构标志被设置为真，则该方法或者接收“PortandNodeAttributeReqeustMessage”或者接收“PortandNodeAttributeResponseMessage”。
根据实施例，PortandNodeAttributeRequestMessage可以包括发送端口表示的最大路径参数(速率、MTU等)以及关于发送端口的附加信息(也可以包括特定于平台的信息)。在发起到LID已知的远程端口的其它通信之前，该方法可以用作SA路径请求的基于对等的替换。与对SA的路径查询一样，只要远程端口仍然可用，就可以跨多个连接高速缓存和重用接收到的信息。
根据实施例，“PortAndNodeAttributeResponseMessage”是CM方法(消息类型)。该消息包含响应端口表示的最大路径参数(速率、MTU等)以及关于响应端口的附加信息(也可以包括特定于平台的信息)。与对SA的路径查询一样，只要远程端口仍然可用，就可以跨多个连接高速缓存和重用接收到的信息。
根据实施例，在步骤2705处接收到一个或两个消息之后，该方法在步骤2706处可以基于本地PortInfo信息和从远程节点接收到的消息中的信息之间的最小值来构造路径信息。
根据实施例，如果本地扩展的PortInfo没有指示SemiHomogenous架构标志为真，则该方法可以在步骤2707处使用SA查询或其它手段(例如，来自本地PortInfo的“FabricGlobalMinimalPathParameters”)来获得远程节点的信息属性。
图28是根据实施例的用于得出路径记录的方法的流程图。
根据实施例，在步骤2810处，该方法可以在一个或多个微处理器处提供第一子网，该第一子网包括：多个交换机，该多个交换机至少包括叶交换机，其中该多个交换机中的每个交换机包括多个交换机端口中的至少一个交换机端口；多个主机通道适配器，其中主机通道适配器中的每个主机通道适配器包括多个主机通道适配器端口中的至少一个主机通道适配器端口，并且其中该多个主机通道适配器经由一个或多个交换机互连；多个主机；以及子网管理器，该子网管理器在多个交换机和多个主机通道适配器中的一个上运行。
根据实施例，在步骤2820处，该方法可以由子网管理器确定多个主机通道适配器端口的集合和多个交换机端口的集合支持相同的能力集合。
根据实施例，在步骤2830处，在子网管理器确定多个主机通道适配器端口的集合和多个交换机端口的集合支持相同的能力集合时，子网管理器可以配置SMA标志，该标志指示可以为多个主机通道适配器端口和多个交换机端口中的每一个设置条件。
根据实施例，在步骤2840处，可以在第一子网中的交换机上的端口处从远程端口接收包括源LID和源GID的分组。
根据实施例，在步骤2850处，源LID和源GID可以与SMA标志组合以确定完整的路径记录。
多播组的创建和加入
多播组可以由架构管理员基于管理策略/动作来创建。架构管理员可以使用管理接口来提示多播组的创建。这样的接口可以接受定义多播组所需的参数。常常，通过高层协议(ULP)创建多播组以供使用。这些ULP中的一些使用在IB分区的上下文中创建的多播组，其中IB分区表示ULP的链路边界。一些管理接口允许与IB分区一起创建多播组，从而在多播组将与特定IB分区相关联时减轻管理开销。例如，当创建IB分区时，可以设置标志，该标志有助于在所创建的IB分区的上下文中自动创建多播组(例如，InfiniBand上的互联网协议(IPoIB)标志)。
根据实施例，列表1示出了用于在对应的IB分区的上下文中(和在用于创建的相同命令内)创建IPoIB多播组的管理接口命令。如列表1所示，“ipoib”标志将导致在正在被创建的“partition_name”分区的上下文中创建多播组。
列表1
#smpartition create-n partition_name-pkey p_key[-flag[ipoib，mtu mtu，rate rate，sl sl，scope scope]][-m defmember]
如上所述，采用与IB分区相关联的多播组的ULP的一个示例是InfiniBand上的互联网协议(IPoIB)。IPoIB使用广播组，它是已在特定IB分区的上下文中创建的IB多播组。由于IB体系架构不支持广播流量，因此广播组用于模拟遗留互联网协议(IP)子网中的广播流量。
IPoIB使用IB分区来模拟IP子网(即，IB分区定义并模拟来自IPoIB协议的广播流量的链路边界)。与广播组相关联的IB分区的每个成员端端口都是IP子网的模拟成员。流量经由广播(多播)组被“广播”到模拟IP子网的每个成员(即，IB分区成员)。作为分区的成员的每个端端口也是在该分区的上下文中定义的广播组的成员。这允许使用IP协议的遗留应用经由IB子网接收广播分组(例如，地址解析协议(ARP)分组)。
当在IB分区的上下文中定义多播组时，可以根据已知的约定在算法上创建多播组的MGID。可以在其上下文中创建多播组的分区的P_Key可以被嵌入到多播组的MGID中。当创建MGID时，也可以遵循附加约定。例如，在广播IPoIB多播组的情况下，特殊签名也被嵌入到MGID中。通过遵循此类约定，为了得出定义多播组的MGID，IB客户端只需知道在其上下文中定义多播组的分区的P_Key。
多播组也可以在端端口向SM发送请求创建新的多播组的MAD时被动态创建。MAD可以指定用于在定义/创建新的多播组时使用的某些参数。例如，MAD可以指定有效的MGID。替代地，MAD可以保留未指定的MGID，在这种情况下，SM可以生成有效的MGID，并将生成的MGID分配给新创建的多播组。在创建新的多播组的请求中可以指定的其它参数包括P_Key、Q_Key、服务级别(SL)、FlowLabel、TClass、JoinState和PortGID。
请求创建新的多播组的MAD可以指定SubnAdmSet()方法，该方法由IB规范中定义的子网管理类提供。MAD还可以指定MCMemberRecord属性，其中可以指定上述参数(即，MGID、P_Key、Q_KEY等)。
一般而言，创建新的多播组的请求被请求的端端口(即，发送请求创建新的多播组的MAD的端端口)视为加入新创建的多播组的隐式请求，并且SM将请求端口包括在新创建的多播组中。即，SM使用请求端口的LID作为在请求端口和新创建的多播组的MGID之间建立关联的方式(即，端口的LID对于多播处理没有意义)。
常规上，为了加入现有的多播组，端端口向SM发送加入请求。加入请求指定现有多播组的MGID以及允许SM确定现有多播组的配置是否与正在请求加入现有多播组的端口的配置兼容的其它参数。如果SM确定请求端口的配置与现有多播组的配置兼容，则SM将请求端口的LID添加到现有多播组。即，SM将请求端口的LID与现有多播组的MGID相关联(例如，在SA数据存储库中，诸如在图15所绘出的数据存储库中)。此外，SM用在发出多播分组时已分配给MCG以供端端口使用的MLID响应请求的端端口。
在端端口加入现有的MCG之后，SM重新生成相关联的生成树，包括已与多播组相关联的请求端口。另外，可以通过将请求端口添加到多播组来将更新后的MFT(由新生成的生成树更新)发送到其现有MFT已过时的任何交换机。因此，当发出的多播分组在分组的DLID字段中具有现有多播组的MLID时，请求端口被识别为相关多播组的成员，并且多播分组的副本被传递到请求端口。
图29图示了根据实施例的用于创建和加入多播组(MCG)的流程图。在步骤2910处，SM可以接收创建新的MCG的请求。在步骤2930处，SM可以从第一端端口接收加入新的MCG的请求。在步骤2940处，SM可以将第一端端口的LID与新的MCG的MGID相关联。在步骤2950处，SM可以基于新的MCG中的第一端端口的成员资格来生成生成树和MFT。在步骤2960处，SM可以从第二端端口接收加入新的MCG的另一个请求。在步骤2970处，SM可以将第二端端口的LID与新的MCG的MGID相关联。在步骤2980处，SM可以基于新的MCG中的第二端端口的成员资格来生成生成树和MFT。
如从图29可以看到的，每次端端口加入MCG时，SM都会接收并处理MAD、更新关联、确定生成树并确定新的MFT。在许多端端口将发送加入请求的大型子网中，这会给SM/SA带来巨大的开销，尤其是在子网初始化时。
如从多播组创建和加入的上述处理中可以看到的，要包括在多播组中的每个端端口必须与SM/SA交互以便加入多播组。此外，每当在子网中选举出新的主SM时，就必然需要端端口重新加入端端口为其成员的任何多播组，因为新的SM可能会将新的MGID分配给MLID映射。在子网上基于SR-IOV的虚拟机部署中，SM/SA必须处理的请求流量的量被放大，因为多个vPort中的每一个都将执行相同类型的SM/SA请求(例如，多播组加入请求)作为物理端端口。
因此，在人口稠密的子网(具有物理和虚拟端端口)中，当子网的管理需求超出SM处理这些需求的能力时，会出现问题。特别地，在较少能力的SM/SA实现(例如，基于连接到交换机管理接口的低性能处理器模块的实现)的情况下，即使中等的SA请求负载也可能导致对于SM以及整个系统严重的开销和降低的效率以及更高的等待时间。
对于快速故障转移和恢复至关重要的高可用性(HA)系统，任何延迟都成问题。特别地，当需要亚秒级的故障转移时间时，重要的是，架构节点可以继续正常操作并与其它可操作节点进行通信而不会中断(只要节点之间的物理连接没有损失)。因此，期望所有节点可以继续将现有地址和路径信息用于单播和多播流量，而无需与SM/SA交互，并且只有当由于架构内的链路(或交换机)故障而导致SM需要执行重新路由或重新初始化时，才发生连接的中断。
此外，即使对于基于具有全功能HCA的高端服务器的SM/SA实现，将256字节的MAD用于SA通信也会严重限制性能和可伸缩性。因此，即使利用最佳高速缓存和高性能硬件用于SA请求处理，当选举新的主SM时重新注册(即，处理新的加入请求)多播成员资格的需求也可能导致由可操作的交换机和链路连接的可操作节点之间的连接中断。
因此，需要优化IB客户端和SM/SA基础设施之间的交互。对于具有低端、交换嵌入式SM/SA实现的中小型系统，需要快速发现和初始化子网，同时避免服务SA请求或以其它方式与IB客户端通信(即，超出SMA级别的发现和初始化操作)的需要。对于具有较高端SM/SA实现的系统，需要用于通过SM/SA实现向IB客户端分发相关信息的处理，该处理以利用最佳IB通信机制并且还提供具有分层实现的能力的方式，该分层实现提供了可伸缩性并且防止甚至在非常大的集群域中的大规模多播风暴。
用于管理多播组创建、加入、删除和取消加入的现有技术处理的改进可以帮助克服SM/SA开销和提升SM/SA实现的效率。
MCG的双MLID分配
如上所述，可以在IB分区的上下文中创建多播组。另外，每个分区成员可以是两种类型之一：受限成员或正式成员。但是，在定义多播组成员资格时，IB规范不会区分正式分区成员和受限分区成员。因此，由于对于每个MLID仅确定单个路由(例如，仅单个生成树)，因此所确定的路由必须将多播分组传递到多播组的每个成员端口，而不管给定端口可能是哪种类型的分区成员。
根据IB规范，由于受限分区成员可能不接受来自其它受限分区成员的分组，因此每个MLID一个路由的限制可能会引起问题。因此，当受限分区成员发送多播分组时，该多播分组表示分区中也是该分区的受限成员的每个接收端口的P_Key访问冲突。这样的P_Key访问冲突可能导致生成发送到SM的P_Key冲突陷阱。
虽然IB规范现在反映了作为从一个受限分区成员转发到另一个受限分区成员的多播分组的结果的P_Key访问冲突不必作为P_Key访问冲突进行报告(经由到SM的陷阱)，但是仍然存在大量不提供这种现代特征的遗留实现。而且，链路容量被浪费在多播分组本身上，该多播分组只有在它使用子网资源被转发到目的地端口之后才将在目的地端口处被丢弃。
根据实施例，为了避免对P_Key访问冲突的以上特殊处理的需要，以及确保受限分区成员之间在多播流量方面的完全隔离，可以将两个MID分配给单个MCG。第一MLID可以被端端口分配和使用，用于从正式分区成员发送到正式分区成员和受限分区成员两者(在本文中称为“正式分区成员MLID”)。此外，第二MLID可以被端端口分配和使用，用于从受限分区成员发送到正式分区成员(在本文中称为“受限分区成员MLID”)。使用这个方案，受限分区成员可以避免向MCG中的其它受限分区成员发送多播分组。
根据实施例，SM负责将多播组的MLID提供给已请求多播组中的成员资格的端端口。在为多播组发送多播分组时，端端口将使用由SM提供的MLID。而且，请求的端端口可以提供与该端端口正在请求加入到SM的多播组相关联的P_Key。P_Key是MCMemberRecord的一部分，该MCMemberRecord在MCG加入请求中被发送到SM。因此，SM可以从端端口的加入请求中确定与端端口正在请求加入的MCG相关联的P_Key。SM还可以维护其自己的关于哪个端端口是哪个(些)分区的成员以及端口是(一个或多个)相关分区的受限成员还是正式成员的策略信息。
一旦SM已经确定与端端口正在请求加入的MCG相关联的P_key，SM就可以(从所确定的P_Key的高阶位)确定请求的端端口是与端端口正在请求加入的MCG相关联的分区的正式成员还是受限成员。如果确定请求的端端口是分区的正式成员，则SM可以将正式分区成员MLID提供给端端口。如果请求的端端口是分区的受限成员，则SM可以将受限分区成员MLID提供给端端口。
列表1中的伪代码示出了根据实施例的用于通过端端口响应对MLID的请求(例如，加入MCG的请求)的算法。
列表1
-接收来自端端口的加入请求；
-确定端端口的分区成员类型；
If加入请求来自正式分区成员，Then
响应MLID＝正式分区成员MLID；
Else
响应MLID＝受限分区成员MLID；
Endif
-生成并发送包括响应MLID的加入响应消息；
图30示出了根据实施例的用于通过端端口响应对MLID的请求(例如，加入MCG的请求)的流程图。在开始3002处，从端端口接收加入请求。在步骤3004处，确定请求端端口的分区成员类型。在判定3006处，确定加入请求是否来自正式分区成员。如果确定加入请求来自正式分区成员，则控制传递到步骤3010，其中响应MLID被设置为分配给请求端端口已请求加入的MCG组的正式分区成员MLID的值。如果确定加入请求不是来自正式分区成员，则控制传递到步骤3008，其中响应MLID被设置为分配给请求端端口已请求加入的MCG的受限分区成员MLID的值。从或者步骤3010或者3008，控制传递到步骤3012，其中响应MLID在响应消息中被发送到请求的端端口。
如图30和列表1所示，根据实施例，SM可以基于与MCG相关联的分区的请求端节点的分区成员资格为已请求MCG中的成员资格的端端口提供MCG的正式分区成员MLID或受限分区成员MLID。该处理对端节点可以是完全透明的，并且不需要在请求的端节点的SMA中进行遗留代码或属性的任何改变。而且，如果受限分区成员尝试使用正式MLID将分组转发给其它受限成员，则这将构成有效的P_Key访问冲突并且应当相应地进行报告。一般而言，此类冲突是端节点生成分组并将分组发送到任何目的地LID—包括任何单播DLID或多播DLID(即，MLID)—的结果。但是，已发送的分组只能表示对于发送端口有效的P_Key值，并且如果发送的P_Key对于目的地端口无效，则分组在P_Key检查后被丢弃。
根据实施例，SM可以将两个MLID分配给MCG—正式分区成员MLID和受限分区成员MLID。另外，如由SM/SA存储的MCG记录可以包括元数据，诸如正式分区成员MLID、受限分区成员MLID、正式分区成员MLID的生成树路由、受限分区成员MLID的生成树路由、两个MLID的成员节点列表、MGID、相关的P_Key等。
为了正确路由MCG的正式分区成员MLID和受限分区成员MLID，SM可以计算两个生成树—一个用于正式分区成员MLID，一个用于受限分区成员MLID。而且，SM可以为每个确定的生成树的所有受影响的交换机确定相关MLID的MFT条目内容，并将更新后的MFT转发到任何受影响的子网交换机。
图31示出了根据实施例的可以针对子网3100中的受限分区成员MLID经由生成树算法确定的示例性多播分组路由。子网3100包括节点3101-3108。节点3101-3108分别包括HCA 3109-3116。另外，HCA 3109-3116各自分别包括端口—端口3117-3124。子网3100中的每个端口是分区3170的成员。同样，子网3100中的每个端口是MCG 3165的成员。
在子网3100中，多播组(MCG)3165由SM/SA 3160定义。双MLID已分配给MCG 3165。正式分区成员MLID 3172用实线以框图形式绘出。受限分区成员MLID 3174用点划线以框图的形式绘出。端口3118-3119和端口3121和3123也用点划线绘出，以指示它们已从SM/SA3160接收到受限分区成员MLID 3174(并且相应地，它们是分区3170的受限成员)。另外，端口3117、3120、3122和3124用实线绘出，以指示它们已从SM/SA 3160接收到正式分区成员MLID 3172(并且相应地，它们是分区3170的正式成员)。
在图31中，用实线绘出了生成树中包括的用于为受限分区成员MLID 3174提供多播流量服务的链路。这是由于为具有受限分区成员MLID作为分组的DLID的多播分组的传递而生成的生成树将仅把多播分组传递到分区的正式成员。根据实施例，SM/SA 3160可以在生成受限分区成员MLID 3174的生成树时，确定分区3170的每个成员(也是MCG 3165的成员)，并确定将把具有受限分区成员MLID 3174作为DLID的分组只传递到分区3170的所确定的正式成员的生成树。以这种方式，具有受限成员P_Key的多播分组将不被传递到作为分区3170的受限成员的任何其它端口。相应地，P_Key访问冲突将不会被触发并发送到SM/SA，并且链路资源将不会被浪费在最终将在传递端口处被丢弃的分组上。
进一步参考图31，链路3142、3141和3143可以被包括在为受限分区成员MLID 3174确定的生成树中。此外，分别服务端端口3117、3120、3122和3124的链路3125、3128、3130和3132也可以被包括在受限分区成员MLID 3174的生成树中。因此，受限分区成员MLID 3174的生成树可以确保具有受限分区成员MLID 3174作为DLID的多播分组将仅被传递给既是MCG 3165的成员又是分区3170的正式成员的每个端端口。
例如，如果端口3121将多播分组注入到子网中，则它将由交换机3152接收。然后，交换机3152可以将多播分组的副本转发到生成树中指定的每条链路。因此，交换机3152可以将接收到的多播分组的副本转发到链路3142、3141和3130。在这种情况下，端口3122将经由链路3130接收多播分组的副本，交换机3150将经由链路3142接收副本，并且交换机3151将经由链路3141接收副本。从这里，交换机3150还可以将从链路3142接收到的多播分组的副本转发到链路3125(但不转发到链路3126，因为它不是生成树的一部分)。在整个子网的生成树之后，该模式可以继续，直到所有正式分区成员端口都接收到多播分组的副本。
在图31中未示出正式成员MLID 3172的生成树路由。这是因为，根据实施例，由于子网3100中的每个节点都是MCG 3165的成员并且是分区3170的成员(如上所述)，因此路由将包括每个端口3117-3124。尽管如此，SM/SA 3160可以以与上述相同的方式生成正式成员MLID 3172的生成树，不同之处在于每个端口3117-3124将被包括在正式成员MLID 3172的生成树中。
根据实施例，SM/SA 3160可以基于图31所示的生成树为每个受影响的交换机3150-3153生成MFT。一旦生成，SM/SA 3160就可以将MFT发送到交换机3150-3153，以由相应的交换机来实现。而且，可以生成为正式成员MLID 3172生成的生成树的MFT，并将其发送到交换机3150-3153，以由相应的交换机实现。可以根据上面关于图17描述的处理来生成这些相应的MFT集合。
根据实施例，端端口可以意识到SM已经将双MLID分配给MCG。当端端口意识到SM已将双MLID分配给MCG时，端端口可以区分双MLID。这种意识可以允许端端口使用受限分区成员MLID，以便仅将多播分组转发到相关MCG内的其它正式分区成员—即使该端端口是对应分区的正式成员。
可以将附加特性添加到例如PortInfo属性，以允许端端口意识到和利用分配给MCG的双MLID。根据实施例，一个这样的特性可以指示端端口是否支持区分正式成员MLID和受限成员MLID。例如，可以将“DualMLIDAllocation”指示符添加到PortInfo属性。DualMLIDAllocation指示符可以是例如一位，其中当该位被设置为高时，指示端端口支持区分正式成员MLID和受限成员MLID。默认情况下，DualMLIDAllocation指示符可以被设置为假(例如，该位可以被设置为低)。支持的HCA的SMA可以在链路工作/初始化期间将DualMLIDAllocation指示符设置为真。如果被设置为真(例如，被设置为高)，则支持的SM可以更新相关联的SMA特性。
根据实施例，另一个这样的特性可以指示是否已将双MLID分配给子网中的MCG。示例性特性可以是“DualMLIDAllocationInUse”指示符。DualMLIDAllocationInUse指示符可以是例如一位，其中当该位被设置为高时，指示支持的SM已将双MLID(即，一个用于正式分区成员，一个用于受限分区成员)分配给子网中定义的多播组。默认情况下，DualMLIDAllocationInUse指示符可以被设置为假(例如，该位可以被设置为低)。如果SM已为子网中的MCG分配双MLID，则支持的SM可以将DualMLIDAllocationInUse指示符设置为真。
根据实施例，由受限分区成员使用的第二MLID的分配可以遵循约定，以便降低子网开销和流量。例如，可以将由受限分区成员使用的第二MLID定义为在分配给由正式分区成员使用的MLID值之后的下一个MLID值(数字上)。以这种方式，支持的端端口可以确定第二MLID的值，而无需实际从SM接收它。
根据实施例，例如PortInfo属性的特性可以指示SM关于分配由受限分区成员使用的第二MLID的约定。示例性指示符可以是“ConsecutiveDualMLIDs”指示符。指示符(例如，ConcecutiveDualMLIDs)可以是例如一位，其中当该位被设置为高时，指示由受限分区成员使用的第二MLID被定义为在分配给由正式分区成员使用的MLID值之后的下一个MLID值(数字上)。默认情况下，ConsecutiveDualMLIDs指示符可以被设置为假(例如，该位可以被设置为低)。如果SM将由受限分区成员使用的第二MLID分配为在分配给由正式分区成员使用的MLID值之后的下一个MLID值(数字上)，则支持的SM可以将ConsecutiveDualMLIDs指示符设置为真。
根据实施例，既意识到对子网中的MCG的双MLID分配，又是与已被分配双MLID的MCG相关联的分区的正式成员的端端口可以在向SM的加入请求中请求由SM返回的受限分区成员MLID。SM可以检查该端端口是与该端端口正在请求加入的MCG相关联的分区的正式成员，并且如果SM确定端端口是该分区的正式成员，则SM可以将受限分区成员MLID返回到请求的端端口。该方法可以由正式分区成员端端口使用，以便仅将多播分组转发到也是相关MCG的成员的其它正式分区成员端端口。
根据实施例，可以定义一种消息类型，该消息类型既请求发送端端口被加入到消息中指定的MCG(即，与消息中指定的MGID相关联)，又请求受限分区成员MLID被返回到请求的端端口。这种消息类型可以包含与普通加入操作相同的参数，不同之处在于，受限分区成员MLID被返回到请求的端端口，而不是(默认的)正式分区成员MLID。这种消息类型可以被实现为例如MCMemberRecord属性的特性(例如，GetLimitedMLID特性)，或者被实现为新的SA方法。
根据实施例，支持对MCG的双MLID分配的使用、配置和/或管理的IB实现可以包括在对MCG的双MLID分配的使用、配置和/或管理中采用的特性的状态改变事件(例如，如上所述的DualMLIDAllocation和DualMLIDAllocationInUse)。另外，支持对MCG的双MLID分配的使用、配置和/或管理的IB实现可以包括动词接口，用于查询在对MCG的双MLID分配的使用、配置和/或管理中使用的特性的值(例如，如上所述的DualMLIDAllocation和DualMLIDAllocationInUse)。
图32示出了根据实施例的用于配置端端口以与分配给MCG的双MLID一起使用的流程图。在步骤3202处，SM将双MLID分配给MCG。在步骤3204处，SM接收到连接到子网的端端口支持对MCG的双MLID分配的指示。在步骤3206处，SM在端端口中设置指示SM已向MCG分配双MLID的指示符。在步骤3208处，SM从端端口接收加入MCG的请求。在步骤3210处，SM向端端口提供分配给MCG的双MLID之一。在步骤3212处，该方法可以结束。
图33图示了根据实施例的用于在高性能计算环境中为每个多播组提供双多播本地标识符(MLID)以促进正式分区成员和受限分区成员的流程图。在步骤3310处，第一多播本地标识符和第二多播本地标识符与定义子网中的多播组的多播全局标识符相关联。在步骤3330处，确定子网的作为多播组的成员并且作为子网中定义的第一分区的成员的端端口的数量。在步骤3340处，确定作为分区的正式成员的端端口的数量的第一子集。在步骤3350处，确定作为分区的受限成员的端端口的数量的第二子集。在步骤3360处，第一多播本地标识符与端端口的数量的第一子集中的每个端端口相关联。在步骤3370处，第二多播本地标识符与端端口的数量的第二子集中的每个端端口相关联。在步骤3380处，确定通过子网拓扑将包括第一多播本地标识符的多播分组传递到子网的作为多播组的成员和作为在子网中定义的第一分区的成员的所确定数量的端端口中的每一个的第一路由。在步骤3390处，确定通过子网拓扑将包括第二多播本地标识符的多播分组仅传递到所确定的作为分区的正式成员的端端口的数量的第一子集中的每个端端口的第二路由。
相对于分区成员资格定义的多播组(MCG)成员资格
根据实施例，作为特定IB分区的成员的所有端端口也都是特定IB多播组的所有成员的情况并不少见。例如，并且如上所述，IPoIB广播组是在IB分区的上下文中定义的多播组。作为分区的成员的每个端端口也是在该分区的上下文中定义的广播组的成员。这允许使用IP协议的遗留应用经由IB子网接收广播分组。
但是，如上所述，广播组所对应的IB分区的每个端端口成员必须向SM/SA发送加入请求，以便成为广播(多播)组的成员。响应于MCG加入请求，除了将请求的端端口的LID与广播组的MGID相关联之外，SM还必须重新创建单个生成树(如上所述)，并重新创建和发送任何受影响的交换机的MFT。为了避免这种情况的开销和低效率，根据实施例，可以如此指示在某个分区的上下文中定义的多播组。另外，SM可以确定分区何时以这种方式与多播组相关联，并且然后可以自动地将分区成员添加到多播组，而无需从分区的每个成员接收MCG加入请求。
根据实施例，当SM接收到创建新的多播组(MCG)的请求时，子网管理器可以检查该请求以确定为了定义多播组所需的传统参数(例如，IB规范中指定的参数)。如上所述，P_Key是定义多播组的请求中所需的参数之一。此外，可以在请求中包含指示与请求中包含的P_Key对应的分区的每个成员是否也将被添加作为新的多播组的成员的参数或指示符(例如，“JoinAllPartitionMembers”参数)。在由SM确定参数指示指定分区的每个端端口成员也将被添加到新的多播组后，SM可以将指定分区的每个成员的LID与新的多播组的MGID相关联。
该方法消除了在MCG创建请求中指定的分区的每个端端口成员(如果MCG被动态创建，则创建端端口成员除外)针对新创建的MCG向SM传送加入请求的需要，因为这些分区成员可以作为MCG创建请求中包含的附加参数的指示的结果来添加。因此，该方法极大地减少了客户端/端端口与SM/SA实现之间的通信，尤其是在通常发生大多数此类通信的架构初始化的关键时间期间。
此外，该方法消除了SM/SA在每个加入请求之后生成生成树和更新MFT并将其发送到受每个单独加入请求影响的交换机的需要。而是，SM可以将分区成员的所有LID与新创建的MCG的MGID相关联。然后，SM可以创建考虑添加到MCG的每个LID的单个生成树。从该生成树，SM可以生成考虑添加到MCG的所有LID的MFT集合，然后将该MFT集合发送到子网交换机。因此，可以在初始化期间和其它时间极大地减少SM工作负载。
图34示出了根据实施例的用于提供高性能计算环境中的相对于分区成员资格定义的多播组成员资格的流程图。在步骤3410处，子网的子网管理器接收创建多播组的请求，其中该请求包括指示符，并且其中该指示符指示子网中定义的分区的每个成员都要与多播组相关联。在步骤3420处，子网管理器确定作为子网中定义的分区的成员的附加端端口的数量。在步骤3430处，子网管理器将作为分区的成员的附加端端口的数量与定义多播组的标识符相关联。在步骤3440处，子网管理器定义将包括定义多播组的标识符的多播分组传递到与定义多播组的标识符相关联的每个端端口的路由。
图35图示了根据实施例的用于提供高性能计算环境中的相对于分区成员资格定义的多播组成员资格的方法的流程图。更具体而言，
图35示出了用于建立多播路由并基于多播组创建请求来更新多播转发表的流程图，该多播组创建请求指示应当将对应分区的每个成员添加到所创建的多播组。
参考图35，在步骤3505处，可以接收指示所有分区成员应该是相关MCG的成员的MCG加入请求或MCG创建指令。在判定步骤3510处，可以确定请求是否是关于MCG的初始请求。如果确定不是关于MCG的初始请求，则在步骤3515处可以进一步确定请求是否是加入相关MCG的加入请求。如果确定请求是加入请求，则可以在步骤3520处返回带有更新后的MLID的MCG记录。但是，如果在步骤3510处确定请求是关于MCG的初始请求，则控制可以传递到步骤3525。在步骤3525处，可以为MCG分配MLID。然后，在步骤3530处，可以从高速缓存的拓扑信息中检索所有相关的分区成员。在步骤3535处，可以生成包括所有分区成员端节点的生成树。在步骤3540处，受影响的交换机的MFT可以被更新并反映生成树，并且更新后的MFT可以被发送到它们相应的交换机。
表1示出了示例性子网管理属性(例如，MCMemberRecord属性)，该属性用于创建多播组，该多播组包括由SM/SA使用以指示对应分区的每个成员是否也应该被添加作为新创建的多播组的成员的参数。表1中的属性包括IB规范中指定的用于创建新的MCG的传统参数。表1中指定的属性还包括JoinAllPartitionMembers参数或指示符，其指示对应分区的每个成员是否也应该被添加作为创建的多播组的成员。对应的分区可以是属性中指定的分区。
表1
根据实施例，在接收到属性(诸如表1中的属性)后(其中属性被包括在用于创建新MCG的管理请求或动态请求中)，SM/SA中的逻辑可以确定JoinAllPartitionMembers参数的值。基于所确定的JoinAllPartitionMembers参数的值，SM可以确定应将对应分区的每个成员添加到新的MCG组。即，分区的每个端端口成员的(一个或多个)LID应该与定义新的MCG的MGID相关联。这些关联然后可以被存储在例如SA数据存储库中。
例如，SM可以接收请求创建新的多播组的MAD。MAD可以指定SubnAdmSet()方法，该方法由IB规范中定义的子网管理类提供。MAD还可以指定MCMemberRecord属性，其中可以指定上述参数(即，MGID、P_Key、Q_KEY等)。此外MCMemberRecord属性可以包含JoinAllPartitionMembers参数。根据实施例，JoinAllPartitionMembers参数可以是单个位。
在接收到包含带有JoinAllPartitionMembers参数的MCMemberRecord属性的MAD时，SM/SA可以确定JoinAllPartitionMembers参数的值。例如，JoinAllPartitionMembers参数位可以被设置为1，从而指示由MCMemberRecord的P_Key参数指定的分区的每个成员都应被加入到新的MCG组。在确定JoinAllPartitionMembers参数位被设置为1(或0，取决于设计)后，子网管理器中的逻辑可以将由MCMemberRecord属性中指定的P_Key表示的分区的所有成员添加到新创建的MCG。
图36图示了根据实施例的用于提供高性能计算环境中的相对于分区成员资格定义的多播组成员资格的方法的流程图。在步骤3600处，作为分区(诸如分区A)的成员的端节点可以发起多播组(MCG)加入请求以加入MCG，诸如MCG A。在步骤3605处，子网管理器可以接收MCG加入请求。在所描绘的方法中，已向加入请求定向到的MCG分配子网内的多播本地标识符(MLID)。在步骤3610处，SM管理器可以确定分区A的其它成员是否也已经是MCG A的成员(例如，如果端节点是子网的新添加并且正在请求添加到MCG A)。在这种情况下，在3615正常地处理MCG加入请求，并且该方法结束。但是，如果分区A的其它成员(一些或所有其它成员)不是MCG A的成员，则SM可以在步骤3620处完全基于SM从第一端节点接收到的MCG加入请求自动地将分区A的所有其它成员添加到MCG A。一旦分区A的其它成员被添加到MCG A，SM就可以在3625处更新MCG A的MLID，以包括分区A的其它成员作为寻址到MCG A的MC分组的目的地。该方法可用在3630处结束。
每个分区的默认MLID值作为SMA属性
根据实施例，并且如上所述，多个MCG可以共享相同的MLID。即，多个MGID(其定义多播组)可以与一个和同一个MLID相关联。而且，共享同一MLID的MCG将通过子网共享它们相应多播分组的相同路由，因为多播分组路由基于指定为多播分组的DLID的MLID。相应地，子网管理器可以为每个分区分配专用的MLID，其中该分区具有在该分区的上下文中定义的一个或多个MCG。然后，与分区关联或在分区的上下文中定义的所有MCG可以共享相同的MLID。这允许子网内更多数量的LID，因为有限数量的LID中更少数量的LID将用于多播组。这还使子网的SM能够创建单个生成树，并为与同一分区关联的多个MCG创建单个MFT集合，从而减少SM/SA开销。
根据实施例，SM策略可以指定为分区定义默认的MLID。该策略可以指定为子网中的每个分区分配默认的MLID，或者仅为多播通信定义的分区(即，在其上下文中定义了MCG的那些分区)被分配默认的MLID。另外，借助于相关分区中端端口的成员资格，可以使相关分区的端端口成员知道默认的MLID。
根据实施例，可以提供默认的MLID值作为相对于SM在子网的初始化期间传递给每个端口的P_Key表内容的元数据。以这种方式，可以使特定分区的端端口成员知道在特定分区的上下文中设置的任何MCG的MLID，只要端端口是该特定分区的成员即可。相应地，端端口可以以先验的方式获知端端口是其成员的MCG组的MLID，从而避免发送将由SM处理的MCG加入请求。
根据实施例，在为与分区相关联的一个或多个MCG分配默认(即，“特定于分区”)的MLID的情况下，特定于分区的MLID可以作为SMA属性被提供给端端口，连同将被放置在端端口的P_Key表中的每个P_Key。通过在P_Key表条目和默认MLID表中的条目之间包括关联或关系，可以在逻辑上扩展P_Key表信息。
P_Key表的大小可以由NodeInfo属性的PartitionCap分量指定，根据IB规范，该属性由子网的每个节点(例如，每个HCA)实现。P_Key表的大小通常是特定于供应商的，但是对于每个节点，PartitionCap分量被设置为至少一(1)的值，以指示P_Key表可以存储至少一个16位P_Key，因为每个端端口是至少默认分区的成员。但是，更大的P_Key表是常见的。根据实施例，常规的P_Key表可以包括数组，其中该数组的元素的数量等于节点的PartitionCap分量中指定的数量。
根据实施例，HCA可以被配置为存储默认MLID表，该默认MLID表包括端端口是其成员的任何分区的特定于分区的MLID(如果已经分配了这样的分区)。端端口的默认MLID表可以与端端口的P_Key表相关联，使得P_Key表中的每个条目被映射到默认MLID表中的条目。
例如，在P_Key表是数组的实施例中，默认MLID表也可以是数组。默认MLID表数组可以具有与P_Key表数组相同数量的元素。此外，P_Key表数组中给定元素的索引值可以等于默认MLID表数组中保持为由P_Key表数组的给定元素中保持的P_Key表示的分区分配的默认MLID的元素的索引值。即，P_Key表和默认MLID表可以是并行数组。以这种方式，可以将P_Key表的每个元素直接映射到默认MLID表的元素，并且端端口节点可以通过使用P_Key表到默认MLID表映射来确定分配给分区(如果有的话)的默认MLID。
列表2表示根据实施例的作为示例性并行数组的P_Key表和默认MLID表。如列表2中所看到的，P_Key表是与默认MLID表数组平行的数组，使得对于P_Key数组元素N处的P_Key，将在默认MLID数组元素N处找到与P_Key相关联的默认MLID。
列表2
P_Key表到默认MLID表映射的其它示例性实施例包括利用例如主键和外键和/或映射表以在P_key表中的P_Key及其在默认MLID表中分配的(一个或多个)默认MLID之间创建关系的关系数据库结构。在又一个实施例中，可以使用二维数组(或在双默认MLID分配给分区的情况下，使用多维数组)来创建所描述的分区键和默认MLID之间的映射关系。还有的其它实施例可以包括文件体系架构，诸如逗号分隔值等。可以使用任何合适的映射技术来创建所描述的分区的P_Key与分配给该分区的默认MLID之间的关系。
在已向MCG分配双默认特定于分区的MLID的情况下(如上面详细描述的)，可以在默认MLID表中表示两个独立的值—一个MLID的值被分配给具有正式分区成员资格的MCG成员，并且一个MLID的值被分配给具有受限分区成员资格的MCG成员。替代地，可以在默认MLID表中利用定义的约定来表示单个值，该约定将允许轻松地得出对应的值(正式成员或受限成员MLID值)。例如，在默认MLID表中表示分配给具有正式分区成员资格的MCG成员的MLID的情况下，约定可以指定分配给具有正式分区成员资格的MCG成员的MLID是正式成员资格MLID加一(即，正式分区成员MLID+1＝受限分区成员MLID)。因此，双MLID中的一个不必被明确地知道，或者被传送到端端口。
根据实施例，如果没有默认MLID被分配给分区，则可以将P_Key表中保持表示该分区的P_Key的元素映射到已知值(通过容纳P_Key表的节点)以指示没有为该分区分配默认的MLID。例如，如果没有给某个分区分配默认MLID，则默认MLID表中被映射到分区表中保持该特定分区的P_Key的元素的元素可以存储零(0)值，其中零的值指示尚未为对应分区分配默认MLID。
根据实施例，IB部件可以支持节点的端端口的默认MLID表。例如，HCA不仅可以包括默认MLID表，而且还可以通过属性支持其配置和使用。另外，子网管理器也可以与节点一起工作，以通过使用此类属性来支持默认MLID表的配置和管理。
一个这样的属性可以是节点(例如，HCA)支持默认MLID表的标志或指示符。这样的指示符可以具有默认值“假”。例如，支持默认MLID表的使用/配置/管理的SM可以将默认MLID表支持属性(例如，“HasDefaultMLIDsTable”属性)设置为“假”。相应地，如果SM发现任何不支持默认MLID表的HCA，则SM将不把不支持的属性修饰符发送到不支持的HCA，以尝试配置未支持或未包含在不支持的HCA中的默认MLID表。
在初始化期间，SM可以发现连接到子网的HCA，并将配置信息发送到发现的HCA。HCA还可以与SM通信或响应来自SM的关于HCA支持的能力的请求。根据实施例，当发现的HCA没有明确地传达其支持默认MLID表时，SM可以简单地将例如HasDefaultMLIDsTable属性的默认设置保留为假。相反，如果HCA支持默认MLID表，则支持的HCA可以在与初始化SM的通信中将属性设置为“真”。这样的通信可以是与SM的直接通信，或者可以是对信息请求的响应(诸如SubnGet()SMP，其中响应是以返回给SM的SubnGetResp()SMP的形式)。
一旦节点已向(支持的)SM传达该节点的端端口支持默认MLID表，SM就可以配置端端口的默认MLID表。SM可以维护默认MLID的记录。每个默认MLID可以与相应的分区相关联。这些MLID可以通过子网策略与其相应的分区相关联(即，分配为其相应分区的默认MLID)。子网管理器可以确定支持的端端口是哪些分区的成员、可以更新端端口的P_Key表，并且基于更新后的P_Key表，可以更新默认MLID表。
根据实施例，支持与端端口一起使用的默认MLID表的HCA可以包括指示默认MLID表是否正在使用中的属性。例如，包含并支持默认MLID表的使用的HCA也可以包含DefaultMLIDTableInUse属性。一旦SM更新支持端端口的MLID表，该属性就可以由SM设置为“真”。然后，IB客户端可以使用该属性来确定是否可以从支持端端口的默认MLID表中学习/检索与客户端相关的MLID值。
根据实施例，下面列表3中所示的伪代码示出了根据端端口的分区表来更新端端口的默认MLID表的方法。
列表3
图37是根据实施例的用于根据端端口的分区表来更新端端口的默认MLID表的方法的流程图。参考图37(并如在列表3中的伪代码中所反映的)，当更新端端口的P_Key表时，SM可以首先通过检查指示这种(例如，HasDefaultMLIDsTable属性)的属性来确定端端口是否支持默认MLID表。如果端端口不支持默认MLID表(例如，如果端端口的HasDefaultMLIDsTable属性为假)，则如果分区表需要被更新，那么SM可以继续更新端端口的分区表。但是，如果端端口支持(并相应地包括)默认MLID表(例如，如果端端口的HasDefaultMLIDsTable属性为真)，则SM可以检查指示端端口的默认MLID表是否在使用中的端端口的属性的值。
继续参考图37，如果指示端端口的默认MLID表是否在使用中的端端口的属性(例如，端端口的DefaultMLIDTableInUse属性)被设置为真，并且如果端端口的分区表需要被更新，则SM可以保持该属性设置为真、清除端端口的默认MLID表、更新端端口的分区表，然后基于更新后的端端口的分区表来更新端端口的默认MLID表。
相反，如果指示端端口的默认MLID表是否在使用中的端端口的属性(例如，端端口的DefaultMLIDTableInUse属性)被设置为假，则SM可以清除端端口的默认MLID表，并将该属性设置为真。然后，如果端端口的分区表需要更新，则SM可以更新分区表。最后，SM可以基于更新后的端端口的分区表来更新端端口的默认MLID表。
图38是根据实施例的用于由IB客户端从支持端端口的默认MLID表中确定默认MLID值的方法的流程图。参考图38，在从支持端端口的默认MLID表检索/学习默认MLID时，IB客户端可以首先确定相关本地端端口的P_Key表的内容是否已被更改或更新。这可以例如通过IB客户端意识到的本地端口事件来确定。一旦确定本地端端口的P_Key表的内容已更改，P_Key表的内容就可以被复制到本地高速缓存。IB客户端可以检查本地端端口都支持默认MLID表(例如，端端口的HasDefaultMLIDsTable属性为真)以及MLID表在使用中(例如，端端口的DefaultMLIDTableInUse属性被设置为真)。如果两个属性都被设置为真，则对于端端口的P_Key表中的每个有效条目，IB客户端可以等待，直到端端口的默认MLID表中的对应条目指示默认MLID(例如，直到该条目为非零)，并且然后将MLID表内容复制到本地高速缓存。
下面的列表4中所示的伪代码示出了根据实施例的由IB客户端从支持端端口的默认MLID表中确定默认MLID值的方法。
列表4
根据实施例，支持默认MLID表的使用、配置和/或管理的IB实现可以包括用于在默认MLID表的使用、配置和/或管理中使用的属性(例如，上述属性)的状态改变事件。另外，支持默认MLID表的使用、配置和/或管理的IB实现可以包括动词接口，用于查询在默认MLID表的使用、配置和/或管理中使用的属性(例如，上述属性)的值。
图39图示了根据实施例的用于在高性能计算环境中提供每个分区的默认多播本地标识符(MLID)值作为附加子网管理代理(SMA)属性的方法的流程图。在步骤3900处，在子网的节点处提供用于存储分区键的表，其中分区键定义子网的分区。在步骤3910处，在子网的节点处提供用于存储多播本地标识符的表。在步骤3920处，配置用于存储分区键的表的元素与用于存储多播本地标识符的表的元素之间的关系，其中该关系将用于存储分区键的表的元素映射到用于存储多播本地标识符的表的元素。在步骤3930处，从节点向子网的子网管理器发送通信，该通信指示节点支持用于存储多播本地标识符的表。在步骤3940处，在节点处接收分区键。在步骤3950处，在节点处接收多播本地标识符。在步骤3960处，分区键被存储在用于存储分区键的表中。在步骤3970处，多播本地标识符被存储在用于存储多播本地标识符的表中。在步骤3980处，用于存储分区键的表的元素与用于存储多播本地标识符的表的元素之间的关系用于从用于存储多播本地标识符的表中检索多播本地标识符。在步骤3990处，用从用于存储多播本地标识符的表中检索到的多播本地标识符来填充节点的多播组记录中的多播本地标识符字段。
通过端端口动态发现MLID
根据IB规范，QP必须被附加到多播组(即，与表示多播组的MGID相关联)，以便接收IB多播消息。通过使用IB动词，可以将QP附加到多播组或从多播组分离。IB动词是服务接口，其包括向HCA提供的I/O服务的消费者(即，IB客户端)暴露所需的HCA的行为的语义集合。动词描述了基于特定排队模型在HCA和IB客户端之间进行用于向HCA提交工作请求并返回完成状态的操作。动词描述了配置和管理通道适配器、分配(创建和销毁)队列对、配置QP操作、将工作请求发布到QP以及从完成队列获取完成状态所需的参数。
IB规范的要求是IB客户端知道它希望加入的MCG的MGID。在常规的加入请求中，与IB客户端相关联的端端口将已知的MGID传递给SM，使得SM知道要将端端口加入到的MCG。而且，如上所述，QP必须被附加到多播组(即，与表示多播组的MGID相关联)，以便接收IB多播消息。因此，并且根据实施例，HCA可以支持将本地QP与相关多播组(MCG)的MGID相关联的IB客户端，而无需向SM发送加入请求。因此，此类支持HCA的端端口可以开始接收MCG的多播分组，而无需向SM发送加入请求来请求从其接收分组的MCG中的成员资格。
图40图示了根据实施例的用于在高性能计算环境中在接收到的多播消息上为相关MGID(多播全局标识符)提供多播组多播本地标识符(MLID)动态发现的方法的流程图。在步骤4000处，可以将本地不可靠数据报(UD)QP与MCG的MGID相关联。在步骤4005处，可以在ULP处接收来自MCG的多播分组。在步骤4010处，ULP可以从多播分组确定MCG的MLID。在步骤4015处，ULP可以将MCG的MLID与另一个UD QP相关联。在步骤4020处，可以更新本地MCG地址高速缓存以反映MLID与MCG/MGID的关联。
根据实施例，HCA可以支持查询参数，该查询参数可以被评估以确定HCA是否支持与MGID(即，MCG)的QP关联，而无需知道MLID。例如，“NoMLIDRequiredForQPMCGAttach”参数可以在支持的HCA中作为可查询参数被包括在内。这样的参数的默认值可以为“假”。当HCA实现在QP到MCG关联操作期间支持未知MLID(例如，MLID参数中的零值)时，HCA接口提供者可以将该参数设置为“真”。IB客户端可以查询这样的参数以确定在QP到MCG关联操作期间HCA是否支持未知的MLID(例如，MLID参数中的零值)。接口提供者也可以供给适当的动词，用于查询参数和与未知MLID的QP到MCG的关联。
根据实施例，列表5示出了示例性的伪代码，该伪代码用于根据所查询的HCA在QP到MCG的关联操作期间是否支持未知的MLID来将QP与MCG相关联。
列表5
If NoMLIDRequiredForQPMCGAttach为真Then
-执行QP附加到MCG操作，将MLID设置为0；
Else
-执行SM/SA请求以加入相关的MCG；
-从SM/SA获得包括相关MCG的SM分配的MLID的响应；
-执行QP附加到MCG操作，将MLID设置为SM分配的MLID；
Endif
图41是根据实施例的用于在高性能计算环境中在接收到的多播消息上为相关的MGID(多播全局标识符)提供多播组多播本地标识符(MLID)动态发现的方法的流程图。更特别地，该图示出了用于决定与具有或不具有MLID的MCG的本地QP关联的流程图。
该方法可以从在步骤4105处创建本地QP开始。如果本地HCA信息指示可以在不指定MLID的情况下将QP附加到MCG(在步骤4110处)，则在步骤4115处，可以经由指定相关MGID但MLID＝0的操作将QP附加到MCG。如果不可以，则在步骤4125处可以执行加入相关MCG并获得具有相关MLID的响应的常规SA请求。然后，可以在步骤4130处执行指定在来自SA的响应中接收到的相关MGID和MLID值的QP附加到MCG操作。
来自端端口的加入MCG的请求通常确保执行多播分组传递的两个必要方面。首先，成功的加入请求包括SM将请求端端口合并到该端端口已请求加入的MCG的多播路由中。其次，一个或多个QP与端端口已请求加入的MCG的MGID相关联。如上所述，由于例如IB客户端或ULP知道执行第二方面的信息，因此可以在端端口不向SM发送加入请求的情况下执行第二方面。而且，也如上所述，作为管理/子网策略或作为MCG的“创建加入”操作的副作用，SM可以隐式地将适当的端端口合并到MCG的多播路由中—例如，如上所述，作为相对于分区成员资格定义的MCG成员资格的结果，相关的端端口可以被包含在MCG的生成树路由中。因此，根据实施例，可以由端节点接收多播分组，而无需端节点向SM发送常规的加入请求。
但是，为了发送多播分组，端端口必须知道与MCG相关联的MLID。IB规范不要求端节点知道MCG的MLID以便加入MCG，因为常规上，MLID将由SM在MCMemberRecord属性中提供给端端口，该MCMemberRecord属性由SM响应于加入请求而返回到端端口。但是，如果可以假定端端口已被合并到MCG的多播路由中，并且QP已与同一MCG的MGID相关联，则除了发送和接收对常规加入请求的响应之外，还有其它选项可供端端口学习MCG的MLID。
根据实施例，IB客户端/ULP可以通过检查在与IB客户端/ULP相关联的端端口处接收到的多播分组的MLID字段来学习MCG的MLID。每个多播分组还包括与分组相关联的MCG的MGID。因此，IB客户端/ULP可以确定包括在接收到的多播分组中的MGID，然后检查MLID(即，接收到的多播分组的DLID)并且将发现的MLID存储为由从接收到的分组中确定的MGID表示的MCG的MLID。因此，IB客户端/ULP可以动态地学习MCG的MLID，而无需发送和接收对常规MCG加入请求的响应。
通过确定MGID并检查多播分组的MLID字段来学习MCG的MLID的一个挑战是必须存在发送的初始多播分组，其包括相关的MGID。根据实施例，关于由执行创建/加入操作的端端口动态创建的MCG，与创建端端口相关联的IB客户端/ULP可以被配置为发送初始多播分组(例如，无偿(gratuitous)ARP)。然后，MCG成员端端口可以对该传递的分组执行检查。
但是，在SM创建的MCG的情况下，在创建多播组之后将不存在负责发送初始多播分组的创建MCG成员端端口。根据实施例，在这种情况下，SM/SA(或相关的特殊服务—例如，与SM一起执行的守护程序)可以负责生成初始多播分组。但是，当为MCG生成初始多播分组时，SM(或守护程序)可能不知道用于应该生成的分组的多播分组协议。根据实施例，在发出初始多播分组时，SM可以使用定义可以被传递到任何MCG成员端端口并且由ULP/IB客户端统一处理的通用多播分组类型的约定。根据这样的约定，相关的IB客户端/ULP可以忽略除检查/学习分组中包含的MLID以及分组中包含的任何其它与MLID相关的信息以外符合该约定的多播分组。
根据实施例，除了相关的MLID和MGID(其在默认情况下被包括在每个多播分组中)之外，初始多播分组还可以包括指示所包括的MLID是否是特定于分区的MLID(即，如上所述，在相关分区的上下文中创建的所有MCG的默认MLID)的信息。例如，初始多播分组约定或协议可以包括指示初始多播分组是否识别特定于分区的MLID或专用MLID的信息(例如，在特殊的初始多播分组有效载荷和/或初始多播分组报头内)。如果初始多播分组识别特定于分区的MLID，则初始多播分组还可以包括该分组的MLID是其默认MLID的分区的P_Key。
根据实施例，当在子网中采用特定于分区的默认MLID(如上面详细描述的)时，任何端端口都可以通过检查与特定分区相关联的任何多播分组的MLID来学习在特定分区的上下文中定义的任何MCG的MLID。即使另一个专用(即，非特定于分区的)MLID(或一对专用MLID)与MCG相关联，也是如此，这是因为IB中没有要求端节点强制将特定的MLID与任何MGID一起使用，并且因为IB规范明确允许多个MGID与单个MLID相关联。
根据实施例，列表6示出了示例性伪代码，该伪代码用于将从传入的多播分组中学习的MLID与已知的MGID相关联，以及更新默认MLID表(如果需要的话)。
列表6
图42是根据实施例的用于在高性能计算环境中在接收到的多播消息上为相关的MGID(多播全局标识符)提供多播组多播本地标识符(MLID)动态发现的方法的流程图。更特别地，该图示出了用于根据传入的MC分组注册MLID的流程图，其中MC分组包括确认初始多播分组约定并包括指示初始多播分组是识别特定于分区的MLID还是识别专用MLID的信息(例如，在特殊的初始多播分组有效载荷和/或初始多播分组报头内)的分组。
该方法可以在步骤4205处从接收传入的多播分组开始。如果多播分组是初始多播分组(例如，符合初始多播约定或协议的分组)并且初始多播分组指示专用(非特定于分区)的MLID(在步骤4210处)，则在步骤4215处可以更新本地MCG信息以反映接收到的分组中的MCG MLID。否则，在步骤4225处，如果多播分组是初始多播分组并且初始多播分组指示特定于分区的MLID，则在步骤4230处可以更新本地分区信息以反映接收到的多播分组中的特定于分区的MLID。否则，在步骤4245处，该方法可以找到与接收到的MGID相关联的本地MCG信息。如果没有MLID与MCG相关联或MCGMLID与分区MLID相同，则在步骤4255处，该方法可以更新本地MCG信息以反映接收到的多播分组中的MLID。
根据实施例，列表7示出了用于为传出分组跟踪特定于分区的MLID以及专用MLID两者的示例性伪代码。
列表7
-从传出的多播分组中获取MGID；
-查找传出MGID的MCG记录；
If MCG记录反映了专用的MCG MLID Then
-分组DLID＝MCG记录中的MCG MLID；
-发送多播分组；
Elseif默认分区表指示特定于分区的MLID Then
-分组DLID＝特定于分区的MLID；
-发送多播分组；
Else
-记录在可以发送MC分组之前必须确定MLID；
-开始超时时段；
Endif
While超时时段未到期Do
-等待，直到MLID被确定(转到第一个If语句)；
Endwhile
-超时
图43图示了根据实施例的用于维护传出多播分组的特定于分区的MLID以及专用的MCG MLID的记录的流程图。在步骤4305处，从传出MC分组中检索MGID。在步骤4310处，查找检索到的MGID的MCG记录。在判定4315处，如果MCG记录反映了专用MCG MLID，则在步骤4320处将分组目的地LID设置为MCG记录中的专用MCG MLID，并且在步骤4350处发送MC分组。否则，如果与MCG相关联的分区具有相关联的默认(特定于分区的)MLID(步骤4325)，则将分组目的地LID设置为与MCG的分区相关联的默认MLID，并且在步骤4350处发送MC分组。否则(在步骤4335处)，该方法可以记录在可以发送多播分组之前必须确定MLID，并且在步骤4335处可以开始超时时段。可以继续检查是否已经确定相关MGID的MLID，直到该时间段到期。如果超时时段到期时还未确定MLID，则该方法可以超时并结束(步骤4355)。但是，如果在超时时段内确定了MLID(例如，在步骤4315或4325处)，则可以用正确的MLID发送分组。
与用于检查/学习所包括的MLID的初始多播分组的传递相关联的另一个挑战是主机节点和相关联的端节点可以在任何时间启动/初始化，而不仅仅是在子网启动/初始化时。因此，为了确保这样的迟到节点/ULP/端端口能够有效地学习相关的MLID，必须执行定期、定时地发送“初始”MC分组(例如，如上所述，符合MLID学习分组约定的初始多播分组)，使得通过晚启动/初始化节点/端端口进行MLID学习可以在合理的延迟内学习MLID。
根据实施例，列表8示出了示例性伪代码，该伪代码用于使用特殊的初始多播分组协议以及在启用IPoIB的分区中利用诸如反向地址解析协议(RARP)之类的协议来发送初始多播分组。可以从例如与负责创建相关MCG的部件相关联的SM共置守护程序执行该代码。每个相关分区可以有一个守护程序上下文：
列表8
图44图示了根据实施例的用于提供高性能计算环境中的多播本地标识符的端节点动态发现的方法的流程图。在步骤4410处，在子网的节点处的多播组记录中包括定义子网的多播组的多播全局标识符。在步骤4420处，与节点的端口相关联的队列对与定义子网中的多播组的多播全局标识符相关联，由此将队列对与多播全局标识符相关联允许端口接收包括多播全局标识符的多播分组。在步骤4430处，在节点处接收包括多播全局标识符和多播本地标识符的多播分组。在步骤4440处，检查多播分组以学习多播本地标识符。在步骤4450处，所学习的多播本地标识符被包括在子网的节点处的多播组记录中。
默认MLID和专用MLID的明确MLID分配
在常规的实现中，不同的主SM实例基于本地状态信息以及作为IB客户端请求定义新的多播组的结果来分配MLID值。在这种情况下，任何主SM重新启动或故障转移，或者任何子网合并操作都可能导致不同的MLID被用于不同的MGID(即，不同的MGID到MLID的映射)，从而在多播通信在相关的端端口之间再次可操作之前会引起不小的延迟。
根据实施例，可以提供明确的MLID分配策略(例如，作为管理输入)，该明确的MLID分配策略明确地定义在特定于分区的默认MLID值(如上所述)正在使用中的实现中，哪些MLID将用于哪些分区。另外，MLID分配策略还可以定义哪些专用MLID将与给定的MGID相关联(例如，独立于分区的MLID)。通过采用这样的MLID分配策略，新的或重新启动的主SM可以观察(并验证)用于现有IB分区的MLID，而不是生成新的MGID到MLID的映射。以这种方式，可以避免由于主SM重新启动或故障转移或任何子网合并操作而导致的任何对应MGID的MLID关联的更改。
图45图示了根据实施例的用于为定义为SM策略输入的特定于分区的默认MLID提供明确多播本地标识符(MLID)分配的方法的流程图。在步骤4500处，该方法可以向子网的子网管理器提供用于多个分区中的分区的默认MLID值。在步骤4505处，该方法可以使主子网管理器脱机，该主子网管理器可以访问和控制子网。在步骤4510处，该方法可以启动新的主子网管理器，该新的主子网管理器可以访问和控制子网。在步骤4515处，该方法可以向新的主子网管理器提供用于多个分区中的分区的默认MLID值。在步骤4520处，该方法可以结束。
图46图示了根据实施例的用于为定义为SM策略输入的每个分区默认MLID提供明确多播本地标识符(MLID)分配的方法的流程图。特别地，图46是在子网重新发现期间用于验证现有MLID/P_Key索引(例如，如上所述的P_Key表到默认MLID表映射)关联的方法的流程图。该方法可以执行子网发现并为发现的HCA端口高速缓存P_Key表内容和任何定义的MLID表。对于每个发现的HCA端口，如果高速缓存的P_Key表内容与当前成员资格策略不同步，则该方法可以记录CA端口需要分区表更新。否则，如果HCA端口支持MLID表并且MLID表与当前P_Key表不同步或者MLID表内容与每个P_Key分配的当前MLID不同步，则该方法可以记录HCA端口需要MLID表更新。然后，该方法可以执行子网重新路由，并为分区成员资格已更改的每个分区MLID生成新的生成树。然后，该方法可以根据记录的P_Key表和/或MLID表更新的需求来执行子网重新初始化和更新每个CA端口。
根据实施例，MLID分配策略可以指定四个策略变量的值。MLID分配策略可以指定为子网中明确定义的MCG分配的MLID范围的开始和结束值(例如，经由管理输入)。此外，MLID分配策略可以指定为由端端口动态创建的MCG分配的MLID范围的开始和结束值。由于MLID被分配给每种类型的MCG，因此分配可以以非易失性格式存储，其中当前的主SM和任何将来的SM将能够确定MLID到MGID(即，MCG)的映射，并重用这些映射，而不是创建新的MLID到MGID的映射。
在常规的实现中，子网中的所有分区定义都基于输入到SM的明确策略。根据实施例，常规分区策略输入约定可以被扩展为包括明确MLID分配策略。例如，SM可以接收用于创建分区的子网分区策略输入。策略输入可以包括分区号(即，P_Key)、分区名称、IPoIB标志(其指示已为分区成员启用了IPoIB)和子网中的端口的成员资格规范。此外，策略输入可以包括MLID值，该值是分配给在分区的上下文中作为策略输入的结果而创建的MCG的MLID的值。根据实施例，包括在策略输入中的MLID值可以是指示正式分区成员MLID的值的基本值，其中该基本值符合可以从中得出受限分区MLID值(反之亦然)的约定(如以上所讨论的)。
根据实施例，当例如使用如上所述的明确策略输入在分区的上下文中创建MCG时，MLID值可以是为在子网中明确定义的MCG分配的MLID范围中的MLID值。根据实施例，MLID值可以不在策略输入中明确定义，而是它可以由SM从为子网中明确定义的MCG分配的MLID范围中分配。
根据实施例，在采用MLID分配策略的子网中，可以进行子网合并和拆分，而无需更改MLID到MGID的映射。独立子网之间的交换机间交叉链路可以用于选择性转发MC分组，而无需任何MLID到MGID的重新映射。而且，可以实现不同IB子网之间基于IB到IB路由器的连接，而无需分配报头映射资源来执行全局路由报头到本地路由报头的映射。
图47图示了根据实施例的两个独立的基于胖树的子网，在子网合并操作之前，每个子网具有为定义为SM策略输入的特定于分区的默认MLID的明确多播本地标识符(MLID)分配。如图47所示，每个子网(子网4702和4704)都包括用于相关MCG/MLID的生成树，其中单个主干交换机作为每个子网中的生成树的根。在子网4702中，主干交换机4730是子网4702的生成树的根(如定义交换机4730的粗线所指示的)。同样，交换机4733是子网4704的生成树的根。根据实施例(例如，如上所述)，已经生成生成树，并且已经将对应的MFT分发给交换机。
继续参考图47，根据实施例，子网4702的生成树可以指示交换机4730作为子网4702中的生成树的根。在这种情况下，生成树将不包含去往/来自交换机4731的任何链路。同样，子网4704的生成树可以将交换机4733指示为子网4704中的生成树的根，并且将不包含去往/来自交换机4732的任何链路。
图48示出了基于单个胖树的子网，该子网在子网合并操作之后具有为定义为SM策略输入的特定于分区的默认MLID的明确多播本地标识符(MLID)分配。如图48所示，子网合并操作是通过互连每个原始子网(即，图47的子网4702和4704)中的主干来实现的。根据实施例，在每个原始子网中采用相同的基于策略的MLID时，合并之后所需的唯一重新配置是通过更新主干交换机4830和4833中的MFT在逻辑上连接两个原始生成树来执行相互转发。因此，可以使得交换机4830的MFT中的条目将所有到达交换机4830并且绑定到交换机4833的下游连接的端端口的所有多播流量转发到交换机4833。一旦这样的分组到达交换机4833(从交换机4830转发)，作为MLID分配策略的结果而生成的原始MFT就将把该分组转发到MCG成员端端口。相应地，作为子网合并的结果，仅需要更新主干交换机4830的MFT。同样，仅需要更新主干交换机4833的MFT，以将在交换机4833处接收并绑定到主干交换机4830的下游的端端口的分组转发到交换机4830。主干交换机的“下游”的端端口将是例如HCA 4801-4812。
用于通告和发现的默认多播组(MCG)
根据实施例，IB规范通过定义指定用于SA请求的LID和SL(服务水平)值的PortInfo元素并且还通过指定每个端口至少是默认分区的受限成员来解决从节点引导IB通信的问题。
根据实施例，类似地，IB上IP(IP-over-IB)规范(不是InfiniBand规范的一部分)定义了可以用于IP到IB地址解析的默认多播组(MCG)。但是，由于IB上IP不是IB规范的一部分，因此它不是可以依赖于通用IB发现、通告和地址解析方案的特征。
因此，根据实施例，为了以良好定义的方式启用IB多播操作而不依赖于SA访问，可以由子网管理器定义至少一个IB多播组(MCG)，并将其经由扩展的SMA属性传送给IB客户端。
根据实施例，通过包括MCG定义作为附加的SMA级别信息，不依赖于不同的IB客户端版本在相关联的MGID上是同步的。此外，子网管理器可以保留当前没有被保留的一个或多个MGID值，然后还可以防止任何用SM打算保留用于其自己使用的MGID值来创建MCG。
根据实施例，在SMA级别定义的专用MCG的另一方面是它可以被指定为允许与为相关端口定义的任何分区一起使用，并且在这种情况下，IB客户端可以在发送MC消息时使用为该分区定义的特定于分区的(一个或多个)MLID。
根据实施例，为了实现基本的通告协议，可以使用与用于端口和节点属性的对等交换的消息格式相同的消息格式。但是，在这种情况下，仅指定发送者地址信息，没有指定目标，也没有预期的响应。
根据实施例，为了还实现地址解析和发现，可以使用指定目标GID或GUID具有来自一个特定节点的(一个或多个)预期响应的一种请求消息格式。同样，为了允许通用可用对等节点发现，可以指定完全或部分通配符的目标，然后所有相关的接收者可以发送带有其本地信息的单播响应。—该方案将意味着发送更少的多播消息，从而就通过IB架构转发并由不同节点接收的“不相关”多播消息的数量而言减少了总开销。
根据实施例，以上公开内容设想了各种InfiniBand规范增强/添加。一个这样的附加SMA属性是用于支持“DefaultMCG”的端口能力，其默认值为假。在链路工作时，可以通过支持SMA将该属性设置为真。当被设置为真时，SM或主SM可以更新相关的SMA特性。
根据实施例，可以设置128位整数“DefautMCGMGID”(默认为0—即，当DefautMCG端口能力为假时)。
根据实施例，可以设置32位整数“DefaultMCGMQ_Key”(默认为0—即，当DefaultMCG端口能力为假时)。
根据实施例，IB规范将常规的MCG元数据定义为包括MGID、P_Key、MLID和其它属性。以上设想的是将新的MCG定义为多个MLID(或MLID对)值关联。特殊的MCG元数据可以包括MGID(来自扩展PortInfo)、分区全局标志和其它属性—(例如，基于来自扩展PortInfo的“FabricGlobalMinimalPathParameters”)。PartitionGlobalFlag暗示在发送时MCG可以与任何本地定义的P_Key值和对应的特定于P_Key的MLID一起用作目的地MLID。
根据实施例，可以提供通告多播消息。通告MC消息可以包括发送者GUID和发送者LID作为MC消息的GRH和LRH的一部分。通告消息的接收者可以更新关于发送者的高速缓存信息。
根据实施例，可以提供特定于目标的发现请求MC消息。该消息可以包括发送者GUID和发送者LID作为MC消息的GRH和LRH的一部分。消息类型可以是目标发现消息。该通告消息的接收者可以检查指定的目标信息是否表示本地信息的完全匹配或通配符匹配，如果是，则发送带有相关本地信息的单播响应。
根据实施例，以上公开内容设想了各种InfiniBand规范增强/添加。一种这样的增强是新类别的通告和发现协议消息。这些可以包括通告多播消息、特定于目标的发现请求多播消息和发现响应单播消息。
图49图示了根据实施例的用于在高性能计算环境中提供通告和发现的默认多播组(MCG)作为扩展端口信息的方法的流程图。
根据实施例，在步骤4900处，该方法可以提供子网，该子网包括两个或更多个节点，该两个或更多个节点中的第一节点包括规范的第一版本，第二节点包括规范的第二版本。
根据实施例，在步骤4905处，该方法由子网管理器保留将用作默认MGID的多播全局标识符。
根据实施例，在步骤4910处，该方法在子网管理代理处提供多播组定义，该多播组定义包括默认MGID。
根据实施例，在步骤4915处，该方法可以发现子网的其它元素，该发现至少基于多播组定义。
图50图示了根据实施例的用于在高性能计算环境中提供用于通告和发现的默认多播组(MCG)作为扩展端口信息的方法的流程图。
根据实施例，在步骤5010处，该方法可以在一个或多个微处理器处提供第一子网，该第一子网包括：多个交换机，该多个交换机至少包括叶交换机，其中该多个交换机中的每个交换机包括多个交换机端口中的至少一个交换机端口；多个主机通道适配器，其中主机通道适配器中的每个主机通道适配器包括多个主机通道适配器端口中的至少一个主机通道适配器端口，并且其中该多个主机通道适配器经由多个交换机互连；以及子网管理器，该子网管理器在多个交换机和多个主机通道适配器中的一个上运行。
根据实施例，在步骤5020处，该方法可以由子网管理器定义多播组，该多播组至少由多播全局标识符(MGID)定义。
根据实施例，在步骤5030中，该方法可以经由子网管理代理(SMA)属性将定义的MCG与MGID一起传送到多个主机通道适配器。
根据实施例，在步骤5040处，该方法可以经由多个端节点的发送者端节点向多个端节点传送利用所定义的MCG的通告消息，该通告消息至少包括发送者端节点的本地标识符。
用于可伸缩转发的默认多播组代理(5836)
根据实施例，随着需要交换信息的节点的数量增加，当所有N个节点都发送多播消息以执行所有其它节点的地址解析时，由于基本复杂度为N平方，因此降低了基于广播的通告和发现/地址解析协议的可伸缩性。
根据实施例，通过在单个请求多播消息中聚合针对多个目标节点的地址解析请求，可以增加可伸缩性，但是对于大型节点集合，这将仍然具有有限的可伸缩性。
根据实施例，为了缩放协议以覆盖任意数量的节点，可以引入分层方案，其中整个系统被划分为多个域，其中每个这样的域由相关协议的MCG代理实例表示。
根据实施例，每个这样的代理实例可以从其域内的节点接收基于MC的通告和请求，但是这样的MC请求将不会被直接发出超过本地域的边界。替代地，各种代理可以经由代理之间基于MC的协议的组合以及作为代理对之间的对等流量的批量数据传输来交换信息。
根据实施例，代理还可以与子网/架构中的(一个或多个)SM合作，并且可以代表SM为可用节点发送基于MC的通告(即，类似于基于单播的SA事件通知)。
根据实施例，还可以允许特权代理以这样的模式操作，即，在该模式中，它们可以以使代理的存在对所涉及的客户端节点透明的方式代表其它节点发送消息。在这种情况下，代理在转发请求或响应时将能够使用相关节点的源地址信息。
根据实施例，以这种方式，作为默认分区(ref admin分区)中的正式成员操作的代理将能够响应来自受限成员客户端节点的发现请求，从而能够基于所涉及的客户端节点的实际分区成员资格实施可见性规则。
根据实施例，也可以将代理转发或生成的请求、响应和通告明确地识别为涉及代理实例。在这种情况下，接收到此类消息的(一个或多个)客户端节点将知道消息的IB源地址与代理相关联，而不与消息所涉及的相关对等节点相关联。
为了在单个子网内的域之间提供所需的隔离，SM必须能够识别域边界以及各种代理实例，使得即使对于单个逻辑MCG，也设置多播路由，使得由非代理发送的MC分组不会被转发到域外。
根据实施例，只要在不同的IB交换机之间存在域边界，就可以在不同域中使用相同的MLID，而无需在域之间进行任何“意外转发”。但是，如果单个IB交换机要由两个不同的域共享，则必须为同一逻辑MCG分配两个MLID。因此，实际上，在单个交换机内具有域边界是没有意义的。
根据实施例，在基于胖树的拓扑中，将各个叶交换机作为单个域是有意义的，或者具有唯一的一组交换机但在所有涉及的叶交换机之间具有完全冗余的物理连接的子树可以表示域。
根据实施例，设想了各种IB规范增强。一个这样的增强可以是对通告和发现协议消息的扩展。这样的扩展将允许明确表示代理生成和转发。
根据实施例，另一个这样的增强可以允许用于代理间通信的指定协议，但是也可以被留作用于特定于供应商、联盟或发行商的创新和增值领域。
根据实施例，为了提供域和代理感知的多播路由，SM必须知道域边界以及各个代理端口。这可以经由特定于SM实现的配置策略来实现，或者可以在代理存在和域边界表示节点本地配置信息时经由带内发现来实现。
图51图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的方法的流程图。
根据实施例，在步骤5100处，该方法可以将层次划分为多个域，该多个域中的每个域包括多播组代理实例。
根据实施例，在步骤5105处，该方法可以在MCG代理实例处从MCG代理实例的域内的节点接收基于MC的通告。
根据实施例，在步骤5110处，该方法可以由MCG代理实例向另一个域内的另一个MCG代理实例发送信息，该信息包含在基于MC的通告中。
根据实施例，在步骤5115处，该方法可以由MCG代理实例将包含在基于MC的通告中的信息发送给子网管理器。
根据实施例，在步骤5120处，该方法可以结束。
图52图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的系统。
更特别地，该图图示了具有与每个叶交换机相关联的代理实例的任意架构的系统。系统5200可以被划分为多个任意域，诸如域A5250、域B 5251和域C 5252。该系统可以包括多个主机通道适配器，诸如HCA1-HCA9 5210-5218，以及多个互连HCA的交换机，诸如交换机1-交换机6 5240-5245。HCA将另外多个主机/端节点(未示出)附加到系统5200。
根据实施例，某些交换机(例如，每个定义域内的一个交换机)可以被定义为代理。在所描绘的实施例中，交换机1 5240、交换机35242和交换机5 5244被定义为代理。在某些实施例中，这些交换机可以被定义为某些协议的多播组代理实例。
根据实施例，每个这样的代理实例可以从其域内的节点接收基于MC的通告和请求，但是这样的MC请求将不会被直接发出超过本地域的边界。替代地，各种代理可以经由其它代理之间基于MC的协议的组合以及作为代理对之间的对等流量的批量数据传输来交换信息。
根据实施例，代理还可以与子网/架构中的(一个或多个)SM合作，并且可以代表SM为可用节点发送基于MC的通知(即，类似于基于单播的SA事件通知)。
图53图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的系统。
更特别地，该图图示了基于中型胖树的架构，其具有与单个级别特定大小的每个子树相关联的代理。交换机代理1 5301处理左子树或子树1 5330，该子树包括交换机15310和交换机2 5311以及HCA1-HCA 3 5320-5322。同样，交换机代理2 5302处理右子树或子树25331，该子树包括交换机3 5312和交换机4 5313以及HCA 4-HCA 65323-5325。
图54图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的系统。
更特别地，该图图示了基于大型胖树的架构，其具有与分层子树，多个级别相关联的代理。带有粗边的交换机表示代理实例，每个基于主干的子树中的一个代理实例和根交换机级别处的一个代理实例提供主干级别代理之间的聚合。
根据实施例，架构可以包括多个HCA(诸如HCA 5401-HCA5412)以及在树拓扑的各个级别的多个交换机。在所描绘的实施例中，交换机5420至5427是叶级别交换机，而交换机5440至5443是根级别交换机。交换机5430至5433是中间级别交换机。
根据实施例，具有粗边的那些交换机(即交换机5430、交换机5432和交换机5440)表示代理实例。交换机5430是最左侧子树的代理实例，而交换机5432是最右侧子树的代理实例。交换机5440是根级别的代理实例，它在子树代理实例之间提供聚合。
图55图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的方法的流程图。
根据实施例，在一种方法中，代理可能必须向其它代理进行转发或与其它代理协商。
根据实施例，一种方法可以在步骤5501处接收消息。该方法可以在步骤5502处基于消息内容来更新本地信息。如果接收到的消息是来自本地域中的节点的信息请求，并且如果相关信息被本地高速缓存，则该方法可以在步骤5504处发送带有相关信息的响应消息。如果相关信息不在本地高速缓存，则该方法可以在步骤5505处向相关对等代理集合发送信息请求。
根据实施例，如果接收到的消息是来自不同域中的代理的信息请求，则该方法可以基于当前高速缓存的本地信息来发送响应。
根据实施例，如果接收到的消息是来自另一个域中的代理的响应或更新，则该方法可以完成任何等待接收的信息的未决请求。该方法然后可以将更新通知发送到本地域中的相关节点，并且将更新通知发送到其它域中的相关代理。
图56图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的方法的流程图。
在步骤5601处，该方法可以在代理处接收消息。
在步骤5602处，该方法可以基于消息内容来更新本地信息。
在步骤5603处，该方法可以确定接收到的消息是否是来自本地域中的节点的信息请求消息。
在步骤5604处，如果消息是来自本地域中的节点的信息请求消息，则该方法可以确定相关信息是否在本地被高速缓存。
在步骤5605处，如果相关信息在本地被高速缓存，则代理可以发送带有相关信息的响应消息。
在步骤5606处，如果相关信息未在本地高速缓存，则代理可以将信息请求发送到相关的对等代理集合。
在步骤5607处，如果接收到的消息来自另一个域中的代理，则该方法可以确定接收到的消息是否是来自另一个域中的代理的信息请求。
在步骤5608处，如果接收到的消息是来自另一个域中的代理的信息请求，则代理可以基于当前高速缓存的本地信息发送响应。
在步骤5609处，如果消息不是来自另一个域中的代理的信息请求，则代理可以确定消息是否是来自另一个域中的代理的响应或更新。
在步骤5610处，在确定消息是来自另一个域中的代理的响应或更新时，代理可以完成正在等待接收到的信息的任何未决请求。
在步骤5611处，代理可以将更新通知发送到本地域中的相关节点。
在步骤5612处，代理可以将更新通知发送到其它域中的相关代理。
图57图示了根据实施例的用于在高性能计算环境中提供用于通告的可伸缩转发和信息请求拦截的默认多播组(MCG)代理的方法的流程图。
根据实施例，在步骤5710处，该方法可以在一个或多个微处理器处提供第一子网，该第一子网包括：多个交换机，该多个交换机至少包括叶交换机，其中该多个交换机中的每个交换机包括多个交换机端口中的至少一个交换机端口；多个主机通道适配器，其中主机通道适配器中的每个主机通道适配器包括多个主机通道适配器端口中的至少一个主机通道适配器端口，并且其中该多个主机通道适配器经由多个交换机互连；以及子网管理器，该子网管理器在多个交换机和多个主机通道适配器中的一个上运行。
根据实施例，在步骤5720处，该方法可以由子网管理员将第一子网划分为两个或更多个逻辑域，每个逻辑域包括多个交换机中的至少一个交换机和多个主机通道适配器中的至少一个主机通道适配器。
根据实施例，在步骤5730处，该方法可以由子网管理器在两个或更多个逻辑域中的每个逻辑域内定义默认多播组代理，其中每个默认多播组代理与高速缓存相关联。
根据实施例，在步骤5740处，该方法可以在两个或更多个逻辑域的第一逻辑域内的第一多播组代理处接收对信息的请求，该对信息的请求是从在两个或更多个逻辑域的第二逻辑域内的第二多播组代理接收的。
根据实施例，在步骤5750处，该方法可以由第一MCG代理在与第一MCG代理相关联的第一高速缓存内检查响应于接收到的请求的信息。
根据实施例，在步骤5760处，该方法由第一MCG代理向第二MCG代理发送响应消息，该响应消息包括响应于请求的信息。
使用QP1在多个分区中接收基于MC的通告
根据实施例，被用作通用管理分组(GMP)的良好定义的目的地的，具有队列对1(QP1)的唯一特征在于，它与普通QP不同，不仅与单个分区相关联，而且可以替代地代表当前与相关端口相关联的所有分区操作以进行发送和接收。
根据实施例，通过将QP1的范围扩展到还包括在为该端口定义的任何分区中接收和发送多播分组，可以实现通用基于MC的通告和发现，而无需针对各个分区的唯一QP的复杂度，也不会由于分区成员资格的更改而对QP配置进行任何更新。
根据实施例，由于端口的默认MGID是在SMA级别定义的，因此它固有地为支持该特征的端口良好定义。因此，除了潜在支持为这种MC流量启用和禁用QP1的使用之外，不需要任何特殊的初始化过程。
根据实施例，在任何情况下，IB客户端都将被允许经由专门为相关分区分配的其它QP来处理相关MC流量。与任何QP MCG关联一样，可以有多个与同一MCG相关联的本地QP，因此可以对不同分区中的默认MCG流量使用专用QP，作为对相同分区使用QP1的替代或附加。
根据实施例，相对于包括代理的远程节点，对于不同分区中的默认MCG流量使用QP1或专用QP通常可以是完全透明的，只是与任何GMP流量一样，应该可以使用传入请求中的源QP作为对应(单播)响应中的目的地QP。但是，无论源QP是QP1还是任何其它QP编号，该方案都以相同的方式应用。
根据实施例，通过利用每个分区的专用MLID，IB客户端将能够在任何本地分区中发送通告和发现消息，并使其被所有相关对等节点接收，而无需任何其它初始化。
根据实施例，在基于代理的操作的情况下，相关域代理也将可以在每个域默认分区中发送通知，但是使用不同分区的MLID使得只有相关节点将接收到对应的消息。特定于分区的MLID将具有相关实际成员的路由，但是由代理使用的端口仍可以作为仅发送成员被包括在内。
根据实施例，在代理在所有相关分区中具有端口成员资格的情况下，它可以选择在特定分区中发送这样的MC消息，而不是使用默认分区。
根据实施例，可以增强IB规范以包括用于查询HCA经由QP1对MC流量的支持的动词接口，以及用于启用和禁用该特征(如果支持的话)的特定于端口的操作。
图58图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的方法的流程图。
根据实施例，在步骤5800处，该方法可以在InfiniBand子网中提供多个分区，每个分区包括一个或多个端节点。
根据实施例，在步骤5805处，该方法扩展队列对1以包括从两个或更多个分区发送和接收多播分组。
根据实施例，在步骤5810处，该方法可以通过队列对1实现通用基于多播的通告。
根据实施例，在步骤5815处，该方法可以结束。
图59图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的系统。
更特别地，该图示出了具有针对每个分区的专用通告QP的默认方案。
根据实施例，可以在诸如InfiniBand架构之类的架构中建立HCA的端口，诸如端口1 5901，其可以包括分区表以及用于多播通告的专用队列对，诸如队列对A 5902、队列对B5903、队列对C5904、队列对D 5905和队列对E 5906。根据相关联的多播组，每个队列对可以与不同的分区键相关联。
图60图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的系统。
更特别地，该图示出了由于分区成员资格处理而导致的通告QP填充的重新配置。
根据实施例，可以在诸如InfiniBand架构之类的架构中建立HCA的端口，诸如端口1 6001，其可以包括分区表以及用于多播通告的专用队列对，诸如队列对A 6002、队列对B6003、队列对C6004、队列对E 6005和队列对F 6006。根据相关联的多播组，每个队列对可以与不同的分区键相关联。
根据实施例，图60示出了在分区成员资格改变之后图59绘出的系统的重新配置。
图61图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的系统。
更特别地，该图示出了特殊竞争条件，其中由于在发布通告时新的QP没有就位而导致通告丢失。
根据实施例，可以在诸如InfiniBand架构之类的架构中建立HCA的端口，诸如端口1 6101，其可以包括分区表以及用于多播通告的专用队列对，诸如队列对A 6102、队列对B6103、队列对C6104、队列对E 6105和队列对F 6106。根据相关联的多播组，每个队列对可以与不同的分区键相关联。
根据实施例，图61图示了在可以建立新的队列对(QP F)以处理来自多播组F的多播通告之前的图60的系统。在这种情况下，当MC信息消息6110在端口1处被接收到时，端口1不能处理MC信息消息，因为尚未为P_Key F和/或多播组F建立队列对F。
图62图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的系统。
更特别地，该图示出了简化的方案，其中QP1接收扩展的连接管理单播消息以及基于多播的通告消息。
根据实施例，可以在诸如InfiniBand架构之类的架构中建立HCA的端口，诸如端口1 6201，其包括分区表。同样，端口可以利用简化的方案，其中队列对1 6202既用于扩展的连接管理单播消息(诸如6220)又用于多播信息消息(诸如6210)。
根据实施例，通过将队列对1既用于单播管理又用于多播信息消息，系统可以避免图61所示的竞争条件。
根据实施例，通过将QP1的范围扩展到还包括在为该端口定义的任何分区中接收和发送多播分组，可以实现通用基于MC的通告和发现，而无需针对各个分区的唯一QP的复杂度，也不会由于分区成员资格的更改而对QP配置进行任何更新。
根据实施例，由于端口的默认MGID是在SMA级别定义的，因此它固有地为支持该特征的端口良好定义。因此，除了潜在支持为这种MC流量启用和禁用QP1的使用之外，不需要任何特殊的初始化过程。
根据实施例，在任何情况下，IB客户端都将被允许经由专门为相关分区分配的其它QP来处理相关MC流量。与任何QP MCG关联一样，可以有多个与同一MCG相关联的本地QP，因此可以对不同分区中的默认MCG流量使用专用QP，作为对相同分区使用QP1的替代或附加。
图63图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的系统。
更特别地，该图示出了如与默认MCG/MGID相关联的QP的存在消除了QP建立与通告MC分组6310的接收之间的任何竞争条件。
根据实施例，如由端口1 6301使用的QP1 6302可以与MCG-Spes永久相关联，并且始终与SM已为相关联端口建立的任何P_Key值集合相关联。
图64图示了根据实施例的在高性能计算环境中使用队列对1(QP1)在多个分区中接收基于多播的通告的方法的流程图。
根据实施例，在步骤6410处，该方法可以在一个或多个微处理器处提供第一子网，该第一子网包括：多个交换机，该多个交换机至少包括叶交换机，其中该多个交换机中的每个交换机包括多个交换机端口中的至少一个交换机端口；多个主机通道适配器，其中主机通道适配器中的每个主机通道适配器包括多个主机通道适配器端口中的至少一个主机通道适配器端口，并且其中该多个主机通道适配器经由多个交换机互连；以及子网管理器，该子网管理器在多个交换机和多个主机通道适配器中的一个上运行。
根据实施例，在步骤6420处，该方法可以建立队列对1以从多个分区中的所有分区接收多播分组。
根据实施例，在步骤6430处，该方法可以从与多个主机通道适配器中的主机通道适配器相关联的本地节点传送通告多播分组。
根据实施例，在步骤6440处，该方法可以利用队列对1在第一子网内传输通告多播分组。
使用传入的MC分组作为GUID/GID到LID高速缓存内容的基础(5838)
根据实施例，由于所有多播分组都具有全局路由报头(GRH)，因此总是存在为传入的多播分组定义的源GID和源LID。这意味着HCA实现通常可以基于所有传入的MC分组收集关于任何发送者节点的GID和GUID到LID映射的信息。
根据实施例，通过与关于“AllSubnetLocalChannelAdapterLIDsUsable”标志和“RouterSourceLIDsReversible”标志值为真还是为假的本地SMA级别特性关联，以及基于能够为本地默认MCG识别传入的明确代理的MC消息，本地端口逻辑可以建立和维护包含GID和/或GUID与对应的(一个或多个)LID之间的映射的动态高速缓存。
根据实施例，只要存在用于处理传入的工作请求处理的特定于HCA的功能，就可以在HCA的CI(通道接口)接口下维持这种高速缓存逻辑。
根据实施例，执行这样的高速缓存维护并不意味着显著的开销，但是开销不会为零，因此，出于这个原因，应该可在端口和个别QP级别处明确地控制该特征的启用。
根据实施例，本公开内容设想了各种IB规范增强。第一增强可以包括用于查询对基于MC的地址映射高速缓存的HCA支持的新的动词接口以及用于在每个端口和每个QP(包括QP1)级别上启用和禁用该动词接口的控制操作。当支持并启用高速缓存时，必须存在动词接口才能观察和控制高速缓存内容。
图65图示了根据实施例的在高性能计算环境中使用所有传入多播(MC)分组作为全局唯一标识符(GUID)到本地标识符(LID)高速缓存内容的基础的方法的流程图。
根据实施例，在步骤6500处，该方法可以提供子网，该子网包括多个多播组。
根据实施例，在步骤6505处，该方法可以接收多播分组，该多播分组包括全局路由报头(GRH)，该全局路由报头定义源全局标识符(GID)和源本地标识符。
根据实施例，在步骤6510处，该方法可以将GRH以及源GID和源LID与本地子网管理代理(SMA)级别特性关联。
根据实施例，在步骤6515处，该方法可以构建动态高速缓存，该高速缓存包括源GID或源GUID与对应的LID之间的映射。
根据实施例，在步骤6520处，该方法可以结束。
图66图示了根据实施例的在高性能计算环境中使用所有传入多播(MC)分组作为全局唯一标识符(GUID)到本地标识符(LID)高速缓存内容的基础的系统。
根据实施例，该图示出了CI接口和在CI接口下面的GUID到LID高速缓存存在的图示。
根据实施例，在包括通用动词接口6601以及通道提供者接口6602(CI)的主机通道适配器处，动词接口6603以及GID或GUID到LID映射高速缓存6604的特定于平台的实现可以在CI层下面提供。
图67图示了根据实施例的在高性能计算环境中使用所有传入多播(MC)分组作为全局唯一标识符(GUID)到本地标识符(LID)高速缓存内容的基础的系统。
根据实施例，该图示出了标准接收功能和在CI接口上方由于传入的MC分组而不知道高速缓存更新的IB客户端的图示。
根据实施例，然后，在接收到MC分组时，HCA可以执行特定于平台的接收功能6703，并且基于GID/GUID到LID高速缓存6704中的MC分组的GRH高速缓存GID/GUID到LID映射，而无需CI6702之上的任何功能，诸如知道这种高速缓存的通用接收功能6701。然后，例如，MC消息完成消息可以被传送到通用接收功能。
根据实施例，为了减少消息交换的数量，在执行任何连接管理操作之前，使用本地高速缓存“咨询”。
根据实施例，当要建立到目的地节点的新连接时，可以使用本地GID/GUID到LID高速缓存映射。如果目的地节点没有已知的/(在高速缓存中)存储的GUID/GID，则本地节点可以使用典型的ARP类型操作来获得目的地节点的GUID/GID。另一方面，如果目的地节点的GID/GUID存储在高速缓存中(来自先前的MC消息)，则可以使用目的地节点的GID/GUID到LID映射来构造消息的地址。
图68图示了根据实施例的在高性能计算环境中使用所有传入多播(MC)分组作为全局唯一标识符(GUID)到本地标识符(LID)高速缓存内容的基础的方法的流程图。
根据实施例，在步骤6810处，该方法可以在一个或多个微处理器处提供第一子网，该第一子网包括：多个交换机，该多个交换机至少包括叶交换机，其中该多个交换机中的每个交换机包括多个交换机端口中的至少一个交换机端口；多个主机通道适配器，其中主机通道适配器中的每个主机通道适配器包括多个主机通道适配器端口中的至少一个主机通道适配器端口，并且其中该多个主机通道适配器经由多个交换机互连；以及子网管理器，该子网管理器在多个交换机和多个主机通道适配器中的一个上运行。
根据实施例，在步骤6820处，该方法可以在第一子网内定义多个多播组。
根据实施例，在步骤6830处，该方法可以在第一子网内的节点处接收多播分组，该多播分组包括定义源全局标识符(GID)和源本地标识符(LID)的全局路由报头(GRH)。
根据实施例，在步骤6840处，该方法可以由子网管理器建立动态高速缓存，该动态高速缓存至少包括源全局标识符和对应的源本地标识符之间的映射。
经由默认IB MCG组合IB和IP地址以及名称解析(5839)
根据实施例，由于用于IB架构中的节点/端口的大多数寻址和节点标识方案都基于RDMA-CM并使用IP地址作为通信端节点的应用级别标识，因此需要IP地址到IB地址的映射，以及解析与节点和接口的符号名称关联。
根据实施例，基于用于基于利用默认IB MCG的通告和发现协议来解析IB地址的高效和可伸缩方案，可以将协议扩展为还包括包含IP地址和符号名称信息的能力。
根据实施例，更具体而言，协议可以包括用于使用TLV(类型-长度-值)样式通用表示来提供特定于应用的值的选项。以这种方式，可以发出具有针对其请求IB地址映射的特定于应用的自变量(例如，IP地址)的请求，并且还可以具有包含任意此类TLV集合的响应和通告消息。
根据实施例，基于核心IB地址高速缓存，各种TLV可以与高速缓存中的IB地址相关联，并且也可以用作查找标准。以这种方式，各种IP地址、符号名称、MAC地址等都可以与相关的IB地址信息相关联，并且通过每个节点上的单个高速缓存进行维护，并且也可以在IB架构上的单个消息中传达。
图69图示了根据实施例的在高性能计算环境中经由默认IB多播组提供组合的IB和IP地址以及名称解析方案的方法的流程图。
根据实施例，在步骤6900处，该方法可以提供子网，该子网包括多个多播组。
根据实施例，在步骤6905处，该方法可以发出请求，该请求具有特定于应用的自变量，该请求寻找InfiniBand地址映射。
根据实施例，在步骤6910处，该方法可以响应于请求而发出与特定于应用的自变量对应的IB地址映射。
根据实施例，在6915处，特定于应用的自变量是IP地址、TLV、符号名称和MAC地址中的一个。
根据实施例，在步骤6920处，该方法可以结束。
图70图示了根据实施例的在高性能计算环境中经由默认IB多播组提供组合的IB和IP地址以及名称解析方案的系统。更特别地，该图示出了常规的GUID到LID高速缓存。
根据实施例，常规的GUID到LID高速缓存可以包括用于GUID 7001的散列函数、N个存储桶(bucket)，诸如存储桶1 7002至存储桶N 7004，以及将GUID 7005与LID 7006相关的多个存储桶条目。
根据实施例，GUID到LID高速缓存可以用作固定特征。使用基于TLV的节点信息记录，可以用相关联的索引方案维护此类记录的动态列表。
根据实施例，对于每种支持的信息类型(例如，IP、MAC地址…等等)，可以提供专用的查询基础设施，其类似于基于散列的GUID到LID高速缓存。但是，在这种情况下，查找值是用于访问节点信息记录列表的主索引的索引值。
根据实施例，查找功能将采用任何支持的TLV作为输入，并且如果匹配则返回相关记录。附加参数可以限制查找的范围(例如，名称查找可以被限制为特定分区)。
根据实施例，可以使用具有用于任意信息的通用TLV的扩展通知多播分组协议。发送者GUID和发送者LID是多播和单播分组的GRH和LRH的一部分—两者都需要GRH。
根据实施例，与单个消息可以包含的相比，可以使用一个以上的消息来表示更多基于TLV的信息。
图71图示了根据实施例的在高性能计算环境中经由默认IB多播组提供组合的IB和IP地址以及名称解析方案的方法的流程图。
更特别地，该流程图示出了通用高速缓存查找方案，其中可以输入TLV(类型-长度值)类型和值以便映射IB地址(GID和LID)或完成具有额外TLV的高速缓存记录。
根据实施例，在步骤7101处，该方法可以开始。
根据实施例，在步骤7102处，该方法可以确保指定的类型是由高速缓存实例所支持的。即，该方法可以确保指定类型的接收消息是由运行在接收该消息的节点内的高速缓存实例所支持的。
根据实施例，在步骤7103处，该方法可以使用相关类型的散列结构来查找相关索引(即，支持指定类型的接收消息的索引)。
根据实施例，在步骤7104处，如果找到索引，则该方法可以使用找到的索引(即，正确的找到的索引意味着找到的支持相关类型的索引)来查找相关记录(即，GRH或GUID/LID与LID映射)。
根据实施例，在步骤7105处，该方法可以从查找的记录中返回所请求的信息。
根据实施例，在步骤7106处，如果没有找到/定位索引，则该方法可以返回没有找到索引和/或不支持指定类型的消息。
图72图示了根据实施例的在高性能计算环境中经由默认IB多播组提供组合的IB和IP地址以及名称解析方案的方法的流程图。
根据实施例，在步骤7210处，该方法可以在一个或多个微处理器处提供第一子网，该第一子网包括：多个交换机，该多个交换机至少包括叶交换机，其中该多个交换机中的每个交换机包括多个交换机端口中的至少一个交换机端口；多个主机通道适配器，其中主机通道适配器中的每个主机通道适配器包括多个主机通道适配器端口中的至少一个主机通道适配器端口，并且其中该多个主机通道适配器经由多个交换机互连；以及子网管理器，该子网管理器在多个交换机和多个主机通道适配器中的一个上运行。
根据实施例，在步骤7220处，该方法可以与第一子网相关联地提供散列函数。
根据实施例，在步骤7230中，该方法可以接收请求，该请求包括特定于应用的自变量，该请求寻找InfiniBand地址映射。
根据实施例，在步骤7240处，该方法可以结合散列函数基于特定于应用的自变量发出IB地址映射，该特定于应用的自变量是IP地址、TLV、符号名称或MAC地址中的一个。
虽然上面已经描述了本发明的各种实施例，但是应当理解的是，它们是作为示例而非限制来呈现的。实施例被选择和描述是为了解释本发明的原理及其实际应用。实施例说明了通过提供新的和/或改进的特征和/或提供诸如降低的资源利用、增加的容量、改进的效率和减少的延迟之类的益处来利用本发明改进系统和方法的性能的系统和方法。
在一些实施例中，本发明的特征全部或部分地在包括处理器、诸如存储器的存储介质和用于与其它计算机通信的网卡的计算机中实现。在一些实施例中，本发明的特征在分布式计算环境中实现，其中一个或多个计算机集群通过诸如局域网(LAN)、交换机架构网络(例如，InfiniBand)或广域网(WAN)之类的网络连接。分布式计算环境可以使所有计算机位于单个位置，或者在通过WAN连接的不同远程地理位置处具有计算机的集群。
在一些实施例中，本发明的特征全部或部分地在云中实现，作为基于使用Web技术以自助服务、计量方式向用户递送的共享的弹性资源的云计算系统的一部分或作为其服务。存在云的五个特征(由国家标准与技术研究院定义：按需自助服务；广泛的网络接入；资源池化；快速弹性；以及测量服务)。参见例如“The NIST Definition of CloudComputing”，Special Publication 800-145(2011)，其通过引用并入本文。云部署模型包括：公共、私有和混合。云服务模型包括软件即服务(SaaS)、平台即服务(PaaS)、数据库作为服务(DBaaS)和基础设施即服务(IaaS)。如本文所使用的，云是硬件、软件、网络和Web技术的组合，其以自助服务、计量方式向用户递送共享的弹性资源。除非另有说明，否则如本文所使用的，云包括公共云、私有云和混合云实施例，以及所有云部署模型，包括但不限于云SaaS、云DBaaS，云PaaS和云IaaS。
在一些实施例中，使用硬件、软件、固件或其组合的辅助来实现本发明的特征。在一些实施例中，使用被配置或编程为执行本发明的一个或多个功能的处理器来实现本发明的特征。在一些实施例中，处理器是被设计为执行本文描述的功能的单芯片或多芯片处理器、数字信号处理器(DSP)、片上系统(SOC)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑设备、状态机、离散门或晶体管逻辑、分立硬件部件或其任意组合。在一些实现中，本发明的特征可以由特定于给定功能的电路实现。在其它实现中，特征可以在处理器中实现，该处理器被配置为使用例如存储在计算机可读存储介质上的指令来执行。
在一些实施例中，本发明的特征结合在软件和/或固件中，用于控制处理和/或联网系统的硬件，并且用于使处理器和/或网络能够利用本发明的特征与其它系统交互。这种软件或固件可以包括但不限于应用代码、设备驱动器、操作系统、虚拟机、管理程序、应用编程接口、编程语言和执行环境/容器。基于本公开的教导，适当的软编码件可以由熟练的程序员容易地准备，这对于软件领域的技术人员来说是清楚的。
在一些实施例中，本发明包括计算机程序产品，其是具有存储在其上/其中的指令的存储介质或计算机可读介质(介质)，指令可以用于编程或以其它方式配置诸如计算机之类的系统，以执行本发明的任何处理或功能。存储介质或计算机可读介质可包括但不限于任何类型的盘，包括软盘、光盘、DVD、CD-ROM、微驱动器和磁光盘、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、闪存设备、磁卡或光卡、纳米系统(包括分子存储器IC)，或适于存储指令和/或数据的任何类型的介质或设备。在特定的实施例中，存储介质或计算机可读介质是非瞬态存储介质或非瞬态计算机可读介质。
前面的描述并非旨在是详尽的或将本发明限制于所公开的精确形式。此外，在使用特定系列的事务和步骤描述了本发明的实施例的情况下，本领域技术人员应当清楚的是，本发明的范围不限于所描述的事务和步骤系列。另外，在已经使用硬件和软件的特定组合描述了本发明的实施例的情况下，应当认识到的是，硬件和软件的其它组合也在本发明的范围内。另外，虽然各种实施例描述了本发明的特征的特定组合，但是应当理解的是，相关领域的技术人员将清楚的是，特征的不同组合在本发明的范围内，使得一个实施例的特征可以结合到另一实施例中。而且，相关领域的技术人员将清楚的是，在不脱离本发明的精神和范围的情况下，可以在形式、细节、实现和应用中进行各种添加、减少、删除、变化以及其它修改和改变。本发明的更广泛的精神和范围旨在由以下权利要求及其等同物限定。

Claims (23)

1.一种用于提供在高性能计算环境中相对于分区成员资格定义的多播组成员资格的方法，包括：
由子网的子网管理器接收创建多播组的请求，其中所述请求包括指示符，并且其中所述指示符指示所述子网中定义的分区的每个成员都要与所述多播组相关联；
由所述子网管理器确定作为在所述子网中定义的所述分区的成员的多个附加端端口；
由所述子网管理器将作为所述分区的成员的所述多个附加端端口与定义所述多播组的标识符相关联；
由所述子网管理器定义将包括定义所述多播组的标识符的多播分组传递到与定义所述多播组的标识符相关联的每个端端口的路由。
2.如权利要求1所述的方法，其中从管理接口接收创建所述多播组的所述请求。
3.如任一前述权利要求所述的方法，其中从所述子网的端节点接收创建所述多播组的所述请求。
4.如任一前述权利要求所述的方法，其中创建所述多播组的所述请求包括管理数据报分组，其中所述管理数据报分组指定方法和方法属性，并且其中所述指示符是在所述方法属性中设置的位。
5.如权利要求4所述的方法，其中所述方法是SubnAdmSet()，并且其中所述方法属性是MCMemberRecord。
6.如任何前述权利要求所述的方法，其中创建所述多播组的所述请求由管理服务作为包括在创建所述分区的请求中的标志的结果而生成。
7.如权利要求6所述的方法，其中所述标志是InfiniBand上的互联网协议(IPoIB)标志。
8.一种用于提供在高性能计算环境中相对于分区成员资格定义的多播组成员资格的系统，所述系统包括子网管理器，所述子网管理器包括处理器，其中所述处理器被配置为：
接收创建多播组的请求，其中所述请求包括指示符，并且其中所述指示符指示所述子网中定义的分区的每个成员都要与所述多播组相关联；
确定作为在所述子网中定义的所述分区的成员的多个附加端端口；
将作为所述分区的成员的所述多个附加端端口与定义所述多播组的标识符相关联；
定义将包括定义所述多播组的标识符的多播分组传递到与定义所述多播组的标识符相关联的每个端端口的路由。
9.如权利要求8所述的系统，其中从管理接口接收创建所述多播组的所述请求。
10.如权利要求8或9中任一项所述的系统，其中从所述子网的端节点接收创建所述多播组的所述请求。
11.如权利要求8至10中任一项所述的系统，其中创建所述多播组的所述请求包括管理数据报分组，其中所述管理数据报分组指定方法和方法属性，并且其中所述指示符是在所述方法属性中设置的位。
12.如权利要求11所述的系统，其中所述系统是SubnAdmSet()，并且其中所述方法属性是MCMemberRecord。
13.如权利要求8至12中任一项所述的系统，其中创建所述多播组的所述请求由管理服务作为包括在创建所述分区的请求中的标志的结果而生成。
14.如权利要求13所述的系统，其中所述标志是InfiniBand上的互联网协议(IPoIB)标志。
15.一种非瞬态机器可读存储介质，包括存储在其上的用于支持高性能计算环境中相对于分区成员资格定义的多播组成员资格的指令，所述指令在执行时使子网的子网管理器执行包括以下的步骤：
由子网管理器接收创建多播组的请求，其中所述请求包括指示符，并且其中所述指示符指示所述子网中定义的分区的每个成员都要与所述多播组相关联；
由所述子网管理器确定作为在所述子网中定义的所述分区的成员的多个附加端端口；
由所述子网管理器将作为所述分区的成员的所述多个附加端端口与定义所述多播组的标识符相关联；
由所述子网管理器定义将包括定义所述多播组的标识符的多播分组传递到与定义所述多播组的标识符相关联的每个端端口的路由。
16.如权利要求15所述的非瞬态机器可读存储介质，其中从管理接口接收创建所述多播组的所述请求。
17.如权利要求15或16中任一项所述的非瞬态机器可读存储介质，其中从所述子网的端节点接收创建所述多播组的所述请求。
18.如权利要求15至17中任一项所述的非瞬态机器可读存储介质，其中创建所述多播组的所述请求包括管理数据报分组，其中所述管理数据报分组指定方法和方法属性，并且其中所述指示符是在所述方法属性中设置的位。
19.如权利要求18所述的非瞬态机器可读存储介质，其中所述方法是SubnAdmSet()，并且其中所述方法属性是MCMemberRecord。
20.如权利要求15至19中任一项所述的非瞬态机器可读存储介质，其中创建所述多播组的所述请求由管理服务作为包括在创建所述分区的请求中的标志的结果而生成。
21.一种计算机程序，包括机器可读格式的程序指令，所述程序指令在由计算机系统执行时使所述计算机系统执行如权利要求1至6中任一项所述的方法。
22.一种计算机程序产品，包括存储在非瞬态机器可读数据存储介质中的如权利要求21所述的计算机程序。
23.一种装置，包括用于执行如权利要求1至6的方法的组件。
CN201880028491.7A 2017-03-24 2018-03-22 在高性能计算环境中提供相对于分区成员资格定义的多播组成员资格的系统和方法 Active CN110574340B (zh)

Applications Claiming Priority (29)

Application Number Priority Date Filing Date Title
US201762476423P 2017-03-24 2017-03-24
US62/476,423 2017-03-24
US201762547259P 2017-08-18 2017-08-18
US201762547264P 2017-08-18 2017-08-18
US201762547260P 2017-08-18 2017-08-18
US201762547261P 2017-08-18 2017-08-18
US201762547223P 2017-08-18 2017-08-18
US201762547206P 2017-08-18 2017-08-18
US201762547213P 2017-08-18 2017-08-18
US201762547218P 2017-08-18 2017-08-18
US201762547225P 2017-08-18 2017-08-18
US201762547258P 2017-08-18 2017-08-18
US201762547255P 2017-08-18 2017-08-18
US201762547203P 2017-08-18 2017-08-18
US62/547,223 2017-08-18
US62/547,213 2017-08-18
US62/547,260 2017-08-18
US62/547,206 2017-08-18
US62/547,259 2017-08-18
US62/547,218 2017-08-18
US62/547,261 2017-08-18
US62/547,225 2017-08-18
US62/547,255 2017-08-18
US62/547,258 2017-08-18
US62/547,264 2017-08-18
US62/547,203 2017-08-18
US15/927,448 US10432414B2 (en) 2017-03-24 2018-03-21 System and method to provide multicast group membership defined relative to partition membership in a high performance computing environment
US15/927,448 2018-03-21
PCT/US2018/023837 WO2018175771A1 (en) 2017-03-24 2018-03-22 System and method to provide multicast group membership defined relative to partition membership in a high performance computing environment

Publications (2)

Publication Number Publication Date
CN110574340A true CN110574340A (zh) 2019-12-13
CN110574340B CN110574340B (zh) 2022-07-05

Family

ID=63581182

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201880028491.7A Active CN110574340B (zh) 2017-03-24 2018-03-22 在高性能计算环境中提供相对于分区成员资格定义的多播组成员资格的系统和方法
CN201880028500.2A Active CN110603785B (zh) 2017-03-24 2018-03-22 在高性能计算环境中提供同构架构属性的系统和方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN201880028500.2A Active CN110603785B (zh) 2017-03-24 2018-03-22 在高性能计算环境中提供同构架构属性的系统和方法

Country Status (5)

Country Link
US (9) US10560277B2 (zh)
EP (2) EP3602962B1 (zh)
JP (4) JP7105248B2 (zh)
CN (2) CN110574340B (zh)
WO (2) WO2018175771A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112073321A (zh) * 2020-11-16 2020-12-11 北京壁仞科技开发有限公司 信息处理方法、互连设备和计算机可读存储介质

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9882968B1 (en) * 2014-12-09 2018-01-30 Amazon Technologies, Inc. Virtual network interface multiplexing
US11968132B2 (en) 2017-03-24 2024-04-23 Oracle International Corporation System and method to use queue pair 1 for receiving multicast based announcements in multiple partitions in a high performance computing environment
US10693815B2 (en) 2017-03-24 2020-06-23 Oracle International Corporation System and method to use all incoming multicast packets as a basis for GUID to LID cache contents in a high performance computing environment
US10841199B2 (en) 2017-03-24 2020-11-17 Oracle International Corporation System and method for optimized path record handling in homogenous fabrics without host stack cooperation in a high performance computing environment
US10868686B2 (en) 2017-03-24 2020-12-15 Oracle International Corporation System and method to provide default multicast group (MCG) for announcements and discovery as extended port information in a high performance computing environment
US10862694B2 (en) 2017-03-24 2020-12-08 Oracle International Corporation System and method to provide default multicast proxy for scalable forwarding of announcements and information request intercepting in a high performance computing environment
US10601765B2 (en) 2017-03-24 2020-03-24 Oracle International Corporation System and method to provide combined IB and IP address and name resolution schemes via default IB multicast groups in a high performance computing environment
US10560277B2 (en) 2017-03-24 2020-02-11 Oracle International Corporation System and method to provide multicast group MLID dynamic discovery on received multicast messages for relevant MGID in a high performance computing environment
US10868685B2 (en) 2017-03-24 2020-12-15 Oracle International Corporation System and method to provide explicit multicast local identifier assignment for per-partition default multicast local identifiers defined as subnet manager policy input in a high performance computing environment
US10461947B2 (en) 2017-03-24 2019-10-29 Oracle International Corporation System and method to provide default multicast lid values per partition as additional SMA attributes in a high performance computing environment
US11102108B2 (en) 2017-08-31 2021-08-24 Oracle International Corporation System and method for a multicast send duplication instead of replication in a high performance computing environment
US11356327B2 (en) 2017-08-31 2022-06-07 Oracle International Corporation System and method for a single logical IP subnet across multiple independent layer 2 (L2) subnets in a high performance computing environment
US11567969B2 (en) * 2018-05-29 2023-01-31 Sap Se Unbalanced partitioning of database for application data
CN109743254B (zh) * 2018-12-25 2021-06-08 新华三技术有限公司 报文转发方法、pe设备及堆叠系统
CN113016163A (zh) * 2019-01-29 2021-06-22 甲骨文国际公司 用于高性能计算环境中跨多个独立的层2（l2）子网的单个逻辑ip子网的系统和方法
CN111614424B (zh) * 2019-02-22 2022-01-25 大唐移动通信设备有限公司 一种子网融合方法、装置、节点及存储介质
US11089507B2 (en) 2019-04-02 2021-08-10 Cisco Technology, Inc. Scalable reachability for movable destinations attached to a leaf-spine switching architecture
JP7193733B2 (ja) * 2019-04-16 2022-12-21 富士通株式会社 通信制御プログラム、通信制御方法および情報処理装置
JP7193734B2 (ja) * 2019-04-16 2022-12-21 富士通株式会社 通信制御プログラム、通信制御方法および情報処理装置
US11178060B2 (en) * 2019-10-08 2021-11-16 Hewlett Packard Enterprise Development Lp Self forming local fabric
US11238019B2 (en) * 2020-05-29 2022-02-01 Microsoft Technology Licensing, Llc Distributed database systems partition merge
CN112671808B (zh) * 2021-03-16 2021-07-13 北京顺谋科技有限公司 互联网数据传输防篡改哨兵系统及互联网数据传输系统
CN114338269B (zh) * 2021-12-24 2023-10-20 北京东土科技股份有限公司 数据传输方法、装置、宽带现场总线设备、系统及介质
WO2023135674A1 (ja) * 2022-01-12 2023-07-20 日本電信電話株式会社 処理システム、処理装置、処理方法およびプログラム
US20230318969A1 (en) * 2022-03-31 2023-10-05 Lenovo (United States) Inc. Optimizing network load in multicast communications

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050027801A1 (en) * 2003-07-31 2005-02-03 International Business Machines Corporation Multicast group management in infiniband
CN102377578A (zh) * 2010-08-13 2012-03-14 丛林网络公司 用于多播虚拟局域网（vlan）注册的基于vlan的成员资格
CN103618659A (zh) * 2013-11-22 2014-03-05 上海电机学院 一种基于逻辑环的可靠多播方法
CN104823409A (zh) * 2012-10-29 2015-08-05 甲骨文国际公司 无限带宽上的网络虚拟化

Family Cites Families (83)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5355371A (en) 1982-06-18 1994-10-11 International Business Machines Corp. Multicast communication tree creation and control method and apparatus
CA2094410C (en) 1992-06-18 1998-05-05 Joshua Seth Auerbach Distributed management communications network
US5748736A (en) * 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
US6671276B1 (en) 1997-11-18 2003-12-30 Nec Corporation Switch based network architecture for IP multicast and integrated services
US6711163B1 (en) * 1999-03-05 2004-03-23 Alcatel Data communication system with distributed multicasting
US6917985B2 (en) * 2000-03-10 2005-07-12 The Regents Of The University Of California Core assisted mesh protocol for multicast routing in ad-hoc Networks
US6738376B1 (en) 2000-04-07 2004-05-18 International Business Machines Corporation Method and system for managing multicast traffic
US7136907B1 (en) 2000-10-19 2006-11-14 International Business Machines Corporation Method and system for informing an operating system in a system area network when a new device is connected
US7133929B1 (en) 2000-10-24 2006-11-07 Intel Corporation System and method for providing detailed path information to clients
US20040213220A1 (en) 2000-12-28 2004-10-28 Davis Arlin R. Method and device for LAN emulation over infiniband fabrics
WO2002062021A1 (en) * 2001-01-31 2002-08-08 International Business Machines Corporation Providing control information to a management processor of a communications switch
US6944786B2 (en) 2001-07-27 2005-09-13 International Business Machines Corporation Network node failover using multicast address or port
US7016299B2 (en) 2001-07-27 2006-03-21 International Business Machines Corporation Network node failover using path rerouting by manager component or switch port remapping
US8935333B2 (en) 2001-08-09 2015-01-13 International Business Machines Corporation Implementing multicast on a system area network channel adapter
US7116673B2 (en) 2001-08-09 2006-10-03 International Business Machines Corporation Queue pair resolution in infiniband fabrics
US20030236900A1 (en) 2002-05-14 2003-12-25 Hsiao-Keng Chu Method and apparatus for facilitating the implementation of an IP link over an InfiniBand network
US7307996B2 (en) 2002-07-30 2007-12-11 Brocade Communications Systems, Inc. Infiniband router having an internal subnet architecture
US7401157B2 (en) 2002-07-30 2008-07-15 Brocade Communications Systems, Inc. Combining separate infiniband subnets into virtual subnets
US20040030763A1 (en) 2002-08-08 2004-02-12 Manter Venitha L. Method for implementing vendor-specific mangement in an inifiniband device
US7283473B2 (en) 2003-04-10 2007-10-16 International Business Machines Corporation Apparatus, system and method for providing multiple logical channel adapters within a single physical channel adapter in a system area network
US7493409B2 (en) 2003-04-10 2009-02-17 International Business Machines Corporation Apparatus, system and method for implementing a generalized queue pair in a system area network
US7171568B2 (en) 2003-06-13 2007-01-30 International Business Machines Corporation Remote power control in a multi-node, partitioned data processing system
US7295525B2 (en) 2003-09-11 2007-11-13 Sun Microsystems, Inc. System and method for managing multicast group membership
US7428598B2 (en) 2003-11-20 2008-09-23 International Business Machines Corporation Infiniband multicast operation in an LPAR environment
US7602712B2 (en) 2004-06-08 2009-10-13 Sun Microsystems, Inc. Switch method and apparatus with cut-through routing for use in a communications network
US7362764B2 (en) 2004-06-08 2008-04-22 Sun Microsystems, Inc. Method and apparatus for verifying service level in a communications network
US7733855B1 (en) * 2004-06-08 2010-06-08 Oracle America, Inc. Community separation enforcement
US7835301B1 (en) * 2005-04-15 2010-11-16 Nvidia Corporation Extended service set mesh topology representation
US7620981B2 (en) * 2005-05-26 2009-11-17 Charles William Frank Virtual devices and virtual bus tunnels, modules and methods
CN1980178A (zh) * 2005-12-03 2007-06-13 鸿富锦精密工业（深圳）有限公司 网络装置及其转发多播封包的方法
US7724678B1 (en) 2006-06-14 2010-05-25 Oracle America, Inc. Method and apparatus for testing a communication link
US7698408B1 (en) 2006-07-24 2010-04-13 Oracle America, Inc. Method and apparatus for testing a network
US7801027B2 (en) 2006-08-30 2010-09-21 Mellanox Technologies Ltd. Auto-negotiation by nodes on an infiniband fabric
US8249068B2 (en) 2006-10-20 2012-08-21 Alcatel Lucent Method and apparatus for establishing multicast groups
US20080192654A1 (en) * 2007-02-09 2008-08-14 Timothy Roy Block Method, Apparatus, and Computer Program Product for Implementing Infiniband Network Topology Simplification
US20090077268A1 (en) 2007-09-14 2009-03-19 International Business Machines Corporation Low Latency Multicast for Infiniband Host Channel Adapters
US8041773B2 (en) 2007-09-24 2011-10-18 The Research Foundation Of State University Of New York Automatic clustering for self-organizing grids
US7782869B1 (en) 2007-11-29 2010-08-24 Huawei Technologies Co., Ltd. Network traffic control for virtual device interfaces
US7962564B2 (en) 2008-02-25 2011-06-14 International Business Machines Corporation Discovery of a virtual topology in a multi-tasking multi-processor environment
US8949389B1 (en) 2008-03-31 2015-02-03 Intel Corporation Method and system for configuring virtual fabrics
US8225182B2 (en) 2009-10-04 2012-07-17 Mellanox Technologies Ltd. Processing of block and transaction signatures
US9660864B2 (en) 2009-10-16 2017-05-23 Brocade Communications Systems, Inc. Staged port initiation of inter switch links
US20110137991A1 (en) * 2009-12-01 2011-06-09 Lester Paul Russell Systems and methods for management and collaboration in a private network
US8443078B2 (en) 2010-08-20 2013-05-14 International Business Machines Corporation Method of determining equivalent subsets of agents to gather information for a fabric
EP2617157B1 (en) 2010-09-17 2018-07-18 Oracle International Corporation Performing partial subnet initialization in a middleware machine environment
US8743890B2 (en) 2011-06-03 2014-06-03 Oracle International Corporation System and method for supporting sub-subnet in an infiniband (IB) network
KR20120140076A (ko) 2011-06-20 2012-12-28 한국전자통신연구원 대용량 스위치를 위한 고확장성의 멀티캐스팅 패킷 포워딩 장치 및 방법
US9402271B2 (en) 2011-06-27 2016-07-26 Brocade Communications Systems, Inc. Converged wireless local area network
US8805672B2 (en) 2011-06-30 2014-08-12 International Business Machines Corporation Translation cache prediction
US8739273B2 (en) * 2011-07-11 2014-05-27 Oracle International Corporation System and method for supporting subnet management packet (SMP) firewall restrictions in a middleware machine environment
WO2013009850A1 (en) 2011-07-11 2013-01-17 Oracle International Corporation System and method for using at least one of a multicast group and a packet process proxy to support a flooding mechanism in a middleware machine environment
CN103765833B (zh) 2011-08-23 2017-07-04 英特尔公司 用于无限带宽织状结构中的启用gid的交换的方法及装置
US8780913B2 (en) 2011-08-30 2014-07-15 International Business Machines Corporation Operating an infiniband network having nodes and at least one IB switch
US8665723B2 (en) 2011-08-30 2014-03-04 International Business Machines Corporation Managing data on Infiniband (IB) networks
US8743878B2 (en) 2011-08-30 2014-06-03 International Business Machines Corporation Path resolve in symmetric infiniband networks
US8782128B2 (en) * 2011-10-18 2014-07-15 International Business Machines Corporation Global queue pair management in a point-to-point computer network
US8913620B2 (en) * 2012-03-14 2014-12-16 International Business Machines Corporation Multicast traffic generation using hierarchical replication mechanisms for distributed switches
WO2013170205A1 (en) * 2012-05-10 2013-11-14 Oracle International Corporation System and method for supporting state synchronization in a network environment
US9401963B2 (en) 2012-06-04 2016-07-26 Oracle International Corporation System and method for supporting reliable connection (RC) based subnet administrator (SA) access in an engineered system for middleware and application execution
US9898317B2 (en) * 2012-06-06 2018-02-20 Juniper Networks, Inc. Physical path determination for virtual network packet flows
US8989183B2 (en) * 2012-10-10 2015-03-24 Microsoft Technology Licensing, Llc Virtual machine multicast/broadcast in virtual network
US9319922B2 (en) 2012-12-18 2016-04-19 Rajant Corporation System and method for multicast over highly mobile mesh networks
US8937949B2 (en) 2012-12-20 2015-01-20 Oracle International Corporation Method and system for Infiniband host channel adapter multicast packet replication mechanism
US9385949B2 (en) * 2012-12-20 2016-07-05 Mellanox Technologies Tlv Ltd. Routing controlled by subnet managers
US9203750B2 (en) 2013-02-13 2015-12-01 Red Hat Israel, Ltd. Ethernet frame translation to internet protocol over infiniband
US9467366B2 (en) * 2013-07-03 2016-10-11 Avaya Inc. Method and apparatus providing single-tier routing in a shortest path bridging (SPB) network
US9602294B1 (en) * 2013-09-30 2017-03-21 Juniper Networks, Inc. Rendezvous point link resiliency for bidirectional protocol independent multicast (PIM-BIDIR)
JP2015088051A (ja) 2013-10-31 2015-05-07 富士通株式会社 情報処理装置、方法、及びプログラム
US9419811B2 (en) * 2014-04-17 2016-08-16 Cisco Technology, Inc. Automatic fabric multicast group selection in a dynamic fabric automation network architecture
US9723008B2 (en) 2014-09-09 2017-08-01 Oracle International Corporation System and method for providing an integrated firewall for secure network communication in a multi-tenant environment
US9747249B2 (en) 2014-12-29 2017-08-29 Nicira, Inc. Methods and systems to achieve multi-tenancy in RDMA over converged Ethernet
US10142353B2 (en) * 2015-06-05 2018-11-27 Cisco Technology, Inc. System for monitoring and managing datacenters
US10536357B2 (en) * 2015-06-05 2020-01-14 Cisco Technology, Inc. Late data detection in data center
US20170026282A1 (en) * 2015-07-21 2017-01-26 Intel IP Corporation Configuration of Data Path Groups in Wireless Networks
US10432470B2 (en) 2015-09-23 2019-10-01 International Business Machines Corporation Distributed subnet manager for InfiniBand networks
US10326860B2 (en) * 2016-01-27 2019-06-18 Oracle International Corporation System and method for defining virtual machine fabric profiles of virtual machines in a high-performance computing environment
US10050770B2 (en) * 2016-09-29 2018-08-14 Intel Corporation Positioning system configuration with round trip time
US10949235B2 (en) 2016-12-12 2021-03-16 Intel Corporation Network semantics integrated into central processing unit (CPU) chipset
US10841195B2 (en) 2017-02-10 2020-11-17 Oracle International Corporation System and method for controlled re-cabling and link testing for switches and switch ports in a high performance computing network
US10560277B2 (en) * 2017-03-24 2020-02-11 Oracle International Corporation System and method to provide multicast group MLID dynamic discovery on received multicast messages for relevant MGID in a high performance computing environment
US10868685B2 (en) 2017-03-24 2020-12-15 Oracle International Corporation System and method to provide explicit multicast local identifier assignment for per-partition default multicast local identifiers defined as subnet manager policy input in a high performance computing environment
US10461947B2 (en) 2017-03-24 2019-10-29 Oracle International Corporation System and method to provide default multicast lid values per partition as additional SMA attributes in a high performance computing environment
US10942666B2 (en) * 2017-10-13 2021-03-09 Cisco Technology, Inc. Using network device replication in distributed storage clusters

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050027801A1 (en) * 2003-07-31 2005-02-03 International Business Machines Corporation Multicast group management in infiniband
CN102377578A (zh) * 2010-08-13 2012-03-14 丛林网络公司 用于多播虚拟局域网（vlan）注册的基于vlan的成员资格
CN104823409A (zh) * 2012-10-29 2015-08-05 甲骨文国际公司 无限带宽上的网络虚拟化
EP2912805A1 (en) * 2012-10-29 2015-09-02 Oracle International Corporation Network virtualization over infiniband
CN103618659A (zh) * 2013-11-22 2014-03-05 上海电机学院 一种基于逻辑环的可靠多播方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
JIAZHENG ZHOU.ETC: ""Hardware supported multicast in fat-tree-based InfiniBand networks"", 《THE JOURNAL OF SUPERCOMPUTING》 *
JIAZHENG ZHOU.ETC: ""Multicast in Fat-Tree-Based InfiniBand Networks"", 《FOURTH IEEE INTERNATIONAL SYMPOSIUM ON NETWORK COMPUTING AND APPLICATIONS》 *
V.KASHYAP: ""IPv4 multicast and broadcast over InfiniBand networks"", 《HTTPS://DATATRACKER.IETF.ORG/DOC/HTML/DRAFT-KASHYAP-IPOIB -IPV4-MULTICAST-01》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112073321A (zh) * 2020-11-16 2020-12-11 北京壁仞科技开发有限公司 信息处理方法、互连设备和计算机可读存储介质
CN112073321B (zh) * 2020-11-16 2021-02-09 北京壁仞科技开发有限公司 信息处理方法、互连设备和计算机可读存储介质

Also Published As

Publication number Publication date
JP2024038087A (ja) 2024-03-19
US10560277B2 (en) 2020-02-11
US11184185B2 (en) 2021-11-23
US10630499B2 (en) 2020-04-21
US10673644B2 (en) 2020-06-02
US11139994B2 (en) 2021-10-05
CN110603785A (zh) 2019-12-20
EP3602963B1 (en) 2021-04-21
JP7411719B2 (ja) 2024-01-11
EP3602963A1 (en) 2020-02-05
US20210399909A1 (en) 2021-12-23
US20180278578A1 (en) 2018-09-27
WO2018175771A1 (en) 2018-09-27
JP7105248B2 (ja) 2022-07-22
US20200007351A1 (en) 2020-01-02
US11695583B2 (en) 2023-07-04
CN110603785B (zh) 2022-06-28
CN110574340B (zh) 2022-07-05
US10530594B2 (en) 2020-01-07
US10432414B2 (en) 2019-10-01
JP2020512638A (ja) 2020-04-23
JP2022122873A (ja) 2022-08-23
US20180278513A1 (en) 2018-09-27
US20180278430A1 (en) 2018-09-27
EP3602962A1 (en) 2020-02-05
US20220086017A1 (en) 2022-03-17
JP2020515188A (ja) 2020-05-21
JP6899445B2 (ja) 2021-07-07
US20180278429A1 (en) 2018-09-27
EP3602962B1 (en) 2022-10-05
US20200259671A1 (en) 2020-08-13
US20180278491A1 (en) 2018-09-27
US11949530B2 (en) 2024-04-02
WO2018175778A1 (en) 2018-09-27

Similar Documents

Publication Publication Date Title
CN110603785B (zh) 在高性能计算环境中提供同构架构属性的系统和方法
US11405229B2 (en) System and method to provide explicit multicast local identifier assignment for per-partition default multicast local identifiers defined as subnet manager policy input in a high performance computing environment
US11218400B2 (en) System and method for optimized path record handling in homogeneous fabrics without host stack cooperation in a high performance computing environment
US10868686B2 (en) System and method to provide default multicast group (MCG) for announcements and discovery as extended port information in a high performance computing environment
US10461947B2 (en) System and method to provide default multicast lid values per partition as additional SMA attributes in a high performance computing environment
US10693815B2 (en) System and method to use all incoming multicast packets as a basis for GUID to LID cache contents in a high performance computing environment
US11968132B2 (en) System and method to use queue pair 1 for receiving multicast based announcements in multiple partitions in a high performance computing environment
US10862694B2 (en) System and method to provide default multicast proxy for scalable forwarding of announcements and information request intercepting in a high performance computing environment
US10601765B2 (en) System and method to provide combined IB and IP address and name resolution schemes via default IB multicast groups in a high performance computing environment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant