一种基于容器的多芯片管理方法和装置与流程

本发明涉及集成电路技术领域，具体涉及一种基于容器的多芯片管理方法和装置。

背景技术：

针对交换机、分流器等通信领域或其他领域的软硬件方案中对于多芯片管理的需求，在芯片供应商本身提供的sdk(softwaredevelopmentkit，即软件开发包)不具备管理多pcie芯片的能力的情况下，如何实现单cpu管理多个pcie芯片成为本领域亟待解决的技术问题之一。

在通信领域的设备设计中，cpu对大型pcie从属芯片(交换芯片、网络处理器等)的管理是常见的需求。

这种管理，在硬件上是cpu和从属芯片通过pcie接口互联，cpu处在pcie主控地位，交换芯片或者网络处理器等则处于pcie从属地位。

在软件上，cpu上一般运行linux操作系统(包括下属pcie设备的驱动软件)以及该pcie设备的上层sdk(softwaredevelopmentkit，即软件开发包)。其中：

linux的驱动软件(一般也是pcie从属芯片的厂商提供)负责芯片的底层管理，包括为pcie从属芯片分配物理地址空间、中断号资源、生成用户态可访问的devfs和sysfs接口

上层sdk一般负责芯片的功能管理和业务应用，包括芯片的业务功能初始化、业务运行管理。这里，上层sdk其实是通过调用驱动软件生成的devfs和sysfs接口实现的对芯片的管理控制。

linux的驱动软件一般都能够做到对多个同型号的pcie从属芯片进行管理和向用户态提供访问接口。但因为各种原因(主要是pcie从属芯片的厂商对上层sdk设计上不够完善、编码风格不够良好)，上层sdk无法同时管理多个同型号pcie从属芯片。

为了解决上层sdk无法同时管理多个同型号pcie从属芯片的问题，现有技术中提供了以下几个方案：

通过调整sdk的设计来实现。这些上层sdk的代码规模一般也很庞大，有的达到几百万行代码。想要通过调整sdk的设计达到该目的，工作量会很大，并且耗时较长；有时客户的需求较为紧急，这在实际应用中就不是个很好的选项了。

调整硬件方案，通过多个cpu来分别管理这些pcie从属芯片(交换芯片、网络处理器等)。这种方案会增加硬件成本(多出了cpu)，同时会使得pcb板上更为拥挤，增加了pcb设计的难度。并且，由多个cpu来管理多个pcie从属芯片时，各个芯片的统一管理变得更为困难了，需要多个cpu通过网络等方式进行交互沟通，设计成本较高。

技术实现要素：

有鉴于此，本发明实施例提供一种基于容器的多芯片管理方法和装置，以实现采用一个cpu对多个剧透相同端口号的芯片进行管理。

为实现上述目的，本发明实施例提供如下技术方案：

一种基于容器的多芯片管理方法，包括：

采用目标容器模拟与被监控对象相匹配的操作系统；

每个操作系统运行一个目标进程，所述目标进程用于实现被监控对象与监控主机之间的数据交互；

通过所述目标进程对所述被监控对象的内核态接口进行访问，以实现所述被监控对象对所述被监控对象的数据读写操作和指令下发操作；

基于访问结果，采用预设的端口映射机制将所述被监控对象的端口号映射成目标端口号，所述不同的被监控对象对应的目标端口号不同；

将所述目标端口号以及通过所述目标进程对所述被监控对象的读写数据发送至监控主机，并基于所述目标端口号，将所述监控主机下发的数据包送至与所述目标端口号相匹配的被监控对象。

可选的，上述基于容器的多芯片管理方法中，采用目标容器模拟与被监控对象相匹配的操作系统，包括：

采用与被监控对象相匹配的两个目标容器模拟与被监控对象相匹配的操作系统；

通过所述目标进程对所述被监控对象的内核态接口进行访问，包括：

采用其中一个目标容器的目标进程对所述被监控对象的第一目标队列的元素进行访问；

采用另一个目标容器的目标进程对所述被监控对象的第二目标队列的元素进行访问。

可选的，上述基于容器的多芯片管理方法中，所述第一目标队列为所述被监控对象的devfs中的对队列；

所述第二目标队列为和所述被监控对象的sysfs中的队列。

可选的，上述基于容器的多芯片管理方法中，所述采用预设的端口映射机制将所述被监控对象的端口号映射成目标端口号，包括：

采用预设的端口映射机制将所述被监控对象的tcp/ip端口号映射成目标端口号。

可选的，上述基于容器的多芯片管理方法中，当所述被监控对象的操作系统为linux操作系统时，所述目标容器模拟的操作系统为ubuntu操作系统。

一种基于容器的多芯片管理装置，包括：

监控主机、被监控设备和接口转换单元；

所述接口转换单元内置有目标容器，所述接口转换单元具体用于：

采用目标容器模拟与被监控对象相匹配的操作系统；

每个操作系统运行一个目标进程，所述目标进程用于实现被监控对象与监控主机之间的数据交互；

通过所述目标进程对所述被监控对象的内核态接口进行访问，以实现所述被监控对象对所述被监控对象的数据读写操作和指令下发操作；

基于访问结果，采用预设的端口映射机制将所述被监控对象的端口号映射成目标端口号，所述不同的被监控对象对应的目标端口号不同；

将所述目标端口号以及通过所述目标进程对所述被监控对象的读写数据发送至监控主机，并基于所述目标端口号，将所述监控主机下发的数据包送至与所述目标端口号相匹配的被监控对象。

可选的，上述基于容器的多芯片管理装置中，采用目标容器模拟与被监控对象相匹配的操作系统，包括：

采用与被监控对象相匹配的两个目标容器模拟与被监控对象相匹配的操作系统；

通过所述目标进程对所述被监控对象的内核态接口进行访问，包括：

采用其中一个目标容器的目标进程对所述被监控对象的第一目标队列的元素进行访问；

采用另一个目标容器的目标进程对所述被监控对象的第二目标队列的元素进行访问。

可选的，上述基于容器的多芯片管理装置中，所述第一目标队列为所述被监控对象的devfs中的对队列；

所述第二目标队列为和所述被监控对象的sysfs中的队列。

可选的，上述基于容器的多芯片管理装置中，所述采用预设的端口映射机制将所述被监控对象的端口号映射成目标端口号，包括：

采用预设的端口映射机制将所述被监控对象的tcp/ip端口号映射成目标端口号。

可选的，上述基于容器的多芯片管理装置中，当所述被监控对象的操作系统为linux操作系统时，所述目标容器模拟的操作系统为ubuntu操作系统。

基于上述技术方案，本发明实施例提供的上述方案，为了解决监控主机无法同时管理多个同型号的被监控对象的问题，本申请计并成功应用了一种通过目标容器来管理多个被监控对象的方案，它只需要一个cpu即可实现，同时又几乎不需要修改被监控对象芯片的sdk，无需增加硬件成本，使得本方案在实际应用中具备良好的可行性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例公开的基于容器的多芯片管理方法的流程示意图；

图2为本申请实施例公开的基于容器的多芯片管理方法的应用场景示意图；

图3为本申请实施例公开的基于容器的多芯片管理装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了提高处理速度，降低处理成本，本申请提供了一种基于docker容器管理多芯片的方案，首先，本申请先对本方案的大致原理和思想进行简要说明：

硬件上，无需对现有的硬件系统做大的调整。必要的调整是让各个pcie从属芯片具备识别自身序号的能力，并且能够通过pcie接口，让cpu获取各个pcie芯片的序号。所述pcie芯片的序号用于在多芯片场景下让cpu通过序号做管理策略的相应差异化。一般来说，可以让pcie下挂cpu的gpio管脚，cpu通过gpio管脚的拉高或者拉低标记芯片的序号。

软件上，方案的关键在于在一个cpu上建立多个docker容器软件实体，在每个docker容器中运行独立的sdk进程，通过这些sdk进程和芯片驱动生成的devfs和sysfs建立的一一映射关系，从而通过多个docker容器实现对多芯片的管理。

docker容器是一个开源的应用容器引擎，让开发者可以以统一的方式打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何安装了docker引擎的服务器上(包括当下流行的linux系统机器、windows系统机器)，也可以实现虚拟化。docker容器是完全使用沙箱机制，相互之间不会有任何接口(类似iphone的app)。几乎没有性能开销,可以很容易地在机器和数据中心中运行。最重要的是,他们不依赖于任何语言、框架包括系统。

docker容器的ce版本(communityedition，即社区版本)的获取成本和使用成本较低，这一点降低了我们软件方案的成本。

docker容器使用namespace和cgroup技术，实现了多重隔离，使得在目标系统上运行在同一个cpu但是不同docker容器中的sdk进程，能够像运行在多个独立的cpu上一样。这些多重隔离包括：

文件系统的隔离；

网络的隔离；

进程间的通信的隔离；

针对权限，用户和用户组的隔离；

进程内的pid(进程号processindex)也需要与宿主机中的pid进行隔离；

容器也要有自己的主机名；

图1为本申请实施例公开的基于容器的多芯片管理方法，参见图1，方法包括：

步骤s101：采用目标容器模拟与被监控对象相匹配的操作系统；

在本方案中，所述目标容器的具体类型可以基于用户需求自行选择，例如，所述目标容器可以为docker容器，所述docker容器是一个开源的应用容器引擎，在本方案中，所述被监控对象的操作系统可以为linux操作系统或是windows操作系统，所述目标容器可以基于被监控对象的操作系统，在所述目标容器中加载与之匹配的操作系统，例如，当所述被监控对象的操作系统为linux操作系统时，在设计时会预先在所述目标容器内模拟出一个ubuntu操作系统。

步骤s102：每个操作系统运行一个目标进程，所述目标进程用于实现被监控对象与监控主机之间的数据交互；

在本步骤中，所述目标容器通过所加载的操作系统模拟一个目标进程，所述目标容器在工作时，执行该目标进程，通过执行该目标进程，实现监控主机与被监控对象之间的数据交互，例如，所述目标进程可以是被监控对象中的pcie从属芯片厂商提供的sdk生成的程序。

步骤s103：通过所述目标进程对所述被监控对象的内核态接口进行访问，以实现所述被监控对象对所述被监控对象的数据读写操作和指令下发操作；

在本申请上述实施例公开的技术方案中，所述目标进程可以为bf_switchd进程或者是其他具有数据访问功能的进程，在软件上，每个bf_switchd进程(即sdk软件)对被监控对象相应的被监控对象的内核态接口(devfs和sysfs中队列的对应元素)进行访问，即实现了目标容器到对被监控对象的访问控制，通过所述目标进程和内核态接口，实现对所述被监控对象的数据的读写以及将监控主机的指令下达至所述被监控对象。

步骤s104：基于访问结果，采用预设的端口映射机制将所述被监控对象的端口号映射成目标端口号，所述不同的被监控对象对应的目标端口号不同；

每个目标容器中的bf_switchd进程会通过目标端口中的端口映射机制，把原先所述被监控对象的固定的tcp/ip端口号向外映射成不同的端口号，使得不同的被监控对象对应的目标端口号不同，即，本步骤中，采用预设的端口映射机制将所述被监控对象的tcp/ip端口号映射成目标端口号。例如，图2中，某一目标容器ubuntu0把被监控对象的9090这个通信端口向外映射为24601，另一docker容器ubuntu1把另一个被监控对象的9090这个通信端口向外映射为24701。这样，位于所述监控主机内的统一管理软件thriftapp就能通过不同的端口号，区分管理两个从属芯片((bfasici和bfasicii))，其中，所述从属芯片即为所述被监控对象。其中，附图3中的software代表软件侧实体，hardware代表硬件侧实体。

步骤s105：将所述目标端口号以及通过所述目标进程对所述被监控对象的读写数据发送至监控主机，并基于所述目标端口号，将所述监控主机下发的数据包送至与所述目标端口号相匹配的被监控对象；

在本方案中，所述目标容器将映射得到的端口号、以及由所述被监控对象采集到的数据发送至所述监控主机，所述监控主机在获取到所述端口号和所述目标容器的采集数据以后，对所述采集数据进行分析，并基于分析结果通过所述目标容器向所述被监控对象发送控制指令。

在上述方案中，为了解决监控主机无法同时管理多个同型号的被监控对象的问题，本申请计并成功应用了一种通过目标容器来管理多个被监控对象的方案，它只需要一个cpu即可实现，同时又几乎不需要修改被监控对象芯片的sdk，无需增加硬件成本，使得本方案在实际应用中具备良好的可行性。

在本申请实施例公开的技术方案中，所述目标容器的数量为两个，两个目标容器内所加载的目标进程相同，且模拟的操作系统也相同，其中一个目标容器用于对被监控对象相应的被监控对象的内核态接口devfs进行访问，另一个目标容器用于对被监控对象相应的被监控对象的内核态接口sysfs进行访问，

采用目标容器模拟与被监控对象相匹配的操作系统，包括：

采用与被监控对象相匹配的两个目标容器生成模拟与被监控对象相匹配的操作系统；

通过所述目标进程对所述被监控对象的内核态接口进行访问，包括：

采用其中一个目标容器的目标进程对所述被监控对象的第一目标队列(devfs)的元素进行访问；

采用另一个目标容器的目标进程对所述被监控对象的第二目标队列(sysfs)的元素进行访问。

所述第一目标队列为所述被监控对象的devfs中的对队列；

所述第二目标队列为和所述被监控对象的sysfs中的队列。

本实施例中，对应于上述方法，还公开了一种基于容器的多芯片管理装置，装置中的各个单元的具体工作内容，请参见上述方法实施例的内容，下面对本发明实施例提供的基于容器的多芯片管理装置进行描述，下文描述的基于容器的多芯片管理装置与上文描述的基于容器的多芯片管理方法可相互对应参照。

参见图3，该基于容器的多芯片管理装置，可以包括：

监控主机100、被监控设备200和接口转换单元300，其中，所述接口转换单元300可以集成在所述监控主机中，加载在所述监控主机中的某个处理芯片内；

所述接口转换单元内置有目标容器，所述接口转换单元具体用于：

采用目标容器模拟与被监控对象相匹配的操作系统；

每个操作系统运行一个目标进程，所述目标进程用于实现被监控对象与监控主机之间的数据交互；

通过所述目标进程对所述被监控对象的内核态接口进行访问，以实现所述被监控对象对所述被监控对象的数据读写操作和指令下发操作；

基于访问结果，采用预设的端口映射机制将所述被监控对象的端口号映射成目标端口号，所述不同的被监控对象对应的目标端口号不同；

将所述目标端口号以及通过所述目标进程对所述被监控对象的读写数据发送至监控主机，并基于所述目标端口号，将所述监控主机下发的数据包送至与所述目标端口号相匹配的被监控对象。

与上述方法相对应，采用目标容器模拟与被监控对象相匹配的操作系统，包括：

采用与被监控对象相匹配的两个目标容器模拟与被监控对象相匹配的操作系统；

通过所述目标进程对所述被监控对象的内核态接口进行访问，包括：

采用其中一个目标容器的目标进程对所述被监控对象的第一目标队列的元素进行访问；

采用另一个目标容器的目标进程对所述被监控对象的第二目标队列的元素进行访问。

与上述方法相对应，所述第一目标队列为所述被监控对象的devfs中的对队列；

所述第二目标队列为和所述被监控对象的sysfs中的队列。

与上述方法相对应，所述采用预设的端口映射机制将所述被监控对象的端口号映射成目标端口号，包括：

采用预设的端口映射机制将所述被监控对象的tcp/ip端口号映射成目标端口号。

与上述方法相对应，当所述被监控对象的操作系统为linux操作系统时，所述目标容器模拟的操作系统为ubuntu操作系统。

为了描述的方便，描述以上系统时以功能分为各种模块分别描述。当然，在实施本发明时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。