Communication apparatus, method of controlling the same, and storage medium

Abstract

To provide a technique for achieving communication protocol processing for reducing the efficiency of parallel processing of a CPU and hardware and reducing overhead to host software processing.SOLUTION: In the communication apparatus, dynamically loaded software 210 hooks the communication protocol processing by the OS kernel. The dynamic load software 210 stores the communication protocol processing request in a processing queue. The communication device 105 transmits the packet subjected to the communication protocol processing corresponding to the communication protocol processing request stored in the processing waiting queue.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present invention relates to a communication device for performing data communication, a control method thereof, and a program. [Background technology]

[0002] In a communication device, processing based on a communication protocol such as TCP / IP involves packetizing user data (transmission data) stored in a buffer to be transmitted. For example, the transmission data is divided into divided data (segment data) in units of MSS (maximum segment size) in TCP. Then, checksums are calculated for the divided data and pseudo headers, and IP packets are generated that include the divided data and have a TCP header and an IP header attached. Furthermore, a MAC header is added to the generated IP packet, thereby generating a MAC frame such as an Ethernet (registered trademark) frame, and the generated MAC frame is transmitted to a transmission path.

[0003] In recent years, in order to reduce the processing load on a CPU and to achieve high-speed transmission, offloading techniques have been used in which the above-mentioned division into segment data and generation of headers for each communication protocol are performed using hardware such as a network interface (I / F). For example, as described in Patent Document 1, TCP Segmentation Offload (TSO) is known, in which a network I / F performs part or all of the TCP segmentation process instead of a CPU. Patent Document 1 also describes a technique in which division into segment data and generation of TCP / IP / Ethernet headers are performed using hardware other than a CPU, regardless of whether a communication device has a TSO function. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2018-196053 Summary of the Invention [Problem to be solved by the invention]

[0005] When performing communication protocol processing using hardware separate from the CPU, as in the conventional technology described above, the hardware performing the communication protocol processing may be operating and unavailable when the CPU requests communication protocol processing. In this case, the CPU must wait for the hardware to complete its operation, or must discard the transmitted data and start over. If the CPU waits for the hardware to complete its operation, the CPU will be locked until the hardware operation is complete, reducing the efficiency of parallel processing between the CPU and the hardware. Furthermore, discarding the transmitted data and restarting it creates overhead in the processing of higher-level software, which may impair communication performance.

[0006] Therefore, an object of the present invention is to provide a technique for realizing communication protocol processing that reduces the efficiency of parallel processing between a CPU and hardware and reduces the overhead on upper level software processing. [Means for solving the problem]

[0007] A communication device according to one embodiment of the present invention comprises a processing means for executing communication protocol processing by an OS kernel running on the communication device on behalf of the OS kernel, the processing means performing a division process for dividing transmission data to be transmitted into segment data and a header generation process for generating and attaching a header to each segment data divided by the division process; a hooking means for hooking the communication protocol processing by the OS kernel; a storage means for storing a communication protocol processing request to the processing means in a processing waiting queue; and a transmission means for transmitting a packet on which the processing means has performed the communication protocol processing corresponding to the communication protocol processing request stored in the processing waiting queue. [Effects of the Invention]

[0008] According to the present invention, it is possible to realize communication protocol processing that reduces the efficiency of parallel processing between a CPU and hardware and reduces the overhead on upper level software processing. [Brief explanation of the drawings]

[0009] [Figure 1] A block diagram showing an example of the hardware configuration of a communication device. [Figure 2] A block diagram showing an example of the functional configuration of a communication device. [Figure 3] Flowchart showing the processing steps performed by dynamic loading software [Figure 4] Flowchart showing the procedure of data determination processing (S302) [Figure 5] Flowchart showing the procedure for enqueuing to the processing queue (S312) [Figure 6] A flowchart showing the processing procedure of an interrupt handler. [Figure 7] Flowchart showing the procedure of delay processing [Figure 8] Flowchart showing the offloading process [Figure 9] A flowchart showing the procedure of enqueue processing (S312) including connection processing to a queue waiting for processing. [Figure 10] Figure 10 shows an example of whether a communication protocol processing request is linked when it is enqueued in a queue waiting for processing. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the invention according to the claims. Although the embodiments describe multiple features, not all of these multiple features are necessarily essential to the invention, and multiple features may be combined arbitrarily. Furthermore, in the accompanying drawings, the same reference numerals are used to designate the same or similar components, and redundant explanations will be omitted.

[0011] <Hardware configuration of communication device> 1 is a block diagram showing an example of the hardware configuration of a communication device 100 according to an embodiment of the present invention. The communication device 100 is a device equipped with a communication function, and may be, for example, a camera, a printer, a smartphone, a tablet, a PC (personal computer), a projector, or the like.

[0012] The communication device 100 includes a CPU 102, a ROM 103, a RAM 104, a communication device 105, and an offload processing unit (offload processing hardware) 106. A system bus 101 interconnects the CPU 102, the ROM 103, the RAM 104, the communication device 105, and the offload processing unit 106, and serves as a transfer path for various data between the connected devices.

[0013] The CPU 102 controls the communication device 100 by comprehensively controlling the hardware devices 103 to 106 via the OS or device drivers. The ROM 103 stores control programs such as the OS and device drivers executed by the CPU 102. The RAM 104 functions as the main memory and work area of ​​the CPU 102, and can temporarily store programs and data.

[0014] The communication device 105 has a MAC (Media Access Control) module 107 and a PHY (Physical Layer) module 108, and communicates with a communication partner device via a network 111. The network 111 is, for example, a network for communication (wired LAN communication) that complies with the Ethernet (registered trademark) standard. Data is transmitted and received via the network 111 by the CPU 102 executing a network driver and controlling the MAC module 107 in accordance with the network driver.

[0015] Note that the communication device 105 may have a function to perform communication (wireless LAN communication) conforming to the wireless LAN (Wi-Fi (registered trademark)) standard instead of or in addition to wired LAN communication. The communication device 105 may be configured to be able to perform IP communication conforming to any wired or wireless communication standard.

[0016] The offload processing unit 106 is a hardware unit including a DMAC (Direct Memory Access Controller) 109 and a protocol processing unit (protocol processing hardware) 110. The offload processing unit 106 executes processing (e.g., segment division processing and header generation processing) offloaded from the CPU 102. The offload processing unit 106 executes communication protocol processing by an OS kernel (OS kernel 201 in FIG. 2 ) running in the communication device 100, instead of the OS kernel. That is, the offload processing unit 106 executes processing offloaded from the CPU 102. Specifically, as will be described later, the offload processing unit 106 performs a division processing for dividing transmission data to be transmitted into segment data, and a header generation processing for generating and attaching headers to each segment data divided by the division processing. Furthermore, when the offload processing is completed, the offload processing unit 106 inputs a hardware interrupt signal to the CPU 102 via an interrupt controller in the CPU 102. Note that the interrupt controller may not be built into the CPU 102, but may be implemented as an independent peripheral.

[0017] The DMAC 109 transfers data stored in the RAM 104 to the protocol processing unit 110, and transfers data processed by the protocol processing unit 110 to the RAM 104. Data transfer by the DMAC 109 is controlled by the CPU 102. Although only one DMAC 109 is shown in FIG. 1, multiple DMACs 109 may be provided in the offload processing unit 106. The multiple DMACs may include, for example, a DMAC for reading data from the RAM 104 and a DMAC for writing data to the RAM 104.

[0018] The protocol processing unit 110 is hardware having a function of executing processing (communication protocol processing) according to a communication protocol such as TCP / IP (Transmission Control Protocol / Internet Protocol). The protocol processing unit 110 can perform, for example, TCP or UDP checksum calculation, header generation processing, and the like.

[0019] Note that the configuration example shown in FIG. 1 is merely an example, and communication device 100 may include components not shown in FIG. 1. For example, communication device 100 may include a timer management unit. The timer management unit may manage whether a predetermined time has elapsed. Furthermore, communication device 100 may include multiple CPUs, and CPU 102 may be configured with one or multiple processors. If communication device 100 is a camera, it may include an imaging unit and a display unit.

[0020] <Functional configuration of communication device> 2 is a block diagram showing an example of a functional configuration of the communication device 100 according to this embodiment. The communication device 100 has, as functional configurations related to this embodiment, an application 200, an OS kernel 201, dynamic loading software 210, and a second segment division unit 220 and a second header generation unit 221 provided in the offload processing unit 106. Note that in this embodiment, Linux (registered trademark) is assumed as the OS kernel 201 executed by the CPU 102, but is not limited to Linux (registered trademark), and an OS kernel other than Linux (registered trademark) may also be used.

[0021] (Application 200) The application 200 is a user application that exists in a user space. In this embodiment, the application 200 is an application that performs TCP / IPv4 communication, but it may also be an application that performs UDP communication. Application data (transmission data) of any size to be transmitted is input from the application 200 to the OS kernel 201 (protocol stack 202).

[0022] (OS Kernel 201) The OS kernel 201 includes a protocol stack 202 and a transfer processing unit 208. The protocol stack 202 includes a connection management unit 203, a first buffer management unit 204, a first segment division unit 205, a first header generation unit 206, a window control unit 207, and an IP processing hook unit 208.

[0023] The connection management unit 203 manages the communication connection of the communication device 100. For example, the connection management unit 203 manages the MSS (Maximum Segment Size) of the communication connection for the application 200, socket information such as offload setting information, and the like.

[0024] The first buffer management unit 204 generates management data for managing the transmission buffer used in kernel space. The transmission buffer is secured in a storage area of ​​the RAM 104 and managed using the management data generated by the first buffer management unit 204. For example, when the OS kernel is Linux (registered trademark), the first buffer management unit 204 generates a structure defined by struct sk_buff as the management data for the transmission buffer. The management data includes a reference to the data address and socket information in the kernel space, a reference to communication device information, etc.

[0025] The first segment division unit 205 divides the transmission data generated by the application 200 into MSS units and stores (copies) the obtained segment data in a transmission buffer in kernel space. The data size of the segment data stored in the transmission buffer is determined based on the TCP transmission window size, congestion window size, etc. managed by the window control unit 207. Furthermore, if offloading of checksum calculation is not configured in the TCP session, the first segment division unit 205 calculates a checksum value for the segment data when storing the segment data in the transmission buffer.

[0026] First header generation unit 206 performs TCP or UDP transport layer processing and IP network layer processing (specifically, header generation processing for each protocol). Window control unit 207 manages the TCP transmission window size and congestion window. IP processing hook unit 208 has a function of registering a callback that hooks IP protocol processing while first header generation unit 206 is performing header generation processing for the IP header, as communication protocol processing (IP protocol processing). For example, in Linux (registered trademark), processing by IP processing hook unit 208 is realized using an API (Application Programming Interface) provided by a framework called Netfilter.

[0027] The transfer processing unit 209 has a function of transferring input management data (i.e., transmission data stored in the transmission buffer and with TCP / IP / MAC headers added) to the communication device 105. The transfer processing unit 209 also includes a driver for the communication device 105. The driver for the communication device 105 may be included in the OS kernel 201, or may be realized as dynamically loaded software 210. The transfer processing unit 209 of the embodiment functions as an example of a transfer means that transfers a MAC frame obtained by adding a MAC header to each segment data obtained by dividing the transmission data to the communication device 105.

[0028] (Dynamic Load Software 210) The dynamically loaded software 210 is software that is dynamically loaded after the OS kernel 201 is started, and operates independently of the OS kernel 201. The dynamically loaded software 210 has a callback registration unit 211, a processing determination unit 212, a second buffer management unit 213, a socket information rewriting unit 214, a processing waiting queue 215, a protocol processing return unit 216, a completion detection unit 217, a delay processing unit 218, and a data link (DL) layer input unit 219. The processing procedures executed by the dynamically loaded software 210 will be described later using the flowcharts of FIGS.

[0029] The callback registration unit 211 uses the function provided by the IP processing hook unit 208 to register a callback that hooks IP protocol processing (communication protocol processing) by the OS kernel 201. That is, in this embodiment, the callback registration unit 211 has a function of hooking IP protocol processing. The callback registration unit 211 also registers a callback that serves as an interrupt handler routine for a hardware interrupt signal that is input to the CPU 102 when processing by the offload processing unit 106 is completed. The registration of these callbacks is executed when the dynamic load software 210 is loaded.

[0030] The processing determination unit 212 analyzes the contents of the management data for which an IP header has been generated, and performs processing determination (determines how to process the management data) on the management data, within a callback that hooks the IP protocol processing registered by the callback registration unit 211. The processing determination unit 212 can perform the following determinations (decisions), for example: A decision to return the management data to the processing of the protocol stack 202 that is the hook source for the IP protocol processing. ●A decision to rewrite the socket information in the management data. ● A decision to offload processing of management data.

[0031] Details of the processing determination by the processing determination unit 212 will be described later using the flowchart in Fig. 4. Furthermore, when the processing determination unit 212 determines that offload processing is to be performed on the management data, the processing determination unit 212 may further make the following determinations (decisions) depending on the state of the offload processing unit 106 and the state of the processing queue 215. ●A decision to start offload processing immediately. - Decision to generate a communication protocol processing request and enqueue it in the processing queue.

[0032] These determinations will be described later using the flowchart of FIG.

[0033] When the processing determination unit 212 determines that offload processing is to be performed on the management data (first management data), the second buffer management unit 213 secures (generates) new management data (second management data) for managing another transmission buffer. In this embodiment, the processing to be offloaded is segment division processing and header generation processing. The number of pieces of management data to be secured is calculated by dividing the segment data size managed by the original management data (first management data) by the MSS of the actual TCP session. If a remainder occurs in this division, it may be rounded up. For example, if the segment data size managed by the original management data is 15,000 bytes and the MSS is 1,460 bytes, 11 pieces of management data corresponding to 11 transmission buffers are secured. The transmission buffers managed by the management data are secured in a storage area in the RAM 104.

[0034] When the processing determination unit 212 determines that the socket information in the management data should be rewritten, the socket information rewriting unit 214 rewrites the socket information in the management data. The socket information to be rewritten is, for example, the cache value of the MSS and the offload setting for offloading (hardware offloading) the checksum calculation.

[0035] By setting the cached MSS value in the socket information to a value larger than the actual MSS value, it is possible to increase the segment data size after division by the first segment division unit 205. This increases the size of segment data managed by one piece of management data. It is also possible to increase the segment data size by setting segment offloading. When setting segment offloading, the maximum segment size and maximum number of segments are also set. Furthermore, by setting checksum calculation to be offloaded, it is possible to eliminate the need for checksum calculation by the first segment division unit 205, thereby reducing the processing load on the protocol stack 202.

[0036] The management data for which the socket information has been rewritten is returned to the protocol stack 202 by the protocol processing return unit 216. For the communication connection for which the socket information has been rewritten, the management data for which checksum calculation has not been performed on, for example, large-sized segment data, is subsequently processed by the dynamic load software 210.

[0037] The processing queue 215 is a processing queue to which the management data is enqueued when the processing determination unit 212 determines that offload processing is to be performed on the management data and determines that a communication protocol processing request is to be generated and enqueued in the processing queue. The processing procedure for enqueuing a communication protocol processing request will be described later using the flowchart in FIG. 5.

[0038] When processing determination unit 212 determines that the management data should be returned to processing in protocol stack 202, protocol processing return unit 216 returns the management data to protocol stack 202. Alternatively, protocol processing return unit 216 returns management data, the socket information of which has been rewritten by socket information rewriting unit 214, to protocol stack 202.

[0039] The completion detection unit 217 detects that the segment division process and header generation process by the offload processing unit 106 have been completed, and starts the processing of the delay processing unit 218. The detection of the completion of the processing by the offload processing unit 106 is implemented, for example, by an interrupt handler triggered by a hardware interrupt signal output by the offload processing unit 106 to the CPU 102. The processing procedure of the completion detection unit 217 will be described later using the flowchart of FIG.

[0040] The delay processing unit 218 outputs, to the DL layer input unit 219, second management data corresponding to the transmission data for which the offload processing unit 106 has completed the segmentation process and header generation process. The delay processing unit 218 also checks whether a communication protocol processing request is stored in the processing queue 215, and if so, acquires the communication protocol processing request that was enqueued first in the processing queue. In response to the acquired communication protocol processing request, the offload processing unit 106 is configured to receive information such as first management data, second management data, and the number of data items, and starts processing. If a communication protocol processing request is stored in the processing queue 215, the acquisition of the communication protocol processing request and the start of the offload processing unit 106 are executed prior to the output of the second management data to the DL layer input unit 219. The processing of the delay processing unit 218 can be implemented, for example, by a delay processing function called a tasklet or a work queue in Linux (registered trademark). The processing procedure of the delay processing unit 218 will be described later using the flowchart of FIG. 7.

[0041] The DL layer input unit 219 receives, from the delay processing unit 218, second management data corresponding to the transmission data that has been offloaded by the offload processing unit 106, and transmits the second management data to the DL layer (transfer processing unit 209) of the OS kernel 201, which is the hook source of the IP protocol processing. The transmission to the DL layer is performed using the functions of the OS kernel 201. For example, in Linux (registered trademark), the input of the second management data to the transfer processing unit 209 can be realized by calling dev_queue_xmit().

[0042] (Offload processing unit 106) The offload processing unit 106 has a second segment division unit 220 and a second header generation unit 221 as its functional components.

[0043] The second segment division unit 220 includes a DMAC 109. The second segment division unit 220 performs segment division processing using the address of the segment data managed using the first management data as the data read source and the segment data area managed using the second management data as the data write destination.

[0044] The second header generation unit 221 generates a TCP header and an IP header to be added to the transmission data that has been subjected to segmentation processing and is indicated by the second management data. Here, the transmission data indicated by the first management data includes header data indicating the IP header obtained by IP protocol processing. Therefore, the second header generation unit 221 performs header generation processing for the transmission data that corresponds to the second management data based on this header data. The processing steps executed by the offload processing unit 106 (the second segment division unit 218 and the second header generation unit 219) will be described later using the flowchart of FIG. 8.

[0045] In this embodiment, the second segment division unit 220 and the second header generation unit 221 are implemented by the offload processing unit 106, but may also be implemented by software. Furthermore, the configuration shown in Fig. 2 is an example, and the multiple functional units shown in Fig. 2 may be integrated into one functional unit, or any of the functional units may be divided into multiple functional units. Furthermore, some or all of the functional units included in the functional units shown in Fig. 2 may be implemented by hardware such as an ASIC (Application Specific Integrated Circuit).

[0046] <Dynamic Load Software Processing Procedure> 3 is a flowchart showing the procedure of processing executed by the dynamic loading software 210 in this embodiment. The dynamic loading software 210 determines (decides) a processing method for first management data related to communication protocol processing (IP protocol processing) hooked from the protocol stack 202 by the IP processing hook unit 208, and executes processing based on the determination result. The processing of each step in FIG. 3 is realized, for example, by the CPU 102 reading and executing a program stored in the ROM 103.

[0047] In S301, the dynamically loaded software 210 causes the processing determination unit 212 to hook the communication protocol processing (IP protocol processing) performed by the OS kernel 201 from the protocol stack 202, and starts the callback processing registered by the callback registration unit 211. Next, in S302, when the communication protocol processing is hooked, the dynamically loaded software 210 causes the processing determination unit 212 to perform a determination process on the first management data related to the hooked communication protocol processing. This determination process is executed in the procedure described below with reference to FIG. 4.

[0048] In S303, the dynamic load software 210 determines whether or not the determination process of S302 has determined that offload processing (hardware offload) should be performed on the first management data. If the determination process of S302 determines that offload processing should not be performed, the dynamic load software 210 proceeds to S304, and if the determination process of S302 determines that offload processing should be performed, the dynamic load software 210 proceeds to S307.

[0049] In S304, the dynamic loading software 210 determines whether the determination process in S302 has determined that the socket information in the first management data should be rewritten. If the determination process in S302 has determined that the socket information should be rewritten, the dynamic loading software 210 proceeds to S305. If the determination process in S302 has determined that the socket information should not be rewritten, the dynamic loading software 210 proceeds to S306. In S305, the dynamic loading software 210 rewrites the socket information in the first management data as described above using the socket information rewriting unit 214, and proceeds to S306. In S306, the dynamic loading software 210 returns the processing for the first management data to the protocol stack 202 that was the hook source, and ends the callback processing. The dynamic loading software 210 returns, as a callback return value, a constant defined by NF_ACCEPT in the NetFilter framework, for example.

[0050] Meanwhile, in S307, the dynamic load software 210 calculates the number of packets (number of segments) to be generated in the segment division process by the offload processing unit 106 (second segment division unit 220) through the above-mentioned calculation using the second buffer management unit 213. In this way, the dynamic load software 210 calculates the size of the transmission data, the predetermined size (in this embodiment, MSS in TCP), and the number of segments indicating the number of segment data obtained from the transmission data in the segment division process.

[0051] Next, in S308, the dynamic loading software 210 uses the second buffer management unit 213 to secure second management data corresponding to the number of packets to be generated calculated in S307. That is, second management data equal to the number of packets to be generated is secured. For example, in Linux (registered trademark), the second management data is secured by calling alloc_skb() a number of times equal to the number of packets to be generated (number of segments). In this way, the dynamic loading software 210 generates management data (second management data) for managing transmission buffers for storing segment data, in a number equal to the number of segments, separate from the transmission buffers for storing transmission data.

[0052] In S309, the dynamic load software 210 determines whether a communication protocol processing request is stored in the processing queue 215. If the determination result indicates that a communication protocol processing request is stored in the processing queue 215, the process proceeds to S310, and if the determination result indicates that a communication protocol processing request is not stored, the process proceeds to S312.

[0053] In S310, the dynamic load software 210 determines whether the offload processing unit 106 is in a standby state. Whether the offload processing unit 106 is in a standby state is determined, for example, by reading a register value indicating the state of the offload processing unit 106 and determining based on the read value. If the determination result indicates that the offload processing unit 106 is in a standby state, the process proceeds to S311, and if the determination result indicates that the offload processing unit 106 is not in a standby state, the process proceeds to S312.

[0054] In S311, the dynamic loading software 210 instructs the offload processing unit 106 to start offload processing. For example, the dynamic loading software 210 writes information necessary for offload processing to a register of the offload processing unit 106 registered as memory-mapped I / O, and instructs the offload processing unit 106 to start executing the offload processing. The information necessary for offload processing includes, for example, address information in memory of the first management data, address information in memory of the second management data, the number of segments, TCP / IP header information, etc. In this way, the dynamic loading software 210 sends the first management data (address information) and the second management data (address information) to the offload processing unit 106.

[0055] In S312, the dynamic load software 210 generates a communications protocol processing request and enqueues it in a processing queue. The procedure for enqueuing a communications protocol processing request will be described later with reference to the flowchart of FIG.

[0056] In S313, the dynamic loading software 210 releases the memory area for the first management data (original management data) related to the hooked communication protocol processing, and ends the callback processing. In Linux (registered trademark), for example, the dynamic loading software 210 releases the memory area for the first management data by calling kfree_skb(). In addition, the dynamic loading software 211 returns, as a callback return value, for example, a constant defined as NF_STOLEN in the Netfilter framework.

[0057] <Data Judgment Processing> 4 is a flowchart showing the procedure of the data determination process (S302) in this embodiment. In the data determination process, the process determination unit 212 analyzes first management data related to communication protocol processing hooked from the protocol stack 202, and determines a processing method for the data.

[0058] In S401, the processing determination unit 212 checks the transport layer communication protocol from the IP header indicated by the first management data, and determines whether the communication protocol is a communication protocol to be offloaded. In this embodiment, as an example, it is assumed that TCP is the communication protocol to be offloaded. That is, the determination in S401 is made based on the type of communication protocol. If the transport layer communication protocol is TCP, the processing determination unit 212 proceeds to S402, and if not, proceeds to S406.

[0059] In S402, the processing determination unit 212 checks the port number from the TCP header of the first management data and determines whether the port number is a port number that is a target for offload processing. In this embodiment, the port number (target port number) of the application that is to be the target for offload processing is specified (input) in advance. If the port number is a target port number, the processing determination unit 212 proceeds to S403, and if it is not a target port number, the processing proceeds to S406. Note that the processing of S402 (filtering by port number) may be executed, for example, when it is desired to perform offload processing only on a specific application, and may be omitted in other cases.

[0060] In S403, the processing determination unit 212 determines whether the socket information has been rewritten. Specifically, the processing determination unit 212 checks the offload setting information in the socket information. If the socket information has been rewritten, the processing determination unit 212 proceeds to S404, and if not, the processing determination unit 212 proceeds to S407.

[0061] In S404, the processing determination unit 212 determines whether the segment data size of the first management data is larger than MSS and whether the IP checksum for the segment data of the first management data has not yet been calculated. If the segment data size is larger than MSS or the IP checksum has not yet been calculated, the processing determination unit 212 proceeds to S405, and if the segment data size is equal to or smaller than MSS and the IP checksum has been calculated, the processing proceeds to S406.

[0062] Through this determination process, if the size of the transmission data exceeds a predetermined size (in this embodiment, MSS in TCP) or the IP checksum has not been calculated, the dynamic load software 210 (processing determination unit 212) controls the offload processing unit 106 to perform a division process for dividing the transmission data into segment data of a predetermined size and a header generation process. Furthermore, if the size of the transmission data does not exceed the predetermined size and the IP checksum has been calculated, the dynamic load software 210 (processing determination unit 212) returns the hooked communication protocol process to the OS kernel 201, thereby controlling the OS kernel 201 to execute the communication protocol process.

[0063] In S405, the processing determination unit 212 determines that offload processing is to be performed on the first management data (the first management data is the target of offload processing). In this case, the dynamic loading software 210 sends the management data to the second buffer management unit 213 in S307 of FIG.

[0064] In S406, the processing determination unit 212 determines that the first management data (corresponding transmission data) is not subject to offload processing and returns the data to protocol processing in the protocol stack 202. In this case, the dynamic load software 210 sends the management data to the protocol processing return unit 216 in S306 of FIG.

[0065] In S407, the process determination unit 212 determines to rewrite the socket information of the first management data. In this case, the dynamic load software 210 sends the management data to the socket information rewriting unit 214 in S305 of FIG.

[0066] <Processing procedure for enqueuing to the processing queue (S312)> 5 is a flowchart showing the procedure of the enqueue process (S312) to the processing waiting queue in this embodiment. In the enqueue process to the processing waiting queue, the processing determination unit 212 checks the state of the processing waiting queue 215, and enqueues a communication protocol processing request for the first management data, or discards the first management data.

[0067] In S501, the processing determination unit 212 determines whether there is free space in the processing waiting queue 215. Whether there is free space in the processing waiting queue 215 is determined by comparing a predetermined maximum storage number with the number of currently stored communication protocol processing requests. If there is free space in the processing waiting queue 215, the process proceeds to S502; if there is no free space, the process proceeds to S504.

[0068] In S502, the processing determination unit 212 generates a communications protocol processing request. The communications protocol processing request includes the first management data to be input, the second management data to be output, and the number of segments (the number of packets calculated in S307).

[0069] In S503, the processing determination unit 212 enqueues the generated communication protocol processing request in a processing queue. The processing queue is implemented, for example, with a data structure such as a list, and enqueuing is implemented by adding an element to the list.

[0070] In S504, the processing determination unit 212 releases the second management data newly secured in S308. In Linux (registered trademark), for example, the processing determination unit 212 calls kfree_skb() to release the memory area for the second management data.

[0071] In S505, the processing determination unit 212 drops (discards) the packet (management data). Specifically, the dynamic load software 211 returns, as a return value of the callback, for example, a constant defined by NF_DROP in the Netfilter framework.

[0072] <Processing Procedure of Interrupt Handler (Completion Detection Unit S217)> 6 is a flowchart showing the processing procedure of the interrupt handler (completion detection unit S217) in this embodiment. The interrupt handler is started by being triggered by a hardware interrupt signal output to the CPU 102 when the communication protocol processing by the offload processing unit 106 is completed.

[0073] In S601, the completion detection unit 217 acquires the interrupt cause from the interrupt controller.

[0074] In S602, the completion detection unit 217 determines from the interrupt cause whether or not the interrupt cause is a communications protocol processing completion interrupt from the offload processing unit 106. If the interrupt cause is a communications protocol processing completion interrupt from the offload processing unit 106, the process proceeds to S603, and if the interrupt cause is not a communications protocol processing completion interrupt, the process ends.

[0075] In S603, the completion detection unit 217 clears the interrupt cause. To clear the interrupt cause, the interrupt of the offload processing unit 106 and the interrupt of the interrupt controller are cleared as necessary. For example, if the interrupt of the offload processing unit 106 is a level interrupt, the interrupt of the offload processing unit 106 is cleared before the interrupt of the interrupt controller is cleared.

[0076] In S604, the completion detection unit 217 schedules the delay processing to be executed by the delay processing unit 218. The procedure of the delay processing executed by the delay processing unit 218 will be described later with reference to the flowchart of FIG.

[0077] <Delay processing procedure> 7 is a flowchart showing the processing procedure of the delay processing (delay processing unit 218) in this embodiment. The delay processing is scheduled by the completion detection unit 217 to the OS kernel, and is executed in a different context from the completion detection unit 217.

[0078] In S701, the delay processing unit 218 determines whether a communication protocol processing request is stored in the processing waiting queue. If a communication protocol processing request is stored, the process proceeds to S702, and if not, the process proceeds to S704.

[0079] In S702, the delay processing unit 218 dequeues the communication protocol processing request that was stored first from the processing waiting queue.

[0080] In S703, the delay processing unit 218 instructs the offload processing unit 106 to start the offload processing. The method of instructing the offload processing unit 106 to start the offload processing is the same as in S311, and therefore description thereof will be omitted.

[0081] In S704, the delay processing unit 218 performs a transmission process on the packet group (second management data) for which the communication protocol processing has been completed by the offload processing unit 106. Specifically, the delay processing unit 218 transmits the second management data to the DL layer input unit 219.

[0082] <Processing Procedure of Offload Processing Unit 106> The offload processing unit 106 executes communication protocol processing by the OS kernel 201 operating in the communication device 100 in place of the OS kernel 201. Specifically, the offload processing unit 106 performs a segment division process that divides transmission data to be transmitted into segment data, and a header generation process that generates and assigns a header to each segment data divided by the segment division process.

[0083] 8 is a flowchart showing the procedure of processing executed by the offload processor 106. The offload processor 106 executes offload processing in accordance with an execution instruction (S311) from the dynamic load software 210 or an execution instruction (S703) from the delay processor 218. The offload processor 106 divides the segment data stored in the transmission buffer corresponding to the first management data, and stores the divided segment data in the transmission buffer corresponding to the second management data. The offload processor 106 further generates a TCP / IP header corresponding to the second management data (i.e., to be added to the divided segment data) from the TCP / IP header corresponding to the first management data.

[0084] The offload processing unit 106 repeats the processes of S801 to S804 for the number of packets to be generated. First, in S801, the offload processing unit 106 performs segment division processing using the second segment division unit 220. Specifically, the second segment division unit 220 uses the address of the segment data managed by the first management data as the read source address to acquire the segment data using the DMAC 109. The second segment division unit 220 performs segment division processing by dividing the acquired segment data into segment data in MSS units. More specifically, the second segment division unit 220 performs segment division processing by copying the segment data to memory in MSS units for the second management data secured by the second buffer management unit 213, with the managed data area as the write destination.

[0085] In S802, the offload processing unit 106 generates a TCP header using the second header generation unit 221. The second header generation unit 221 acquires a TCP header corresponding to the first management data, and calculates a sequence number, a checksum, and the like for the second management data while using the port number information, control flags, and the like as they are.

[0086] In S803, the offload processing unit 106 generates an IP header using the second header generation unit 221. The second header generation unit 221 acquires an IP header corresponding to the first management data, and uses address information, protocol information, and the like for the second management data as is to calculate values ​​(packet length, identifier, checksum, and the like) that differ for each piece of second management data.

[0087] In S804, the offload processing unit 106 generates a MAC header using the second header generation unit 221. The offload processing unit 106 generates a MAC header using cache information of the MAC header included in the neighbor entry input from the dynamic load software 210. Specifically, the offload processing unit 106 generates a MAC header by copying the destination MAC address, source MAC address, etc. included in the cache information to the MAC header area corresponding to the second management data.

[0088] In this way, packets (MAC frames) are generated as transmission data by adding a TCP header, an IP header, and a MAC header to the segment data divided in S801. The generated packets (MAC frames) are stored in a transmission buffer managed by the second management data.

[0089] In S805, the offload processing unit 106 determines whether the processes of S801 to S804 have been repeated for the number of packets generated, and if not, returns to S801, and if completed, proceeds to S806.

[0090] In S806, the offload processing unit 106 performs processing to notify that the offload processing for packet generation has been completed. This completion notification is made by outputting a hardware interrupt signal indicating the completion of processing to the interrupt controller in the CPU 102.

[0091] Note that various modifications are possible to this embodiment. For example, in the processing procedure of the dynamically loaded software shown in Fig. 3, the step of determining whether the queue is empty (S309) and the step of determining the status of the offload processing unit (S310) may be omitted, and the task may be enqueued in the queue regardless of the status of the queue or the offload processing unit. This makes it possible to aggregate all offload processing start instructions into a delayed process.

[0092] Furthermore, in the process of enqueuing a communication protocol processing request to a queue waiting for processing (S312), if the segment size of an already stored communication protocol processing request is less than the maximum data size that can be processed by the offload processing unit, these requests can be concatenated, thereby improving the processing efficiency of the offload processing unit.

[0093] 9 is a flowchart showing the procedure of the enqueue process (S312) including the process of linking a communication protocol processing request to the processing waiting queue. Only the differences from the flowchart showing the enqueue process procedure shown in FIG.

[0094] In S901, the processing determination unit 212 determines whether a communication protocol processing request is stored in the processing waiting queue. If a communication protocol processing request is not stored, the process proceeds to S503, and if a communication protocol processing request is stored, the process proceeds to S902.

[0095] In S902, the processing determination unit 212 determines whether the sum of the segment size of the communication protocol processing request last enqueued in the processing waiting queue and the segment size of the communication protocol processing request generated in S502 is equal to or less than the maximum size that can be processed by the offload processing unit. If the sum of the segment sizes is equal to or less than the maximum size that can be processed by the offload processing unit, the processing proceeds to S903, and if the sum of the segment sizes is greater than the maximum size that can be processed, the processing proceeds to S503.

[0096] In S903, the processing determination unit 212 connects the communication protocol processing request last enqueued in the processing waiting queue with the communication protocol processing request generated in S502.

[0097] 10 is a diagram showing an example of whether or not a communication protocol processing request is linked when it is enqueued in a queue waiting for processing. Here, it is assumed that the maximum size that can be processed by the offload processing unit is 64 KB.

[0098] 10 shows how a new communications protocol processing request 1001 with a segment size of 30 KB is enqueued when communications protocol processing request 1000 with a segment size of 40 KB is stored in processing queue 215. The sum of the segment sizes of communications protocol processing request 1000 and communications protocol processing request 1001 is 70 KB, which is larger than the maximum size of 64 KB that can be processed by the offload processing unit, so they are not concatenated (upper right of FIG. 10).

[0099] 10 shows the state in the upper right corner of Fig. 10, in which a new communications protocol processing request 1002 with a segment size of 30 KB is enqueued. The sum of the segment size of the last enqueued communications protocol processing request 1001 and the segment size of communications protocol processing request 1002 is 60 KB. This is less than the maximum size of 64 KB that can be processed by the offload processing unit, so they are concatenated to become a new communications protocol processing request 1003 with a segment size of 60 KB. When the communications protocol processing requests are concatenated, the first and second management data information included in the communications protocol processing requests are concatenated and the number of segments is added.

[0100] <Summary> As described above, in the communication device 100 of this embodiment, the dynamic loading software 210 hooks the communication protocol processing by the OS kernel 201. When the communication protocol processing is hooked, the dynamic loading software 210 determines whether the processing queue 215 is empty and whether the offload processing unit 106 is in a standby state. If the processing queue 215 is empty and the offload processing unit 106 is in a standby state, the dynamic loading software 210 instructs the start of the offload processing 106 in the context of the hook processing. On the other hand, if the processing queue 215 is not empty or the offload processing unit 106 is not in a standby state, the dynamic loading software 210 enqueues a communication protocol processing request in the processing queue 215. When the communication protocol processing by the offload processing unit 106 is completed, the dynamic loading software 210 dequeues the communication protocol processing request from the processing queue and instructs the offload processing 106 to start in the context of a delayed processing started by an interrupt handler. Furthermore, in the delayed processing, the dynamic loading software 210 performs a transmission process for a group of packets for which communication protocol processing has been completed after the instruction to start the offload processing 106 was issued.

[0101] In this way, when communication protocol processing of transmission data is hooked in a situation where the offload processing unit cannot start communication protocol processing, the communication protocol processing request is enqueued in the processing waiting queue. This allows communication protocol processing to be realized without discarding the transmission data, and it is possible to reduce the overhead on upper software processing due to discarding the transmission data. Furthermore, when the offload processing unit completes communication protocol processing, it starts the offload processing unit based on the communication protocol processing request stored in the processing waiting queue before transmitting the packet group for which communication protocol processing has been completed. This increases the parallel processing efficiency of the CPU and the offload processing unit.

[0102] [Other embodiments] The present invention can also be realized by supplying a program that realizes one or more functions of the above-described embodiments to a system or device via a network or a storage medium, and having one or more processors in the computer of the system or device read and execute the program. It can also be realized by a circuit (e.g., ASIC) that realizes one or more functions.

[0103] The invention is not limited to the above-described embodiments, and various changes and modifications can be made without departing from the spirit and scope of the invention. Accordingly, the following claims are appended to apprise the public of the scope of the invention.

[0104] The disclosure of the above-described embodiment also includes the following configurations.

[0105] (Configuration 1) A communication device, a processing means for executing communication protocol processing by an OS kernel operating in the communication device in place of the OS kernel, the processing means performing a division process for dividing transmission data to be transmitted into segment data, and a header generation process for generating and attaching a header to each segment data divided by the division process; hooking means for hooking the communication protocol processing by the OS kernel; a storage means for storing a communication protocol processing request to the processing means in a processing queue; a transmitting means for transmitting a packet that has undergone the communication protocol processing corresponding to the communication protocol processing request stored in the processing queue by the processing means; A communication device comprising:

[0106] (Configuration 2) The communication device further comprises a control means; When the hooking means hooks the communication protocol processing by the OS kernel, the control means When the processing means is in a standby state, control is performed so that the processing means executes the communication protocol processing hooked by the hook means; When the processing means is not in a standby state, the storage means is controlled to store the communication protocol processing request corresponding to the communication protocol processing hooked by the hook means in the processing waiting queue. 2. The communication device according to configuration 1.

[0107] (Configuration 3) a detection means for detecting completion of the communication protocol processing by the processing means; and control means for controlling, when the detection means detects completion of the communication protocol processing by the processing means, if a communication protocol processing request is stored in the processing waiting queue, the processing means to execute the communication protocol processing corresponding to the communication protocol processing request. 3. The communication device according to configuration 1 or 2.

[0108] (Configuration 4) When the detection means detects the completion of the communication protocol processing by the processing means, the control means controls the transmission means to transmit the packet on which the processing means has performed the communication protocol processing. 4. The communication device according to configuration 3.

[0109] (Configuration 5) When the detection means detects the completion of the communication protocol processing by the processing means, if a communication protocol processing request is stored in the processing waiting queue, the control means controls the processing means to execute the communication protocol processing corresponding to the communication protocol processing request before the transmission means transmits the packet. 5. The communication device according to configuration 4.

[0110] (Configuration 6) The communication protocol processing request includes address information of the transmission data, address information of the segment data generated by the communication protocol processing, and TCP / IP header information. 6. The communication device according to any one of configurations 1 to 5.

[0111] (Configuration 7) 7. The communication device according to claim 1, wherein, when storing the communication protocol processing request in the processing waiting queue, if a communication protocol processing request is already stored in the processing waiting queue and the size of the transmission data in the communication protocol processing request stored in the processing waiting queue is less than the maximum data size that can be processed by the processing means, the storage means generates a new communication protocol processing request by concatenating data up to the maximum data size, and replaces the communication protocol processing request stored in the processing waiting queue with the new communication protocol processing request. [Explanation of symbols]

[0112] 100 Communication equipment 102 CPU 105 Communication Devices 106 Offload Processing Unit 201 OS kernel 202 Protocol Stack 210 Dynamically Loaded Software 212 Processing decision unit

Claims

1. A communication device, a processing means for executing communication protocol processing by an OS kernel operating in the communication device in place of the OS kernel, the processing means performing a division process for dividing transmission data to be transmitted into segment data, and a header generation process for generating and attaching a header to each segment data divided by the division process; hooking means for hooking the communication protocol processing by the OS kernel; a storage means for storing a communication protocol processing request to the processing means in a processing queue; a transmitting means for transmitting a packet that has undergone the communication protocol processing corresponding to the communication protocol processing request stored in the processing queue by the processing means; A communication device comprising:

2. The communication device further comprises a control means; When the hooking means hooks the communication protocol processing by the OS kernel, the control means When the processing means is in a standby state, control is performed so that the processing means executes the communication protocol processing hooked by the hook means; When the processing means is not in a standby state, the storage means is controlled to store the communication protocol processing request corresponding to the communication protocol processing hooked by the hook means in the processing waiting queue.

2. The communication device according to claim 1.

3. a detection means for detecting completion of the communication protocol processing by the processing means; and control means for controlling, when the detection means detects completion of the communication protocol processing by the processing means, if a communication protocol processing request is stored in the processing waiting queue, the processing means to execute the communication protocol processing corresponding to the communication protocol processing request.

2. The communication device according to claim 1.

4. When the detection means detects the completion of the communication protocol processing by the processing means, the control means controls the transmission means to transmit the packet that has undergone the communication protocol processing by the processing means.

4. The communication device according to claim 3.

5. When the detection means detects the completion of the communication protocol processing by the processing means, if a communication protocol processing request is stored in the processing waiting queue, the control means controls the processing means to execute the communication protocol processing corresponding to the communication protocol processing request before the transmission means transmits the packet.

5. The communication device according to claim 4.

6. The communication protocol processing request includes address information of the transmission data, address information of the segment data generated by the communication protocol processing, and TCP / IP header information.

6. The communication device according to claim 1, wherein the first and second inputs are connected to the first and second inputs.

7. 6. The communication device according to claim 1, wherein, when storing the communication protocol processing request in the processing waiting queue, if a communication protocol processing request is already stored in the processing waiting queue and the size of the transmission data in the communication protocol processing request stored in the processing waiting queue is less than the maximum data size that can be processed by the processing means, the storage means generates a new communication protocol processing request that is concatenated up to the maximum data size, and replaces the communication protocol processing request stored in the processing waiting queue with the new communication protocol processing request.

8. A control method for a communication device including a processing means that executes communication protocol processing by an OS kernel running in the communication device instead of the OS kernel, the processing means performing a division process of dividing transmission data to be transmitted into segment data, and a header generation process of generating and attaching a header to each segment data divided by the division process, a hooking step of hooking the communication protocol processing by the OS kernel; a storing step of storing a communication protocol processing request to the processing means in a processing waiting queue; a transmission step in which the processing means transmits a packet that has undergone the communication protocol processing corresponding to the communication protocol processing request stored in the processing queue; A control method for a communication device, comprising:

9. A program for causing a computer to execute each step of the method for controlling a communication device according to claim 8.

Images