CN112073321B - 信息处理方法、互连设备和计算机可读存储介质 - Google Patents

信息处理方法、互连设备和计算机可读存储介质 Download PDF

Info

Publication number
CN112073321B
CN112073321B CN202011275787.4A CN202011275787A CN112073321B CN 112073321 B CN112073321 B CN 112073321B CN 202011275787 A CN202011275787 A CN 202011275787A CN 112073321 B CN112073321 B CN 112073321B
Authority
CN
China
Prior art keywords
request
multicast
requests
interconnect device
interconnect
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.)
Active
Application number
CN202011275787.4A
Other languages
English (en)
Other versions
CN112073321A (zh
Inventor
不公告发明人
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.)
Beijing Bilin Technology Development Co ltd
Shanghai Bi Ren Technology Co ltd
Original Assignee
Beijing Bilin Technology Development Co ltd
Shanghai Biren Intelligent Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Bilin Technology Development Co ltd, Shanghai Biren Intelligent Technology Co Ltd filed Critical Beijing Bilin Technology Development Co ltd
Priority to CN202011275787.4A priority Critical patent/CN112073321B/zh
Publication of CN112073321A publication Critical patent/CN112073321A/zh
Application granted granted Critical
Publication of CN112073321B publication Critical patent/CN112073321B/zh
Priority to US17/524,688 priority patent/US11855878B2/en
Priority to US18/487,118 priority patent/US12095654B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/20Hop count for routing purposes, e.g. TTL
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1836Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/42Centralised routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/80Actions related to the user profile or the type of traffic
    • H04L47/806Broadcast or multicast traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/829Topology based
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/146Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multi Processors (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供了一种信息处理方法、互连设备和计算机可读存储介质。该互连设备包括:请求处理模块,其被配置为:接收来自该多个处理器中的一个多播组中的至少一个处理器的数据访问请求,其中该数据访问请求包括合并位、MGID和MTID;基于该合并位确定该数据访问请求是否是多播请求;如果确定该数据访问请求是多播请求,基于该MGID、该MTID以及该多播组的静态路由策略确定该互连设备是否会接收到其他多播请求;以及如果确定该互连设备会接收到该其他多播请求,获取该其他多播请求,将该多播请求和该其他多播请求合并为一个合并请求,并且将该合并请求转发至该互连设备的下一跳设备。

Description

信息处理方法、互连设备和计算机可读存储介质
技术领域
本发明概括而言涉及多处理器领域,更具体地,涉及一种互连设备、该互连设备中的信息处理方法以及计算机可读存储介质。
背景技术
在许多需要快速执行大量运算的领域,已经广泛使用了多处理器系统。一种典型的多处理器系统包括多个处理器和多个存储器,它们通过由交换机和物理传输链路构成的互连网络连接在一起。多个处理器通常执行相同的程序,并以完全相同的顺序访问存储器中的相同数据。例如,在人工智能(AI)领域对神经网络进行模型并行处理的并行计算系统中,多个处理器被编程为从存储器中读取相同的神经网络模型参数,并使用它们来处理不同批次的数据。这些处理器以完全相同的顺序读取相同的参数数据。
图1示出了一种现有技术的多处理器系统1的拓扑结构的示意图。如图1中所示,多处理器系统1包括多个处理器101、102、……10N(其中N是大于1的正整数,以下也统称为处理器10)、多个存储器301、302、……30M(其中M是大于或等于1的正整数,以下也统称为存储器30)以及连接多个处理器10和多个存储器30的互连网络200。其中,互连网络200包括多个互连设备201、202、203……(以下也统称为互连设备20)以及互连设备20与处理器10之间、互连设备20与存储器30之间以及互连设备20之间的物理链路201、202、203、204……在本文中,有时也将从处理器10通向存储器30的物理链路称为上行物理链路(如物理链路201、203、205、207……),将从存储器30通向处理器10的物理链路称为下行物理链路(如物理链路202、204、206、208……),但是本领域技术人员可以理解,一对上行物理链路和下行物理链路可以是一条复用的实体线路或者可以是两条单独的实体线路。此外,这里的上行和下行仅仅用于区分物理链路上的信息传输的方向,并不表示任何上或下的位置关系。
在如图1所示的多处理器系统1中,如果多个处理器10需要从某一存储器30获取特定数据,则每个处理器需要分别从该存储器30读取该数据,从而导致存储器访问带宽和网络链路带宽的消耗比每个单独处理器所需的带宽高很多倍。例如,如图1所示,假设有4个处理器10i、10j、10m、10n从一个存储器30k中读取相同的数据,其中处理器10i、10j分别通过上行物理链路201和203与互连设备202相连,处理器10m、10n分别通过上行物理链路205和207与互连设备203相连,互连设备202、203分别通过上行物理链路209和211与互连设备201相连,互连设备202通过上行物理链路213与存储器30k相连。在这种情况下,同一数据将需要从存储器30k中读取4次,消耗4倍的存储器访问带宽,并且上行物理链路213上需要传输针对该数据的4次访问请求,下行物理链路214上需要传输4次响应数据,上行物理链路209和211上需要传输针对该数据的2次访问请求,下行物理链路210和212上需要传输2次响应数据,即消耗最高达4倍的链路带宽。当有更多的存储器访问同一数据时,存储器访问带宽和网络链路带宽的消耗将更加庞大,对整个网络造成巨大的负担。
针对上述问题的一种方法是在存储器30处添加高速缓存。当第一次从该存储器30读取某一数据时,读出的数据被存储在高速缓存中。随后其他处理器10对该数据的读取请求可以直接从该高速缓存中获取,而无需再次访问较低带宽的存储器30。在这种情况下,只要所请求的数据在高速缓存中(即高速缓存命中),则低速存储器30仅需要第一次请求时被访问一次。然而,一方面,这种方法只能缓解低速存储器的带宽瓶颈,不能解决互连网络200的链路带宽的消耗问题。另一方面,高速缓存的实现成本很高,但是它可以提供的数据访问带宽通常仅比低速存储器高几倍,可以缓存的数据量比低速存储器低2-3个数量级。因此,对于诸如神经网络处理之类的应用,这种方法也不能完全解决存储器访问带宽问题。
针对上述问题的另一种方法是使用通用多播写入技术。一个处理器或多播协处理器从某一存储器30读取数据,然后通过多播写操作将该数据发送到多个请求处理器10。在这种情况下,也仅需要访问低速存储器30一次,并且对于支持多播写操作的互连网络200(即,互连设备20可以同时将数据发送给多个下行物理链路),数据仅需要在一个下行物理链路上发送一次。然而,这种方法对多处理器系统1的编程方式需要进行重大更改。代替由每个单独的处理器10独立地访问存储器30中的数据的几乎普遍使用的请求-响应方法,多个处理器10必须协调以发起和完成数据访问。这显著增加了编程复杂度,并使编程模型与现有软件不兼容。此外,如果互连网络200不支持多播写入(例如几乎所有片上互连网络都不支持多播写入),则不能减少互连网络200链路上的传输带宽消耗。
发明内容
针对上述问题中的至少一个,本发明提供了一种用于互连网络的互连设备,该互连设备可以降低存储器访问带宽消耗和互连网络上的传输带宽消耗。
根据本发明的一个方面,提供了一种互连设备。该互连设备用于互连网络。所述互连网络包括多个互连设备。所述多个互连设备连接多个处理器和多个存储器。所述互连设备包括:请求处理模块,其被配置为:接收来自所述多个处理器中的一个多播组中的至少一个处理器的数据访问请求,其中所述数据访问请求包括合并位、多播组标识符(MGID)和多播事务标识符(MTID),所述MTID用于标识所述多播组针对所述多个存储器中的一个目的存储器的目标数据单元的未完成的数据访问请求;基于所述合并位确定所述数据访问请求是否是多播请求,其中所述多播请求被允许与其他多播请求进行合并;如果确定所述数据访问请求是多播请求,基于所述MGID、所述MTID以及所述多播组的静态路由策略确定所述互连设备是否会接收到其他多播请求,所述其他多播请求来自所述多播组中的其他处理器并且具有相同MGID和MTID;以及如果确定所述互连设备会接收到所述其他多播请求,获取所述其他多播请求,将所述多播请求和所述其他多播请求合并为一个合并请求,并且将所述合并请求转发至所述互连设备的下一跳设备。
根据本发明的另一个方面,提供了一种信息处理方法。该方法包括,在互连设备处:接收来自多个处理器中的一个多播组中的至少一个处理器的数据访问请求,其中所述数据访问请求包括合并位、多播组标识符(MGID)和多播事务标识符(MTID),所述MTID用于标识所述多播组针对多个存储器中的一个目的存储器的目标数据单元的未完成的数据访问请求,所述多个处理器和所述多个存储器经由互连网络的多个互连设备连接;基于所述合并位确定所述数据访问请求是否是多播请求,其中所述多播请求被允许与其他多播请求进行合并;如果确定所述数据访问请求是多播请求,基于所述MGID、所述MTID以及所述多播组的静态路由策略确定所述互连设备是否会接收到其他多播请求,所述其他多播请求来自所述多播组中的其他处理器并且具有相同MGID和MTID;如果确定所述互连设备会接收到所述其他多播请求,获取所述其他多播请求,并将所述多播请求和所述其他多播请求合并为一个合并请求;以及将所述合并请求转发至所述互连设备的下一跳设备。
根据本发明的又一个方面,提供了一种互连设备。该互连设备包括:至少一个处理单元;以及至少一个存储单元,该至少一个存储单元被耦合到该至少一个处理单元并且存储用于由该至少一个处理单元执行的指令,该指令当由该至少一个处理单元执行时,使得该互连设备执行根据上述方法的步骤。
根据本发明的再一个方面,提供了一种计算机可读存储介质,其上存储有计算机程序代码,该计算机程序代码在被运行时执行如上所述的方法。
附图说明
通过参考下列附图所给出的本发明的具体实施方式的描述,将更好地理解本发明,并且本发明的其他目的、细节、特点和优点将变得更加显而易见。
图1示出了一种现有技术的多处理器系统的拓扑结构的示意图。
图2示出了根据本发明的实施例的一种多处理器系统的拓扑结构的示意图。
图3示出了根据本发明的实施例的一种多处理器系统的示例性拓扑结构的示意图。
图4示出了根据本发明实施例的互连设备中的请求处理模块的结构示意图。
图5示出了根据本发明实施例的互连设备中的响应处理模块的结构示意图。
图6示出了根据本发明实施例的用于互连网络的信息处理方法的示意图流程图。
图7示出了根据本发明一些实施例的互连设备的结构示意图。
具体实施方式
下面将参照附图更详细地描述本发明的优选实施例。虽然附图中显示了本发明的优选实施例,然而应该理解,可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了使本发明更加透彻和完整,并且能够将本发明的范围完整地传达给本领域的技术人员。
在本文中使用的术语“包括”及其变形表示开放性包括,即“包括但不限于”。除非特别申明,术语“或”表示“和/或”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一些实施例”表示“至少一个示例实施例”。术语“另一实施例”表示“至少一个另外的实施例”。术语“第一”、“第二”等等可以指代不同的或相同的对象。
本发明提供了一种在不需要更改通用的请求-响应存储器访问编程模型的情况下使存储器的访问带宽和/或互连网络链路上的传输带宽最小的互连设备。图2示出了根据本发明的实施例的一种多处理器系统2的拓扑结构的示意图。图2所示的多处理器系统2的结构与图1所示的多处理器系统1的结构类似,主要不同之处在于互连设备20可以包括单独的请求处理模块250和/或响应处理模块260。在一些实施例中,互连设备20可以是芯片片上网络中的交换模块,或者是交换机或路由器,其除了具有常规数据交换的功能之外,还具有根据本发明的请求处理模块250和/或响应处理模块260的功能。本领域技术人员可以理解,图2仅仅是示例性的,根据实际情况,多处理器系统2的互连网络200可以包括更多或更少的互连设备20。
概括而言,根据本发明的每个请求处理模块250被配置为接收来自多播组中的至少一个处理器10针对多个存储器30中的一个目的存储器(如存储器30k)中的一个目标数据单元的数据访问请求,并且将这些数据访问请求合并为针对该目标数据单元的单个请求,以从目的存储器30k读取该目标数据单元。
这里,取决于与每个互连设备20相连的上一跳设备(如处理器10或上一跳互连设备20)的数量,该互连设备20的请求处理模块250所合并的数据访问请求的数量也不同。例如,如图2中所示,对于互连设备202来说,其上一跳设备包括处理器10i和10j,因此其可以合并来自处理器10i和10j的两个数据访问请求。类似地,对于互连设备203来说,其上一跳设备包括处理器10m和10n,因此其可以合并来自处理器10m和10n的两个数据访问请求,对于互连设备201来说,其上一跳设备包括互连设备202和203,因此其可以合并来自互连设备202和203的两个合并后的数据访问请求。
在本文中,多播组是指多处理器系统2中的预先配置的一组处理器10,该组处理器10可以以相同的顺序对同一存储器30中的同一组数据单元进行访问,该多播组中至少包含两个处理器10。一个处理器10可以同时属于多个多播组,并且对于其所属的每个多播组来说,它可以与该多播组中的其他处理器一起以相同的顺序读取对应的一组数据单元。例如,假设一个处理器10同时属于多播组A和多播组B,则其可以与多播组A中的其他处理器10一起按照相同顺序读取一组数据单元DA中的各个数据单元,同时,它还可以与多播组B中的其他处理器10一起按照相同顺序读取另一组数据单元DB中的各个数据单元。在多处理器系统2中,可以根据要访问的数据单元将多个处理器10划分到不同的多播组,每个多播组中的处理器10执行基本相同的功能,可以对同一组数据单元进行访问。这里,数据单元是指可以通过一次存储器数据访问请求访问的一定数量的存储器数据。在一种实施例中,一个数据单元可以专用于多处理器网络2中的一次特定操作。例如,在用于人工智能应用的一个多处理器系统2中,一个数据单元可以包括可由所有处理器10构成的一个多播组以相同顺序访问的神经网络模型参数,另一个数据单元可以包括由部分处理器10构成的另一个多播组以相同顺序访问的神经网络激活数据。
通过这种合并请求方式,一个多播组中针对一个目标数据单元的数据访问请求可以在路由中的每个上行物理链路上仅传输一次,从而降低了上行链路带宽消耗。
目的存储器30k仅从互连网络200(例如经由上行物理链路213从互连设备201)接收一个数据访问请求,根据该数据访问请求中的目标数据单元的信息(如目标数据单元的标识符或地址等)读取该目标数据单元,并且将该目标数据单元发送给互连网络200(例如经由下行物理链路214发送给互连设备201)作为响应数据。
通过这种方式,对于一个多播组中的处理器10针对一个目标数据单元的数据访问请求,目的存储器30仅需执行一次读取操作,从而降低了存储器访问带宽消耗。
互连设备20的响应处理模块260接收该响应数据,根据其下一跳设备(如下一跳互连设备20或处理器10)的数量将该响应数据复制出一个或多个副本,并且将该响应数据的副本发送给其每一个下一跳设备。例如,如图2中所示,对于互连设备201来说,其下一跳设备包括两个互连设备202和203,因此其可以将从存储器30k接收的响应数据复制出两个副本,并分别通过下行物理链路210和212发送给互连设备202和203。类似地,对于互连设备202来说,其下一跳设备包括处理器10i和10j,因此其可以将从互连设备201接收的响应数据继续复制出两个副本,并分别通过下行物理链路202和204发送给处理器10i和10j,对于互连设备203来说,其下一跳设备包括处理器10m和10n,因此其可以将从互连设备201接收的响应数据继续复制出两个副本,并分别通过下行物理链路202和204发送给处理器10m和10n
通过这种方式,对于一个多播组中的处理器10针对一个目标数据单元的数据访问请求,在路由过程中的每个下行物理链路上仅需传输一次该目标数据单元,从而降低了下行链路带宽消耗。
注意,在图2中,将每个互连设备20都显示为包含请求处理模块250和响应处理模块260以使得互连网络200上的请求和响应数据最小化,然而,这仅仅是示例性的。事实上,图2所示的互连设备20中可以仅包含请求处理模块250或者响应处理模块260,并且也可以仅有部分互连设备20中包含请求处理模块250和/或响应处理模块260。例如,可以仅在与存储器30直接相连的互连设备20(如图2中所示的互连设备201)中实现请求处理模块250或者响应处理模块260。在这种情况下,仍能解决存储器访问带宽消耗的问题,并且部分降低了链路带宽消耗(例如降低了上行物理链路213或者下行物理链路214上的带宽消耗)。
图3示出了根据本发明的实施例的一种多处理器系统3的示例性拓扑结构的示意图。多处理器系统3可以认为是多处理器系统2的一个简化实例。如图3中所示,多处理器系统3包括4个处理器312、314、316和318(每个与图2所示的处理器10相同),2个存储器332和334(每个与图2所示的存储器30相同),它们通过具有4个互连设备322、324、326和328(每个与图2所示的互连设备20相同)以及10条物理链路340至349(类似于图2所示的物理链路201至214)的互连网络连接在一起。这里,物理链路340至349是一条复用的实体线路,其包含从处理器到存储器的上行物理链路和从存储器到处理器的下行物理链路。
图4示出了根据本发明实施例的互连设备200中的请求处理模块250的结构示意图。以下结合图2至图4对根据本发明的互连设备20的请求处理模块250进行更加详细的描述。
如图4中所示,请求处理模块250可以包括请求合并引擎251。请求合并引擎251被配置来接收来自多播组中的处理器的数据访问请求。如前结合图2所述,在多处理器系统2中,可以根据要访问的数据单元将多个处理器10划分到不同的多播组,每个多播组中的处理器10执行基本相同的功能,可以对同一组数据单元进行访问。多播组的划分可以是在多处理器系统2在针对某一应用的初始化阶段进行的,一旦划分完成,在该应用的执行期间,多播组将不再变化,即是静态的。同样,对于图3所示的简化结构的多处理器系统3中,可以根据要访问的数据单元将4个处理器312、314、316和318划分到不同的多播组,每个多播组至少包含其中的两个处理器并且每个多播组中的处理器执行基本相同的功能,可以对存储器332或334中的同一组数据单元进行访问。例如,可以设置第一多播组(例如为其分配多播组标识符MGID = 0),其包含所有4个处理器312、314、316和318,这些处理器被编程为以完全相同的顺序访问2个存储器332或334中的一组数据单元(例如,神经网络模型参数)。还可以设置第二多播组(例如为其分配多播组标识符MGID = 1),其包含2个处理器312和314,这些处理器被编程为仅以完全相同的顺序访问存储器332中的另一组数据单元(例如,神经网激活数据)。也就是说,成员处理器不同或者针对的数据单元不同都应建立不同的多播组。
这里,除了与请求处理器、要访问的目的存储器以及目的存储器中的目标数据单元有关的信息(如请求处理器的地址或标识符、目的存储器的地址或标识符、目标数据单元的地址或标识符等,类似于现有技术的多处理器系统1中的数据访问请求)之外,根据本发明的实施例的多处理器系统2或3中的数据访问请求还可以包括合并位、多播组标识符(多播组ID或MGID)和多播事务标识符(Transaction ID或MTID)。
合并位用于指示该数据访问请求是否被允许与其他数据访问请求合并。允许与其他数据访问请求合并(如合并位设置为1)的数据访问请求在本发明中也称为多播请求,其可以在路由路径上的互连设备20处与其他多播请求合并。相对应的,不允许与其他数据访问请求合并(如合并位设置为0)的数据访问请求在本发明中也称为单播请求,其通过互连网络200直接路由到目的存储器。这里,“单播请求”和“多播请求”用于描述是否允许与其他请求合并,其本质上仍然是针对某个数据单元的数据访问请求。因此,为了描述方便起见,在本文中有时也将单播请求、多播请求(以及后面的合并请求)统称为数据访问请求。处理器10在构造数据访问请求时,可以根据要访问的数据单元和访问该数据单元的多播组等,设置该数据访问请求的合并位。例如,如果一个处理器10确定要访问的数据单元不存在任何多播组,则该处理器可以将针对该数据单元的数据访问请求的合并位设置为0。反之,可以将该数据访问请求的合并位设置为1。
多播事务标识符(MTID)用于标识由一个多播组内的所有处理器发出的针对同一数据单元的未完成的访问请求。每个处理器10需要对同一多播组内的不同的未完成的数据访问请求分配不同的MTID。这里,未完成的数据访问请求是指尚未接收到针对该数据访问请求的响应数据且尚未超时的数据访问请求。为了使得路由过程中的互连设备20能够合并多播组中的所有处理器发出的针对同一数据单元的同一次数据访问请求,该多播组中的所有成员处理器应当为该次数据访问请求使用相同的MTID。也就是说,在同一多播组按照相同顺序依次访问同一组数据单元中的各个数据单元的情况下,应当为每次的访问设置不同的MTID,从而便于准确处理每次的请求。
在一种实施例中,多播组中的每个处理器10可以使用相同的同步增量计数器,并将计数器值用作MTID。多播组的所有成员处理器10上的计数器的初始值应设置为相同的值(例如0)。每当多播组中的处理器10发出多播请求时,相应的计数器就会加1。只有一个多播请求已完成时,该请求的MTID才能重新用于另一个多播请求。
在一个互连设备20的请求处理模块250(更进一步地,请求合并引擎251)接收到来自多播组中的一个处理器10的数据访问请求时,其基于该数据访问请求中的合并位确定该数据访问请求是否是允许与其他数据访问请求进行合并的多播请求。
请求合并引擎251可以基于接收到的该数据访问请求中的合并位确定该数据访问请求是否是允许与其他数据访问请求合并的多播请求。如果确定该数据访问请求是多播请求,请求合并引擎251可以基于该数据访问请求中的MGID、MTID以及该多播组的静态路由策略确定该互连设备20是否会接收到来自该多播组中的其他处理器10的具有相同MGID和MTID的其他多播请求。如果确定该互连设备20会接收到来自该多播组中的其他处理器10的具有相同MGID和MTID的其他多播请求,则请求合并引擎251获取其他多播请求并将该多播请求和其他多播请求合并为一个合并请求,并且将该合并请求转发至互连设备20的下一跳设备。例如,请求合并引擎251可以根据该多播组的静态路由策略确定该互连设备20的下一跳设备并将该合并请求发送给该下一跳设备。
这里,与多播请求类似,该合并请求也包含合并位、MGID和MTID。
另一方面,如果互连设备20的请求合并引擎251确定该数据访问请求不是多播请求,或者确定该互连设备20不会接收到该多播组中的其他处理器10的具有相同MGID和MTID的其他多播请求,则该请求合并引擎251可以将该数据访问请求直接转发至互连设备20的下一跳设备。
以图3为例,假设在所有4个互连设备322、324、326、328中都实现了请求处理模块250,并且存在一个多播组(如MGID=2)包含处理器312和314。当该多播组中的处理器312需要读取存储器334中的一个目标数据单元时,它将生成一个合并位为1、MGID=2的数据访问请求(即多播请求)。根据多播组MGID=2的静态路由策略,处理器312将该数据访问请求发送到互连设备322。在互连设备322处,其请求合并引擎251根据该多播请求的合并位确定该数据访问请求可以与其他数据访问请求合并(即接收到的是多播请求)。互连设备322的请求处理模块250的请求合并引擎251根据该多播组的MGID、MTID和静态路由策略,确定在互连设备322处将不会接收到来自多播组MGID=2中的其他处理器(即处理器314)的具有相同MGID和MTID的其他多播请求,并且基于该多播组MGID=2的静态路由策略将来自处理器312的该多播请求发送至互连设备324。在互连设备324处,其请求合并引擎251根据该多播请求的合并位确定该数据访问请求可以与其他数据访问请求合并(即接收到的是多播请求)。互连设备324的请求处理模块250的请求合并引擎251根据该多播组的MGID、MTID和静态路由策略,确定在互连设备324处将接收到来自多播组MGID=2中的其他处理器(即处理器314)的具有相同MGID和MTID的其他多播请求,并且将来自处理器312与来自处理器314的针对存储器334中的相同目标数据单元的多播请求进行合并。
在本文中,对于同一多播组使用相同的静态路由策略,即多播组中的每个处理器10将使用相同的路由策略通过互连网络200寻址到目的存储器30。这样,在给定网络拓扑结构的情况下,一个多播组中的一个处理器10对同一目标存储器30的数据访问请求将始终经由相同的互连设备20的集合进行路由,并且同一多播组中的多个处理器10针对同一数据单元的数据访问请求会尽可能早地在路由路径上的互连设备20处合并。例如,假设上述多播组MGID=2在多处理器系统3中使用x-y路由(即请求首先水平传播,然后垂直传播到目的存储器),则从处理器312到存储器334的多播请求将依次经由物理链路340、346、348和345路由通过互连设备322、324和328到达存储器334,而从处理器314到存储器334的多播请求将依次经由物理链路341、348和345路由通过互连设备324和328到达存储器334。因此,互连设备322的请求处理模块250的请求合并引擎251判断不会接收到来自多播组MGID=2的另一处理器314的具有相同MGID和MTID的其他多播请求,从而直接将从处理器312接收的多播请求转发给下一跳互连设备324。而互连设备324的请求处理模块250的请求合并引擎251判断将会接收到来自多播组MGID=2的另一处理器314的具有相同MGID和MTID的多播请求,因此将来自处理器312与来自处理器314的针对存储器334中的相同目标数据单元的多播请求进行合并。
此外,不同的多播组可以使用不同的静态路由策略。因此,在一个处理器10是多个不同的多播组的成员的情况下,其到达同一目的存储器30的路由可能不同。
此外,同一多播组的请求处理过程和响应处理过程可以使用不同的静态路由策略。例如其请求处理过程使用静态x-y路由策略,响应处理过程用静态y-x路由策略(即响应数据首先垂直传播,然后水平传播到发出请求的处理器)。
在本发明中,为了简化描述起见,对于所有的多播组的请求处理过程使用静态x-y路由策略,而对于所有的多播组的响应处理过程使用静态y-x路由策略,因此这些静态路由策略有时也称为多处理器系统2或3或者互连网络200而不是多播组的静态路由策略。
在一些实施例中,互连设备20的请求处理模块250的请求合并引擎251还确定所产生的合并请求是否已经包含了多播组中的所有处理器10的数据访问请求。如果包含了多播组中的所有处理器10的数据访问请求,则可以将合并请求的合并位设置为指示单播(例如将合并位设置为0),如果未包含多播组中的所有处理器10的数据访问请求,则可以将该合并请求的合并位设置为指示多播(例如将合并位保持或重新设置为1)。
以上述MGID=2的多播组为例,互连设备324的请求处理模块250的请求合并引擎251判断所产生的合并请求已经包含了来自该多播组的所有处理器312和314的数据访问请求,因此可以将该合并请求的合并位设置为0以指示单播,从而将该合并请求转换为单播请求。该单播请求从互连设备324经由物理链路348路由至互连设备328,互连设备328的请求处理模块250的请求合并引擎251根据该合并位确定接收到的请求是单播请求,因此直接将该请求路由至互连设备328的下一跳设备(在图3所示实例中为目的存储器334)。
在另一种实例中,假设对于MGID=0的多播组,其包含4个处理器312、314、316和318并且也使用x-y路由策略,这些处理器被编程为访问存储器334中的一个目标数据单元。在这种情况下,从处理器312到存储器334的多播请求将依次经由物理链路340、346、348和345路由通过互连设备322、324和328到达存储器334,从处理器314到存储器334的多播请求将依次经由物理链路341、348和345路由通过互连设备324和328到达存储器334,从处理器316到存储器334的多播请求将依次经由物理链路342、349和345路由通过互连设备326和328到达存储器334,而从处理器318到存储器334的多播请求将依次经由物理链路343和345路由通过互连设备328到达存储器334。在这种情况下,与上述实例中类似,互连设备324的请求合并引擎251对来自存储器312和314的多播请求进行合并,并且确定所产生的合并请求并未包含多播组MGID=0中的所有处理器的数据访问请求。在这种情况下,互连设备324将所产生的合并请求的合并位保持为1,即,该合并请求仍然是多播请求,并且将该合并请求传输至互连设备328。在互连设备328处,其对经由互连设备326的、来自处理器316的多播请求、来自处理器318的多播请求、来自互连设备324的合并请求进行进一步合并以产生新的合并请求,并且确定该新的合并请求包含了多播组MGID=0中的所有处理器的数据访问请求,从而将该新的合并请求的合并位设置为0以指示单播。
在上述描述中可以看出,每个互连设备20的请求处理模块250可以从其上一跳设备(处理器10或上一跳互连设备20)接收数据访问请求或合并请求,并且将该数据访问请求或合并请求发送给下一跳设备(存储器30或下一跳互连设备20)。因此,请求处理模块250应当配置请求输入接口和/或请求输出接口来执行请求的输入或输出。
在一些实施例中,互连设备20的请求处理模块250还包括第一数量的请求输入接口252。其中该第一数量应当设置为该请求处理模块250可能会收到的用于从该多播组访问同一目标数据单元的多播请求的最大数量。更具体地,如果互连网络200中的每个互连设备20都配置有请求处理模块250,则对于一个互连设备20来说,其需要配置的请求输入接口252的数量等于基于静态路由策略通向该互连设备20的物理链路的数量。另一方面,如果互连网络200中不是所有互连设备20都配置有请求处理模块250,则对于一个互连设备20来说,其需要配置的请求输入接口252的数量等于具有请求处理模块250的上一跳互连设备20的数量和与不具有请求处理模块250的上一跳互连设备20相连的处理器10的数量。
例如,在图3所示的多处理器系统3中,如果在所有4台互连设备322、324、326和328上都实现了请求处理模块250,则对于互连设备328,最多可以从每个物理链路343、348和349接收到一个多播请求。因此,在互连设备328上的请求处理模块250上需要配置3个请求输入接口252,每个请求输入接口252接收来自物理链路343、348和349之一的多播请求。
又例如,在图3所示的多处理器系统3中,如果仅在直接连接到存储器332或334的互连设备(即互连设备326和328)上实现了请求处理模块250,则对于互连设备328,从物理链路348最多可能有2个数据访问请求(即分别来自处理器312和314的数据访问请求),而从物理链路343和349中的每个可能有1个数据访问请求。因此,互连设备328上的请求处理模块250需要实现总共4个请求输入接口252。
其中,请求处理模块250的每个请求输入接口252被配置为接收来自不同处理器10或针对不同目的存储器30的数据访问请求。也就是说,来自一个处理器10的针对同一个目的存储器30的数据访问请求应当总是通过请求处理模块250的同一请求输入接口252输入,而来自不同处理器10或者针对不同目的存储器30的数据访问请求有可能需要通过请求处理模块250的不同请求输入接口252输入。
例如,在如图3所示的多处理器系统3中,在互连设备328中,来自处理器312的对存储器334中的数据单元的多播请求始终通过互连设备328的请求处理模块250的、与物理链路348对应的请求输入接口252输入,而来自两个不同的处理器314和316的对存储器334中数据的多播请求将分别来自两个不同的物理链路348和349,因此通过互连设备328的请求处理模块250的、分别与两个不同的物理链路348和349相对应的两个不同请求输入接口252输入。
另一方面,从处理器312到两个不同的存储器332和334的两个多播请求将分别通过两个不同的互连设备326和328各自的请求处理模块250的请求输入接口252输入。
在一些实施例中,互连设备20的请求处理模块250还包括第二数量的请求输出接口253,以向互连设备20的下一跳设备发送合并请求(或者没有执行合并操作时直接转发接收到的数据访问请求)。其中,该第二数量应当设置为该互连设备20可用来将合并请求发送到存储器30的输出物理链路(即图2中所示的每个互连设备20处的上行物理链路)的最大数量。互连设备20的输出物理链路的最大数量可以基于互连网络200的拓扑结构和静态路由策略确定。例如,在图3所示的多处理器系统3中,在对请求处理过程使用静态x-y路由策略的情况下,对于互连设备322来说,其可以配置2个请求输出接口,一个通过物理链路347向互连设备326(继而向存储器332)发送数据访问请求,另一个通过物理链路346向互连设备324(继而向存储器334)发送数据访问请求。类似地,对于互连设备324来说,其可以配置2个请求输出接口,一个通过物理链路346向互连设备322(继而向存储器332)发送数据访问请求,另一个通过物理链路348向互连设备328(继而向存储器334)发送数据访问请求;对于互连设备326来说,其可以配置2个请求输出接口,一个通过物理链路344向存储器332发送数据访问请求,另一个通过物理链路349向互连设备328(继而向存储器334)发送数据访问请求;对于互连设备328来说,其可以配置2个请求输出接口,一个通过物理链路345向存储器334发送数据访问请求,另一个通过物理链路349向互连设备326(继而向存储器332)发送数据访问请求。
此外,请求处理模块250被配置为将来自同一多播组中的同一处理器10并通过同一请求输入接口252输入的数据访问请求都通过同一请求输出接口253输出。由于每个多播组中的处理器10使用相同的静态路由策略来通过互连网络200传输多播请求,因此由同一多播组中的同一处理器10对同一目的存储器30产生的数据访问请求将始终通过相同的互连设备20的集合并且经由集合中的每个互连设备20的请求处理模块250的同一对{请求输入接口252,请求输出接口253}输入和输出。
注意,一个处理器10可以是多个多播组的成员,在不同的多播组使用不同的静态路由策略的情况下,从同一处理器10到同一存储器30但具有不同MGID的多播请求(这被视为是不同的多播请求)可能会经过不同的互连设备20的集合。例如,在图3所示的多处理器系统3中,如果一个多播组(如MGID = 0的多播组)使用静态x-y路由,则从处理器312到存储器334的多播请求将通过互连设备322、324和328;如果另一个多播组(如MGID = 1的多播组)使用静态y-x路由,则从处理器312到存储器334的多播请求将通过互连设备322、326和328。
通过在请求处理模块250中配置请求输入接口252和请求输出接口253,使得同一多播组中的同一处理器10对同一存储器30的数据访问请求(可能具有不同MTID)总是通过互连设备20的请求处理模块250的同一请求输入接口和同一请求输出接口。
例如,在图3所示的系统中,从一个多播组(如MGID = 0的多播组)中的处理器314到存储器334的所有多播请求将始终到达互连设备328的处理模块250的、与物理链路348对应的同一请求输入接口252,并且从同一请求输出接口253输出到存储器334。而从另一多播组(如MGID=2的多播组)中的处理器314到存储器334的多播请求已在互连设备324中转变为单播请求,所以可以直接通过互连设备328的请求处理模块250而无需经由特定的请求输入接口252和请求输出接口253。类似地,来自另一多播组(如MGID=2的多播组)中的处理器314到不同的存储器332的多播请求也不会通过互连设备328。
如前所述,通过在请求处理模块250中配置请求输入接口252和请求输出接口253,使得同一多播组中的同一处理器10对同一存储器30的数据访问请求总是通过互连设备20的同一请求输入接口和同一请求输出接口。在有多个多播组的情况下,每个互连设备20应当为每个多播组维护请求输入接口252和请求输出接口253之间的对应关系以避免混乱。这里,请求输入接口252和/或请求输出接口253可以是实现在请求处理模块250中的逻辑或物理接口。
为此,在一些实施例中,互连设备20的请求处理模块250还可以配置有多播组位图(Multicast Group Bitmap,MGB)存储单元254,其为可以向该互连设备20发送多播请求的每个多播组分别维护一组MGB。其中,每个MGB针对该请求处理模块250的每个请求输入接口252设置1个比特来指示是否将从该请求输入接口252接收多播请求。
假设一个互连设备20的请求处理模块250配置有Ni个请求输入接口252和No个请求输出接口253,并且假设最多Ng个多播组的多播请求可以通过该请求处理模块250。
在这种情况下,每个MGB的宽度均为Ni比特,一个比特对应于一个请求输入接口252。由于对多播请求使用静态路由策略,所以一个多播组最多可以有No个不同的MGB,即MGB存储单元254最多为一个多播组维护No个MGB。这样,MGB存储单元254最多需要存储No *Nt个MGB,最多需要Ni * No * Nt个比特,其中Nt是多播组的最大的不同MTID数目,Ni、No、Ng、Nt都为正整数。
MGB存储单元254中的MGB可以预先计算(例如通过软件计算),并在多处理器系统2或3中建立多播组时下载到各个互连设备20的请求处理模块250中,也可以由各个请求处理模块250根据多播组和互连网络200的配置自行计算。以下给出了一种软件计算MGB的编程实例:
对于每个多播组,
对于每个互连设备20的请求处理模块250
对于该请求处理模块250的每个请求输出接口253
将其MGB初始化为0
对于每个处理器10,基于静态路由策略计算请求输入接口252的比特值
如果计算的请求输入接口252的比特值不为0,将MGB的对应比特设置为1
这样,对于一个请求输出接口253来说,如果能够从某个请求输入接口252接收多播请求,则MGB中与该请求输入接口252对应的比特设置为预定值(如1),反之,如果不能从某个请求输入接口252接收多播请求,则MGB中与该请求输入接口252对应的比特设置为另一预定值(如0)。
例如,在图3所示的多处理器系统3中,互连设备326上的多播组MGID = 0的MGB集合可以计算如下:
在一种实例中,假设在所有4个互连设备322、324、326和328上都实现了请求处理模块250,则互连设备326的请求处理模块250可以配置3个请求输入接口252,它们分别从{物理链路342,物理链路347,物理链路349}接收多播请求,还可以配置2个请求输出接口253,它们向{物理链路344,物理链路349}发送数据访问请求。
与物理链路344的请求输出接口253相对应的MGB为{1、1、1},其指示互连设备326能够从3个物理链路342、347和349中的每个接收来自多播组MGID = 0的数据访问请求并通过物理链路344的请求输出接口253输出数据访问请求。
与物理链路349的请求输出接口253相对应的MGB为{1、1、0},其指示互连设备326能够从2个物理链路342和347中的每个接收来自多播组MGID = 0的数据访问请求并将其通过物理链路349的请求输出接口253输出数据访问请求,而不会从物理链路349接收到数据访问请求。这是因为,虽然互连设备326与物理链路342、347和349都相连,但是根据多处理器系统3的静态x-y路由策略,互连设备326只能将来自物理链路342和347的数据访问请求输出给物理链路349,不会将来自物理链路349的数据访问请求再次输出给物理链路349。
在另一种实例中,假设仅在互连设备326和328上实现了请求处理模块250,则互连设备326的请求处理模块250可以配置4个请求输入接口252,它们分别从{物理链路342,处理器312,处理器314,物理链路349}接收多播请求,还可以配置2个请求输出接口253,它们向{物理链路344,物理链路349}发送数据访问请求。
与物理链路344的请求输出接口253相对应的MGB为{1、1、1、1},其指示互连设备326能够从物理链路342、处理器312、处理器314以及物理链路349中的每一个接收来自多播组MGID = 0的数据访问请求并通过物理链路344输出数据访问请求。
与物理链路349的请求输出接口253相对应的MGB为{1、1、1、0},其指示互连设备326能够从物理链路342、处理器312、处理器314中的每一个接收来自多播组MGID = 0的数据访问请求并将其通过物理链路349的请求输出接口253输出数据访问请求,而不能从物理链路349接收数据访问请求。
如前所述,一个多播组内的处理器10针对同一组数据单元可能具有多个未完成的数据访问请求,并使用MTID来标识不同的未完成的数据访问请求。在这种情况下,每个互连设备20应当维护每个多播组的未完成的数据访问请求的状态。
为此,在一些实施例中,互连设备20的请求处理模块250还可以配置有请求合并表(Request Merge Table,RMT)存储单元255,其用于存储未完成的数据访问请求的状态信息。
具体地,在该RMT存储单元255中可以为每个MGID和MTID对维护一个RMT条目,该RMT条目可以存储接收到的具有相同{MGID,MTID}的多播请求的信息。存储在一个RMT条目中的信息可以包含关于数据访问请求的信息(如目的存储器30的信息)和合并过程的状态(例如已经接收到的具有该{MGID,MTID}对的数据访问请求的个数和对应的处理器10的信息)。
假设互连设备20的请求处理模块250设计能够支持的最大组播组数量是MGID_max,并且每个处理器10可以发送的未完成组播请求的最大数量是MTID_max,则RMT存储单元255最多需要实现RMT_max = MGID_max * MTID_max个条目。
由于通常不可能所有的组播组同时具有最大数量的未完成请求,因此在实际实现时可以将RMT存储单元255设计为实现少于RMT_max个条目以节省成本。
如果RMT存储单元255用完了所有空闲条目,请求处理模块250将停止接收需要新的RMT条目的多播请求,直到RMT存储单元255中再次出现空闲RMT条目。例如,如果一个互连设备20已经从目的存储器30接收到了针对该{MGID,MTID}对的响应数据并且将该响应数据下发给了下一跳设备,则该互连设备20可以删除RMT存储单元255中与该{MGID,MTID}对相关联的RMT条目的内容以释放该RMT条目。
在接收到一个多播请求时,请求合并引擎251确定该多播请求的{MGID,MTID}对是否存在于RMT存储单元255中的一个RMT条目中。如果确定接收到的多播请求的{MGID,MTID}对存在于RMT存储单元255的一个RMT条目中,请求合并引擎251向该RMT条目写入接收到的多播请求的信息,如发出该多播请求的处理器10的信息(处理器10的地址或标识符等),并且可以将该RMT条目中记录的接收到的多播请求的数量加一。
如果确定接收到的多播请求的{MGID,MTID}对不存在于RMT存储单元255的任何一个RMT条目中,请求合并引擎251在该RMT存储单元255为该{MGID,MTID}对分配一个空闲RMT条目,并将接收到的多播请求的信息写入该RMT条目。后续接收到的所有具有该{MGID,MTID}对的多播请求的信息都在该RMT条目中存储和更新。
此外,在请求合并引擎251对多个多播请求进行合并时,其可以将RMT存储单元255中的一个RMT条目中的所有多播请求合并为一个合并请求。这是因为,存储在一个RMT条目中的所有多播请求都具有相同的{MGID,MTID}对,因此具有相同的目的存储器30,可以使用相同的请求输出接口253以相同的路径路由至目的存储器30。
此外,请求合并引擎251还被配置为确定对多个多播请求进行合并的时机。具体地,在一种实施例中,如上所述,在每次接收到具有一个{MGID,MTID}对的多播请求时,请求合并引擎251在与该{MGID,MTID}对相关联的RMT条目中更新了接收到的多播请求的数量Req_num。因此请求合并引擎251可以确定该RMT条目中的更新后的多播请求的数量Req_num是否等于与该RMT条目相对应的MGB中被设置为预定值(如1)的比特的数量。当该RMT条目中的更新后的多播请求的数量Req_num等于与之相对应的MGB中被设置为该预定值的比特的数量时,请求合并引擎251判断已经接收到了针对该MGID和MTID的所有多播请求并且不会再接收到新的多播请求,因此将接收到的多播请求合并为一个合并请求并发送该合并请求。
或者,还可以在请求处理模块250中设置超时机制,当请求合并引擎251确定超过预定时间之后仍然没有接收到针对该MGID和MTID的所有多播请求时(例如多播组中的某些成员处理器无法发送其多播请求时),其将接收到的多播请求合并为一个合并请求并发送该合并请求。
与目的存储器30相连的互连设备20(例如图3中所示的互连设备328)将最终产生的单播请求发送给目的存储器30(如图3中所示的存储器334),目的存储器30读取该单播请求所请求的目标数据单元,并将该目标数据单元作为响应数据发送给与其相连的互连设备328。
利用互连设备20中的请求处理模块250,在最优情况(所有互连设备20中都具有请求处理模块250)下,一个多播组中的处理器10针对一个目标数据单元的数据访问请求可以在路由中的每个上行物理链路上仅传输一次,从而降低了上行链路带宽消耗。
如前所述,在一些实施例中,多处理器系统中的至少一些互连设备20还可以包括响应处理模块260,其将从目的存储器30接收的针对多播组的数据访问请求的响应数据复制出一个或多个副本,并且将响应数据的副本发送给其下一跳设备。
图5示出了根据本发明实施例的互连设备20中的响应处理模块260的结构示意图。
如图5中所示,响应处理模块260可以包括响应复制引擎261。响应复制引擎261被配置为接收来自目的存储器30的目标数据单元,并将其作为多播组对该目标数据单元的数据访问请求的响应数据。基于互连网络200的拓扑结构和静态路由策略,响应复制引擎261可以确定将该响应数据复制的副本数量。这里,用于响应数据传播的静态路由策略可以与上述用于数据访问请求的静态路由策略不同,以下也将其称为第二静态路由策略,其例如是静态y-x路由策略。
以图3为例,假设在所有4个互连设备322、324、326、328中都实现了响应处理模块260,并且多播组MGID=2包含处理器312和314,处理器312和314对存储器334中的一个目标数据单元发出了数据访问请求。如前所述,根据用于数据访问请求的静态路由政策,在互连设备324中,来自处理器312和314的数据访问请求合并并且产生单播请求,该单播请求经由互连设备328发送给目标存储器334,并且互连设备328从目标存储器334接收到了对该数据访问请求的响应数据。在这种情况下,在互连设备328处,互连设备328的响应处理模块260可以根据互连网络200的拓扑结构和第二静态路由策略,确定针对多播组MGID=2的数据访问请求的响应数据需要复制1份,并将该响应数据的副本发送给互连设备200的下一跳设备(即互连设备324)。在互连设备324处,互连设备324的响应处理模块260可以根据互连网络200的拓扑结构和第二静态路由策略,确定针对多播组MGID=2的数据访问请求的响应数据需要复制2份,一份通过物理链路341发送给处理器314,另一份通过物理链路346发送给互连设备322。在互连设备322处,互连设备322的响应处理模块260可以根据互连网络200的拓扑结构和第二静态路由策略,确定该响应数据需要复制1份,并将该响应数据的副本通过物理链路340发送给处理器312。
与请求处理模块250中的请求输入接口252和请求输出接口253类似,响应处理模块260还可以包括一个或多个响应输入接口262和/或一个或多个响应输出接口263。
每个响应输入接口262被配置为接收上述响应数据(或其副本)。
在一些实施例中,如果在一个互连设备20中同时实现了请求处理模块250和响应处理模块260,则该响应处理模块260仅需配置单个响应输入接口262。在这种情况下,响应复制引擎261可以从请求处理模块250的RMT存储单元255获取针对该MGID和MTID对的RMT条目,并且利用该RMT条目中的信息执行响应数据的多播。
在另一些实施例中,一个互连设备20中可能仅实现了响应处理模块260,则该响应处理模块260需要配置的响应输入接口262的数量应与可从其接收响应数据的物理链路的数量相同。例如,在图3所示的多处理器系统3中,互连设备326的响应处理模块260需要实现2个分别对应于输入物理链路344和349的输入响应接口262。
每个响应输出接口263被配置为将响应数据(或其副本)发送回请求处理器10。
在一些实施例中,如果在互连网络200的每个互连设备20上都实现了响应处理模块260,则互连设备20的响应输出接口263的数量被配置为与该互连设备20连接到处理器10的输出物理链路的数量相同。例如,在图3所示的多处理器系统3中,互连设备326的响应处理模块260需要实现3个分别与物理链路342、347和349对应的响应输出接口263。
在另一些实施例中,如果不是互连网络200的每个互连设备20上都实现了响应处理模块260,则对于直接连接到一个互连设备20的每个处理器10或已实现了响应处理模块260的互连设备20的每个输出物理链路,以及对于未直接连接到该互连设备20的处理器10并且向该处理器10发送响应数据的路由上所有互连设备20都未实现相应处理模块260的每个处理器10,互连设备326的响应处理模块260需要配置一个响应输出接口263。例如,在图3所示的多处理器系统3中,如果仅在互连设备326和328上实现了响应处理模块260,则互连设备326上的响应处理模块260需要实现与物理链路342、物理链路349、处理器312和处理器314对应的4个响应输出接口263。
与请求处理模块250中的MGB存储单元254类似,响应处理模块260还可以包括响应复制位图(Response Replicate Bitmap,RRB)存储单元265,其对于每个多播组维护一组响应复制位图RRB来确定应将响应数据发送到哪些响应输出接口263。
在一些实施例中,在同一互连设备20中实现了请求处理模块250,则响应处理模块260可以直接从请求处理模块250的RMT存储单元255获取其RMT条目作为一个RRB条目。具体地,与响应数据的{MGID,MTID}对相对应的RMT条目包含已接收到多播请求的输入请求接口252的位图,因此响应处理模块260可以将此位图用作针对该多播请求的响应数据的RRB。
在另一些实施例中,在同一互连设备20中未实现请求处理模块250,则响应处理模块260需要在RRB存储单元265中配置自己的RRB。与请求处理模块250的MGB类似,可以预先计算(例如通过软件计算)并配置RRB存储单元265中的RRB,也可以由响应处理模块260根据多播组和互连网络200的配置直接计算生成RRB。以下给出了一种软件计算RRB的编程实例:
对于每个多播组,
对于每个互连设备20的响应处理模块260
对于该响应处理模块260的每个响应输入接口262
将其RRB初始化为0
对于每个处理器10,基于第二静态路由策略计算响应输出接口263的比特值
如果计算的响应输出接口263的比特值不为0,将RRB的对应比特设置为1
例如,在图3所示的多处理器系统3中,如果在所有4个互连设备322、324、326、328中都实现了响应处理模块260,则在互连设备326处,与多播组MGID = 0的物理链路344的响应输入接口262相对应的RRB对于物理链路342和347而言比特值为1,并且对于物理链路349而言比特值为0。
响应处理模块260的响应复制引擎261执行从响应输入接口262接收到的响应数据的复制,并将复制的响应数据的副本发送到响应输出接口263。
在一些实施例中,如果在同一互连设备20中实现了请求处理模块250,则等待直至相应的RMT条目的合并过程完成(即,该RMT条目的所有多播请求都到达该互连设备20)或出现超时,该互连设备20才从目的存储器30请求该目标数据单元。
如果合并过程完成,则对于一个RRB条目中对应比特为预定值(如1)的响应输出接口262,对于连接到实现了响应处理模块260而没有实现请求处理模块250的同一下一跳互连设备20的一组响应输出接口263,响应复制引擎261将响应数据的一个副本通过该组响应输出接口263中的一个响应输出接口263发送到下一跳互连设备20,对于所有其他响应输出接口263,响应复制引擎261将响应数据的一个副本发送到每个响应输出接口263。
如果在合并过程完成之前发生超时,则响应复制引擎261将响应数据的一个副本发送到该请求处理模块250的相应请求输入接口252已收到RMT条目的多播请求的那些响应输出接口263中的每个响应输出接口263。这里,响应复制引擎261可以使用一个超时标志比特来将每个响应数据的副本标记为超时响应。
在这些实施例中,在完成发送响应数据后,响应复制引擎261可以释放其从RMT存储单元255获取的RMT条目。
在另一些实施例中,未在同一互连设备20中实现请求处理模块250。在这种情况下,如果响应复制引擎261将收到的响应数据被标记为超时响应,则响应复制引擎261仅将响应数据的一个副本发送到其相应的响应输出接口263,否则响应复制引擎261将响应数据的一个副本发送到RRB中对应位为1的每个响应输出接口263。
在另一些实施例中,代替在所有多播请求到达互连设备20后对这些多播请求进行合并,该互连设备20的请求处理模块250的请求合并引擎251可以采用另一种合并策略,即,在请求合并引擎251收到一个RMT条目的第一个多播请求之后立即向目的存储器30发送数据访问请求,从目的存储器30接收响应数据,并且将该响应数据存储在请求处理模块250中。具有相同{MGID,MTID}对的所有后续多播请求都记录在该RMT条目中,但是它们不会生成对目的存储器30的新请求。当请求合并引擎251确定已接收到所有多播请求或发生超时时,响应复制引擎261按照如上所述的方法将响应数据发送给各个处理器10。与所有多播请求到达互连设备20后对这些多播请求进行合并的合并策略相比,这种合并策略能够以较低的等待时间将响应数据返回到发出请求的处理器10,但是缺点是在请求处理模块250需要缓冲空间以临时存储响应数据。
图6示出了根据本发明实施例的用于互连网络200的信息处理方法600的示意性流程图。该信息处理方法600例如可以由图2所示的多处理器系统2中的互连设备20或图3所示的多处理器系统3中的互连设备322、324、326或328执行(以下统一使用互连设备20)。
如图6所示,在步骤610,互连设备20接收来自多个处理器10中的一个多播组中的至少一个处理器的数据访问请求。该数据访问请求可以包括合并位、MGID和MTID。
在步骤620,互连设备20基于该数据访问请求中的合并位确定该数据访问请求是否是多播请求,即,是否允许与其他多播请求进行合并。
如果确定该数据访问请求是多播请求(步骤620的判断为“是”),在步骤630,互连设备20基于MGID、MTID以及该多播组的静态路由策略确定该互连设备20是否会接收到来自该多播组中的其他处理器10的具有相同MGID和MTID的其他多播请求。
如果确定该互连设备20会接收到来自多播组中的其他处理器10的具有相同MGID和MTID的其他多播请求(步骤630的判断为“是”),在步骤640,互连设备20获取这些其他多播请求,并将所有多播请求合并为一个合并请求。
更具体地,在一些实施例中,在步骤640,互连设备20可以确定该合并请求是否包含了该多播组中的所有处理器10的数据访问请求。如果确定该合并请求包含了该多播组中的所有处理器10的数据访问请求,互连设备20将合并请求的合并位设置为指示单播以将该合并请求转换为单播请求。路由路径上的其他互连设备20根据该合并位可以确定接收到的是单播请求,即不再需要对接收到的请求进行合并。
在一些实施例中,在步骤640中,互连设备20可以利用请求合并表(RMT)来执行合并操作。
具体地,互连设备20可以确定接收到的多播请求的MGID和MTID对是否存在于该互连设备20的RMT存储单元(如RMT存储单元255)中的一个RMT条目中。如果确定接收到的多播请求的MGID和MTID对存在于该RMT存储单元中的一个RMT条目中,互连设备20向该RMT条目添加发送该多播请求的处理器10的信息并将该RMT条目中记录的接收到的多播请求的数量加一。反之,如果确定接收到的多播请求的MGID和MTID对未存在于该RMT存储单元中的任何一个RMT条目中,互连设备20在该RMT存储单元中分配一个空闲RMT条目并将该多播请求的信息添加到该空闲RMT条目中。
互连设备20将接收到的多播请求的数量记录在与该数据访问请求的MGID和MTID相关联的RMT条目中,并且确定接收到的多播请求的数量是否等于该互连设备20的第二数量的请求输出接口(如请求输出接口253)中与该多播组相对应的多播组位图MGB中被设置为预定值(如1)的比特的数量。如果确定接收到的多播请求的数量等于与请求输出接口253中与该多播组相对应的MGB中被设置为该预定值的比特的数量,将接收到的多播请求合并为该合并请求。
接下来,在步骤650,互连设备20可以根据该多播组的静态路由策略将该合并请求转发到其下一跳设备。这里,互连设备20的下一跳设备可以是处理器10或下一跳互连设备20,如图2和图3所示。
如果确定该数据访问请求不是多播请求(步骤620的判断为“否”)或者确定该互连设备20不会接收到来自该多播组中的其他处理器10的具有相同MGID和MTID的其他多播请求(步骤630的判断为“否”),则方法600直接进行到步骤650,互连设备20将接收到的数据访问请求转发至其下一跳设备。
此外,方法600还可以包括(图中未示出):在接收到针对该MGID和MTID的响应数据并将该响应数据发送给该互连设备20的下一跳设备之后,互连设备20释放该RMT存储单元中与该MGID和MTID相关联的RMT条目。这样,RMT存储单元中的RMT条目可以重复使用。
此外,方法600还可以包括(图中未示出):互连设备20可以接收来自目的存储器30的目标数据单元作为该多播组对该目标数据单元的数据访问请求的响应数据,并且基于互连网络200的拓扑结构的第二静态路由策略,确定将该响应数据复制的副本数量并将每个副本发送给与该互连设备20相连的下一跳设备。这里,与该互连设备20相连的下一跳设备可以是处理器10或下一跳互连设备20,如图2和图3中所示。
图7示出了根据本发明一些实施例的互连设备700的结构示意图。互连设备700可以是如上所述的互连设备20或322、324、326或328。
如图7中所示,互连设备700可以包括一个或多个处理单元710。处理单元710控制互连设备700的操作和功能。例如,在某些实施例中,处理单元710可以借助于与其耦合的一个或多个存储单元720中所存储的指令730来执行各种操作。存储单元720可以是适用于本地技术环境的任何合适的类型,并且可以利用任何合适的数据存储技术来实现,包括但不限于基于半导体的存储器件、磁存储器件和系统、光存储器件和系统。尽管图7中仅仅示出了一个处理单元710和一个存储单元720,但是在互连设备700中可以有更多个物理不同的处理单元710和存储单元720。
处理单元710可以是适用于本地技术环境的任何合适的类型,并且可以包括但不限于微处理器、数字信号处理器(DSP)等。
当互连设备700用来执行根据本发明所述的方案时,处理单元710可被配置(例如,由存储单元720中的指令730来配置)以实现上文参考图1至图6描述的方法600或互连设备20、322、324、326或328的功能。此外,存储单元720中还可以实现上文结合图2至图6所述的MGB存储单元254、RMT存储单元255、RRB存储单元265中的至少一个。上文参考图1至图6所描述的所有特征均适用于互连设备700,在此不再赘述。
本领域技术人员可以理解,这里所描述的方法步骤不仅仅局限于附图中所示例性示出的顺序,而是可以按照任何其他可行的顺序来执行。
在一个或多个示例性设计中,可以用硬件、软件、固件或它们的任意组合来实现本发明所述的功能。例如,如果用软件来实现,则可以将所述功能作为一个或多个指令或代码存储在计算机可读介质上,或者作为计算机可读介质上的一个或多个指令或代码来传输。
本文公开的互连设备的各个组成部分可以使用分立硬件组件来实现,也可以集成地实现在一个硬件组件上。例如,可以用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立门或者晶体管逻辑、分立硬件组件或用于执行本文所述的功能的任意组合来实现或执行结合本发明所描述的各种示例性的逻辑块、模块和电路。
本领域普通技术人员还应当理解,结合本发明的实施例描述的各种示例性的逻辑块、模块、电路和算法步骤可以实现成电子硬件、计算机软件或二者的组合。
本发明的以上描述用于使本领域的任何普通技术人员能够实现或使用本发明。对于本领域普通技术人员来说,本发明的各种修改都是显而易见的,并且本文定义的一般性原理也可以在不脱离本发明的精神和保护范围的情况下应用于其它变形。因此,本发明并不限于本文所述的实例和设计,而是与本文公开的原理和新颖性特性的最广范围相一致。

Claims (22)

1.一种互连设备,其用于互连网络,所述互连网络包括多个互连设备,所述多个互连设备连接多个处理器和多个存储器,其中所述互连设备包括:
请求处理模块,其被配置为:
接收来自所述多个处理器中的一个多播组中的至少一个处理器的数据访问请求,其中所述数据访问请求包括合并位、多播组标识符MGID和多播事务标识符MTID,所述MTID用于标识所述多播组针对所述多个存储器中的一个目的存储器的目标数据单元的未完成的数据访问请求;
基于所述合并位确定所述数据访问请求是否是多播请求,其中所述多播请求被允许与其他多播请求进行合并;
如果确定所述数据访问请求是多播请求,基于所述MGID、所述MTID以及所述多播组的静态路由策略确定所述互连设备是否会接收到其他多播请求,所述其他多播请求来自所述多播组中的其他处理器并且具有相同MGID和MTID;以及
如果确定所述互连设备会接收到所述其他多播请求,获取所述其他多播请求,将所述多播请求和所述其他多播请求合并为一个合并请求,并且将所述合并请求转发至所述互连设备的下一跳设备。
2.如权利要求1所述的互连设备,其中所述请求处理模块还被配置为:
如果确定所述数据访问请求不是多播请求或者确定所述互连设备不会接收到所述其他多播请求,将所述数据访问请求转发至所述下一跳设备,所述下一跳设备包括所述目的存储器或者所述互连网络中的下一跳互连设备。
3.如权利要求1所述的互连设备,其中所述请求处理模块还被配置为:
确定所述合并请求是否包含所述多播组中的所有处理器的数据访问请求;以及
如果确定所述合并请求包含所述多播组中的所有处理器的数据访问请求,将所述合并请求的合并位设置为指示单播以将所述合并请求转换为单播请求。
4.如权利要求1所述的互连设备,其中所述请求处理模块包括:
第一数量的请求输入接口,其中所述第一数量等于从所述多播组接收到的针对所述目标数据单元的多播请求的最大数量,并且如果所述互连网络中的每个互连设备都具有所述请求处理模块,则所述第一数量等于基于所述静态路由策略确定的输入物理链路的数量,如果所述互连网络中不是每个互连设备都具有所述请求处理模块,则所述第一数量等于具有所述请求处理模块的上一跳互连设备的数量和与不具有所述请求处理模块的上一跳互连设备相连的处理器的数量;
其中所述第一数量的请求输入接口分别被配置为接收来自不同处理器的数据访问请求或针对不同存储器的数据访问请求。
5.如权利要求4所述的互连设备,其中所述请求处理模块还包括:
第二数量的请求输出接口,其中所述第二数量等于基于所述静态路由策略和所述互连网络的拓扑结构确定的所述互连设备的输出物理链路的最大数量,其中所述请求处理模块被配置为将来自同一多播组中的同一处理器并通过同一请求输入接口输入的数据访问请求都通过同一请求输出接口输出。
6.如权利要求5所述的互连设备,其中所述请求处理模块还包括:
多播组位图MGB存储单元,所述MGB存储单元为所述多播组维护一组MGB,每个MGB针对所述第一数量的请求输入接口中的每个请求输入接口设置一个比特来指示是否从该请求输入接口接收数据访问请求。
7.如权利要求1所述的互连设备,其中所述请求处理模块包括:
请求合并表RMT存储单元,所述RMT存储单元用于为每个MGID和MTID对维护一个RMT条目,所述RMT条目包括发送具有所述MGID和MTID对的多播请求的处理器的信息、接收到的多播请求的数量和目的存储器的地址。
8.如权利要求7所述的互连设备,其中所述请求处理模块还被配置为:
确定接收到的多播请求的MGID和MTID对是否存在于所述RMT存储单元中的RMT条目中;
如果确定接收到的多播请求的MGID和MTID对存在于所述RMT存储单元中的RMT条目中,向所述RMT条目添加发送所述多播请求的处理器的信息,并且将所述RMT条目中记录的接收到的多播请求的数量加一;以及
如果确定接收到的多播请求的MGID和MTID对未存在于所述RMT存储单元中的任何一个RMT条目中,在所述RMT存储单元中分配一个空闲RMT条目,并且将所述多播请求的信息添加到所述空闲RMT条目中。
9.如权利要求8所述的互连设备,其中所述请求处理模块还被配置为:
在接收到针对所述MGID和所述MTID的响应数据并将所述响应数据发送给所述互连设备的下一跳设备之后,释放所述RMT存储单元中与所述MGID和所述MTID相关联的RMT条目。
10.如权利要求7所述的互连设备,其中所述请求处理模块还被配置为:
在与所述MGID和MTID相关联的RMT条目中记录接收到的多播请求的数量;
确定接收到的多播请求的数量是否等于与所述RMT条目相对应的MGB中被设置为预定值的比特的数量;以及
如果确定接收到的多播请求的数量等于与所述RMT条目相对应的MGB中被设置为预定值的比特的数量,将接收到的多播请求合并为所述合并请求。
11.如权利要求1所述的互连设备,还包括:
响应处理模块,其被配置为:
接收来自所述目的存储器的所述目标数据单元,并将其作为所述多播组对所述目标数据单元的数据访问请求的响应数据;以及
基于所述互连网络的拓扑结构的第二静态路由策略,确定将所述响应数据复制的副本数量并将每个副本发送给与所述互连设备相连的下一跳设备。
12.一种信息处理方法,包括,在互连设备处:
接收来自多个处理器中的一个多播组中的至少一个处理器的数据访问请求,其中所述数据访问请求包括合并位、多播组标识符MGID和多播事务标识符MTID,所述MTID用于标识所述多播组针对多个存储器中的一个目的存储器的目标数据单元的未完成的数据访问请求,所述多个处理器和所述多个存储器经由互连网络的多个互连设备连接;
基于所述合并位确定所述数据访问请求是否是多播请求,其中所述多播请求被允许与其他多播请求进行合并;
如果确定所述数据访问请求是多播请求,基于所述MGID、所述MTID以及所述多播组的静态路由策略确定所述互连设备是否会接收到其他多播请求,所述其他多播请求来自所述多播组中的其他处理器并且具有相同MGID和MTID;
如果确定所述互连设备会接收到所述其他多播请求,获取所述其他多播请求,并将所述多播请求和所述其他多播请求合并为一个合并请求;以及
将所述合并请求转发至所述互连设备的下一跳设备。
13.如权利要求12所述的信息处理方法,还包括:
如果确定所述数据访问请求不是多播请求或者确定所述互连设备不会接收到所述其他多播请求,将所述数据访问请求转发至所述下一跳设备,所述下一跳设备包括所述目的存储器或者所述互连网络中的下一跳互连设备。
14.如权利要求12所述的信息处理方法,其中将所述多播请求和所述其他多播请求合并为一个合并请求包括:
确定所述合并请求是否包含所述多播组中的所有处理器的数据访问请求;以及
如果确定所述合并请求包含所述多播组中的所有处理器的数据访问请求,将所述合并请求的合并位设置为指示单播,以将所述合并请求转换为单播请求。
15.如权利要求12所述的信息处理方法,其中将所述多播请求和所述其他多播请求合并为一个合并请求包括:
确定接收到的多播请求的MGID和MTID对是否存在于所述互连设备的RMT存储单元中的RMT条目中;
如果确定接收到的多播请求的MGID和MTID对存在于所述RMT存储单元中的RMT条目中,向所述RMT条目添加发送所述多播请求的处理器的信息,并且将该RMT条目中的接收到的多播请求的数量加一;以及
如果确定接收到的多播请求的MGID和MTID对未存在于所述RMT存储单元中的任何一个RMT条目中,在所述RMT存储单元中分配一个空闲RMT条目,并且将所述多播请求的信息添加到所述空闲RMT条目中。
16.如权利要求15所述的信息处理方法,还包括:
在与所述MGID和MTID相关联的RMT条目中记录接收到的多播请求的数量;
确定接收到的多播请求的数量是否等于与所述多播组相对应的多播组位图MGB中被设置为预定值的比特的数量;以及
如果确定接收到的多播请求的数量等于与MGB中被设置为预定值的比特的数量,将接收到的多播请求合并为所述合并请求。
17.如权利要求15所述的信息处理方法,还包括:
在接收到针对所述MGID和所述MTID的响应数据并将所述响应数据发送给所述互连设备的下一跳设备之后,释放所述RMT存储单元中与所述MGID和所述MTID相关联的RMT条目。
18.如权利要求12所述的信息处理方法,还包括:
接收来自所述目的存储器的所述目标数据单元,并将其作为所述多播组对所述目标数据单元的数据访问请求的响应数据;以及
基于所述互连网络的拓扑结构的第二静态路由策略,确定将所述响应数据复制的副本数量并将每个副本发送给与所述互连设备相连的下一跳设备。
19.一种互连设备,包括:
至少一个处理单元;以及
至少一个存储单元,所述至少一个处理单元被耦合到所述至少一个处理单元并且存储用于由所述至少一个处理单元执行的指令,所述指令当由所述至少一个处理单元执行时,使得所述互连设备执行根据权利要求12至18中任一项所述的方法的步骤。
20.如权利要求19所述的互连设备,其中所述至少一个处理单元包括MGB存储单元,所述MGB存储单元为所述多播组维护一组MGB,每个MGB针对所述互连设备的第一数量的请求输入接口中的每个请求输入接口设置一个比特来指示是否从该请求输入接口接收数据访问请求。
21.如权利要求19所述的互连设备,其中所述至少一个处理单元包括RMT存储单元,所述RMT存储单元用于为每个MGID和MTID对维护一个RMT条目,所述RMT条目包括发送具有所述MGID和MTID对的多播请求的处理器的信息、接收到的多播请求的数量和目的存储器的地址。
22.一种计算机可读存储介质,其上存储有计算机程序代码,所述计算机程序代码在被运行时执行如权利要求12至18中任一项所述的方法。
CN202011275787.4A 2020-11-16 2020-11-16 信息处理方法、互连设备和计算机可读存储介质 Active CN112073321B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202011275787.4A CN112073321B (zh) 2020-11-16 2020-11-16 信息处理方法、互连设备和计算机可读存储介质
US17/524,688 US11855878B2 (en) 2020-11-16 2021-11-11 Information processing method, interconnection device and computer-readable storage medium
US18/487,118 US12095654B2 (en) 2020-11-16 2023-10-15 Interconnection device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011275787.4A CN112073321B (zh) 2020-11-16 2020-11-16 信息处理方法、互连设备和计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN112073321A CN112073321A (zh) 2020-12-11
CN112073321B true CN112073321B (zh) 2021-02-09

Family

ID=73655136

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011275787.4A Active CN112073321B (zh) 2020-11-16 2020-11-16 信息处理方法、互连设备和计算机可读存储介质

Country Status (2)

Country Link
US (2) US11855878B2 (zh)
CN (1) CN112073321B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112783648B (zh) * 2021-01-18 2023-03-14 上海壁仞智能科技有限公司 基于内存区域的内存分配方法和设备以及访问方法和设备
CN113285880B (zh) * 2021-07-19 2021-10-15 北京壁仞科技开发有限公司 多播路由方法、互连设备、网状网络系统及其配置方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019046609A1 (en) * 2017-08-30 2019-03-07 Idac Holdings, Inc. RESOURCE REQUEST PROCESSING
CN110574340A (zh) * 2017-03-24 2019-12-13 甲骨文国际公司 在高性能计算环境中提供相对于分区成员资格定义的多播组成员资格的系统和方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8121122B2 (en) * 2006-08-23 2012-02-21 International Business Machines Corporation Method and device for scheduling unicast and multicast traffic in an interconnecting fabric
US8948023B2 (en) * 2010-08-31 2015-02-03 Cisco Technology, Inc. Enhancing mtrace to detect failure in multicast diverse paths
US20130064164A1 (en) * 2011-09-09 2013-03-14 Electronics And Telecommunications Research Institute Method and apparatus for managing multicast service
US10581711B2 (en) * 2016-01-28 2020-03-03 Oracle International Corporation System and method for policing network traffic flows using a ternary content addressable memory in a high performance computing environment

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110574340A (zh) * 2017-03-24 2019-12-13 甲骨文国际公司 在高性能计算环境中提供相对于分区成员资格定义的多播组成员资格的系统和方法
WO2019046609A1 (en) * 2017-08-30 2019-03-07 Idac Holdings, Inc. RESOURCE REQUEST PROCESSING

Also Published As

Publication number Publication date
CN112073321A (zh) 2020-12-11
US20220158929A1 (en) 2022-05-19
US20240048475A1 (en) 2024-02-08
US12095654B2 (en) 2024-09-17
US11855878B2 (en) 2023-12-26

Similar Documents

Publication Publication Date Title
US11003604B2 (en) Procedures for improving efficiency of an interconnect fabric on a system on chip
US7840675B2 (en) Multi node server system
TW544589B (en) Loosely coupled-multi processor server
CN100370443C (zh) 集成电路
US12095654B2 (en) Interconnection device
US8989193B2 (en) Facilitating insertion of device MAC addresses into a forwarding database
US8204054B2 (en) System having a plurality of nodes connected in multi-dimensional matrix, method of controlling system and apparatus
US9369298B2 (en) Directed route load/store packets for distributed switch initialization
TW201543218A (zh) 具有多節點連接的多核網路處理器互連之晶片元件與方法
JP2010250813A (ja) ストレージシステムのための方法及びシステム
WO2021114768A1 (zh) 数据处理装置、方法、芯片、处理器、设备及存储介质
US7716409B2 (en) Globally unique transaction identifiers
US6408365B1 (en) Multiprocessor system having means for arbitrating between memory access request and coherency maintenance control
US8069273B2 (en) Processing module
JP4605874B2 (ja) マルチプロセッサによる通信プロトコル処理装置
KR101016984B1 (ko) 집적 회로 및 요청 전송 방법
CN114095289B (zh) 数据多播电路、方法、电子设备及计算机可读存储介质
SU1481786A1 (ru) Локальна вычислительна сеть
JPH0158542B2 (zh)
JP2001111555A (ja) セルコピー装置

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
CP03 Change of name, title or address
CP03 Change of name, title or address

Address after: Room 0106-508, 1st floor, No.26, shangdixin Road, Haidian District, Beijing 100085

Patentee after: Beijing Bilin Technology Development Co.,Ltd.

Country or region after: China

Patentee after: Shanghai Bi Ren Technology Co.,Ltd.

Address before: Room 0106-508, 1st floor, No.26, shangdixin Road, Haidian District, Beijing 100085

Patentee before: Beijing Bilin Technology Development Co.,Ltd.

Country or region before: China

Patentee before: Shanghai Bilin Intelligent Technology Co.,Ltd.