CN116982030A - 服务器内延迟控制装置、服务器内延迟控制方法和程序 - Google Patents

服务器内延迟控制装置、服务器内延迟控制方法和程序 Download PDF

Info

Publication number
CN116982030A
CN116982030A CN202180095948.8A CN202180095948A CN116982030A CN 116982030 A CN116982030 A CN 116982030A CN 202180095948 A CN202180095948 A CN 202180095948A CN 116982030 A CN116982030 A CN 116982030A
Authority
CN
China
Prior art keywords
packet
server
delay control
kernel
thread
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.)
Pending
Application number
CN202180095948.8A
Other languages
English (en)
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.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone 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 Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Publication of CN116982030A publication Critical patent/CN116982030A/zh
Pending legal-status Critical Current

Links

Classifications

    • 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/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
    • 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/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • 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
    • 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/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H04L47/56—Queue scheduling implementing delay-aware scheduling
    • H04L47/568—Calendar queues or timing rings
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

OS(70)具有环形缓冲区(72)和轮询列表(186)，在内核(171)内具有服务器内延迟控制装置(100)，所述服务器内延迟控制装置(100)启动使用轮询模型来监视数据包到达的thread，具有数据包到达监视部(110)、数据包采集部(120)和sleep管理部(130)，其中，所述数据包到达监视部(110)监视轮询列表(186)；在数据包到达的情况下，所述数据包采集部(120)参照保存在环形缓冲区(72)中的数据包，基于接下来进行的处理来执行从环形缓冲区(72)删除对应的队列的条目的采集；所述sleep管理部(130)在数据包在规定期间未到达的情况下使线程休眠，并且在数据包到达时通过该线程的硬中断进行休眠解除。

Description

服务器内延迟控制装置、服务器内延迟控制方法和程序
技术领域
本发明涉及服务器内延迟控制装置、服务器内延迟控制方法和程序。
背景技术
在使用NFV(Network Functions Virtualization：网络功能虚拟化)的虚拟化技术不断进步等背景下，正在针对每项服务来构建并运用系统。另外，根据上述针对每项服务构建系统的方式，将服务功能分割为可再利用的模块单元，且使其在独立的虚拟机(VM：Virtual Machine、容器(container)等)环境中进行运行，据此，如零部件那样根据需要使用来提高运用性的被称为SFC(Service Function Chaining：服务功能链)的方式正在成为主流。
作为构成虚拟机的技术，已知有由Linux(注册商标)和KVM(kernel-basedvirtual machine：基于内核的虚拟机)构成的虚拟机监视器(hypervisor)环境。在该环境中，组装有KVM模块的Host OS(将安装在物理服务器上的OS称为Host OS)作为虚拟机监视器，在与被称为内核空间(kernel space)的用户空间不同的存储区域中进行运行。在该环境下，虚拟机在用户空间中进行运行，Guest OS(将被安装在虚拟机上的OS称为Guest OS)在该虚拟机内进行运行。
供Guest OS运行的虚拟机不同于供Host OS运行的物理服务器，包括(以太网卡设备等所代表的)网络设备的所有的HW(hardware：硬件)执行从HW向Guest OS的中断处理、或从Guest OS向硬件的写入所需的寄存器控制。在这种寄存器控制中，本来应该由物理硬件执行的通知或处理被软件疑似地模仿，因此，性能一般低于Host OS环境中的性能。
在该性能劣化中存在一种技术，尤其针对从Guest OS到存在于本虚拟机外的HostOS或外部进程(external process)，削减HW的模仿，通过高速且统一的接口来提高通信的性能和通用性。作为这种技术，开发出virtio等的设备的抽象化技术、即准虚拟化技术，以Linux(注册商标)为代表，当前已经编入FreeBSD(注册商标)等众多的通用OS而使用。
在virtio中，对控制台、文件输入输出、网络通信等的数据输入输出，作为传输数据的单向的传输方式，通过队列的操作来定义基于在环形缓冲区(ring buffer)中设计的队列(queue)的数据转换。然后，利用virtio的队列的规范，在Guest OS启动时准备适合各个设备的队列的个数和大小，据此，不执行硬件模拟而仅仅通过基于队列的操作来实现Guest OS与本虚拟机外部的通信。
[基于中断模型的数据包传输(packet transfer)(通用VM结构的例子)]
图9是说明通用Linux kernel(注册商标)和VM结构的服务器虚拟化环境中的基于中断模型的数据包传输的图。
HW10具有NIC(Network Interface Card：网络接口卡)11(物理NIC)(接口部)，通过由Host OS20、构建虚拟机的虚拟机监视器即KVM30、虚拟机(VM1、VM2)40、以及GuestOS50构建的虚拟通信路径，在其与user space(用户空间)60上的数据包处理APL(应用软件：Application)1之间进行数据收发的通信。在以下的说明中，如图9的粗箭头所示，将数据包处理APL1接收来自HW10的数据包的数据的流动称为Rx侧接收，将数据包处理APL1向HW10发送数据包的数据的流动称为Tx侧发送。
Host OS20具有kernel21、Ring Buffer22和Driver23，kernel21具有作为kernelthread的vhost-net模块221、tap设备222和虚拟交换机(vSwitch)(br)223。
tap设备222是虚拟网络的内核设备，由软件来支持。虚拟机(VM1)40为，GuestOS50和Host OS20能够通过被制成虚拟桥(bridge)的虚拟交换机(br)223进行通信。tap设备222是与被制成该虚拟桥的Guest OS50的虚拟NIC(vNIC)相连接的设备。
Host OS20将在Guest OS50的虚拟机内构建的结构信息(共享缓冲区队列的大小、队列的数量、识别符、用于访问环形缓冲区的初始地址信息等)复制到vhost-net模块221，在Host OS20内部构建虚拟机侧的端点的信息。该vhost-net模块221是virtio联网用的内核级别的后端，能够通过将virtio数据包处理任务从用户区域(用户空间)转移到kernel21的vhost-net模块221来减少虚拟化的开销(overhead)。
Guest OS50具有被安装在虚拟机(VM1)上的Guest OS(Guest1)和被安装在虚拟机(VM2)上的Guest OS(Guest2)，Guest OS50(Guest1、Guest2)在虚拟机(VM1、VM2)40内运行。作为Guest OS50，当采用Guest1为例时，Guest OS50(Guest1)具有kernel51、RingBuffer52和Driver53，Driver53具有virtio-driver531。
具体而言，作为PCI(Peripheral Component Interconnect：外围设备互连)设备，在虚拟机内，分别针对控制台、文件输入输出、网络通信而存在virtio设备(控制台被称为virtio-console、文件输入输出被称为virtio-blk、网络被称为virtio-net的设备和与其对应的OS所具有的驱动程序由virtio队列来定义)，当Guest OS启动时，创建Guest OS与对方侧之间的数据的两个传递端点(收发端点)，构建数据收发的父子关系。很多情况下，在虚拟机侧(子端)和Guest OS(父端)构成父子关系。
子端作为虚拟机内的设备的结构信息而存在，向父端请求各个数据区域的大小和所需的端点的组合的个数、设备的类别。父端按照子端的请求，为用于储存、传输所需的数据的共享缓冲区队列分配和确保存储器，并且将其地址返回给子端以便子端能够访问。数据的传输所需的共享缓冲区队列的操作在virtio中都是通用的，且按照父端、子端双方达成协议后来执行。并且共享缓冲区队列的大小也是双方达成协议(即按设备确定)。据此，仅仅通过向子端传输地址，就能够操作父端、子端的双方共享的队列。
由于在virtio中准备的共享缓冲区队列是为了单向使用而准备的，因此，例如在被称为virtio-net设备的虚拟网络设备中，由发送用、接收用、控制用的3个Ring Buffer52构成。父子之间通信通过向共享缓冲区队列写入和缓冲区更新通知来实现，在写入RingBuffer52之后通知对方侧。当对方侧收到通知时，利用virtio的共同操作来确认在哪个共享缓冲区队列中有多少新的数据，且提取出新的缓冲区区域。据此，建立从父到子或者从子到父的数据的传输。
如上所述，通过共享用于在父子之间相互进行数据转换的Ring Buffer52和各个环形缓冲区用的操作方法(在virtio中共用)，实现无需硬件模拟的Guest OS50与外部的通信。据此，与现有技术的硬件模拟相比，能够高速地实现Guest OS50与外部的数据的收发。
在虚拟机内的Guest OS50与外部进行通信的情况下，需要子端与外部相连接，并且子端作为外部与父端的中继来收发数据。例如，Guest OS50与Host OS20间的通信是这种例子之一。在此，在设外部为Host OS20的情况下，现有的通信方法存在两种。
第1方法(下面称为外部通信方式1)为，在虚拟机内构建子端的端点，在虚拟机内将Guest OS50与虚拟机间的通信、和Host OS20提供的通信端点(通常被称为tap/tun设备)相连接。通过该连接，构建以下连接，实现从Guest OS50到Host OS20的通信。
此时，Guest OS50在作为用户空间的存储区域内运行，该存储区域具有与作为tap驱动程序、Host OS20运行的内核空间的存储区域不同的权限。因此，在从Guest OS50到Host OS20的通信中至少发生一次内存复制(memory copy)。
第2方法(下面称为外部通信方式2)中，作为解决该问题的技术手段，存在vhost-net等技术。在vhost-net中，将在虚拟机内构建的父端的结构信息(共享缓冲区队列的大小、队列的数量、识别符、用于访问环形缓冲区的初始地址信息等)在Host OS20内部的vhost-net模块221中复制一次，在主机内部构建子端的端点的信息。根据该构建，这是一种能够在Guest OS50与Host OS20间直接实施共享缓冲区队列的操作的技术。据此，复制实质上为0次，与virtio-net相比，复制次数少1次，与外部通信方式1相比较，能够更高速地实现数据传输。
这样，在通过virtio连接的Host OS20和Guest OS50中，通过减少virtio-net相关联的内存复制次数，能够使数据包传输处理高速化。
另外，kernel v4.10(2017.2～)以后，tap接口的规格发生变化，从tap设备插入的数据包在与向tap设备进行数据包复制的处理相同的上下文内完成。据此，软中断(softIRQ)不再发生。
[基于轮询模型(polling model)的数据包传输(DPDK的例子)]
使多个虚拟机相连接、协调的方法被称为Inter-VM Communication，在数据中心等大规模的环境中，在VM间的连接中已标准使用虚拟交换机。但是，由于该方法通信的延迟大，因此，新提出了更高速的方法。例如，提出了使用被称为SR-IOV(Single Root I/OVirtualization)的特别的硬件的方法、基于使用高速数据包处理库即Intel DPDK(IntelData Plane Development Kit)(下面称为DPDK)的软件的方法等(参照非专利文献1)。
DPDK是用于在用户空间进行以往Linux kernel(注册商标)进行的NIC(NetworkInterface Card：网络接口卡)的控制的框架。与Linux kernel中的处理的最大的区别在于，具有被称为PMD(Pull Mode Driver)的基于轮询的接收机制。通常，在Linux kernel中，接收到数据到达NIC而发生中断，以此为契机执行接收处理。另一方面，PMD为，专用的线程(thread)连续地进行数据到达的确认和接收处理。通过排除上下文切换(contextswitch)、中断等的开销，能够进行高速的数据包处理。DPDK大幅提高数据包处理的性能和吞吐量，由此能够为数据平面应用程序处理确保更多的时间。
DPDK占有地使用CPU(Central Processing Unit)、NIC等计算机资源。因此，难以将其适用于如SFC那样按模块单位灵活地重新连接的用途。存在用于缓解该问题的应用程序即SPP(Soft Patch Panel)。SPP通过在VM间准备共享存储器，采用各VM能够直接参照相同的存储器空间的结构，省略虚拟化层中的数据包复制。另外，物理NIC与共享存储器间的数据包的交换使用DPDK来实现高速化。SPP通过控制各VM的存储器交换的参照目的地，能够使用软件来变更数据包的输入目的地、输出目的地。通过该处理，SPP实现VM间、VM与物理NIC间的动态的连续切换。
图10是说明基于OvS-DPDK(Open vSwitch with DPDK)的结构中的轮询模型的数据包传输的图。对与图9相同的构成部分标注相同的附图标记，省略重复部分的说明。
如图10所示，Host OS20具有用于数据包处理的软件即OvS-DPDK70，OvS-DPDK70具有：vhost-user71，其是用于连接于虚拟机(在此为VM1)的功能部；和dpdk(PMD)72，其是用于连接于NIC(DPDK)11(物理NIC)的功能部。
另外，数据包处理APL1A具有dpdk(PMD)2，dpdk(PMD)2是在Guest OS50区间进行轮询的功能部。即，数据包处理APL1A是通过使图9的数据包处理APL1具有dpdk(PMD)2来改变数据包处理APL1的APL。
作为DPDK的扩展，基于轮询模型的数据包传输使得在经由共享存储器以零复制高速执行Host OS20与Guest OS50间、以及Guest OS50间的数据包复制的SPP中，能够通过GUI来进行路径操作。
[基于New API(NAPI)的Rx侧数据包处理]
图11是基于由Linux kernel 2.5/2.6实现的New API(NAPI)的Rx侧数据包处理的概略图(参照非专利文献2)。对与图9相同的构成部分标注相同的附图标记。
如图11所示，New API(NAPI)在具有OS70(例如，Host OS)的服务器上，执行配置在用户能使用的user space60的数据包处理APL1，在连接于OS70的HW10的NIC11与数据包处理APL1之间进行数据包传输。
OS70具有kernel71、Ring Buffer72和Driver73，kernel71具有协议处理部74。
Kernel71是OS70(例如，Host OS)的核心部分的功能，以进程为单位管理硬件的监视或程序的执行状态。在此，kernel71能够响应于来自数据包处理APL1的请求，并且能够将来自HW10的请求发送给数据包处理APL1。Kernel71通过系统调用(“以非特权模式运行的用户程序”向“以特权模式运行的内核”请求处理)对来自数据包处理APL1的请求进行处理。
Kernel71经由Socket75向数据包处理APL1传递数据包。Kernel71经由Socket75接收来自数据包处理APL1的数据包。
Ring Buffer72由Kernel71进行管理，位于服务器中的存储器空间内。RingBuffer72是将Kernel71所输出的消息保存为日志的一定大小的缓冲区，当超过上限大小时，从头开始覆盖。
Driver73是用于由kernel71进行硬件的监视的设备驱动程序。另外，Driver73依赖于kernel71，如果创建(构建)的内核源发生变化，则它会变成其他驱动程序。在此情况下，获取对应的驱动程序源，在使用驱动程序的OS上重建，创建驱动程序。
协议处理部74进行由OSI(Open Systems Interconnection：开放系统互连)参照模型定义的L2(数据链路层)/L3(网络层)/L4(传输层)的协议处理。
Socket75是用于kernel71进行进程间通信的接口。Socket75具有数据包缓冲区，不会频繁发生数据的复制处理。通过Socket75建立通信为止的流程如下。1.服务器侧创建接受客户端的数据包文件。2.对用于接受的数据包文件命名。3.创建数据包队列。4.接受数据包队列中的来自客户端的最初的一个连接。5.在客户端侧创建数据包文件。6.由客户端侧向服务器发出连接请求。7.在服务器侧，不同于用于接受的数据包文件，创建用于连接的数据包文件。建立通信的结果，数据包处理APL1向kernel71调用read()、write()等的系统调用。
在以上的结构中，Kernel71通过硬中断(hardIRQ)接收来自NIC11的数据包到达的通知，调用用于数据包处理的软中断(softIRQ)。
上述通过Linux kernel 2.5/2.6实现的New API(NAPI)在数据包到达时，在硬中断(hardIRQ)之后通过软中断(softIRQ)进行数据包处理。如图11所示，基于中断模型的数据包传输通过中断处理(参照图11的附图标记c)进行数据包的传输，因此，发生中断处理的等待，数据包传输的延迟增大。
下面，对NAPI Rx侧数据包处理概要进行说明。
[基于New API(NAPI)的Rx侧数据包处理结构]
图12是说明基于图11的虚线包围的部位的New API(NAPI)的Rx侧数据包处理的概要的图。
<Device driver>
如图12所示，在Device driver配置：NIC11(物理NIC)，其为网络接口卡；hardIRQ81，其是通过NIC11的处理请求的发生而被调用并执行所请求的处理(硬中断)的处理程序(handler)；和netif_rx82，其是软中断的处理功能部。
<Networking layer>
在Networking layer配置：softIRQ83，其是通过netif_rx82的处理请求的发生而被调用并执行所请求的处理(软中断)的处理程序；和do_softirq84，其是进行软中断(softIRQ)的实体的控制功能部。另外，配置：net_rx_action85，其是接受软中断(softIRQ)并执行的数据包处理功能部；poll_list86，其登录表示来自NIC11的硬中断为哪个设备的网络设备(net_device)的信息；netif_receive_skb87，其制作sk_buff结构体(用于使Kernel71能够感知数据包是怎样的结构体)；和Ring Buffer72。
<Protocol layer：协议层>
在Protocol layer，配置作为数据包处理功能部的ip_rcv88、arp_rcv89等。
上述netif_rx82、do_softirq84、net_rx_action85、netif_receive_skb87、ip_rcv88以及arp_rcv89是在Kernel71中用于数据包处理的程序的部分(函数的名称)。
[基于New API(NAPI)的Rx侧数据包处理操作]
图12的箭头(附图标记)d～o表示Rx侧数据包处理的流程。
NIC11的hardware功能部11a(下面称为NIC11)在从对方装置接收到帧内的数据包(或者帧)时，通过DMA(Direct Memory Access：直接存储器访问)传输，不使用CPU而复制到达Ring Buffer72的数据包(参照图12的附图标记d)。该Ring Buffer72在服务器中的存储器空间内，由Kernel71(参照图11)进行管理。
但是，仅仅通过NIC11复制到达Ring Buffer72的数据包，Kernel71无法识别该数据包。因此，当数据包到达时，NIC11将硬中断(hardIRQ)转移到hardIRQ81(参照图12的附图标记e)，由netif_rx82执行下述的处理，据此Kernel71识别该数据包。另外，图12中的椭圆包围表示的hardIRQ81表示处理程序而不是功能部。
netif_rx82是实际上进行处理的功能，当hardIRQ81(处理程序)被启动时(参照图12的附图标记f)，在poll_list86中保存作为硬中断(hardIRQ)的内容的信息之一、即表示来自NIC11的硬中断是哪个设备的网络设备(net_device)的信息，并登录队列的采集(参照在缓冲区中累积的数据包的内容，针对数据包的处理，考虑接下来进行的处理来从缓冲区中删除对应的队列的条目(entry))(参照图12的附图标记g)。具体而言，netif_rx82接收到在Ring Buffer72中塞满数据包，使用NIC11的驱动程序，将以后的队列的采集登录在poll_list86(参照图12的附图标记g)。据此，在poll_list86中登录由于在Ring Buffer72中塞满数据包而进行队列的采集信息。
这样，在图12的<Device driver>中，NIC11在接收到数据包时，复制通过DMA传输而到达Ring Buffer72的数据包。另外，NIC11启动hardIRQ81(处理程序)，netif_rx82在poll_list86中登录net_device，调度软中断(softIRQ)。
至此，图12的<Device driver>中的硬中断的处理停止。
在此之后，netif_rx82使用poll_list86中积累的队列中的信息(具体而言，指针)，通过软中断(softIRQ)将采集保存在Ring Buffer72中的数据转移到softIRQ83(处理程序)(参照图12的附图标记h)，且通知给作为软中断的控制功能部的do_softirq84(参照图12的附图标记i)。
do_softirq84是软中断控制功能部，定义软中断的各功能(数据包处理有多种，中断处理是其中之一。其定义中断处理)。do_softirq84f基于该定义，向实际进行软中断处理的net_rx_action85通知请求这次(对应的)软中断(参照图12的附图标记j)。
当轮到softIRQ时，net_rx_action85根据登录在poll_list86中的net_device(参照图12的附图标记k)，调用用于从Ring Buffer72采集数据包的轮询例程，采集数据包(参照图12的附图标记l)。此时，net_rx_action85继续采集直到poll_list86变空为止。
在此之后，net_rx_action85通知netif_receive_skb87(参照图12的附图标记m)。
netif_receive_skb87制作sk_buff结构体，分析数据包的内容，按类型将处理移交给后一级的协议处理部74(参照图11)。即，netif_receive_skb87分析数据包的内容，在根据数据包的内容进行处理的情况下，将处理移交给<Protocol layer>的ip_rcv88(图12的附图标记n)，另外，例如如果为L2则将处理移交给arp_rcv89(图12的附图标记o)。
在非专利文献3中记载了服务器内网络延迟控制装置(KBP：Kernel Busy Poll)。KBP在kernel内通过polling模型来始终监视数据包到达。据此，抑制softIRQ，实现低延迟的数据包处理。
现有技术文献
非专利文献
非专利文献1:“Developer Quick Start Guide Learn How To Get InvolvedWith DPDK,”Intel,[online],[2021年3月5日检索],因特网〈URL:https://www.dpdk.org/〉
非专利文献2:New API(NAPI),[online],[2021年3月5日检索],因特网〈URL:http://http://lwn.net/2002/0321/a/napi-howto.php3〉
非专利文献3:Kei Fujimoto,Kenichi Matsui,Masayuki Akutsu,“KBP:KernelEnhancements for Low-Latency Networking without Application Customization inVirtual Server”,IEEE CCNC 2021.
发明内容
然而，使用中断模型和轮询模型进行的数据包传输均存在下述技术问题。
中断模型为，通过由接收到来自HW的事件(硬中断)的kernel进行数据包加工的软中断处理来进行数据包传输。因此，中断模型存在以下技术问题，由于通过中断(软中断)处理来进行数据包传输，因此，如果与其他中断相冲突、或中断目标CPU被优先级更高的进程使用，则发生等待，数据包传输的延迟增大。在此情况下，当中断处理混杂时，等待延迟变得更大。
例如，如图9所示，基于中断模型的数据包传输通过中断处理(参照图9的附图标记a、b)来进行数据包的传输，因此发生中断处理的等待，数据包传输的延迟增大。
对在中断模型中发生延迟的机制进行补充。
一般的kernel为，数据包传输处理是在硬中断处理之后通过软中断处理来传递。
在发生数据包传输处理的软中断时，在下述条件(1)～(3)下，无法立即执行所述软中断处理。因此，通过ksoftirqd(每一CPU的内核线程，当软中断的负载变高时执行)等的调度程序来调节，调度中断处理，据此发生ms量级的等待。
(1)与其他的硬中断处理冲突的情况
(2)与其他的软中断处理冲突的情况
(3)被优先级高的其他进程、kernel thread(migration thread等)、中断目标CPU使用的情况
在上述条件中，无法立即执行所述软中断处理。
另外，针对基于New API(NAPI)的数据包处理也同样，如图12中的虚线框p所示，由于中断处理(softIRQ)的冲突而发生ms量级的NW延迟。
另一方面，轮询模型占用CPU来轮询通信队列，在数据包到达时立即采集。轮询模型尽管能够减小传输延迟，但需要使APL具有轮询功能，因此，APL需要改变。
例如，如图10所示，基于轮询模型的数据包传输需要使数据包处理APL1具有在Guest OS50区间进行轮询的功能部即dpdk(PMD)72，因此数据包处理APL1需要改变。
另外，非专利文献3所记载的KBP在kernel内通过polling模型始终监视数据包到达，据此，能够抑制softIRQ，实现低延迟的数据包处理。
但是，始终监视数据包到达的kernel thread占用CPU核心，始终使用CPU计时器，因此存在电功率消耗变高的技术问题。参照图13和图14对工作负荷与CPU使用率的关系进行说明。
图13是映像(30FPS)的数据传输例。图13所示的工作负荷以传输率350Mbps，每30ms来间歇地进行数据传输。
图14是表示非专利文献3所记载的KBP中的、busy poll thread使用的CPU使用率的图。
如图14所示，在KBP中，kernel thread进行频繁轮询(busy poll)，因此占用CPU核心。即使是图13所示的间歇性的数据包接收，在KBP中也始终使用CPU，而不管数据包是否到达，因此存在电功率消耗增大的技术问题。
本发明是鉴于这种背景而完成的，本发明要解决的技术问题在于，通过在实现降低电功率消耗的同时不改变APL而减少服务器内的延迟来进行数据包传输。
为了解决上述的技术问题，提供一种服务器内延迟控制装置，其特征在于，OS具有内核、环形缓冲区和轮询列表(pole list)，其中，所述环形缓冲区在具有所述OS的服务器中的存储器空间内，由所述内核进行管理；所述轮询列表登录表示来自接口部的硬中断是哪个设备的网络设备的信息，在所述内核内具有所述服务器内延迟控制装置，所述服务器内延迟控制装置启动使用轮询模型来监视数据包到达的线程，所述服务器内延迟控制装置具有数据包到达监视部、数据包采集部和休眠管理部，其中，所述数据包到达监视部监视所述轮询列表；在数据包到达的情况下，所述数据包采集部参照保存在所述环形缓冲区中的数据包，基于接下来进行的处理来执行从所述环形缓冲区删除对应的队列的条目的采集；所述休眠管理部在数据包在规定期间未到达的情况下使所述线程休眠，且在数据包到达时通过硬中断进行该线程的休眠解除。
发明效果
根据本发明，能够通过在实现降低电功率消耗的同时不改变APL而减小服务器内的延迟来进行数据包传输。
附图说明
图1是本发明实施方式所涉及的服务器内延迟控制系统的概略结构图。
图2是说明由本发明实施方式所涉及的服务器内延迟控制系统的New API(NAPI)进行的Rx侧数据包处理的细节的图。
图3是表示本发明实施方式所涉及的服务器内延迟控制系统的polling thread运行例的图。
图4是表示本发明的实施方式所涉及的服务器内延迟控制系统的服务器内延迟控制装置的Rx侧运行和用于省电化的管理处理的流程图。
图5是表示用于本发明实施方式所涉及的服务器内延迟控制系统的服务器内延迟控制装置的省电化的CPU频率/CPU idle设定处理的流程图。
图6是表示实现本发明实施方式所涉及的服务器内延迟控制系统的服务器内延迟控制装置的功能的计算机一例的硬件结构图。
图7是表示对通用Linux kernel和VM结构的服务器虚拟化环境中的中断模型适用服务器内延迟控制系统的例子的图。
图8是表示对容器结构的服务器虚拟化环境中的中断模型适用服务器内延迟控制系统的例子的图。
图9是说明由通用Linux kernel和VM结构的服务器虚拟化环境中的中断模型进行的数据包传输的图。
图10是说明由OvS-DPDK的结构中的轮询模型进行的数据包传输的图。
图11是由Linux kernel 2.5/2.6实现的New API(NAPI)进行的Rx侧数据包处理的概略图。
图12是说明由图11的虚线包围的部位的New API(NAPI)进行的Rx侧数据包处理的概要的图。
图13是表示映像(30FPS)的数据传输例的图。
图14是非专利文献3所记载的KBP中的busy poll thread使用的CPU使用率的图。
具体实施方式
以下，参照附图对本发明的实施方式(以下，称为“本实施方式”)中的服务器内延迟控制系统等进行说明。
[概要]
图1是本发明的实施方式所涉及的服务器内延迟控制系统的概略结构图。本实施方式是适用于由Linux kernel 2.5/2.6实现的New API(NAPI)进行的Rx侧数据包处理的例子。对与图11相同的构成部分标注相同的附图标记。
如图1所示，服务器内延迟控制系统1000在具有OS70(例如，Host OS)的服务器上，执行被配置于用户能使用的user space60的数据包处理APL1，在连接于OS70的HW10的NIC11与数据包处理APL1之间进行数据包传输。
OS70具有kernel171、Ring Buffer72和Driver73，kernel171具有服务器内延迟控制装置100和协议处理部74。
在本实施方式中，kernel171由于具有服务器内延迟控制装置100的关系，与图11所示的kernel71相区别而标注新的编号。kernel171除了设置有服务器内延迟控制装置100以外，具有与图11所示的kernel71相同的功能。但是，kernel171能够通过使用livepatch(后述)来实现，而无需对现有的kernel71(参照图11)进行改造(新建)。
kernel171是OS70(例如，Host OS)的核心部分的功能，以进程为单位管理硬件的监视和程序的执行状态。在此，kernel171能够响应来自数据包处理APL1的请求，并且能够将来自HW10的请求发送给数据包处理APL1。kernel171通过系统调用对来自数据包处理APL1的请求进行处理。
kernel171通过Socket75向数据包处理APL1发送数据包。Kernel71通过Socket75从数据包处理APL1接收数据包。
Ring Buffer72在服务器中的存储器空间内，由kernel171进行管理。RingBuffer72是将kernel171所输出的消息保存为日志的一定大小的缓冲区，当超过上限大小时，从头开始覆盖。
Driver73是用于由kernel171进行硬件的监视的设备驱动程序。
协议处理部74进行由OSI参照模型定义的L2/L3/L4的协议处理。
Socket75是用于kernel171进行进程间通信的接口。Socket75具有数据包缓冲区，不会频繁发生数据的复制处理。
<服务器内延迟控制装置>
服务器内延迟控制装置100具有数据包到达监视部110、数据包采集部(packetharvesting unit)120、sleep管理部130和CPU频率/CPU idle设定部140(CPU频率设定部、CPU空闲设定部)。
数据包到达监视部110是用于监视数据包是否到达的thread。数据包到达监视部110监视(polling)poll_list186(参照图2)。
数据包到达监视部110从poll_list186获取在Ring_Buffer72(参照图2)中存在数据包的指针信息(pointer information)和net_device信息，并向数据包采集部120传递该信息(指针信息和net_device信息)。在此，在poll_list186存在多个数据包信息的情况下，传递该多个信息。
在数据包到达的情况下，数据包采集部120参照保存在Ring Buffer72中的数据包，基于接下来进行的处理，执行从Ring Buffer72删除对应的队列的条目的采集(下面，有时简称为从Ring Buffer72采集数据包)。数据包采集部120根据接收到的信息从Ring_Buffer72取出数据包，向netif_receive_skb87传递数据包。
在规定期间内数据包未到达的情况下，sleep管理部130使线程(polling thread)休眠(sleep)，且在数据包到达时通过该线程(polling thread)的硬中断(hardIRQ)进行休眠解除(细节后述)。
CPU频率/CPU idle设定部140在休眠中将线程(polling thread)使用的CPU核心的CPU运行频率设定得较低。CPU频率/CPU idle设定部140在休眠中将该线程(pollingthread)使用的CPU核心的CPU空闲(CPU idle)状态设定为省电模式(细节后述)。
图2是说明由图1的服务器内延迟控制系统1000的New API(NAPI)进行的Rx侧数据包处理的细节的图。对与图1以及图12相同的构成部分标注相同的附图标记。
<Device driver>
如图2所示，在Device driver配置：NIC11，其为网络接口卡；hardIRQ81，其是通过NIC11的处理请求的发生而被调动并执行所请求的处理(硬中断)的处理程序；和netif_rx182，其是软中断的处理功能部。
<Networking layer>
在Networking layer配置：poll_list186，其注册表示来自NIC11的硬中断是哪个设备的网络设备(net_device)的信息；数据包到达监视部110；netif_receive_skb87，其对采集到队列的数据包，制作用于没有发生中断的数据包通信的sk_buff结构体(kernel171表示数据包的状态的结构体)；和Ring Buffer72。
<Protocol layer>
在Protocol layer，配置作为数据包处理功能部的ip_rcv88、arp_rcv89等。另外，除了ip_rcv88、arp_rcv89以外，还存在协议处理。
上述netif_rx182、netif_receive_skb87、ip_rcv88和arp_rcv89是在Kernel171中为了进行数据包处理而调出的程序的部分(函数的名称)。
下面，说明服务器内延迟控制系统1000的运行。
[本发明的Rx侧数据包处理操作]
图2的箭头(附图标记)d～g、k～o表示Rx侧数据包处理的流程。
NIC11在从对方装置接收到帧内的数据包(或者帧)时，通过DMA传输，不使用CPU而复制到达Ring Buffer72的数据包(参照图2的附图标记d)。该Ring Buffer72在服务器中的存储器空间内，由Kernel171(参照图1)进行管理。
当数据包到达时，NIC11在hardIRQ81(处理程序)中启动硬中断(hardIRQ)(参照图2的附图标记e)，netif_rx182执行下述的处理，据此，Kernel171识别该数据包。
当hardwire81(处理程序)被启动时(参照图2的附图标记f)，netif_rx182在poll_list186中保存硬中断(hardIRQ)的内容的信息之一、即表示来自NIC11的硬中断是哪个设备的网络设备(net_device)的信息，且登录队列的采集信息(参照图2的附图标记g)。具体而言，netif_rx182接收到在Ring Buffer72中塞满数据包，使用NIC11的驱动程序，将以后的队列的采集登录在poll_list186(参照图2的附图标记g)。据此，在poll_list186中登录由于在Ring Buffer72中塞满数据包而进行队列的采集。
在poll_list186登录net_device，但与图12的netif_rx82不同，netif_rx182不进行软中断(softIRQ)的调度。即，netif_rx182在不进行软中断(softIRQ)的调度的点，与图12的netif_rx82不同。
另外，netif_rx182进行唤醒休眠(sleep)的polling thread的sleep解除(参照图2的附图标记p)。本实施方式对非专利文献3记载的KBP追加该polling thread的唤醒处理(sleep解除)。
至此，图2的<Device driver>中的硬中断的处理停止。
在本实施方式中，在图12所示的<Networking layer>中，删除softIRQ83和do_softirq84，伴随与此，图12所示的netif_rx82也不进行启动softIRQ83(处理程序)的通知(参照图12的附图标记h)。
在本实施方式中，服务器内延迟控制系统1000删除图12所示的softIRQ83和do_softirq84，作为替代，在图2所示的<Networking layer>的服务器中的存储器空间设置服务器内延迟控制装置100。
在图2所示的<Networking layer>中，服务器内延迟控制装置100的数据包到达监视部110监视(polling)poll_list186(参照图2的附图标记k)，确认数据包是否到达。
数据包到达监视部110从poll_list186获取在Ring_Buffer72中存在数据包的指针信息和net_device信息，向数据包采集部120传递该信息(参照指针信息和net_device信息)(参照图2的附图标记q)。在此，在poll_list186中存在多个数据包信息的情况下，传递该多个信息。
在数据包到达的情况下，服务器内延迟控制装置100的数据包采集部120从RingBuffer72采集数据包(参照图2的附图标记l)。
数据包采集部120根据接收到的信息从Ring_Buffer72取出数据包，向netif_receive_skb87传递数据包(参照图2的附图标记m)。
这样，服务器内延迟控制系统1000使作为NW延迟发生的主要原因的数据包处理的softIRQ停止，执行服务器内延迟控制装置100的数据包到达监视部110监视数据包到达的polling thread。并且，数据包采集部120在数据包到达时，通过polling模型(无softIRQ)进行数据包处理。
即，服务器内延迟控制装置100中的polling thread作为kernel thread来运行，以polling模式来监视数据包到达。数据包到达监视部110监视poll_list186。数据包采集部120在数据包到达时从Ring Buffer72取出数据包，向netif_receive_skb87传输数据包。
数据包到达时，由硬中断处理程序创建polling thread，据此，避免softIRQ冲突，由此能够立即进行数据包传输处理。换言之，作为kernel thread使数据包到达监视功能待机，通过由硬中断唤醒，由此与基于NAPI等的软中断的数据包传输处理相比能够实现低延迟化。
监视数据包到达的kernel thread在数据包未到达期间能够休眠。
上述polling thread根据数据包是否到达进行休眠，在数据包到达时通过hardIRQ81进行sleep解除。具体而言，服务器内延迟控制装置100的sleep管理部130根据数据包是否到达，即在一定期间内没有数据包的到达时，使polling thread休眠(sleep)。sleep管理部130在数据包到达时通过hardIRQ81进行sleep解除。据此，避免softIRQ冲突，实现低延迟化。
服务器内延迟控制装置100的CPU频率/CPU idle设定部140根据数据包是否到达来变更CPU运行频率、idle设定。具体而言，CPU频率/CPU idle设定部140在休眠(sleep)时降低CPU频率，再次启动时提高CPU频率(使CPU运行频率恢复到原来的频率)。另外，CPU频率/CPU idle设定部140在休眠(sleep)时将CPU idle设定变更为省电模式。休眠(sleep)时将CPU运行频率变更得较低，另外，通过将CPU idle设定变更为省电模式，也能够实现省电化。
netif_receive_skb87制作sk_buff结构体，分析数据包的内容，按类型将处理移交给后一级的协议处理部74(参照图11)。即，netif_receive_skb87分析数据包的内容，在根据数据包的内容进行处理的情况下，将处理移交给<Protocol layer>的ip_rcv88，另外，例如如果为L2则将处理移交给arp_rcv89。
图3是表示服务器内延迟控制装置100的polling thread运行例的图。纵轴表示polling thread使用的CPU核心的CPU使用率[％]，横轴表示时间。另外，图3表示基于与图13所示的间歇地接收到数据包的映像(30FPS)的数据传输例对应的数据包到达的pollingthread运行例。
如图3所示，服务器内延迟控制装置100的sleep管理部130在一定期间内没有数据包到达的情况下(更详细而言，在从某一数据包到达起，即使经过了维护/运营商预先确定的固定值(一定期间)也没有下一数据包到达的情况下)，使polling thread休眠(参照图3的附图标记s)。并且，sleep管理部130由数据包到达的hardIRQ81使polling thread启动(参照图3的附图标记t)。
另外，在休眠期间，由于kernel thread不占用CPU核心，因此，除了pollingthread使用以外，用于系统稳定运行的计时器的中断进入对应的CPU核心，用于错误处理等的migration thread进入对应的CPU核心，据此，有时polling thread使用的CPU核心的CPU使用率发生变动(参照图3的附图标记u)。
[基于live patch的登录运行]
接着，对基于live patch的登录运行进行说明。
服务器内延迟控制系统1000(参照图1)为，图1所示的OS70的kernel171具有服务器内延迟控制装置100。kernel171通过使用livepatch，无需对现有的kernel71(参照图11)进行改造(新建)而能够实现。下面，对适用于kernel171的livepatch进行说明。
livepatch是适用于Linux(注册商标)kernel的内核补丁功能。通过使用livepatch，无需重启系统而能够在内核空间立即适用修复。即，
(1)livepatch抑制netif_rx182(参照图2)的softIRQ调度功能。
(2)livepatch启动进行数据包到达监视的thread(数据包到达监视部110、具体而言isol_net_rx)。启动时，thread(数据包到达监视部110)占用CPU核心，以使得不会被其他进程或kernel thread繁忙轮询(busy poll)(参照图2的附图标记k)的干扰。因此，该thread分配实时进程(real time process)等的高优先级设定。根据业务流的数量(或者业务量)，在多个CPU核心上启动thread，分配进行监视的poll_list186(参照图2)。据此，能够根据业务流(业务量)进行扩展。
以后，执行图2所示的数据包处理的运行。
[服务器内延迟控制装置100的Rx侧数据包处理操作流程]
图4是表示服务器内延迟控制装置100(参照图2)的Rx侧运行和用于省电化的管理处理的流程图。参照图2来说明Rx侧运行。
在polling thread启动期间，循环执行本运行流程。
在步骤S1中，服务器内延迟控制装置100的数据包到达监视部110(参照图2)占用CPU来监视(poll)poll_list186(参照图2)(参照图2的附图标记k)，确认数据包是否到达。
在步骤S2中，数据包到达监视部110(参照图2)判别在poll list186中是否有意味着数据包到达的指针信息。
在poll list186中存在意味着数据包到达的指针信息的情况下(S2：是)，进行步骤S3，在poll list186中没有意味着数据包到达的指针信息的情况下(S2：否)，返回步骤S1的处理。
在步骤S3中，数据包到达监视部110从poll_list186获取在Ring_Buffer72(参照图2)中存在数据包的指针信息和NET_DEVICE信息，且向数据包采集部120传递该信息(指针信息和NET_DEVICE信息)(参照图2的附图标记q)。在此，在poll_list186中存在多个数据包信息的情况下，传递该多个信息。
在步骤S4中，在数据包到达的情况下，服务器内延迟控制装置100的数据包采集部120(参照图2)参照保持在Ring Buffer72中的数据包，基于以下进行的处理来执行从RingBuffer72删除对应的队列的条目的采集(参照图2的附图标记l)。
在步骤S5中，数据包采集部120根据接收到的信息从Ring_Buffer72取出数据包，且向netif_receive_skb87传递数据包(参照图2的附图标记m)。
在步骤S6中，服务器内延迟控制装置100的sleep管理部130判别即使经过一定期间在poll_list186中也没有数据包的保存(没有数据包到达)的情况。
即使经过一定期间在poll_list186中也没有数据包的保存的情况下(S6：是)，在步骤S7中sleep管理部130使polling thread休眠(sleep)。在poll_list186中有数据包的保存的情况下(S6：否)，返回步骤S1。
在步骤S8中，CPU频率/CPU idle设定部140将polling thread使用的CPU核心的运行频率设定得较低而结束本流程的处理。CPU频率/CPU idle设定部140在还能设定CPUidle设定的情况下有效化。
图5是表示用于服务器内延迟控制装置100的省电化的CPU频率/CPU idle设定处理的流程图。
在步骤S11中，在数据包到达时被启动的硬中断处理部(图2的netif_rx182)在数据包到达时启动polling thread(图2的服务器内延迟控制装置100)。在polling thread已经启动的情况下继续该状态。sleep管理部130通过数据包到达时的hardIRQ进行sleep解除。
在步骤S12中，CPU频率/CPU idle设定部140将polling thread使用的CPU核心的运行频率设定得较高(使CPU核心的运行频率恢复到原来的频率)而结束本流程的处理。在此，CPU频率/CPU idle设定部140在CPU idel设定也变更了的情况下返回。
<附加功能>
为了防止来自poll_list186的数据包漏采，也可以定期地启动polling thread，确认poll_list186的数据包是否到达。
这样一来，在存在基于NIC11的数据包到达和polling thread的sleep同时发生等的时间问题的情况下，能够防止在poll_list186残留数据包。
[本实施方式与现有技术的差异]
接着，对本实施方式与现有技术(参照图12)的差异进行说明。
<背景>
一般而言，硬中断(hardIRQ)的优先级高，需要中断对应的CPU的处理，最优先地进行hardIRQ的处理。因此，开销大。因此，在hardIRQ中只通知数据包到达，数据包处理的设计思想是由softIRQ进行处理(称为“kernel的原则”)。在此，softIRQ与其他的softIRQ冲突，产生等待的事件(成为发生延迟的主要原因)。
现有技术采用中断模型的理由为，过去CPU资源有限(或者，即使在如RaspberryPi等单板计算机(Single board Computer)那样CPU核心少的设备中也进行运行)，因此，设计思想为与其他处理共享1个CPU核心来使用。在此情况下，在通常的处理、中断处理等中一边切换CPU时间一边进行处理。即使在上述中断处理中，softIRQ也会冲突，产生等待时间。
另外，作为进行softIRQ的调度的调度程序的ksoftirqd不具有根据softIRQ的类别来赋予优先级的功能，无法抑制该冲突导致的延迟发生。
<现有技术(参照图12)>
如图12所示，kernel71(图11)通过hardIRQ81接收来自NIC11的数据包到达的通知(参照图12的附图标记h)，调度用于数据包处理的softIRQ83(参照图12的虚线框p)。此时，如果与其他中断处理冲突则发生等待，由此产生ms量级的NW延迟。
<服务器内延迟控制系统1000(参照图2)>
·数据包到达监视部110和数据包采集部120的安装
如图2所示，服务器内延迟控制系统1000为，在<Networking layer>中，netif_rx182在poll_list186中登录net_device，但与现有技术(参照图12)的netif_rx82不同，不进行软中断(softIRQ)的调度(“变更点1”)。
如图2所示，服务器内延迟控制系统1000在位于<Networking layer>的服务器中的存储器空间设置服务器内延迟控制装置100(“变更点2”)。
服务器内延迟控制装置100的数据包到达监视部110始终监视(busy poll)poll_list186(参照图2的附图标记k)，确认数据包是否到达。
数据包到达监视部110从poll_list186获取在Ring_Buffer72中存在数据包的指针信息和NET_DEVICE信息，向数据包采集部120传递该信息(指针信息和NET_DEVICE信息)(参照图2的附图标记q)。
在数据包到达的情况下，服务器内延迟控制装置100的数据包采集部120从RingBuffer72采集数据包(参照图2的附图标记l)。
数据包采集部120根据接收到的信息从Ring_Buffer72取出数据包，且向netif_receive_skb87传递数据包(参照图2的附图标记m)。
基于上述“变更点1”的作用效果如下。
首先，在本实施方式中，针对基于硬中断(hardIRQ)的数据包到达的通知，遵循NAPI。softIRQ在合理有效使用CPU资源方面很便利，但从数据包的立即传输的观点来看并不合适。因此，在本实施方式中新颖之处在于，停止softIRQ的功能，在kernel中实现polling模型。具体而言，示出图2所示的netif_rx182并不如图12所示的netif_rx82那样启动softIRQ83(处理程序)的通知(参照图12的附图标记h)。
另外，关于polling模型，从用户空间进行polling的DPDK是现有技术(参照图10)。然后，DPDK由于需要由APL进行polling，因此，APL需要改变。
基于上述“变更点2”的作用效果如下。
本实施方式为，在图1所示的kernel171中启动polling专用的thread(服务器内延迟控制装置100的数据包到达监视部110)，服务器内延迟控制装置100的数据包采集部120在数据包到达时通过polling模型(无softIRQ)进行数据包处理。据此，无需APL改变，换言之，能够利用现有的POSIX socket API。
另外，为了使前述thread不会被其他的softIRQ等侵占CPU时间，如在上述[基于live patch的登录]中叙述的那样，在thread启动时占用CPU核心，进行高优先级设定，据此不会妨碍polling。
以上，服务器内延迟控制装置100具有数据包到达监视部110和数据包采集部120，据此实现低延迟的数据包传输。即，停止数据包到达时的软中断(softIRQ)，在kernel内实现polling模型。重建监视数据包到达的kernel thread，监视向poll_list186的数据包到达。据此，数据包到达时，无需等待而被立即采集，因此能够实现低延迟的数据包处理。
·sleep管理部130和CPU频率/CPU idle设定部140的安装
服务器内延迟控制装置100还具有sleep管理部130和CPU频率/CPU idle设定部140，据此除了上述的低延迟的数据包处理以外，实现省电。即，监视数据包到达的kernelthread在没有数据包到达的期间能够休眠。休眠中的thread通过数据包到达时的hardIRQ处理程序唤醒，据此一边避免softIRQ冲突一边立即启动。通过按照上述休眠来调整CPU运行频率或CPU idle状态，进一步实现低能耗。
<sleep管理部130和CPU频率/CPU idle设定部140的详细运行(参照图2)>
图2所示的netif_rx182在数据包到达时polling thread休眠的情况下启动(参照图2的附图标记p)。在polling thread已经启动的情况下，不进行任何特殊的运行而结束硬中断处理程序。
通过硬中断处理程序启动的polling thread(服务器内延迟控制装置100)的CPU频率/CPU idle设定部140将polling thread使用的CPU核心的CPU运行频率设定得较高(使CPU核心的运行频率恢复到原来的频率)。
在此，kernel能够通过governor设定变更CPU核心的运行频率，CPU频率/CPU idle设定部140能够利用governor设定等，将CPU运行频率设定得较高。但是，CPU idle设定取决于CPU型号。另外，在CPU核心使CPU idle设定有效化的情况下，也可以解除。
数据包到达监视部110确认在poll_list186中是否保存有数据包的指针。在保存有指针的情况下，向数据包采集部120传递对应的指针信息和device driver信息。
在polling thread启动期间，循环执行目前为止的运行。另外，也可以根据数据包到达的频度来增减基于该循环的数据包到达确认间隔。例如，对每单位时间T的数据包到达数N进行计数，将确认频度设定为N/T[次/秒]以上等。通过该增减，能够进一步降低CPU使用率。
数据包采集部120根据接收到的指针信息和device driver信息，从RingBuffer72采集数据包。在此之后，向图2所示的netif_receive_skb87(数据包结构体管理部)传递对应的数据。
netif_receive_skb87根据接收到的数据制成数据包处理所需的结构体(sk_buff结构体等)。另外，以后，继续基于kernel的协议处理。
sleep管理部130在上述poll_list186的数据包的指针确认中，从数据包到达监视部110接收poll_list186的数据包是否到达信息。sleep管理部130根据该数据包是否到达信息，在判断为在一定期间内没有数据包到达的情况下，向CPU频率/CPU idle设定部140传递在一定期间内没有数据包到达的意思。
CPU频率/CPU idle设定部140在一定期间内没有数据包到达的情况下，接收来自sleep管理部130的通知，将polling thread使用的CPU核心的CPU运行频率设定得较低。此时，CPU频率/CPU idle设定部140在能使CPU idle设定有效化的情况下有效化(但是，有时取决于CPU型号)。
sleep管理部130在CPU频率/CPU idle设定部140的设定结束之后，使pollingthread进入sleep状态(休眠)。
另外，降低CPU频率设定的处理和进入该sleep状态的处理可以同时执行。另外，也可以在确认数据包传输处理完成之后休眠。
[硬件结构]
本实施方式所涉及的服务器内延迟控制装置100例如通过图6所示的结构的计算机900来实现。
图6是表示实现服务器内延迟控制装置100的功能的计算机900一例的硬件结构图。
计算机900具有CPU901、ROM902、RAM903、HDD904、通信接口(I/F：Interface)906、输入输出接口(I/F)905和多媒体接口(I/F)907。
CPU901基于保存在ROM902或者HDD904中的程序来运行，进行图1所示的服务器内延迟控制装置100的各部的控制。ROM902保存计算机900启动时由CPU901执行的启动程序、依赖于计算机900的硬件的程序等。
CPU901通过输入输出I/F905，控制鼠标、键盘等输入装置910、以及显示器等输出装置911。CPU901通过输入输出I/F905从输入装置910获取数据，并且向输出装置911输出所生成的数据。另外，作为处理器，也可以与CPU901一起使用GPU(Graphics ProcessingUnit：图形处理器)等。
HDD904存储由CPU901执行的程序和由该程序所使用的数据等。通信I/F906通过通信网(例如，NW(Network)920)从其他装置接收数据且将其输出给CPU901，另外，通过通信网将CPU901生成的数据发生给其他的装置。
多媒体I/F907读取保存在存储介质912中的程序或者数据，通过RAM903将其输出给CPU901。CPU901通过多媒体I/F907将目标的处理所涉及的程序从存储介质912加载到RAM903上，且执行加载的程序。存储介质912是DVD(Digital Versatile Disc：数字通用光盘)、PD(Phase change rewritable Disk：相变可重写盘)等光学存储介质、MO(MagnetoOptical disk：磁光盘)等光磁存储介质、磁存储介质、导体存储带介质或者半导体存储器等。
例如，在计算机900作为构成为本实施方式所涉及的一装置的服务器内延迟控制装置100来发挥作用的情况下，计算机900的CPU901通过执行加载到RAM903上的程序来实现服务器内延迟控制装置100的功能。另外，在HDD904存储RAM903内的数据。CPU901从存储介质912读出目标的处理所涉及的程序并执行。除此以外，CPU901也可以通过通信网(NW920)从其他的装置来读取目标的处理所涉及的程序。
[适用例]
服务器内延迟控制装置100是在Kernel内启动使用轮询模型来监视数据包到达的线程的服务器内延迟控制装置即可，并不限定OS。另外，也不限定于服务器虚拟化环境下。因此，服务器内延迟控制系统1000能够适用于图7和图8所示的各结构。
<对VM结构的适用例>
图7是表示对通用Linux kernel(注册商标)和VM结构的服务器虚拟化环境中的中断模型适用服务器内延迟控制系统1000A的例子的图。对与图1及图9相同的构成部分标注相同的附图标记。
如图7所示，服务器内延迟控制系统1000A为，在Guest OS70的Kernel171内配置服务器内延迟控制装置100，在Host OS90的Kernel91内配置服务器内延迟控制装置100。
详细而言，服务器具有虚拟机以及形成于虚拟机外的外部进程能够运行的HostOS90和在虚拟机内运行的Guest OS70。
HostOS90具有：Kernel91；Ring Buffer22，其在具有HostOS90的服务器中的存储器空间内，由Kernel91进行管理；poll_list186(图2)，其登录表示来自NIC11的硬中断(hardIRQ)是哪个设备的网络设备的信息；作为kernel thread的vhost-net模块221；tap设备222，其是由Kernel91制成的虚拟接口；和虚拟交换机(br)223。
Kernel91具有服务器内延迟控制装置100。
Kernel91通过tap设备222向虚拟机30传递数据包。
另一方面，GuestOS70具有：Kernel171；Ring Buffer52，其在具有GuestOS70的服务器中的存储器空间内，由Kernel171进行管理；poll_list186(图2)，其登录表示来自NIC11的硬中断(hardIRQ)是哪个设备的网络设备的信息；和Socket75，其是Kernel171用于进行进程间通信的接口。
Kernel171具有：服务器内延迟控制装置100；和协议处理部74，其进行被执行采集的数据包的协议处理。
Kernel171通过协议处理部74向数据包处理APL1传递数据包。
这样一来，在VM的虚拟服务器结构的系统中，在HostOS90和GuestOS70中的任一OS均无需改变APL而减小服务器内的延迟来进行数据包传输。
<向容器结构的适用例>
图8是表示对容器结构的服务器虚拟化环境中的中断模型适用服务器内延迟控制系统1000B的例子的图。对与图1相同的构成部分标注相同的附图标记。
如图8所示，服务器内延迟控制系统1000B具有Guest OS180和将OS替换为Container210的容器结构。Container210具有vNIC(虚拟NIC)211。在Guest OS180的Kernel181内配置服务器内延迟控制装置100。
在容器等的虚拟服务器结构的系统中，无需改变APL而能够减小服务器内的延迟来进行数据包传输。
<对裸金属(bare metal)结构(非虚拟化结构)的适用例>
本发明能够如裸金属结构那样适用于非虚拟化结构的系统。在非虚拟化结构的系统中，无需改变APL3而能够减少服务器内的延迟来进行数据包传输。
<扩展技术>
在业务流的数量增加的情况下，本发明与能够通过多个CPU对入站(inbound)的网络流量进行处理的RSS(Receive-Side Scaling)协作，增加对数据包到达监视thread分配的CPU数，据此能够针对网络负荷进行扩展。
[效果]
如以上说明的那样，OS(OS70)具有：内核(Kernel171)；环形缓冲区(RingBuffer72)，其在具有OS的服务器中的存储器空间内，由内核进行管理；轮询列表(poll_list186)，其登录表示来自接口部(NIC11)的硬中断(hardIRQ)是哪个设备的网络设备的信息，在内核内具有服务器内延迟控制装置100，服务器内延迟控制装置100启动使用轮询模型来监视数据包到达的线程(thread)，服务器内延迟控制装置100具有：数据包到达监视部110，其监视(polling)轮询列表；数据包采集部120，其在数据包到达的情况下，参照保存在环形缓冲区中的数据包，基于以下进行的处理执行从环形缓冲区删除对应的队列的条目的采集；和sleep管理部130，其在规定期间内没有数据包到达的情况下使线程(pollingthread)休眠(sleep)，且在数据包到达时通过该线程(polling thread)的硬中断(hardIRQ)来进行休眠解除。
这样一来，服务器内延迟控制装置100使作为NW延迟发生的主要原因的数据包处理的软中断(softIRQ)停止，执行服务器内延迟控制装置100的数据包到达监视部110监视数据包到达的thread，数据包采集部120在数据包到达时通过polling模型(无softIRQ)进行数据包处理。并且，sleep管理部130在规定期间内没有数据包到达的情况下使线程(polling thread)休眠(sleep)，据此，线程(polling thread)在没有数据包到达时休眠。sleep管理部130在数据包到达时通过硬中断(hardIRQ)进行休眠解除。
据此，发挥下述(1)～(4)的效果。
(1)使作为延迟发生的原因的数据包到达时的软中断(softIRQ)停止，在内核(Kernel171)内实现polling模型。即，服务器内延迟控制系统1000与现有技术的NAPI不同，实现polling模型而不是作为NW延迟的主要原因的中断模型。数据包到达时，无需等待而立即采集，因此能够实现低延迟的数据包处理。
(2)服务器内延迟控制装置100中的polling thread作为kernel thread来运行，以polling模式来监视数据包到达。监视数据包到达的kernel thread(polling thread)在没有数据包到达的期间休眠。在没有数据包到达的情况下，通过休眠而不使用CPU，因此能够得到省电的效果。
并且，数据包到达时，休眠中的polling thread通过数据包到达时的hardIRQ处理程序唤醒(休眠解除)。通过由hardIRQ处理程序进行休眠解除，能够一边避免softIRQ冲突，一边立即启动polling thread。在此，sleep解除的特征在于，由hardIRQ处理程序来触发，不是具有计时器而通过该计时器来触发。另外，在预先知道流量负载的情况下，例如在如图13所示的工作负荷传输率那样已知30mssleep的情况下，也可以在该时间由hardIRQ处理程序触发。
这样，服务器内延迟控制装置100通过执行进行数据包传输处理的pollingthread的sleep管理，能够同时实现低延迟和省电。
(3)无需使APL具有用于数据包高速传输的功能，APL只需与内核(Kernel171)具有的现有POSIX socket API进行互通即可。即，服务器内延迟控制系统1000与现有技术的DPDK不同，在kernel内实现polling模型，因此APL无需改变。具体而言，如图10所示，无需使数据包处理APL1A(参照图10)具有用于数据包高速传输的功能(参照图10的dpdk(PMD)2)，本服务器内延迟控制系统1000的数据包处理APL1(参照图1)只需与kernel具有的现有的POSIX socket API进行互通即可(无需修改kernel的协议栈)。因此，无需改变APL而能够实现。
(4)由于同样的理由，无需制作独自的kernel而能够实现。
另外，在虚拟机内运行的Guest OS(GuestOS70)具有：内核(Kernel171)；环形缓冲区(Ring Buffer72)，其在具有Guest OS的服务器中的存储器空间内，由内核进行管理；轮询列表(poll_list186)，其登录表示来自接口部(NIC11)的硬中断(hardIRQ)是哪个设备的网络设备的信息；和协议处理部74，其进行被执行采集的数据包的协议处理，在内核内具有服务器内延迟控制装置100，服务器内延迟控制装置100启动使用轮询模型来监视数据包到达的线程(thread)，服务器内延迟控制装置100具有：数据包到达监视部110，其监视(polling)轮询列表；数据包采集部120，其在数据包到达的情况下，参照保存在环形缓冲区中的数据包，基于接下来进行的处理，执行从环形缓冲区删除对应的队列的条目的采集；和sleep管理部130，其在规定期间内没有数据包到达的情况下使线程(polling thread)休眠(sleep)，且在数据包到达时通过该线程(polling thread)的硬中断(hardIRQ)来进行休眠解除。
这样一来，在VM的虚拟服务器结构的系统中，在具有Guest OS(GuestOS70)的服务器中，能够通过在实现降低电功率消耗的同时无需改变APL而减小服务器内的延迟来进行数据包传输。
另外，虚拟机以及形成于虚拟机外的外部进程能够运行的Host OS(HostOS90)具有：内核(Kernel91)；环形缓冲区(Ring Buffer22)，其在具有Host OS的服务器中的存储器空间内，由内核进行管理；轮询列表(poll_list186)，其登录表示来自接口部(NIC11)的硬中断(hardIRQ)是哪个设备的网络设备的信息；和tap设备222，其是由内核(Kernel91)制成的虚拟接口，在内核内具有服务器内延迟控制装置100，服务器内延迟控制装置100启动使用轮询模型来监视数据包到达的线程(thread)，服务器内延迟控制装置100具有：数据包到达监视部110，其监视(polling)轮询列表；数据包采集部120，其在数据包到达的情况下，参照保存在环形缓冲区(Ring Buffer72)中的数据包，基于接下来进行的处理，执行从环形缓冲区(Ring Buffer72)删除对应的队列的条目的采集；和sleep管理部130，其在规定期间内没有数据包到达的情况下使线程(polling thread)休眠(sleep)，且在数据包到达时通过该线程(polling thread)的硬中断(hardIRQ)来进行休眠解除。
这样一来，在VM的虚拟服务器结构的系统中，在具有内核(Kernel171)和Host OS(HostOS90)的服务器中，能够通过在实现降低电功率消耗的同时无需改变APL而减小服务器内的延迟来进行数据包传输。
在服务器内延迟控制装置100中，其特征在于，具有CPU频率设定部(CPU频率/CPUidle设定部140)，在休眠中，所述CPU频率设定部将线程使用的CPU核心的CPU运行频率设定得较低。
这样，服务器内延迟控制装置100能够根据流量动态地变更CPU运行频率，即，如果通过休眠而不使用CPU，则将休眠中的CPU运行频率设定得较低。据此能够进一步提高省电的效果。
在服务器内延迟控制装置100中，其特征在于，具有CPU空闲设定部(CPU频率/CPUidle设定部140)，在休眠中，CPU空闲设定部将线程使用的CPU核心的CPU空闲状态设定为省电模式。
这样一来，服务器内延迟控制装置100能够根据流量动态地变更CPU idle状态(变更运行电压等、与CPU型号对应的省电功能)，据此能够进一步提高省电的效果。
在服务器内延迟控制装置100中，其特征在于，内核(Kernel171)具有能够在使该内核(Kernel171)启动的状态下变更处理操作的补丁(livepatch)。
这样一来，服务器内延迟控制装置100使用livepatch，能够在启动(Kernel171)的状态下变更处理操作，因此无需kernel的改造。因此，服务器内延迟控制装置100例如无需在每次进行kernel的安全更新时重新开发，只需在相关的kernel功能发生变更时变更处理操作即可。
另外，也能够手动进行在上述实施方式中说明的各处理中的说明为自动进行的处理的全部或者一部分，或者也能够使用公知的方法自动进行说明为手动进行的处理的全部或者一部分。除此以外，除了特别记载的情况以外，上述说明书中和附图中所示的处理步骤、控制步骤、具体名称、包括各种数据或参数的信息能够任意地变更。
另外，图示的各装置的各结构要素是功能概念性的，无需物理性地如图示那样构成。即，各装置的分散、综合的具体方式并不限定于图示，还能够根据各种负荷或使用状况等，以任意的单位将其全部或者一部分功能性或者物理性地分散、综合来构成。
另外，上述的各结构、功能、处理部、处理装置等例如可以通过在集成电路中进行设计等而由硬件来实现其中的一部分或者全部。另外，上述的各结构、功能等也可以通过由解释、执行处理器实现各个功能的程序的软件来实现。实现各功能的程序、表格、文件等的信息能够保存在存储器、硬盘SSD(Solid State Drive)等存储装置、或者IC(IntegratedCircuit)卡、SD(Secure Digital)卡、光盘等存储介质中。
附图标记说明
1：数据包处理APL(应用程序)；10：HW；11：NIC(物理NIC)(接口部)；70：OS；74：协议处理部；60：user space(用户空间)；72：Ring Buffer(环形缓冲区)；90：Host OS(OS)；91、171、181：Kernel(内核)；100：服务器内延迟控制装置(polling thread)；110：数据包到达监视部；120：数据包采集部；130：sleep管理部；140：CPU频率/CPU idle设定部(CPU频率设定部、CPU空闲设定部)；180：Guest OS(OS)；186：poll_list(轮询列表)；210：Container；1000、1000A、1000B：服务器内延迟控制系统。

Claims (8)

1.一种服务器内延迟控制装置，其特征在于，
OS具有内核、环形缓冲区和轮询列表，其中，
所述环形缓冲区在具有所述OS的服务器中的存储器空间内由所述内核进行管理；
所述轮询列表登录表示来自接口部的硬中断是哪个设备的网络设备的信息，
在所述内核内具有所述服务器内延迟控制装置，所述服务器内延迟控制装置启动使用轮询模型来监视数据包到达的线程，
所述服务器内延迟控制装置具有数据包到达监视部、数据包采集部和休眠管理部，其中，
所述数据包到达监视部监视所述轮询列表；
在数据包到达的情况下，所述数据包采集部参照保存在所述环形缓冲区中的数据包，基于接下来进行的处理来执行从所述环形缓冲区删除对应的队列的条目的采集；
所述休眠管理部在数据包在规定期间未到达的情况下使所述线程休眠，并且在数据包到达时通过硬中断进行该线程的休眠解除。
2.一种服务器内延迟控制装置，其特征在于，
在虚拟机内运行的Guest OS具有内核、环形缓冲区、轮询列表和协议处理部，其中，
所述环形缓冲区在具有所述Guest OS的服务器中的存储器空间内由所述内核进行管理；
所述轮询列表登录表示来自接口部的硬中断是哪个设备的网络设备的信息；
所述协议处理部进行被执行采集的数据包的协议处理，
在所述内核内具有所述服务器内延迟控制装置，所述所述服务器内延迟控制装置启动使用轮询模型来监视数据包到达的线程，
所述服务器内延迟控制装置具有数据包到达监视部、数据包采集部和休眠管理部，其中，
所述数据包到达监视部监视所述轮询列表；
在数据包到达的情况下，所述数据包采集部参照保存在所述环形缓冲区中的数据包，基于接下来进行的处理来执行从所述环形缓冲区中删除对应的队列条目的所述采集；
所述休眠管理部在数据包在规定期间未到达的情况下使所述线程休眠，并且在数据包到达时通过硬中断进行该线程的休眠解除。
3.一种服务器内延迟控制装置，其特征在于，
虚拟机以及形成于所述虚拟机外的外部进程能够运行的Host OS具有内核、环形缓冲区、轮询列表和tap设备，其中，
所述环形缓冲区在具有所述Host OS的服务器中的存储器空间内由所述内核进行管理；
所述轮询列表登录表示来自接口部的硬中断是哪个设备的网络设备的信息；
所述tap设备是由所述内核制成的虚拟接口，
在所述内核内具有所述服务器内延迟控制装置，所述服务器内延迟控制装置启动使用轮询模型来监视数据包到达的线程，
所述服务器内延迟控制装置具有数据包到达监视部、数据包采集部和休眠管理部，其中，
所述数据包到达监视部监视所述轮询列表；
在数据包到达的情况下，所述数据包采集部参照保存在所述环形缓冲区中的数据包，基于接下来进行的处理来执行从所述环形缓冲区中删除对应的队列条目的采集；
所述休眠管理部在数据包在规定期间未到达的情况下使所述线程休眠，并且在数据包到达时通过硬中断进行该线程的休眠解除。
4.根据权利要求1至3中任一项所述的服务器内延迟控制装置，其特征在于，
具有CPU频率设定部，所述CPU频率设定部在所述休眠中将所述线程使用的CPU核心的CPU运行频率设定得较低。
5.根据权利要求1至3中任一项所述的服务器内延迟控制装置，其特征在于，
具有CPU空闲设定部，所述CPU空闲设定部在所述休眠中将所述线程使用的CPU核心的CPU空闲状态设定为省电模式。
6.根据权利要求1至3中任一项所述的服务器内延迟控制装置，其特征在于，
所述内核具有能够在使该内核启动的状态下变更处理操作的补丁。
7.一种服务器内延迟控制装置的服务器内延迟控制方法，其特征在于，
OS具有内核、环形缓冲区和轮询列表，其中，
所述环形缓冲区在具有所述OS的服务器中的存储器空间内由所述内核进行管理；
所述轮询列表登录表示来自接口部的硬中断是哪个设备的网络设备的信息，
在所述内核内具有服务器内延迟控制装置，所述服务器内延迟控制装置启动使用轮询模型来监视数据包到达的线程，
所述服务器内延迟控制装置执行以下步骤：
监视所述轮询列表；
在数据包到达的情况下，参照保存在所述环形缓冲区中的数据包，基于接下来进行的处理来执行从所述环形缓冲区中删除对应的队列条目的采集；
在数据包在规定期间未到达的情况下使所述线程休眠，并且在数据包到达时通过硬中断来进行该线程的休眠解除。
8.一种程序，其特征在于，
OS具有内核、环形缓冲区和轮询列表，其中，
所述环形缓冲区在具有所述OS的服务器中的存储器空间内由所述内核进行管理；
所述轮询列表登录表示来自接口部的硬中断是哪个设备的网络设备的信息；
在所述内核内具有服务器内延迟控制装置，所述服务器内延迟控制装置启动使用轮询模型来监视数据包到达的线程，
所述程序使作为所述服务器内延迟控制装置的计算机执行数据包到达监视步骤、数据包采集步骤和休眠管理步骤，其中，
在所述数据包到达监视步骤中监视所述轮询列表；
在所述数据包采集步骤中，在数据包到达的情况下，参照保存在所述环形缓冲区中的数据包，基于接下来进行的处理来执行从所述环形缓冲区中删除对应的队列条目的采集；
在所述休眠管理步骤中，在数据包在规定期间未到达的情况下使所述线程休眠，并且在数据包到达时通过硬中断来进行该线程的休眠解除。
CN202180095948.8A 2021-03-18 2021-03-18 服务器内延迟控制装置、服务器内延迟控制方法和程序 Pending CN116982030A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/011237 WO2022195826A1 (ja) 2021-03-18 2021-03-18 サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム

Publications (1)

Publication Number Publication Date
CN116982030A true CN116982030A (zh) 2023-10-31

Family

ID=83320176

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202180095948.8A Pending CN116982030A (zh) 2021-03-18 2021-03-18 服务器内延迟控制装置、服务器内延迟控制方法和程序

Country Status (5)

Country Link
US (1) US20240160468A1 (zh)
EP (1) EP4310680A1 (zh)
JP (1) JPWO2022195826A1 (zh)
CN (1) CN116982030A (zh)
WO (1) WO2022195826A1 (zh)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009060530A1 (ja) * 2007-11-09 2009-05-14 Fujitsu Limited ネットワーク処理制御装置，プログラムおよび方法
US9558132B2 (en) * 2013-08-14 2017-01-31 Intel Corporation Socket management with reduced latency packet processing
JP5960186B2 (ja) * 2014-04-03 2016-08-02 日本電信電話株式会社 仮想通信路構築システム、仮想通信路構築方法、及び仮想通信路構築プログラム

Also Published As

Publication number Publication date
US20240160468A1 (en) 2024-05-16
JPWO2022195826A1 (zh) 2022-09-22
WO2022195826A1 (ja) 2022-09-22
EP4310680A1 (en) 2024-01-24

Similar Documents

Publication Publication Date Title
JP7310924B2 (ja) サーバ内遅延制御装置、サーバ、サーバ内遅延制御方法およびプログラム
US7231638B2 (en) Memory sharing in a distributed data processing system using modified address space to create extended address space for copying data
US20020091826A1 (en) Method and apparatus for interprocessor communication and peripheral sharing
Larsen et al. Architectural breakdown of end-to-end latency in a TCP/IP network
TWI408934B (zh) 網路介面技術
US10884786B2 (en) Switch device, switching method, and computer program product
JP5453825B2 (ja) プログラム並列実行システム、マルチコアプロセッサ上のプログラム並列実行方法
US20140068165A1 (en) Splitting a real-time thread between the user and kernel space
JP2005267118A (ja) シングルプロセッサ向けｏｓによる並列処理システムにおけるプロセッサ間通信システム及びプログラム
CN114490499A (zh) 用于流送输入/输出数据的系统、装置和方法
CN114691286A (zh) 服务器系统、虚拟机创建方法及装置
Chang et al. Virtualization technology for TCP/IP offload engine
JP2010134698A (ja) 情報処理システム
JP7251648B2 (ja) サーバ内遅延制御システム、サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP2002024195A (ja) 並列処理装置、及び、並列処理方法
CN116982030A (zh) 服务器内延迟控制装置、服务器内延迟控制方法和程序
JP7451438B2 (ja) 通信装置、通信システム、通知方法及びプログラム
WO2023144878A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
JP7485101B2 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2023002547A1 (ja) サーバ内データ転送装置、サーバ内データ転送方法およびプログラム
WO2023218596A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2024013830A1 (ja) サーバ内データ転送装置、データ転送システム、サーバ内データ転送方法およびプログラム
WO2023199519A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
WO2023144958A1 (ja) サーバ内遅延制御装置、サーバ内遅延制御方法およびプログラム
US12001895B2 (en) Server delay control system, server delay control device, server delay control method, and program

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