本发明涉及服务器内延迟控制装置、服务器内延迟控制方法以及程序。
背景技术：
1、以基于nfv(network functions virtualization：网络功能虚拟化)的虚拟化技术的进展等为背景，针对每个服务构建并运用系统。此外，根据上述针对每个服务构建系统的方式，将服务功能分割为可再利用的模块单位，并使其在独立的虚拟机(vm：virtualmachine、容器等)环境上动作，由此，如组件那样根据需要利用并提高运用性这样的被称为sfc(service function chaining：服务功能链)的方式逐渐成为主流。
2、作为构成虚拟机的技术，已知由linux(注册商标)和kvm(kernel-based virtualmachine：基于内核虚拟机)构成的虚拟机监控程序(hypervisor)环境。在该环境中，嵌入有kvm模块的母操作系统(host os，将安装在物理服务器上的os称为母操作系统)作为虚拟机监控程序在与被称为内核空间的用户空间不同的存储器区域中动作。在该环境中，虚拟机在用户空间中动作，子操作系统(guest os，将安装在虚拟机上的os称为子操作系统)在该虚拟机内动作。
3、供子操作系统动作的虚拟机与供母操作系统动作的物理服务器不同，包括(以太网卡设备等为代表的)网络设备的所有的hw(hardware：硬件)，执行从hw到子操作系统的中断处理、从子操作系统到硬件的写入所需的寄存器控制。在这样的寄存器控制中，原本应该由物理硬件来执行的通知、处理被以软件模拟的方式模仿，因此相比于母操作系统环境，性能一般较低。
4、在该性能劣化的情况下，特别是针对从子操作系统向存在于自虚拟机外的母操作系统、外部进程，存在削减hw的模仿，通过高速且统一的接口提高通信的性能和通用性的技术。作为该技术，开发了virtio这一设备的抽象化技术即准虚拟化技术，已经嵌入至以linux为首、freebsd(注册商标)等多个通用os中，当前正在被利用。
5、在virtio中，关于控制台、文件输入输出以及网络通信等数据输入输出，作为传输数据的单向的传输用运输(transport)，通过队列的操作来定义由环状缓冲器设计的队列进行的数据交换。然后，利用virtio的队列的技术规格，通过在子操作系统起动时准备好适合各个设备的队列的个数和大小，能够不执行硬件仿真而只通过队列的操作来实现子操作系统和自虚拟机外部的通信。
6、[基于轮询模型的数据包传输(dpdk的例子)]
7、使多个虚拟机连接、协作的方法被称为inter-vm communication(vm间通信)，在数据中心等大规模的环境中，虚拟交换机已被标准地用于连接vm之间。但是，由于是通信的延迟大的方法，因此新提出了更高速的方法。例如，提出了使用被称为sr-iov(single rooti/o virtualization：单根i/o虚拟化)的特殊硬件的方法、基于使用作为高速数据包处理库的intel dpdk(intel data plane development kit：英特尔数据平面开发套件)(以下，称为dpdk)的软件的方法等。
8、dpdk是用于在用户空间进行以往linux kernel(注册商标)进行的nic(networkinterface card：网络接口卡)的控制的框架。与linux kernel中的处理的最大的不同是，具有被称为pmd(pull mode driver：轮询模式驱动)的基于轮询的接收机构。通常，在linuxkernel中，响应于向nic的数据的到达而发生中断，并以此为契机执行接收处理。另一方面，pmd由专用线程持续进行数据到达的确认、接收处理。通过排除上下文切换、中断等开销，能够进行高速的数据包处理。dpdk极大地提高了数据包处理的性能和吞吐量，并能为数据平面/应用处理确保更多的时间。
9、dpdk占有性地使用cpu(central processing unit：中央处理单元)、nic等计算机資源。因此，很难适用于像sfc那样以模块为单位灵活地换接的用途。spp(soft patchpanel：软件修补面板)是用于缓解这种情况的应用。spp设为通过在vm之间准备共享存储器，各vm能够直接参照相同的存储器空间的构成，由此省略在虚拟化层的数据包复制。此外，在物理nic和共享存储器间的数据包的交换中，使用dpdk来实现高速化。spp可以通过控制各vm的存储器交换的参照目的地来软件地变更数据包的输入目的地、输出目的地。通过该处理，spp实现vm之间、vm和物理nic之间的动态连接切换。
10、[基于new api(napi)的rx侧数据包处理]
11、图22是由linux kernel 2.5/2.6实施的基于new api(napi)的rx侧数据包处理的概略图(参照非专利文献1)。
12、如图22所示，在具备os70(例如，母操作系统)的服务器上，执行配置于用户能使用的用户空间60的数据包处理apl1，new api(napi)在连接于os70的hw10的nic11与数据包处理apl1之间进行数据包传输。
13、os70具有内核71、环状缓冲器72、以及驱动程序73，内核71具有协议处理部74。
14、内核71是os70(例如，母操作系统)的核心部分的功能，以进程为单位管理硬件的监视、程序的执行状态。在此，内核71能响应来自数据包处理apl1的请求，并且能将来自hw10的请求传达给数据包处理apl1。内核71经由系统调用(“在非特权模式下动作的用户程序”委托“在特权模式下动作的内核”进行处理)对来自数据包处理apl1的请求进行处理。
15、内核71经由套接字75向数据包处理apl1传递数据包。内核71经由套接字75从数据包处理apl1接收数据包。
16、环状缓冲器72由内核71管理，位于服务器中的存储器空间内。环状缓冲器72是将内核71所输出的消息储存为日志的固定大小的缓冲器，当超过上限大小时，从头开始覆盖。
17、驱动程序73是用于由内核71进行硬件的监视的设备驱动程序。需要说明的是，驱动程序73依赖于内核71，如果创建的(构建的)内核源代码发生变化，则会变成其他驱动程序。在该情况下，获取相应的驱动程序/源代码，在使用驱动程序的os上重新构建，创建驱动程序。
18、协议处理部74进行由osi(open systems interconnection：开放系统互连)参照模型定义的l2(数据链路层)/l3(网络层)/l4(传输层)的协议处理。
19、套接字75是用于内核71进行进程间通信的接口。套接字75具有套接字缓冲器，不会频繁地发生数据的复制处理。经由套接字75建立通信为止的流程如下：1.服务器侧创建接受客户端的套接字文件。2.为接受用套接字文件命名。3.创建套接字/队列。4.接受进入套接字/队列的来自客户端的连接的第一个。5.在客户端侧创建套接字文件。6.从客户端侧向服务器发出连接请求。7.在服务器侧，不同于接受用套接字文件，创建连接用套接字文件。建立通信的结果是，数据包处理apl1能向内核71调用read()、write()等系统调用。
20、在以上的构成中，内核71通过硬件中断(hardirq)领取来自nic11的数据包到达的通知，调度用于数据包处理的软件中断(softirq)。
21、上述通过linux kernel 2.5/2.6实现的new api(napi)在数据包到达时，在硬件中断(hardirq)后通过软件中断(softirq)来进行数据包处理。如图22所示，基于中断模型的数据包传输通过中断处理(参照图22的附图标记a)进行数据包的传输，因此发生中断处理的等待，数据包传输的延迟变大。
22、以下，对napi rx侧数据包处理概要进行说明。
23、[基于new api(napi)的rx侧数据包处理构成]
24、图23是对图22的虚线包围的部位的基于new api(napi)的rx侧数据包处理的概要进行说明的图。
25、<设备驱动程序>
26、如图23所示，在设备驱动程序配置有：nic11(物理nic)，其是网络接口卡；hardirq81，其是通过nic11的处理请求的发生而被调用，执行请求的处理(硬件中断)的处理程序；以及netif_rx82，其是软件中断的处理功能部。
27、<网络层>
28、在网络层配置有：softirq83，其是通过netif_rx82的处理请求的发生而被调用，执行请求的处理(软件中断)的处理程序；以及do_softirq84，其是进行软件中断(softirq)的实体的控制功能部。此外，配置有：net_rx_action85，其是响应于软件中断(softirq)而执行的数据包处理功能部；poll_list86，其登记表示来自nic11的硬件中断是哪个设备的中断的网络设备(net_device)的信息；netif_receive_skb87，其创建sk_buff结构体(用于使内核71感知数据包怎样的结构体)；以及环状缓冲器72。
29、<协议层>
30、在协议层配置有作为数据包处理功能部的ip_rcv88、arp_rcv89等。
31、上述netif_rx82、do_softirq84、net_rx_action85、netif_receive_skb87、ip_rcv88、以及arp_rcv89是在内核71中用于数据包处理的程序的组件(函数的名称)。
32、[基于new api(napi)的rx侧数据包处理动作]
33、图23的箭头(附图标记)b～m表示rx侧数据包处理的流程。
34、当从对方装置接收到帧内的数据包(或者帧)时，nic11的硬件功能部11a(以下称为nic11)通过dma(direct memory access：直接存储器访问)传输不使用cpu地向环状缓冲器72复制到达的数据包(参照图23的附图标记b)。该环状缓冲器72在服务器中的存储器空间，由内核71(参照图22)进行管理。
35、但是，仅仅通过nic11向环状缓冲器72复制到达的数据包，内核71无法知晓该数据包。因此，当数据包到达时，nic11将硬件中断(hardirq)上报到hardirq81(参照图23的附图标记c)，由netif_rx82执行下述的处理，由此内核71知晓该数据包。需要说明的是，图23的椭圆包围表示的hardirq81表示处理程序而不是功能部。
36、netif_rx82是实际上进行处理的功能，当hardirq81(处理程序)启动时(参照图23的附图标记d)，在poll_list86保存作为硬件中断(hardirq)的内容的信息之一的、表示来自nic11的硬件中断是哪个设备的中断的网络设备(net_device)的信息。然后，netif_rx82登记队列的割取(参照滞留在缓冲器中的数据包的内容，针对该数据包的处理，考虑接下来要进行的处理而从缓冲器删除相应的队列的条目)(参照图23的附图标记e)。具体而言，netif_rx82响应于在环状缓冲器72塞入了数据包，使用nic11的驱动程序，将以后的队列的割取登记在poll_list86。由此，在poll_list86登记基于在环状缓冲器72塞入了数据包的队列的割取信息。
37、如此，在图23的<设备驱动程序>中，当接收到数据包时，nic11通过dma传输向环状缓冲器72复制到达的数据包。此外，nic11启动hardirq81(处理程序)，netif_rx82在poll_list86登记net_device，调度软件中断(softirq)。
38、至此，图23的<设备驱动程序>中的硬件中断的处理停止。
39、在此之后，netif_rx82使用在poll_list86积累的进入队列的信息(具体而言，指针)，将割取储存于环状缓冲器72的数据通过软件中断(softirq)上报到softirq83(处理程序)(参照图23的附图标记f)，通知给作为软件中断的控制功能部的do_softirq84(参照图23的附图标记g)。
40、do_softirq84是软件中断控制功能部，定义软件中断的各功能(数据包处理有多种，中断处理是其中之一。其定义中断处理)。do_softirq84基于该定义，向实际上进行软件中断处理的net_rx_action85通知这次的(相应的)软件中断的委托(参照图23的附图标记h)。
41、当轮到softirq时，net_rx_action85基于登记在poll_list86的net_device(参照图23的附图标记i)，调用用于从环状缓冲器72割取数据包的轮询例程，割取数据包(参照图23的附图标记j)。此时，net_rx_action85继续割取直到poll_list86变空为止。
42、在此之后，net_rx_action85通知netif_receive_skb87(参照图23的附图标记k)。
43、netif_receive_skb87创建sk_buff结构体，解析数据包的内容，按类型将处理移交给后一级的协议处理部74(参照图22)。即，netif_receive_skb87解析数据包的内容，在根据数据包的内容进行处理的情况下，将处理移交给<协议层>的ip_rcv88(图23的附图标记l)，此外，例如如果是l2则将处理移交给arp_rcv89(图23的附图标记m)。
44、在专利文献1中记载了服务器内网络延迟控制装置(kbp：kernel busy poll：内核繁忙轮询)。kbp在内核内通过轮询模型持续监视数据包到达。由此，抑制softirq，实现低延迟的数据包处理。
45、现有技术文献
46、专利文献
47、专利文献1：国际公开第2021/130828号
48、非专利文献1：
49、非专利文献1:new api(napi),[online],[令和4年4月4日检索],因特网〈url:http://http://lwn.net/2002/0321/a/napi-howto.php3〉
技术实现思路
1、发明所要解决的问题
2、然而，关于基于中断模型和轮询模型的数据包传输的任一个都存在下述问题。
3、就中断模型而言，接收到来自hw的事件(硬件中断)的内核通过用于进行数据包加工的软件中断处理来进行数据包传输。因此，中断模型存在以下问题：由于通过中断(软件中断)处理来进行数据包传输，因此如果与其他的中断相冲突、中断目标cpu被优先级更高的进程使用，则发生等待，数据包传输的延迟变大。在该情况下，当中断处理拥挤时，等待延迟变得更大。
4、例如，基于中断模型的数据包传输通过中断处理进行数据包的传输，因此发生中断处理的等待，数据包传输的延迟变大。
5、对在中断模型中发生延迟的机制进行补充。
6、就一般的内核而言，数据包传输处理是在硬件中断处理之后，通过软件中断处理来传递。
7、在发生数据包传输处理的软件中断时，在下述条件(1)～(3)下，无法立即执行所述软件中断处理。因此，通过ksoftirqd(是按每个cpu的内核线程，当软件中断的负荷变高时执行)等调度程序来调解，调度中断处理，由此发生ms量级的等待。
8、(1)与其他的硬件中断处理冲突的情况
9、(2)与其他的软件中断处理冲突的情况
10、(3)优先级高的其他进程、内核线程(migration thread等：迁移线程等)在使用中断目标cpu的情况
11、在上述条件中，无法立即执行所述软件中断处理。
12、此外，对于基于new api(napi)的数据包处理也同样，如图23的虚线包围的n所示，由于中断处理(softirq)的冲突，发生ms量级的nw延迟。
13、另一方面，如果使用专利文献1所记载的技术，则通过持续监视数据包到达，能够抑制软件中断，实现低延迟的数据包割取。然而，为了监视数据包到达，占有cpu核心并使用cpu时间，因此电力消耗变高。即，由于持续监视数据包到达的内核线程占有cpu核心，始终使用cpu时间，因此存在电力消耗变大的问题。参照图24和图25，对工作负荷和cpu使用率的关系进行说明。
14、图24是影像(30fps)的数据传输例。图24所示的工作负荷以传输速率350mbps，每30ms来间歇地进行数据传输。
15、图25是表示专利文献1中记载的kbp中的、繁忙轮询线程使用的cpu使用率的图。
16、如图25所示，在kbp中，内核线程进行繁忙轮询，因此占有cpu核心。即使是图24所示的间歇性的数据包接收，在kbp中也始终使用cpu，而无论数据包是否到达，因此存在电力消耗变大的问题。
17、本发明是鉴于这样的背景而完成的，本发明的问题在于，在抑制由于使轮询线程睡眠而引起的hw中断的过度发生，并谋求电力消耗的降低的同时，减小服务器内的延迟地进行数据包传输。
18、用于解决问题的方案
19、为了解决所述的问题，采用一种服务器内延迟控制装置，配置于os的内核空间，并启动使用轮询模型监视数据包到达的线程，所述服务器内延迟控制装置的特征在于，具备：数据包到达监视部，对登记表示来自接口部的硬件中断是哪个设备的中断的网络设备的信息的轮询列表进行监视；数据包割取部，在数据包到达的情况下，执行参照保存在环状缓冲器中的数据包并从所述环状缓冲器删除相应的队列的条目的割取；睡眠管理部，在数据包在规定时段没有到达的情况下使所述线程睡眠，并且在数据包到达时通过硬件中断进行该线程的睡眠解除；以及空闲状态恢复控制部，在睡眠时定期地唤醒该线程或者根据数据包到达定时在该数据包到达的紧前唤醒该线程。
20、发明效果
21、根据本发明，能够在抑制由于使轮询线程睡眠而引起的hw中断的过度发生，并谋求电力消耗的降低的同时，减小服务器内的延迟地进行数据包传输。
1.一种服务器内延迟控制装置，配置于操作系统的内核空间，并启动使用轮询模型监视数据包到达的线程，所述服务器内延迟控制装置的特征在于，具备：
2.一种服务器内延迟控制装置，配置于用户空间，并启动使用轮询模型监视数据包到达的线程，所述服务器内延迟控制装置的特征在于，具备：
3.一种服务器内延迟控制装置，其特征在于，
4.一种服务器内延迟控制装置，其特征在于，
5.根据权利要求1至4中任一项所述的服务器内延迟控制装置，其特征在于，
6.一种服务器内延迟控制装置的服务器内延迟控制方法，该服务器内延迟控制装置配置于操作系统的内核空间，并启动使用轮询模型监视数据包到达的线程，所述服务器内延迟控制方法的特征在于，执行以下步骤：
7.一种服务器内延迟控制装置的服务器内延迟控制方法，该服务器内延迟控制装置配置于用户空间，并启动使用轮询模型监视数据包到达的线程，所述服务器内延迟控制方法的特征在于，执行以下步骤：
8.一种程序，用于使计算机作为如权利要求1至4中任一项所述的服务器内延迟控制装置发挥功能。
